요약

  • 1995년 RFC 1761은 Sun이 만든 Snoop Version 2 패킷 캡처 파일의 구조를 공개해 수집과 나중 분석을 서로 다른 프로그램에서 할 수 있게 했다.
  • 원래 패킷 길이와 실제 저장 길이는 별도다. 누적 손실 값이 0이어도 수집 프로그램이 손실을 셀 수 없어서 그렇게 기록했을 수 있다.

패킷을 모아 둔 파일은 회의실에서 묘한 권위를 얻는다. 기억은 엇갈려도 바이트는 남아 있으니까. 그런데 바이트가 남아 있다는 사실과 필요한 바이트가 모두 남아 있다는 사실은 다르다. Brent Callaghan과 Robert Gilligan은 1995년 2월 RFC 1761에서 Sun의 Snoop 파일 형식을 설명했다. 목적은 분명했다. 다른 프로그램도 그 파일을 만들고 해석하게 하자는 것이었다. 설명서를 읽다 보면 정돈된 기록이 얼마나 솔직하게 자신의 빈틈을 드러내는지도 보인다.

파일은 16옥텟짜리 머리말로 시작한다. 처음 여덟 옥텟은 소문자 snoop 뒤에 널 옥텟 셋을 붙인 식별 표시다. 다음 넷은 버전 2, 마지막 넷은 링크 계층 유형이다. Ethernet은 코드 4, IEEE 802.3은 코드 0이다. 왜 이런 차이를 챙겨야 할까. 각 패킷의 저장 데이터가 링크 계층 머리말부터 시작하기 때문이다. 여기서 유형을 잘못 읽으면 뒤따르는 프로토콜 해석도 다른 출발선에 서게 된다. Token Ring, HDLC, FDDI도 목록에 있다. 정수는 모두 상위 바이트를 먼저 저장한다.

머리말 뒤에는 길이가 제각각인 패킷 기록이 이어진다. 각 기록 앞의 설명 영역은 32비트 정수 여섯 개, 곧 24옥텟이다. 첫째는 네트워크에서 받은 패킷의 원래 길이, 둘째는 파일에 실제로 넣은 포함 길이다. 포함 길이가 더 짧으면 수집 과정에서 패킷을 잘랐다는 뜻이다. 화면에 보이는 첫 부분이 선명하다고 해서 저장되지 않은 끝부분까지 본 셈은 아니다. 이 두 수치는 파일 속 빈자리를 가리키는 첫 번째 영수증이다.

셋째 수치는 기록 전체 길이다. 앞의 24옥텟, 저장된 패킷 데이터, 필요하면 정렬용 채움 바이트까지 포함한다. 다음 패킷 기록을 찾을 때 이 길이를 써야 한다. 포함 길이와 전체 길이를 뒤섞으면 채움 바이트를 트래픽으로 읽거나 다음 기록의 시작을 놓칠 수 있다. RFC가 바이트 순서와 기록 경계를 세세히 적은 까닭도 여기에 있다. 호환성은 프로그램들이 같은 파일 이름을 알아보는 수준에서 끝나지 않는다.

넷째는 누적 손실이다. 첫 기록부터 지금 기록까지 수집 시스템이 놓친 패킷을 센다. 가장 위험한 숫자는 큰 수가 아니라 0일 때가 있다. RFC는 일부 구현이 손실을 셀 능력이 없어도 이 칸을 0으로 둘 수 있다고 명시한다. 따라서 0은 측정 결과일 수도, 계측 불능의 단정한 표정일 수도 있다. 수집 장치의 손실 값으로 애플리케이션의 수신 성공까지 판단하는 것도 범위를 벗어난다.

마지막 두 수치는 1970년 1월 1일부터 지난 초와 마이크로초 단위의 도착 시각이다. 저장된 패킷을 시간순으로 놓는 데 쓸 수 있다. 실제 서비스 장애의 원인이나 상대편에서 벌어진 일은 다른 기록을 대조해야 한다. RFC 1761은 파일을 기계 사이로 옮겨 분석하게 만들었다. 더 귀중한 점은, 잘 읽으면 그 파일이 놓친 것에 대해 함부로 대신 말하지 않게 해 준다는 사실이다.