Преброяване на един пакет G.729 през тунел IPsec
Разработен пример с G.729 показва как се натрупват полезният товар, RTP, ESP и кадрирането на Ethernet и защо същото повикване струва различна честотна лента на всяка граница.
Гласът през 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, пет пъти скоростта на кодека, и разликата не е разхищение, а цената на преноса.
| Boundary | Packet size | Rate at 33.3 packets/s | What it counts |
|---|---|---|---|
| Codec payload | 30 bytes | 8.0 kbit/s | The audio alone |
| Inner IP packet | 70 bytes | 18.7 kbit/s | Application headers included |
| Outer IP packet | 132 bytes | 35.2 kbit/s | ESP and NAT-T included |
| Ethernet frame | 150 bytes | 40.0 kbit/s | Link framing included |
Цифрата 40 kbit/s все още изключва преамбюла, междукадровия интервал, VLAN етикетите, инкапсулацията на доставчика, RTCP, сигнализацията и аудиото, пътуващо в другата посока. Това е оценка за една посока, а не резервация на връзката, и цитирането ѝ като такава надценява това, което връзката трябва да резервира на едно място, и го подценява на друго. Заснемане на хоста също може да пропусне кадриране, което връзката добавя, затова границата трябва да се наименува заедно с цифрата, и затова таблицата с граници е по-полезна от една основна цифра. Резервирайте отделно за посоката, която не сте преброили.
Проверете аритметиката срещу интерфейса
Преди да се доверите на оценката, сравнете я с това, което интерфейсът отчита за известен брой пакети. Заснемайте на физическия интерфейс, а не на устройството на тунела, така че кадрирането, което се опитвате да отчетете, да е включено, и очаквайте малко разминаване, а не идеално съвпадение.
sudo tcpdump -ni eth0 -c 50 'udp port 4500'
ip -s link show eth0Заснемането потвърждава външния размер на пакета, докато броячите на интерфейса показват скоростта с включено кадриране. Ако двете се различават с около допустимото за Ethernet, аритметиката е вярна и само границата е била обозначена погрешно. Разлика, много по-голяма от една заглавка на кадър, сочи към нещо друго на връзката, например повторни предавания или друг поток, споделящ интерфейса. Запишете интервала на пакетизация, набора за защита и границата до цифрата, защото оценка без тези три се цитира като измерване от следващия, който я прочете.