Nagłówki i ładunek pakietu
Dane w sieci są dzielone na odrębne jednostki zwane . Pakiet zawiera część danych użytkownika, czyli ładunek (payload), oraz informacje sterujące zapisane w nagłówku. Nagłówki służą między innymi do adresowania, kontroli kolejności i interpretacji ładunku. Przy przejściu przez kolejne warstwy stosu każdy protokół może dodać własny nagłówek, tworząc zagnieżdżoną strukturę enkapsulacji.
W połączeniu wykorzystującym stos TCP/IP pakiet może przenosić nagłówki z kilku warstw. Ich pola zależą od użytych protokołów. Każdy nagłówek opisuje inną funkcję, dlatego usunięcie pola bez wspólnego mechanizmu odtworzenia zmieniłoby znaczenie pakietu. Opcje, nagłówki rozszerzeń i fragmentacja mogą dodać kolejne pola do typowego zestawu. Warstwa łącza może również dodać własne ramkowanie i pola integralności poza pakietem IP:
- Nagłówek IP (Internet Protocol): Zawiera między innymi adres źródłowy i docelowy, na przykład . Minimalny nagłówek IPv4 bez opcji ma 20 bajtów, a opcje mogą zwiększyć go do 60 bajtów. Pole IHL określa długość nagłówka, dzięki czemu odbiorca wie, gdzie zaczyna się ładunek.
- Nagłówek TCP (Transmission Control Protocol) lub UDP (User Datagram Protocol): Oba nagłówki zawierają port źródłowy i docelowy. TCP dodatkowo używa numerów sekwencyjnych, potwierdzeń i pól sterujących, a UDP ma prostszą strukturę z długością i sumą kontrolną. Minimalny nagłówek TCP ma 20 bajtów, a nagłówek UDP 8 bajtów.
- Nagłówki warstwy aplikacji: Niektóre protokoły, takie jak RTP (Real-time Transport Protocol), dodają własny nagłówek do strumienia transportowanego zwykle przez UDP. RTP zawiera między innymi numer sekwencyjny i znacznik czasu. Minimalny nagłówek RTP ma 12 bajtów, lecz pola CSRC i rozszerzenia mogą go wydłużyć.
Narzut protokołowy
Łączny rozmiar informacji sterujących jest określany jako . Dla dużego ładunku, na przykład obrazu o rozmiarze 5 MB, 40 bajtów nagłówków przypadających na pakiet stanowi zwykle małą część danych. Przy małym ładunku ta sama liczba bajtów może istotnie ograniczać efektywną przepływność. Wartość 40 bajtów dotyczy przykładu IPv4, UDP i RTP, bez nagłówka warstwy łącza, tuneli i opcji.
Przykładem jest Voice over IP (VoIP). W zależności od kodeka i długości ramki pakiet może zawierać 20 lub 30 bajtów danych audio. Dla przykładowego pakietu obliczenie nagłówka wygląda następująco:
Przy 20 bajtach ładunku pakiet ma 60 bajtów, z czego 40 bajtów, czyli około 67 procent, stanowi narzut. Na łączach o małej przepływności lub wysokim koszcie zwiększa to wymagane pasmo i może ograniczać liczbę rozmów. Kompresja nagłówków zmniejsza tę część pakietu przy zachowaniu informacji potrzebnych do odtworzenia nagłówka. Wartość procentowa odnosi się do całego pakietu, a udział narzutu względem samego ładunku wynosi w tym przykładzie 200 procent.
Redundancja między pakietami
W obrębie jednego strumienia komunikacyjnego wiele pól nagłówków pozostaje stałych albo zmienia się według znanej reguły. Dotyczy to między innymi rozmów, strumieni wideo i kolejnych segmentów jednego pliku. Kompresor może więc przesyłać wartości początkowe oraz różnice względem poprzedniego pakietu, zamiast powtarzać pełne pola.
Dla rozmowy VoIP od użytkownika A do użytkownika B można wyróżnić następujące pola:
- Pola statyczne: W ramach jednego przepływu adresy IP i porty mogą pozostawać stałe. Ich ponowne przesyłanie w każdym pakiecie zwiększa narzut bez dodawania nowej informacji.
- Pola zmieniające się przewidywalnie: Numer sekwencyjny RTP zwiększa się o jeden dla kolejnych pakietów. Znacznik czasu zwiększa się zgodnie z liczbą próbek i sposobem pakietowania, więc jego przyrost może być przewidywalny w danym strumieniu.
Schemat kompresji przechowuje te informacje we wspólnym stanie kompresora i dekompresora, zwanym . Kontekst może zawierać wartości statyczne, wartości referencyjne i reguły zmian pól. Jego uszkodzenie wymaga odświeżenia albo ponownej inicjalizacji. Przykładowy przebieg jest następujący.
- Początkowe pakiety strumienia mogą zawierać pełne nagłówki. Odbiorca buduje na ich podstawie lokalny kontekst z adresami, portami i innymi polami.
- Po uzgodnieniu kontekstu kompresor przesyła krótki nagłówek z identyfikatorem kontekstu oraz informacją o zmianach, na przykład o zwiększeniu numeru sekwencyjnego o jeden.
- W wybranych profilach dekompresor otrzymuje krótki nagłówek o długości 1-3 bajtów, odczytuje wskazany kontekst i aktualizuje zmienne pola. Przy poprawnym kontekście odtwarza pełny nagłówek przed przekazaniem pakietu aplikacji. Jeśli kontekst jest błędny, krótki nagłówek może zostać odrzucony i wymagać pakietu odświeżającego.
W profilach przeznaczonych dla podobnych strumieni 40-bajtowy narzut pakietu VoIP może zostać zmniejszony do 1-3 bajtów. Odpowiada to redukcji przekraczającej 90 procent w tym przykładzie.
ROHC i stany kontekstu
ROHC (Robust Header Compression) to określony w dokumentach RFC zestaw mechanizmów kompresji nagłówków dla łączy, na których występują straty, błędy lub zmiana kolejności pakietów. Mechanizmy kontekstu, kontroli i odświeżania ograniczają propagację błędów. Ramki mogą zawierać informacje kontrolne i krótkie sumy CRC, które pomagają wykryć błędną aktualizację kontekstu. Kompresja jest stosowana na odcinku między punktami kompresji, a pełny nagłówek IP nadal może być potrzebny poza tym odcinkiem. Kontekst jest lokalny dla kanału kompresji i nie zastępuje nagłówków w całym Internecie. Musi zostać zainicjalizowany na obu końcach i zachować spójność przy zmianie kolejności lub utracie pakietów.
ROHC jest protokołem stanowym. Profile, takie jak ROHC-RTP i ROHC-TCP, określają sposób kompresji konkretnych nagłówków. Identyfikator kontekstu pozwala rozróżnić kilka przepływów na jednym kanale. Zestaw mechanizmów definiuje trzy podstawowe stany:
- Stan inicjalizacji i odświeżania (IR): Kompresor wysyła informacje potrzebne do ustanowienia lub odświeżenia kontekstu dekompresora.
- Stan pierwszego rzędu (FO): Po ustanowieniu kontekstu przesyła skompresowane nagłówki z aktualizacjami pól zmiennych lub wymagających synchronizacji.
- Stan drugiego rzędu (SO): Przy ustabilizowanym przepływie umożliwia użycie najmniejszych nagłówków, opisujących przewidywalne zmiany, na przykład numer sekwencyjny.
Przejścia między stanami zależą od poprawności kontekstu i profilu. Po utracie pakietu dekompresor może zgłosić problem kanałem zwrotnym. Kompresor wraca wtedy do trybu z większą ilością informacji i odświeża kontekst. Bez kanału zwrotnego profil może używać okresowych pakietów odświeżających. Częstsze aktualizacje poprawiają odzyskiwanie po błędach i zmniejszają możliwą oszczędność bajtów.
6LoWPAN dla sieci ograniczonych
W sieciach Internetu Rzeczy stosuje się kompresję nagłówków IPv6. ma stały podstawowy nagłówek o rozmiarze 40 bajtów. Minimalny nagłówek IPv4 ma 20 bajtów, lecz IPv6 zapewnia 128-bitowe adresy i inny układ pól.
W urządzeniach o małej mocy 40-bajtowy nagłówek może stanowić dużą część pakietu z kilkubajtowym ładunkiem. Standard 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) definiuje formaty transmisji IPv6 w takich sieciach, w tym kompresję nagłówków:
- Pomijanie wspólnych pól: Wybrane pola IPv6 i UDP można pominąć oraz wywnioskować z warstwy łącza lub kontekstu.
- Wspólny prefiks: Prefiks IPv6 może być znany w całej sieci lub zapisany w kontekście. Wtedy nie trzeba przesyłać go w każdym pakiecie.
- Wyprowadzanie adresu: W niektórych konfiguracjach identyfikator interfejsu można wyprowadzić z adresu warstwy łącza, na przykład z 48-bitowego adresu MAC po odpowiednim mapowaniu albo z 64-bitowego identyfikatora IEEE 802.15.4.
Nagłówki IPv6 i UDP mają łącznie 48 bajtów przed kompresją. Po zastosowaniu LOWPAN_IPHC i kompresji UDP wynik zależy od kontekstu, portów, sumy kontrolnej i sposobu routingu. Sam podstawowy zapis IPHC może mieć 2 bajty w najlepszym przypadku, lecz pełna reprezentacja IPv6 i UDP wymaga także pozostałych pól. Przy routingu wieloskokowym skompresowany nagłówek IPv6 może mieć 7 bajtów, a UDP korzysta z osobnego formatu NHC. Nie istnieje jedna wartość końcowa dla wszystkich pakietów 6LoWPAN. Format UDP NHC może kompresować wybrane numery portów do krótkiego pola, lecz porty spoza obsługiwanego zakresu są przenoszone jawnie. Kodowanie IPHC ma podstawową długość 2 bajtów i może otrzymać dodatkowy bajt identyfikatora kontekstu. Tryb bezstanowy korzysta z informacji adresowych warstwy łącza, a tryb stanowy przechowuje prefiksy w tabeli kontekstów. W standardowej transmisji IPv6 suma kontrolna UDP jest obowiązkowa. 6LoWPAN może ją pominąć tylko wtedy, gdy warstwa wyższa wyrazi na to zgodę i zapewniono dodatkowy mechanizm integralności. W przeciwnym razie pole pozostaje w pakiecie, a odbiorca przy pominięciu odtwarza sumę przez ponowne obliczenie. Nagłówki fragmentacji są obsługiwane osobno, gdy skompresowany datagram nie mieści się w jednej ramce IEEE 802.15.4.