크로스플랫폼 패킷/트래픽 생성기 Ostinato 를 아시나요?

크로스플랫폼 기반의 네트워크 패킷생성 도구인 Ostinato 를 소개한다. 물론 오픈소스이며, 윈도우, 리눅스등 환경에서도 동작한다. 다양한 패킷을 생성할 수 있으며, 전송할 패킷에 대한 전송속도 및 프로토콜을 세부적으로 수정할 수 있다. 사용해보면, 처음에는 어떻게 해야 패킷을 전송할 수 있지 하고 의문을 가졌는데 잠깐만 사용해 보면 금방 익숙해 질 수 있다. 주요 기능은 아래와 같다:

- 윈도우, 리눅스, BSD, 맥 OS X 등에서 동작하는 크로스플랫폼 기반
- 다양한 표준 프로토콜 지원 및 세부적 수정 가능
- 패킷 전송방법 정의 가능
- 패킷 캡쳐 및 캡쳐 내용 뷰어 (단, 캡쳐된 패킷 보기 위해서는 와이어샤크 필요)
- 실시간 패킷 전송 비율 출력등

좀더 세부적인 내용 및 다운로드는 아래 사이트에서 가능하다.
http://code.google.com/p/ostinato/

이 도구를 이용한 패킷생성 도구 제품도 볼 수 있는데, 앞으로 계속 발전이 기대된다. 처음 0.1 버전은 2010년 4월에 공개되었으며, 개발기간은 길지가 않다. (하지만 이에 대한 기획은 2007년 부터 시작되었던것 같다) 일단 다운로드 받아 실행해 보면 크게 레이아웃은 4개 정도로 구분된다.

- 사용할 포트 인터페이스
- 생성할 패킷등을 정의하는 스트림
- 제어 아이콘
- 상태 정보

본인 컴퓨터에서 사용가능한 포트 인터페이스를 지정하고 스트림에서 오른쪽 마우스를 클릭하여 새로운 스트림을 생성한다. 여기서는 'test' 라는 이름으로 생성하였고, 아이콘을 더블 클릭하면 아래와 같은 화면을 볼 수 있다. 처음에는 패킷을 어디서 어떻게 정의해야 할지가 아리송했는데, 바로 이 부분이 정답이었다. 아직은 GUI 화면 구성등에 대한 아쉬움이 있다.

스트림 수정은 4가지 큰 탭으로 나뉘어져 있고, 클릭해 보면 알겠지만 세부적으로 수정이 가능하다.

생성할 패킷 정의가 끝났으면 메인 윈도우에서 Apply 를 하고 Statistics 화면에서 캡쳐를 시작하고, 전송 버튼을 누른다. 그리고, 생성한 패킷이 제대로 되었는지 보고 싶다면 돋보기 모양의 아이콘을 누르면 와이어샤크가 실행된다. 물론, 와이어샤크는 이미 설치되어 있어야 한다.

Ostinato 소개는 여기서 일단 끝내고, 사용방법이 더 궁금하다면 아래 참고 부분을 보기 바란다. 동영상도 있으니 한번 살펴보는 것만으로도 대충 사용방법을 익힐 수 있으리라 생각된다. 

지금까지 패킷인사이드에서 소개한 패킷생성 도구만으로도 여러분들이 하고 싶어하는 기능은 대부분 구현이 되어 있을것으로 생각한다. :-)

[참고]

1. QuickStart Guide

http://code.google.com/p/ostinato/wiki/UserGuide#Quickstart

오픈 네트워킹 파운데이션(Open Networking Foundation) 기구에 대해서....

오픈 네트워킹 파운데이션, 최근 이 기구에 대해서 기사를 통해서건 간접적으로라도 접해본적이 있는 분들이 있을 것이다. 올해 3월 말 경, 공식적으로 이 기구를 발족했는데, 전세계적으로 큰 네트워크를 운영중인 도이치 텔레콤, 페이스북, 구글, 마이크로소프트, 버라이즌, 야후가 참여하고 있다. 현재 초기 이 멤버들 이외 주요 네트워크 장비 업체, 가상화 업체 등 다양하게 참여하고 있다.


[이미지 출처: 오픈 네트워킹 파운데이션]

