이 디렉토리에는 특정 네트워크 문제를 추적할 때 tcpdump 데이터를 줄이는 방법의 예시로 사용되는 몇 가지 짧은 awk 프로그램도 포함되어 있습니다:

send-ack.awk
	ftp(또는 다른 단방향 TCP 전송)에 대한 tcpdump 추적을 단순화합니다. 한 호스트는 송신만 하고 다른 호스트는 ack만 보낸다고 가정하므로 모든 주소 정보는 생략하고 패킷이 "send"인지 "ack"인지만 기록합니다.

	원본 추적의 각 줄에 대해 한 줄의 출력이 생성됩니다.
	필드 1은 대화 시작을 기준으로 한 십진수 초 단위의 패킷 시간입니다. 필드 2는 이전 패킷과의 델타 시간입니다. 필드 3은 패킷 유형/방향입니다.
	"Send"는 송신자에서 수신자로 가는 데이터를 의미하고, "ack"는 수신자에서 송신자로 가는 ack를 의미합니다. 앞에 "*"가 있으면 데이터가 재전송임을 나타냅니다.
	앞에 "-"가 있으면 시퀀스 공간에 구멍(즉, 누락된 패킷)이 있음을 나타내고, "#"는 비정상적인 크기(최대 세그먼트 크기가 아님)의 패킷을 의미합니다. 필드 4에는 패킷 플래그가 있습니다(원시 추적과 동일한 형식). 필드 5는 시퀀스 번호입니다(송신자의 경우 시작 시퀀스 번호, ack의 경우 다음 예상 시퀀스 번호). ack 다음의 괄호 안 숫자는 패킷의 첫 번째 송신부터 ack까지의 델타 시간입니다. send 다음의 괄호 안 숫자는 패킷의 첫 번째 송신부터 현재 송신까지의 델타 시간입니다(중복 패킷에만 해당). 중복 send 또는 ack는 지금까지의 중복 횟수를 보여주는 대괄호 안의 숫자가 있습니다.

	다음은 ftp 시작 부분 근처의 짧은 예시입니다:
		3.00    0.20   send . 512
		3.20    0.20    ack . 1024  (0.20)
		3.20    0.00   send P 1024
		3.40    0.20    ack . 1536  (0.20)
		3.80    0.40 * send . 0  (3.80) [2]
		3.82    0.02 *  ack . 1536  (0.62) [2]
	대화 시작 후 3초 후에 바이트 512~1023이 전송되었습니다. 200ms 후에 ack되었습니다. 곧이어 바이트 1024-1535가 전송되었고 다시 200ms 후에 ack되었습니다. 그런 다음 명백한 이유 없이 0-511이 초기 전송 후 3.8초 후에 재전송되었습니다(이 ftp의 왕복 시간은 1초 +-500ms였습니다). 수신자는 1536을 기대하고 있으므로 0이 도착하면 1536이 다시 ack됩니다.

