Kalkulator MTU
Oblicz maksymalny payload TCP lub UDP w podanym MTU, liczbę jednostek potrzebnych dla danych oraz narzut podstawowych i dodatkowych nagłówków.
Oblicz MTU, MSS i rozmiar danych
Od danych do świadomej decyzji
- Dane
- Obliczenie
- Wykres
- Decyzja
MTU 1500, IPv4 i TCP bez opcji dają MSS 1460 bajtów
MTU ogranicza rozmiar pakietu IP na danym łączu
MTU 1500 oznacza, że w jednostce przesyłanej przez rozpatrywane łącze może znaleźć się pakiet IP o maksymalnej długości 1500 bajtów. Wartość obejmuje nagłówek IP oraz jego ładunek, ale zwykle nie obejmuje pełnego narzutu ramki Ethernet.
MTU interfejsu lokalnego nie musi być najmniejszą wartością na całej trasie. Tunel, VPN, PPPoE lub inny segment może obniżyć Path MTU. To najmniejsze MTU na ścieżce decyduje, jaki pakiet przejdzie bez fragmentacji.
Kalkulator traktuje wpisane MTU jako efektywny budżet pakietu IP po uwzględnieniu ewentualnej enkapsulacji. Jeżeli znasz tylko fizyczne MTU 1500, a tunel dodaje własny zewnętrzny nagłówek, odejmij jego narzut albo użyj zmierzonego PMTU.
Podstawowy nagłówek IPv4 i TCP zajmują po 20 bajtów
Minimalny nagłówek IPv4 bez opcji ma 20 B. Minimalny nagłówek TCP również ma 20 B. W najprostszym przypadku razem zajmują 40 B z budżetu 1500 B, pozostawiając 1460 B danych TCP.
Ta wartość jest często nazywana MSS, czyli Maximum Segment Size. RFC 9293 opisuje MSS jako wielkość danych TCP po odjęciu nagłówków odpowiednich dla ścieżki i konkretnego segmentu. MSS nie jest tym samym co MTU.
Wzór 1500−40 działa tylko bez opcji IPv4 i TCP. Timestamp TCP, dodatkowe opcje lub nagłówki rozszerzeń IPv6 zmniejszają rzeczywisty ładunek danego pakietu. Kalkulator ma osobne pola na dodatkowe bajty.
5000 bajtów danych wymaga czterech segmentów modelowych
Trzy pełne segmenty przeniosą 3·1460=4380 B. Pozostaje 620 B, więc potrzebny jest czwarty segment. Zaokrąglenie 5000/1460 w górę daje cztery jednostki transmisji z danymi.
Podstawowe nagłówki IP i TCP zajmą co najmniej 4·40=160 B. Łączna liczba bajtów na poziomie IP wyniesie więc 5160 B, bez ramek Ethernet, potwierdzeń TCP, retransmisji i opcji.
TCP jest strumieniem i sam segmentuje dane zgodnie z efektywnym MSS, oknem oraz algorytmami stosu. Cztery segmenty są planem rozmiarowym dla podanego bloku, nie gwarancją identycznego grupowania wywołań aplikacji na przewodzie.
IPv6 i UDP zmieniają budżet nagłówków
Podstawowy nagłówek IPv6 ma 40 bajtów
Przy MTU 1500 i minimalnym TCP bez opcji IPv6 pozostawia 1500−40−20=1440 B danych. To o 20 B mniej niż podstawowy wariant IPv4, ponieważ stały nagłówek IPv6 jest większy.
IPv6 może używać nagłówków rozszerzeń umieszczonych między nagłówkiem bazowym a transportem. Każdy dodatkowy bajt zmniejsza przestrzeń dla TCP lub UDP w tym samym MTU. Nie zakładaj zawsze 1440, jeśli trasa lub aplikacja używa rozszerzeń.
RFC 8200 wymaga minimalnego MTU 1280 dla łączy IPv6. Dla podstawowego IPv6 i TCP odpowiada to 1220 B, zgodnie z domyślnym MSS omawianym przez RFC 9293, gdy nie otrzymano opcji MSS.
Nagłówek UDP ma osiem bajtów, ale protokół nie segmentuje strumienia jak TCP
Dla IPv4 bez opcji i UDP maksymalny ładunek mieszczący się w MTU 1500 wynosi 1500−20−8=1472 B. Dla IPv6 jest to 1500−40−8=1452 B. RFC 768 definiuje minimalną długość UDP równą ośmiu bajtom nagłówka.
Jeśli aplikacja chce wysłać 5000 B w jednym datagramie UDP, IP może go pofragmentować albo transmisja może się nie udać zgodnie z polityką ścieżki. Kalkulatorowa liczba czterech oznacza, że aplikacja musiałaby podzielić dane na cztery osobne datagramy mieszczące się w limicie.
Taki podział wymaga własnej numeracji, składania i obsługi utraty, jeśli aplikacja potrzebuje kompletnego komunikatu. Utrata jednego datagramu nie jest automatycznie naprawiana przez UDP. Nie traktuj „liczby pakietów” jak funkcji wbudowanej w protokół.
Opcje transportowe zmieniają rozmiar każdego segmentu osobno
TCP z timestampami często ma nagłówek większy niż 20 B. Jeśli opcje dodają 12 B, przy IPv4 i MTU 1500 dane mogą spaść do 1448 B. RFC 9293 wskazuje, że efektywny MSS uwzględnia rzeczywisty rozmiar nagłówka i opcji.
Nie wszystkie opcje występują w każdym segmencie. SYN może zawierać MSS, window scale, SACK permitted i timestamp, a późniejsze segmenty inny zestaw. Kalkulator stosuje wpisany narzut do każdej modelowej jednostki, co jest bezpiecznym uproszczeniem planistycznym.
Dodatkowe pola nie służą do odjęcia Ethernetu ani zewnętrznego tunelu od wewnętrznego MSS w przypadkowy sposób. Najpierw ustal warstwę, na której definiowane jest MTU, i unikaj dwukrotnego odejmowania tego samego nagłówka.
Path MTU jest najmniejszym limitem na całej trasie
PMTUD pozwala nadawcy dostosować rozmiar bez zgadywania
RFC 1191 opisuje Path MTU Discovery dla IPv4: nadawca wysyła pakiety z ustawionym zakazem fragmentacji, a router, który nie może ich przesłać, zwraca komunikat o potrzebie fragmentacji i MTU następnego łącza.
Celem jest użycie największego pakietu, który nie wymaga fragmentacji nigdzie po drodze. Mniejsze pakiety zwiększają udział nagłówków i liczbę operacji, natomiast zbyt duże mogą zostać odrzucone lub pofragmentowane.
Filtrowanie potrzebnych komunikatów ICMP może tworzyć tzw. PMTU black hole: połączenie zestawia się, ale większe pakiety znikają. Diagnostyka powinna obejmować MSS w SYN, ICMP Packet Too Big lub Fragmentation Needed oraz próbę pakietów o różnych rozmiarach.
IPv6 nie pozwala routerom fragmentować pakietów po drodze
RFC 8200 podkreśla, że w IPv6 fragmentację wykonuje tylko węzeł źródłowy, a nie router tranzytowy. Router odrzuca zbyt duży pakiet i wysyła ICMPv6 Packet Too Big, aby nadawca mógł zmniejszyć rozmiar.
Źródło może użyć nagłówka Fragment, ale standard odradza fragmentację aplikacjom zdolnym dostosować pakiety do zmierzonego PMTU. Dopasowanie rozmiaru jest zwykle bardziej niezawodne i ogranicza koszt utraty jednego fragmentu.
Każdy link IPv6 musi obsługiwać MTU co najmniej 1280 na warstwie IPv6 lub zapewnić niżej mechanizm potrzebny do przeniesienia takiego pakietu. Nie oznacza to, że każda ścieżka ma dokładnie 1280; często jest większa.
Tunele zużywają część fizycznego MTU na zewnętrzną kopertę
VPN, GRE, VXLAN, IPsec i inne enkapsulacje dodają zewnętrzne nagłówki. Jeżeli fizyczne łącze pozostaje przy 1500 B, wewnętrzny pakiet musi być mniejszy, aby całość zmieściła się bez fragmentacji.
Narzut zależy od wariantu protokołu, uwierzytelniania, rodziny adresów zewnętrznych i wyrównania. Nie istnieje jedna liczba „VPN overhead” dla wszystkich konfiguracji. Odczytaj ją z dokumentacji i potwierdź przechwyceniem pakietów.
Popularnym rozwiązaniem dla TCP jest MSS clamping na brzegu tunelu. Urządzenie modyfikuje reklamowany MSS, aby końce od razu wysyłały mniejsze segmenty. To nie zmienia MTU samego interfejsu i nie rozwiązuje automatycznie dużych datagramów UDP.
Narzut zależy również od ramek, potwierdzeń i zachowania aplikacji
Wynik IP nie obejmuje pełnego kosztu na przewodzie
Obliczone 5160 B obejmuje dane, podstawowe nagłówki IPv4 i TCP czterech segmentów. Ethernet dodaje nagłówek, FCS, preambułę i przerwę międzyramkową. VLAN, PPPoE lub inne warstwy mogą dołożyć kolejne bajty.
Na różnych warstwach narzut liczy się inaczej: część pól znajduje się w ramce, część zajmuje czas, ale nie jest raportowana jako jej długość. Przy planowaniu przepustowości określ, czy liczysz goodput aplikacji, bajty IP, rozmiar ramki czy czas zajęty na medium.
Wykres na stronie pokazuje wyłącznie modelowy budżet wewnątrz MTU i podstawowe nagłówki. Nie używaj go bez korekty do dokładnego wyliczenia PPS na Ethernet ani rachunku operatora naliczającego ruch według innej warstwy.
TCP generuje ACK, retransmisje i czasem segmenty niepełne
Odbiorca wysyła potwierdzenia, a utracone dane mogą zostać retransmitowane. Nagłówki ACK oraz dodatkowe przebiegi nie są wliczone do prostego podziału 5000 B. Rzeczywisty stos może łączyć potwierdzenia i stosować offload sprzętowy.
Aplikacja zapisująca małe porcje może wywołać mniejsze segmenty, choć MSS pozwala na 1460 B. Nagle, opóźnione ACK, TLS i granice rekordów wpływają na obserwowany przebieg. MSS jest górnym limitem danych segmentu, nie obowiązkowym rozmiarem.
TLS dodaje rekordy i własny narzut wewnątrz strumienia TCP. Może zwiększyć liczbę bajtów aplikacyjnych przesyłanych przez TCP, choć nie zmienia długości nagłówka TCP. Przy dokładnym modelu uwzględnij warstwy nad transportem osobno.
Najpewniejsza kontrola łączy konfigurację, przechwycenie i test końcowy
Sprawdź MTU interfejsów, trasę tunelową, reklamowane MSS i rozmiary przechwyconych pakietów. Następnie przetestuj transfer dużych danych w obu kierunkach, ponieważ trasy i PMTU mogą być asymetryczne.
Dla domyślnego przykładu oczekuj danych TCP do 1460 B przy podstawowych nagłówkach. Jeśli widzisz 1448 B, prawdopodobną przyczyną są opcje TCP o długości 12 B. Jeśli znacznie mniej, sprawdź tunel i MSS clamping.
W dokumentacji zapisz warstwę MTU, wersję IP, transport, opcje, enkapsulację i zaobserwowany PMTU. Sama liczba 1500 bez kontekstu nie wystarcza do odtworzenia decyzji ani wyjaśnienia problemu z fragmentacją.
Najczęstsze pytania
Czy MSS i MTU to to samo?
Nie. MTU obejmuje pakiet IP, a MSS ogranicza dane TCP po odjęciu odpowiednich nagłówków.
Czy TCP zawsze wysyła segmenty pełne do MSS?
Nie. MSS jest limitem; aplikacja, algorytmy stosu, TLS i warunki sieci mogą tworzyć mniejsze segmenty.
Czy UDP automatycznie dzieli 5000 B na kilka datagramów?
Nie. Aplikacja musi sama podzielić komunikat albo narazić pojedynczy duży datagram IP na fragmentację lub odrzucenie.
Dlaczego opcje TCP zmniejszają dane w pakiecie?
Zajmują dodatkowe bajty wewnątrz tego samego MTU, więc pozostaje mniej miejsca na payload.
Co to jest Path MTU?
Najmniejsze MTU na całej trasie między źródłem i celem.
Czy wynik uwzględnia Ethernet i retransmisje?
Nie. Kalkulator pokazuje budżet IP/transport; ramki, ACK, retransmisje, TLS i inne warstwy wymagają osobnego rachunku.
Źródła i dalsza lektura
- IETF. (2022). RFC 9293 — Transmission Control Protocol.
- IETF. (2017). RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification.
- IETF. (1980). RFC 768 — User Datagram Protocol.
- IETF. (1990). RFC 1191 — Path MTU Discovery.