IPsec 터널을 지나는 G.729 패킷 하나 세기

IPsec 위의 음성은 코덱 비트레이트로 인용되는데, 그 수치는 코덱 자체의 경계를 빼면 모든 경계에서 틀렸다. 오디오는 8 kbit/s이고, 그것을 나르는 패킷은 더 크고, ESP 외피는 더 크며, 이더넷 프레임은 터널 위의 캡처에는 결코 나타나지 않는 프레이밍을 더한다. 정해진 형식에서 패킷 하나를 세는 것이 물리 링크가 실제로 무엇을 날라야 하는지 아는 유일한 방법이다. 아래의 설명은 한 방향에 대해서만 그것을 하며, 여기 있는 모든 수는 측정이 아니라 산술이다.

코덱 수치가 아니라 패킷화 선택에서 시작하라

코덱 표는 페이로드 비율만 주고 그 밖에는 아무것도 주지 않는다. G.729는 8 kbit/s를 내보내며, 그것은 30 ms마다 30바이트의 오디오다. 헤더, 보호, 프레이밍에 대해서는 아무 말도 하지 않으며, 결과를 지배하는 것은 이 셋이다. 간격은 양쪽 끝이 합의해야 하는 정책 선택이므로 먼저 고르고 밝혀 두어야 한다. 이후의 모든 수가 그 하나의 결정에 달려 있기 때문이다.

이 예시는 30 ms를 사용하므로 패킷 비율은 초당 33.3이다. 12바이트 RTP 헤더, 8바이트 UDP 헤더, 옵션이 없는 20바이트 내부 IPv4 헤더를 가정하고, SRTP, 헤더 압축, 트래픽 흐름 기밀성 패딩은 없다고 본다. 무엇이든 바뀌면 예산도 함께 움직이므로 가정은 답 옆에 두어야 한다.

내부 헤더를 더하고, 그다음 ESP 외피를 더한다

응용 프로그램은 페이로드에 RTP, UDP, IP를 더해 보내며, 이 패킷화에서는 70바이트가 된다. 이 내부 흐름은 18.7 kbit/s가 되는데, 이미 코덱 비율의 두 배가 넘는다. 패킷의 대부분을 차지하는 것이 음성이 아니라 헤더이기 때문이다. 그 바이트 중 어느 것도 목소리가 아니며, 주소 지정과 순서 부여의 값이다. 터널 위에서 뜬 캡처는 정확히 이 수를 보여 주며, 통화가 작다고 말할 때 사람들이 인용하는 수가 이것이다.

이것은 케이블에 결코 닿지 않는 수이기도 하다. ESP 터널 모드는 8바이트 SPI와 시퀀스 번호, AES-GCM을 위한 8바이트 명시적 IV, 2바이트 트레일러, 16바이트 인증 태그를 더한다. 70바이트 페이로드에 트레일러를 더하면 72가 되고, 이는 네 바이트 정렬을 이미 만족하므로 여기서는 추가 패딩이 필요 없다.RFC 4106 은 GCM IV와 태그의 크기를 정하며, 둘 다 각주가 아니라 산술에 들어간다:

30  payload, G.729 at 30 ms
12  RTP
 8  UDP
20  inner IPv4
--
70  inner IP packet
 8  ESP SPI and sequence
 8  explicit IV
 2  pad length and next header
16  authentication tag
--
104 ESP packet

NAT 통과가 요구하는 바깥 헤더를 더한다

ESP 외피 밖에는 20바이트 바깥 IPv4 헤더와 NAT 통과를 위한 8바이트 UDP 헤더가 있어 패킷은 132바이트가 된다. UDP 캡슐화가 있는 이유는 패킷이 두 피어 사이의 변환 장치를 견뎌야 하기 때문이며, 보호된 페이로드를 건드리지 않고 바깥 모양을 바꾼다. 초당 33.3 패킷에서 132바이트는 약 35.2 kbit/s이며, 코덱의 공칭 비율의 약 네 배다.

태그도 IV도 추정을 작게 만들기 위해 빼놓을 수 없다. 둘 다 링크가 실제로 나를 것의 일부이기 때문이다. 그것들을 생략한 추정은 수신자가 거부할 패킷을 서술한다. 보호 영역 안에서 페이로드 경계와 다음 헤더를 표시하기 위해 존재하는 트레일러도 마찬가지다.

수를 인용하기 전에 경계를 이름 붙여라

바깥 IP 수는 여전히 이더넷 프레이밍을 제외한다. 태그가 있든 없든 액세스 링크는 14바이트 MAC 헤더와 4바이트 프레임 검사 시퀀스를 더해 프레임을 150바이트로 만들며, 이것이 스위치 포트가 세는 크기다. 같은 패킷 비율에서 그것은 40 kbit/s, 코덱 비율의 다섯 배이며, 그 차이는 낭비가 아니라 운반의 값이다.

40 kbit/s라는 수는 프리앰블, 프레임 간 간격, VLAN 태그, 사업자 캡슐화, RTCP, 신호, 그리고 반대 방향으로 가는 음성을 여전히 제외한다. 이것은 방향별 추정이지 링크 예약이 아니며, 예약으로 인용하면 링크가 한곳에서 확보해야 할 양을 과장하고 다른 곳에서는 축소한다. 호스트의 캡처는 링크가 더하는 프레이밍을 놓칠 수도 있으므로 수 옆에 경계를 이름 붙여야 하며, 그래서 경계 표가 하나의 표제 수보다 유용하다. 세지 않은 방향에 대해서는 따로 확보하라.

산술을 인터페이스와 대조하라

추정을 믿기 전에 알려진 패킷 수에 대해 인터페이스가 보고하는 값과 비교하라. 터널 장치가 아니라 물리 인터페이스에서 캡처하여, 계산하려는 프레이밍이 포함되게 하고, 완벽한 일치가 아니라 작은 차이를 기대하라.

sudo tcpdump -ni eth0 -c 50 'udp port 4500'
ip -s link show eth0

캡처는 바깥 패킷 크기를 확인해 주고, 인터페이스 카운터는 프레이밍을 포함한 비율을 보여 준다. 둘이 대략 이더넷 허용량만큼 다르면 산술은 맞고 경계의 이름만 잘못 붙은 것이다. 프레임 헤더 하나보다 훨씬 큰 차이는 링크의 다른 무언가, 예컨대 재전송이나 인터페이스를 공유하는 다른 흐름을 가리킨다. 패킷화 간격, 보호 모음, 경계를 수 옆에 적어라. 이 셋이 없는 추정은 다음 사람이 측정으로 인용한다.