packetdat.awk
	ftp(또는 유사한 단방향 TCP 전송)에 대한 청크 요약 데이터를 계산합니다. ["청크"는 시퀀스 공간의 청크, 즉 패킷 시퀀스 번호를 최대 세그먼트 크기로 나눈 것을 나타냅니다.]

	청크 수, 그 많은 청크를 보내는 데 걸린 패킷 수(손실되거나 중복된 패킷이 없으면 패킷 수는 청크 수와 같아야 함), ack 수를 보여주는 요약 줄이 출력됩니다.

	요약 줄 다음에는 청크당 한 줄의 정보가 있습니다. 줄에는 8개의 필드가 포함됩니다:
	   1 - 청크 번호
	   2 - 이 청크의 시작 시퀀스 번호
	   3 - 첫 번째 전송 시간
	   4 - 마지막 전송 시간
	   5 - 첫 번째 ack 시간
	   6 - 마지막 ack 시간
	   7 - 청크가 전송된 횟수
	   8 - 청크가 ack된 횟수
	(모든 시간은 대화 시작을 기준으로 한 십진수 초 단위입니다.)

	예를 들어, ftp 추적의 첫 번째 부분 출력은 다음과 같습니다:

	# 134 chunks.  536 packets sent.  508 acks.
	1       1       0.00    5.80    0.20    0.20    4       1
	2       513     0.28    6.20    0.40    0.40    4       1
	3       1025    1.16    6.32    1.20    1.20    4       1
	4       1561    1.86    15.00   2.00    2.00    6       1
	5       2049    2.16    15.44   2.20    2.20    5       1
	6       2585    2.64    16.44   2.80    2.80    5       1
	7       3073    3.00    16.66   3.20    3.20    4       1
	8       3609    3.20    17.24   3.40    5.82    4       11
	9       4097    6.02    6.58    6.20    6.80    2       5

	이는 134개의 청크가 전송되었으며(평균 패킷 크기가 512바이트이므로 약 70KB), 데이터를 전송하는 데 536개의 패킷이 필요했음을 나타냅니다(즉, 평균적으로 각 청크가 4번 전송되었습니다). 예를 들어 청크 4를 보면 1561에서 2048까지의 512바이트 시퀀스 공간을 나타냄을 알 수 있습니다. 대화 시작 후 1.86초에 처음 전송되었습니다. 마지막 전송은 대화 시작 후 15초였으며 총 6번 전송되었습니다(즉, 평균 2초마다 재전송되었습니다). 한 번 ack되었으며, 처음 도착한 후 140ms 후에 ack되었습니다.

stime.awk
atime.awk
	각각 send 또는 ack당 한 줄씩 출력하며, 형식은 다음과 같습니다:
		<time> <seq. number>
	여기서 <time>은 전송 시작 이후의 시간(초)이고 <seq. number>는 전송되거나 ack된 시퀀스 번호입니다. 일반적으로 이 데이터를 플로팅하여 의심스러운 패턴을 찾습니다.


제가 조사하던 문제는 일반적인 DARPA 인터넷 조건에서 중간 지연 네트워크 경로(1-6초 왕복 시간)의 대량 데이터 전송 처리량이었습니다. 대용량 파일의 ftp 전송 추적을 원시 데이터 소스로 사용했습니다. 방법은 다음과 같습니다:

  - 로컬 호스트(tcpdump를 실행하는 Sun이 아닌)에서 원격 ftp에 연결합니다.

  - 모니터 Sun에서 추적을 시작합니다. 예를 들어:
      tcpdump host local-host and remote-host and port ftp-data >tracefile

  - 로컬에서 대용량 파일(~500KB)을 get 또는 put합니다. 가능하면 널 디바이스로 수행합니다(디스크 쓰기를 기다리는 동안 수신 창을 닫는 등의 영향을 최소화하기 위해).

  - 전송이 완료되면 tcpdump를 중지합니다. awk를 사용하여 두 개의 요약 데이터 파일을 만듭니다(maxsize는 최대 패킷 크기, tracedata는 tcpdump 추적 데이터 파일):
      awk -f send-ack.awk packetsize=avgsize tracedata >sa
      awk -f packetdat.awk packetsize=avgsize tracedata >pd

  - 요약 데이터 파일이 출력되는 동안 전송 동작을 살펴봅니다:
      awk -f stime.awk tracedata | xgraph
    (배우는 것의 90%는 이 단계에서 발생하는 것 같습니다).

  - 위의 모든 단계를 여러 번 수행합니다. 양방향으로, 하루 중 다른 시간에, 상대방의 다른 프로토콜 구현에서 수행합니다.

  - Unix 데이터 분석 패키지(제 경우 S와 Gary Perlman의 Unix|Stat) 중 하나를 사용하여 몇 달 동안 데이터를 분석합니다.

  - 로컬 프로토콜 구현에서 무언가를 변경하고 위 단계를 다시 수행합니다.

  - 일주일에 한 번, 연구 자금 제공자에게 멋진 것을 발견하고 있으며 연구 보고서를 "정말 곧" 작성할 것이라고 말합니다.