이 기구의 목적은 일단 Non-Profit 이며, SDN(Software-Defined Networking) 이라 불리는 새로운 네트워크 접근 방법을 찾아보고자 함이다. 과거의 네트워킹 형태와 달리 이제는 새롭게 변화될 필요가 있으며, SDN 을 통해 사업자는 고객들에게 좀더 최적화 된 네트워크 서비스를 제공할 수 있으며, 그들의 네트워크를 좀더 자유롭게 제어할 수 있게 된다고 한다. 일단 SDN 의 기본 컴포넌트중의 하나인 OpenFlow(www.openflow.org) 를 중점적으로 개발하고 있다.

SDN 이름에서 느껴지는 것과 같이 소프트웨어로 정의된 네트워킹은 오늘날 네트워크에 더욱 부합되는 것이 아닐까 한다. 휴대폰이 전통적인 제조산업을 넘어서 소프트웨어의 중요성이 부각되고 있는 만큼, 네트워킹 영역에서도 예외는 아니다. 공식적인 활동은 2011년 4월 1일 부터 시작되었다.

보드멤버를 포함해 초기 멤버들은 아래와 같다:

Broadcom, Brocade, Ciena, Cisco, Citrix, Dell, Deutsche Telekom, Ericsson, Facebook, Force10, Google, HP, IBM, Juniper Networks, Marvell, Microsoft, NEC, Netgear, NTT, Riverbed Technology, Verizon, VMware, and Yahoo!.

회사 이름을 보았을때, 한국 기업은 보이지 않는다. 항상 느끼는 것이지만, 이런 기구들에서의 한국 참여 비중이 작은게 개인적으로 아쉽다. 한국에 비해서 일본은 활동이 활발한것에 비하면 말이다. 일단 멤버로 참여하기 위해서는 년간 $30,000 을 지급해야 한다. 자세한 정보는 아래 사이트를 방문해 보면 된다.


http://www.opennetworkingfoundation.org/

네트워크에 관심있는 사용자라면 이런 기구가 있다는것 하나쯤은 알아두면 좋을것 같다.

2005년의 인터넷 모습은 어떠했을까? OPTE 프로젝트로 살펴본다.

2005년의 인터넷 모습은 어떨까? Opte 프로젝트에서 그 당시 인터넷을 모델링한 것이 있다.  첫 모델링한 이미지는 2003년 10월말 스캐닝을 통하여 얻은 데이터로 만들어 졌다.

좌측의 이미지는 2005년1월15일 모델링한 것이다. 각 색깔의 표시는 아래와 같다:

net, ca, us com, org mil, gov, edu
jp, cn, tw, au de, uk, it, pl, fr br, kr, nl unknown


해당 날짜 이후로는 업데이트 되지 않고 있으며, 그냥 참고용으로만 살펴보길 바란다.  찾아보면 유사한 프로젝트가 또 있겠지만, 검색하다 우연히 보게 된 프로젝트 여서 한번 공유해 보고자 하였다.


추가적인 정보를 얻기 위해서는 다음 사이트를 방문하면 된다:

http://opte.org/

리눅스 GUI 기반에 뿌리를 둔 패킷생성기 packETH, 하지만 윈도우도 OK

패킷생성기 하나를 소개한다. 이번에는 리눅스 GUI 기반의 생성기로 이름은 packETH 이다. 이더넷 패킷을 생성하고 전송할 수 있는 기본적인 기능과 몇가지 유용한 기능들이 포함되어 있다. 참고로, 윈도우에서도 사용가능하도록 포팅되어 있다.


다운로드는 다음의 경로에서 할 수 있다.

[리눅스]
http://packeth.sourceforge.net/
[윈도우]
http://eth.cyberine.com/

일단 기본적인 기능을 좀더 알아보면 아래와 같다:

- 다양한 프로토콜을 지원해 이더넷 패킷을 생성, 편집, 전송 할 수 있다.
- Ethernet II, Ethernet 802.3, 802.1q
- ARP, IPv4, IPv6, 사용자 정의 페이로드
- UDP, TCP,ICMP,IGMP, 사용자 정의 레이어 페이로드 등이다.
- 패킷 연속 전송 기능 (최대 속도, 패킷간 Delay, 전송할 패킷 수 등)

현재 2010년10월 업데이트가 최신이며 버전은 1.7 이다. 설명서는 충분치 않은데, 한번 사용해 보면 어느정도 감을 잡을 수 있다. 메인 화면은 아래와 같다.



