Policzyć jeden pakiet G.729 przez tunel IPsec

Głos przez IPsec podaje się jako bitrate kodeka, a ta liczba jest błędna na każdej granicy poza granicą samego kodeka. Audio to 8 kbit/s, pakiet, który je niesie, jest większy, otoczka ESP jeszcze większa, a ramka Ethernet dodaje ramkowanie, którego żaden zrzut na tunelu nie pokazuje. Policzenie jednego pakietu z podanego formatu to jedyny sposób, by dowiedzieć się, co fizyczne łącze naprawdę musi przenosić. Poniższe przejście robi to tylko dla jednego kierunku, a każda liczba jest tu arytmetyką, nie pomiarem.

Zacznij od wyboru paketyzacji, a nie od liczby kodeka

Tabela kodeka podaje szybkość ładunku i nic więcej: G.729 daje 8 kbit/s, czyli 30 bajtów audio co 30 ms. Nie mówi nic o nagłówkach, ochronie ani ramkowaniu, a te trzy dominują w wyniku. Interwał to wybór polityki, na który muszą się zgodzić oba końce, więc wybierz go najpierw i podaj, bo każda późniejsza liczba zależy od tej jednej decyzji.

Ten przykład używa 30 ms, więc szybkość pakietów to 33.3 na sekundę. Zakłada nagłówek RTP 12 bajtów, nagłówek UDP 8 bajtów i wewnętrzny nagłówek IPv4 20 bajtów bez opcji oraz brak SRTP, kompresji nagłówków i wypełnienia poufności strumienia ruchu; każda zmiana przesuwa też budżet, dlatego założenia stoją obok odpowiedzi.

Dodaj nagłówki wewnętrzne, potem otoczkę ESP

Aplikacja wysyła ładunek plus RTP plus UDP plus IP, co przy tej paketyzacji daje 70 bajtów. Ten wewnętrzny strumień wychodzi na 18.7 kbit/s, już ponad dwukrotnie więcej niż szybkość kodeka, bo większość pakietu stanowią nagłówki, a nie audio. Żaden z tych bajtów nie jest głosem; to cena adresowania i numerowania. Zrzut zrobiony nad tunelem pokazuje dokładnie tę liczbę i ją cytują ludzie, mówiąc, że rozmowa jest mała.

To także liczba, która nigdy nie dociera do kabla. Tryb tunelu ESP dodaje 8-bajtowy SPI i numer sekwencji, 8-bajtowy jawny IV dla AES-GCM, 2-bajtowy trailer i 16-bajtowy znacznik uwierzytelnienia. Ładunek 70 bajtów plus trailer daje 72, co już spełnia wyrównanie do czterech bajtów, więc dodatkowe wypełnienie nie jest tu potrzebne.RFC 4106 ustala rozmiary IV i znacznika GCM, i oba należą do arytmetyki, a nie do przypisu:

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

Dodaj nagłówki zewnętrzne, których wymaga przejście przez NAT

Poza otoczką ESP stoją zewnętrzny nagłówek IPv4 20 bajtów i nagłówek UDP 8 bajtów do przejścia przez NAT, więc pakiet ma 132 bajty. Enkapsulacja UDP istnieje, bo pakiet musi przetrwać urządzenie tłumaczące między stronami, i zmienia zewnętrzny kształt bez dotykania chronionego ładunku. Przy 33.3 pakietach na sekundę 132 bajty to około 35.2 kbit/s, czyli mniej więcej czterokrotność nominalnej szybkości kodeka.

Ani znacznika, ani IV nie można usunąć z szacunku, by go zmniejszyć, bo oba są częścią tego, co łącze rzeczywiście przeniesie. Szacunek, który je pomija, opisuje pakiet, który odbiorca by odrzucił. To samo dotyczy trailera, który istnieje po to, by oznaczyć granicę ładunku i następny nagłówek w obszarze chronionym.

Nazwij granicę, zanim zacytujesz liczbę

Liczba zewnętrznego IP nadal wyklucza ramkowanie Ethernet. Łącze dostępowe z tagiem lub bez dodaje nagłówek MAC 14 bajtów i sekwencję kontrolną ramki 4 bajty, przez co ramka ma 150 bajtów, a to rozmiar, który liczy port przełącznika. Przy tej samej szybkości pakietów to 40 kbit/s, pięciokrotność szybkości kodeka, a różnica nie jest marnotrawstwem, lecz kosztem transportu.

Liczba 40 kbit/s nadal wyklucza preambułę, odstęp między ramkami, tagi VLAN, enkapsulację dostawcy, RTCP, sygnalizację i audio jadące w drugą stronę. To szacunek na kierunek, nie rezerwacja łącza, a cytowanie go jako rezerwacji przecenia to, co łącze musi zarezerwować w jednym miejscu, i nie docenia w innym. Zrzut na hoście może też pominąć ramkowanie dodawane przez łącze, dlatego granicę trzeba nazwać obok liczby, i dlatego tabela granic jest użyteczniejsza niż jedna liczba nagłówkowa. Rezerwuj osobno dla kierunku, którego nie policzyłeś.

Sprawdź arytmetykę względem interfejsu

Zanim zaufasz szacunkowi, porównaj go z tym, co interfejs raportuje dla znanej liczby pakietów. Zrzucaj na interfejsie fizycznym, a nie na urządzeniu tunelu, żeby ramkowanie, które próbujesz rozliczyć, było uwzględnione, i oczekuj małej rozbieżności, a nie idealnej zgodności.

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

Zrzut potwierdza zewnętrzny rozmiar pakietu, a liczniki interfejsu pokazują szybkość z ramkowaniem. Jeśli oba różnią się o mniej więcej dodatek Ethernet, arytmetyka jest poprawna i tylko granica była źle nazwana. Różnica znacznie większa niż jeden nagłówek ramki wskazuje na coś innego na łączu, na przykład retransmisje albo inny strumień dzielący interfejs. Zapisz interwał paketyzacji, zestaw ochrony i granicę obok liczby, bo szacunek bez tych trzech jest cytowany jako pomiar przez następnego czytelnika.