Порахувати один пакет 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, арифметика правильна і лише межу названо неправильно. Розходження, значно більше за один заголовок кадру, вказує на щось інше в каналі, наприклад на повторні передачі або інший потік, що ділить інтерфейс. Запишіть інтервал пакетизації, набір захисту і межу поруч із числом, бо оцінку без цих трьох наступний читач цитує як вимірювання.