메뉴 아이콘을 보면 Builder 가 보인다. 기본 생성 도구로서 여기는 각 레이어별 생성을 할 수 있도록 지원한다.
- 링크레이어
- 네트워크 레이어 (IPv4 or IPv6 데이터)
- 트랜스포트 레이어 (TCP, UDP or )

원하는 값을 지정하고, Send 버튼을 누르면 전송이 쉽게 된다. 그 다음 Gen-b 아이콘은 전송할 패킷 수, 패킷간 딜레이 등을 지정하여 대량으로 전송할 때 사용할 수 있다. Gen-s 는 다른데서는 못 보던 기능인데, 유용할 수도 있다고 본다. 패킷 파일을 여러개 지정하여 연속적으로 전송할 수 있는 기능이다. 각 패킷에 대해서 전송 개수, 딜레이, 전송속도를 조정할 수가 있다. Pcap 을 로드한 PCAP 데이터 리스트를 보고 선택할 수 있도록 해준다. Load 아이콘을 통해 읽어들일 PCAP 을 지정하면 Pcap 리스트에 나타난다. 여기서 더블클릭하여 선택하고, Builder 를 보면 해당 데이터를 볼 수 있다. 즉, 특정 패킷파일의 데이터를 Builder 에서 다시 재조정하여 보낼 수 있는 것이다.



리눅스 기반에서 패킷생성이 많은 사용자라면 이 도구가 도움이 될 것이다. 참고로 윈도우로 포팅된 것도 리눅스와 같은 형태의 UI 를 가지고 있다.

HTTP 프로토콜 테스트에는 WBox 로 간단히 해결해 보자!

인터넷을 사용하면서 많이 사용하는 프로토콜 중에 하나가 HTTP 이다. 패킷 분석을 하다 보면 많이 보는 프로토콜 종류 또한 HTTP 이다. 패킷분석과는 약간 거리가 있지만, HTTP 를 테스트 할 수 있는 도구를 공유해 보고자 한다. 일단 이름은 'WBox' 이고, 다음 경로에서 파일을 다운로드 받을 수 있다.

[소스파일]
http://www.hping.org/wbox/wbox-5.tar.gz
[윈도우 바이너리 파일]
http://www.hping.org/wbox/wbox-3.zip

윈도우에서도 사용할 수 있도록, 컴파일된 파일이 있으므로 윈도우 사용자도 쉽게 사용해볼 수 있다. cygwin 환경에서 컴파일 된 것이므로 압축을 풀어보면 wbox.exe 와 cygwin1.dll 파일이 있으며, 이 dll 파일이 함께 있어야 한다.

WBox 로 할 수 있는 것들은 HTTP 와 관련된 것들로,
- 웹 페이지를 다운로드 받는데 걸리는 시간 테스트
- 웹서버, 웹 애플리케이션 스트레스 테스트
- 이외 헤더보기, HTTP compression 동작 테스트, HTTP/1.0 요청등의 기능이 가능하다.

사용해보면 얼핏 ping 과도 비슷한 형태로 출력된다. 그만큼 사용법도 아주 쉽다.

C:\PlayGround\wbox>wbox www.packetinside.com
WBOX www.packetinside.com (72.14.203.121) port 80
0. 200 OK    146460 bytes    1017 ms
1. 200 OK    (146408) bytes    792 ms
2. 200 OK    146408 bytes    586 ms
3. 200 OK    146408 bytes    751 ms
4. 200 OK    146408 bytes    802 ms
 user terminated

출력되는 결과를 보면 맨 앞 숫자는 요청하는 숫자가 차례대로 증가하는 것이며, 그 다음은 HTTP 응답코드 (200 번은 OK 라는 뜻) 그리고 서버로 부터 전송받은 데이터 사이즈 그리고 마지막은 요청을 처리하기 까지 걸린 시간이다. 기본적으로 요청할 개수를 지정하지 않으면 계속 반복된다. 아래와 같이 맨 뒤에 숫자를 붙여 주면 지정한 숫자만큼만 동작한다.

C:\PlayGround\wbox>wbox www.packetinside.com 2
WBOX www.packetinside.com (72.14.203.121) port 80
0. 200 OK    146408 bytes    707 ms
1. 200 OK    146408 bytes    752 ms

timesplit 옵션은 웹 페이지에서 받아오는 각 파트를 단위별로 소요된 시간을 보여준다.

