Посчитать один пакет G.729 через туннель IPsec

Голос через IPsec указывают как битрейт кодека, и это число неверно на каждой границе, кроме границы самого кодека. Аудио — 8 kbit/s, пакет, который его несёт, больше, конверт ESP ещё больше, а кадр Ethernet добавляет кадрирование, которого не покажет ни один захват на туннеле. Подсчёт одного пакета из заданного формата — единственный способ узнать, что физический канал действительно должен нести. Разбор ниже делает это только для одного направления, и каждое число здесь — арифметика, а не измерение.

Начните с выбора пакетизации, а не с числа кодека

Таблица кодека даёт скорость полезной нагрузки и ничего больше: G.729 выдаёт 8 kbit/s, то есть 30 байт аудио каждые 30 ms. Она ничего не говорит о заголовках, защите или кадрировании, и именно эти три определяют результат. Интервал — это политический выбор, о котором должны договориться обе стороны, поэтому выберите его первым и укажите, потому что каждое последующее число зависит от этого одного решения.

В этом примере используется 30 ms, поэтому частота пакетов — 33.3 в секунду. Предполагается заголовок RTP в 12 байт, заголовок UDP в 8 байт и внутренний заголовок IPv4 в 20 байт без опций, а также отсутствие SRTP, сжатия заголовков и заполнения конфиденциальности потока трафика; любое изменение сдвигает и бюджет, поэтому допущения стоят рядом с ответом.

Добавьте внутренние заголовки, затем конверт ESP

Приложение отправляет полезную нагрузку плюс RTP плюс UDP плюс IP, что при такой пакетизации составляет 70 байт. Этот внутренний поток даёт 18.7 kbit/s, уже более чем вдвое превышая скорость кодека, потому что большую часть пакета составляют заголовки, а не аудио. Ни один из этих байт не является голосом; они — цена адресации и упорядочивания. Захват, сделанный над туннелем, показывает именно это число, и его цитируют, когда говорят, что вызов небольшой.

Это ещё и число, которое никогда не доходит до провода. Режим туннеля ESP добавляет 8-байтовый SPI и номер последовательности, 8-байтовый явный IV для AES-GCM, 2-байтовый трейлер и 16-байтовый тег аутентификации. Нагрузка в 70 байт плюс трейлер даёт 72, что уже удовлетворяет выравниванию по четыре байта, поэтому дополнительное заполнение здесь не нужно.RFC 4106 фиксирует размеры IV и тега GCM, и оба входят в арифметику, а не в сноску:

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 стоят внешний заголовок IPv4 в 20 байт и заголовок UDP в 8 байт для прохождения NAT, поэтому пакет становится 132 байта. Инкапсуляция UDP существует потому, что пакет должен пережить устройство трансляции между партнёрами, и она меняет внешнюю форму, не касаясь защищённой нагрузки. При 33.3 пакета в секунду 132 байта — это около 35.2 kbit/s, или примерно вчетверо больше номинальной скорости кодека.

Ни тег, ни IV нельзя выбросить из оценки, чтобы уменьшить её, потому что оба входят в то, что канал действительно понесёт. Оценка, которая их опускает, описывает пакет, который получатель отверг бы. То же относится к трейлеру, который существует, чтобы обозначить границу нагрузки и следующий заголовок внутри защищённой области.

Назовите границу, прежде чем цитировать число

Число внешнего IP всё ещё исключает кадрирование Ethernet. Канал доступа с тегом или без него добавляет заголовок MAC в 14 байт и контрольную последовательность кадра в 4 байта, делая кадр 150 байт, а это размер, который считает порт коммутатора. При той же частоте пакетов это 40 kbit/s, впятеро больше скорости кодека, и разница — не расточительство, а цена переноса.

Число 40 kbit/s всё ещё исключает преамбулу, межкадровый интервал, теги VLAN, инкапсуляцию провайдера, RTCP, сигнализацию и аудио, идущее в обратную сторону. Это оценка на одно направление, а не резервирование канала, и цитирование её как резервирования завышает то, что канал должен зарезервировать в одном месте, и занижает в другом. Захват на хосте тоже может пропустить кадрирование, которое добавляет канал, поэтому границу нужно называть рядом с числом, и поэтому таблица границ полезнее одной заголовочной цифры. Резервируйте отдельно для направления, которое вы не считали.

Сверьте арифметику с интерфейсом

Прежде чем доверять оценке, сравните её с тем, что интерфейс сообщает для известного числа пакетов. Делайте захват на физическом интерфейсе, а не на устройстве туннеля, чтобы кадрирование, которое вы пытаетесь учесть, было включено, и ожидайте небольшого расхождения, а не точного совпадения.

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

Захват подтверждает внешний размер пакета, а счётчики интерфейса показывают скорость с учётом кадрирования. Если они расходятся примерно на допуск Ethernet, арифметика верна и неверно названа только граница. Расхождение, намного большее одного заголовка кадра, указывает на что-то другое в канале, например на повторные передачи или другой поток, делящий интерфейс. Запишите интервал пакетизации, набор защиты и границу рядом с числом, потому что оценку без этих трёх следующий читатель цитирует как измерение.