C:\PlayGround\wbox>wbox www.packetinside.com timesplit 1
WBOX www.packetinside.com (72.14.203.121) port 80
0. 200 OK    146408 bytes    661 ms
       [0] 0-4095 -> 329 ms
       [1] 4096-8191 -> 2 ms
       [2] 8192-12287 -> 1 ms
       [3] 12288-16383 -> 63 ms
       [4] 16384-20479 -> 2 ms
       [5] 20480-24575 -> 1 ms
       [6] 24576-28671 -> 1 ms
       [7] 28672-32767 -> 62 ms
       [8] 32768-36863 -> 2 ms
       [9] 36864-40959 -> 1 ms
       [10] 40960-45055 -> 1 ms
       [11] 45056-49151 -> 1 ms
       [12] 49152-53247 -> 23 ms
       [13] 53248-57343 -> 38 ms
       [14] 57344-61439 -> 2 ms
       [15] 61440-65535 -> 1 ms
       [16] 65536-69631 -> 1 ms
       [17] 69632-73727 -> 1 ms
       [18] 73728-77823 -> 1 ms
       [19] 77824-81919 -> 1 ms
       [20] 81920-86015 -> 1 ms
       [21] 86016-90111 -> 58 ms
       [22] 90112-94207 -> 3 ms
       [23] 94208-98303 -> 1 ms
       [24] 98304-102399 -> 1 ms
       [25] 102400-106495 -> 1 ms
       [26] 106496-110591 -> 1 ms
       [27] 110592-114687 -> 1 ms
       [28] 114688-118783 -> 1 ms
       [29] 118784-122879 -> 1 ms
       [30] 122880-126975 -> 1 ms
       [31] 126976-131071 -> 1 ms
       [32] 131072-135167 -> 0 ms
       [33] 135168-139263 -> 1 ms
       [34] 139264-143359 -> 53 ms
       [35] 143360-146407 -> 1 ms

showhdr 옵션은 HTTP 요청후 전달받은 응답 헤더를 보여주게 된다. 또는 showhdr 대신, dump 옵션을 사용하면 받아오는 데이터를 그대로 출력해 준다. 즉, 헤더뿐만 아니라 모두 다 보여주게 되는 것이다.

C:\PlayGround\wbox>wbox www.packetinside.com showhdr
WBOX www.packetinside.com (72.14.203.121) port 80

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Expires: Thu, 11 Aug 2011 13:23:00 GMT
Date: Thu, 11 Aug 2011 13:23:00 GMT
Cache-Control: private, max-age=0
Last-Modified: Thu, 11 Aug 2011 13:03:48 GMT
ETag: "3f24bea2-148f-45bf-96c3-8638f8ffa6b3"
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Server: GSE
Connection: close

웹 서버 스트레스 테스트도 해 볼 수 있는데, clients 라는 옵션을 사용하면 된다.

C:\PlayGround\wbox>wbox www.packetinside.com clients 1
WBOX www.packetinside.com (72.14.203.121) port 80
0. 200 OK    146408 bytes    676 ms
1. 200 OK    146408 bytes    713 ms
2. 200 OK    146408 bytes    644 ms
 user terminated

clients 뒤에 붙은 옵션은 동시접속으로 지정할 클라이언트 개수이다. 이 숫자가 높으면 높을 수록 그만큼 크게 요청이 되는 것이다. 테스트에서는 그냥 1로만 지정하였다. 테스트를 하는 분들이라면 위 예제대로 패킷인사이드에 대량의 스트레스 테스트를 하는 실수를 범하지 않기를 바란다 ^^

이외 compr 은 HTTP 압축 방식을 지원하는지 테스트를 하는 것이며, http10 은 HTTP/1.1 대신 1.0 으로 요청한다.

C:\PlayGround\wbox>wbox www.packetinside.com compr
WBOX www.packetinside.com (72.14.203.121) port 80 [compr]
0. 200 OK    30889 bytes    483 ms    compr
1. 200 OK    30889 bytes    477 ms    compr
 user terminated

마지막으로 간단하면서도 유용한 기능이 있는데, 서버모드로 동작하는 것이다. WBox 를 이용해 HTTP 서버로 간단히 동작할 수 있도록 하여, 급하게 파일 공유나 간단한 테스트로 유용하게 사용할 수 있다.
예를 들어, 아래 예제는 서버모드로 동작시키는 것으로 webroot 옵션을 통해 문서 루트가 될 곳을 지정한다. 이후 브라우저로 http://localhost:8081 와 같이 접속하면 디렉토리 리스트를 볼 수 있다.

C:\PlayGround\wbox>wbox servermode webroot c:\PlayGround
WBOX starting in server mode, port 8081, webroot c:\PlayGround
127.0.0.1:50802 connected
127.0.0.1:50802 handled by process 1980
127.0.0.1:50802 served with success
127.0.0.1:50803 connected
127.0.0.1:50803 handled by process 2440
127.0.0.1:50803 served with success
127.0.0.1:50804 connected
127.0.0.1:50804 handled by process 2344
127.0.0.1:50804 served with success
127.0.0.1:50807 connected
127.0.0.1:50807 handled by process 1748

0. 200 OK    146408 bytes    640 ms
 user terminated

HTTP 서버를 설치하기는 귀챦고, 급하게 HTTP 서버로 동작시켜 잠깐 테스트 하는 경우는 유용할 것이다. HTTP 테스트에 간단하면서도 유용한 WBox 가 도움이 되기를 바라며 마무리 한다.

P.S 아직까지 많이 알려져 있는 도구인 hping 을 소개하지 못하고 있다. 많은 기능이 있어, 이전부터 소개하려고 하였던 도구이며 조만간 hping 에 대해서도 여러분들에게 소개하도록 하겠다.

[참고]
1. WBox
http://www.hping.org/wbox/

Ethereal 과 궁합이 맞는 오픈소스 패킷분석기 Packetzyer

오픈소스 패킷 분석 도구인 Packetyzer 를 소개한다. 사실 이 도구는 더 이상 업데이트가 되고 있지 않지만, 나름 깔끔한 인터페이스로 어느정도 사용하기에는 충분한것 같다. 내가 지금까지 많은 패킷 도구들을 소개해 오고 있지만, 아직도 소개할 패킷도구들이 너무나 많이 남아 있다. 자기한테 적당한 도구를 선택하는 것은 여러분들의 몫이므로, 이런것이 있다는 것만 알아두자.

일단 현재 5.0 버전이며, 이더리얼 0.99.00 과 winpcap 3.1 이 포함되어 있다. 이더리얼의 기능을 이용해 구현된 것이라 볼 수 있다. 현재 와이어샤크로 불리기 이전 버전인 이더리얼 이므로 기능적으로는 와이어샤크에 비하면 못 할 수 잇겠으나 처음 패킷 분석을 접하는 윈도우 사용자에게는 쉬운 인터페이스와 윈도우적인 느낌으로 더 쉽게 다가설 수 있지 않나 싶다.
(참고로, 현재 이더리얼은 와이어샤크로 계속 개발되고 있으며, Ethereal 자체는 개발이 중지된 상태이다)

프로그램은 다음 경로에서 다운로드 받아 설치하면 된다. 윈도우 기반이라 따로 설치하는데 어려움은 없다.

http://www.gotomanage.com/open_source_tools/packetyzer_thankyou

실행하고, 캡쳐를 시작하면 다음과 같은 형태의 화면을 볼 수 있다:

처음 사용하는 사용자라도 몇번 클릭해 보면 어렵지 않게 사용할 수 있으며, 과거 이더리얼이 가지고 있던 기능들을 포함하고 있다. 출력 필터, 캡쳐 필터, 다양한 프로토콜 분석 기능등이 이에 해당한다. 이 프로그램이 또 다른 특징은 패킷 수정/보내기 기능이 있다. Session 메뉴에 Send Packet... 기능이 있는데, 각 헤더를 수정하여, 전송하는 기능을 가지고 있다.

윈도우 기반의 패킷분석기에 관심 있다면, Packetyzer 소스를 살펴보는 것도 도움이 될 것이다.


[참고]
1. Packetyer
http://www.gotomanage.com/open_source_tools/packetyzer
2. Packetyer 소스파일 받을 수 있는 곳
http://sourceforge.net/projects/packetyzer/

오픈에듀케이션과 지식혁명 '웹으로 배운다' 책을 소개한다.

오늘은 책을 한권 소개해 볼까 한다. 책 제목은 '웹(Web)으로 배운다' 이다. 아래 이미지와 같이 표지는 이러며, 책 내용은 웹으로 배우는 오픈 에듀케이션과 지식혁명에 대한 이야기 이다.

사실 필자가 추천사를 쓴 책이기도 하다. 

책을 처음 보았을때, 내가 오래전부터 생각해 오던 내용들이 있었기 때문에 추천사를 쓸 수 있었는데 배움의 욕망이 있는 분들에게는 도움이 되지 않을까 생각한다.

좋아 하는 단어중의 하나가 바로 '오픈(Open)' 이다. 누구에게나 열려 있는 이 오픈은 말 그대로 책에서는 오픈 테크놀로지, 오픈 콘텐츠, 오픈 놀리지 등으로 표현하고 있다. 누구에게나 공개되어 있는 정보, 그리고 계속 가속화되는 정보공유에 대한 이야기등이 나온다. 광고아닌 광고가 되었지만, 오픈이라는 단어와 그리고 배움의 열망에 관심이 있다면 추천해 보고 싶다.

From Rigel

*NIX 명령어 옵션 하나의 큰 차이 그리고 잊고 지냈던 옵션들...

여러분들이 항상 사용하는 명령어들에는, 각자 사용하는 스타일이 분명 하나씩 있다.
그것이 의식적이든 의식적이지 않던, 나도 모르게 오랜 세월동안 자주 사용하는 명령어 스타일 말이다. 예를들어, ls 명령어를 사용한다고 했을때 어떤 사람들은 그냥 ls 를 치기도 하지만, 또 다른 사람은 ls -l 또는 ls -al 등으로 다양하게 있을 것이다.

항상 익숙하게 사용하던 이 명령어 옵션도 알고 보면 시간이 지나면서 새로운 기능들이 추가되거나 또는 이미 있지만 모르고 사용하지 못했던 것들도 있다. 항상 많이 쓰는 명령어 이면서도 사용하던 옵션만 주로 사용하는 경우가 많다. 알고보면 좋은 기능이 숨어 있음에도 불구하고 말이다.

최근에는 가끔 항상 사용하던 명령어라도 한번씩은 man 페이지 또는 --help 옵션으로 무엇이 있는지 살펴본다. 그러다 아, 이런 것들이 있었네 하는 것이 있다. 너무 익숙한 명령어 이다 보니 오히려 모르고 지나치는 것이다. 예를 들어, grep 명령어는 단순히 문자열을 찾기 위해서 사용했는데, 때로는 탐지한 문자열 패턴 위, 아래 영역을 더 보고 싶을때가 있다. 이때는  -A, -B 옵션이 유용하다. -A 는 after, -B 는 before 뜻으로 탐지된 패턴의 앞뒤로 얼마 라인만큼 더 볼지 지정할 수 있는 것이다. 항상 그렇게 많이 사용하는 명령어 이면서 미처 모르고 지나쳤던 것이다.

또, netstat 는 주로 -na, -nr 만 주로 사용했는데, -p 는 해당 소켓을 사용하고 있는 프로세스를 알려준다.   다른 예로, 속도 차이를 가져오는 경우의 Case 도 있다.  한 디렉토리 안에 파일이 약 9만 4천개가 있었다. 여기서 파일 이름중에 FAIL 이라는 것이 있는 것을 찾기 위해 ls 를 사용하였다.

# time ls -1 | grep FAIL | wc -l
1428

real 0m3.337s
user 0m0.980s
sys 0m0.608s

# time ls -l | grep FAIL | wc -l
1428

real 0m39.320s
user 0m2.076s
sys 0m7.472s

위 차이를 보면 3초와 39 초로 차이가 크게 나타난다. 얼핏보면 비슷해 보이는 명령어 옵션인데 말이다. 한개는 숫자 1 을 사용한 것이고 다른 하나는 많이 사용하는 영문 l 을 사용한 것이다. 숫자 1은 파일이름만 출력하지만, 영문 l 은 파일소유주,날짜 등 좀더 많은 정보를 보여준다. 그래서 이렇게 파일이 많이 있는 경우에는 리스트 출력할때 차이가 발생하는 것이다. 사용하는 목적에 따라 다르지만, 조금만 생각해 보면 다른 결과를 가져오는 것이다.

항상 내가 똑같이 사용하던 방식에 너무 익숙해져 있다면, 한번 이런 명령어들을 다시 돌아보는 것도 좋을것 같다. 여러분이 사용하던 쉘 스크립트, 명령어들이 정말 최선의 선택인지. :-)

From Rigel.