Czy mniejszy MTU VPN jest szybszy? Porównaj rzeczywiste dowody
Niższe MTU może ominąć ograniczenie ścieżki i nadal kosztować przepustowość. Porównaj rzeczywiste ograniczenie, narzut nagłówków i obciążenie, zanim zachowasz zmianę.
Tunel odrzuca duże transfery, ale przepuszcza ping, więc rada przychodzi szybko: zmniejsz MTU. Poprawka czasem działa, a potem jest stosowana do każdego profilu w każdej sieci. Właśnie wtedy ukierunkowana naprawa staje się trwałym podatkiem od wydajności. Porównanie, które trzeba wykonać, dotyczy rzeczywistego limitu ścieżki i kosztu zmniejszenia każdego pakietu poniżej niego.
Co naprawdę się kurczy, gdy obniżasz MTU
Każdy pakiet niesie nagłówki, zanim poniesie twoje dane. Na ścieżce Ethernet 1500 bajtów IPv4 i TCP zużywają 40 bajtów i zostawiają 1460 na ładunek; enkapsulacja dodaje na wierzchu zewnętrzne nagłówki IP, UDP i tunelu, więc wewnętrzny budżet ładunku znów spada. Obniżenie MTU interfejsu celowo zmniejsza ten budżet.
Koszt jest proporcjonalny do liczby pakietów, a nie do liczby bajtów. Ten sam plik podzielony na więcej pakietów wymaga więcej przerwań, więcej decyzji routingu i więcej przetwarzania na pakiet na każdym urządzeniu na ścieżce. Na routerze, który już jest blisko limitu pakietów na sekundę, to realne spowolnienie, a nie błąd zaokrąglenia. Koszt widać nawet wtedy, gdy sam transfer się udaje.
Dlatego mniejszy MTU jest obejściem ograniczenia, a nie ogólną optymalizacją. Kupuje niezawodność wobec ścieżki, która nie może unieść większej ramki, i pobiera narzut za każdy pakiet, który nie potrzebował zmniejszenia.
Kiedy mniejszy MTU jest właściwą poprawką
Klasyczny objaw jest konkretny: uścisk dłoni TCP kończy się, przychodzą małe odpowiedzi, a duże pobieranie zatrzymuje się lub jest resetowane. Ping z bitem nie-fragmentuj przy 1472 bajtach zawodzi, podczas gdy ping 1400 bajtów się udaje, co wskazuje na ścieżkę, która nie może unieść pakietu pełnego rozmiaru i nie dostarcza komunikatu ICMP, który powiedziałby nadawcy, aby zmniejszył.
Wykrywanie MTU ścieżki zależy od tych komunikatów ICMP o wymaganej fragmentacji. Gdy zapora je odrzuca, nadawca wciąż ponawia duży pakiet i połączenie wygląda na zawieszone. Obniżenie MTU po stronie tunelu pozwala uniknąć ponawiania, i jest to uzasadniona naprawa dla tej sieci.
Technologie dostępu też narzucają własne limity: PPPoE zwykle kończy się na 1492, niektóre ścieżki mobilne i DSL są niższe, a zagnieżdżone tunele odejmują narzut dwa razy. Mierz rzeczywistą ścieżkę, zamiast kopiować liczbę z poradnika, i pamiętaj, że IPv6 wymaga co najmniej 1280 bajtów MTU na każdym łączu, które go przenosi, jak określa RFC 8200.
Porównaj trzy mechanizmy, zanim zmienisz jeden
MTU, MSS i fragmentacja to różne mechanizmy na różnych warstwach, a zmiana niewłaściwego zostawia objaw na miejscu.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
Ograniczanie MSS jest często najmniej inwazyjną naprawą, bo dotyczy tylko TCP i zostawia interfejs wolny dla innego ruchu. Niższe MTU interfejsu jest szersze i łatwiejsze do przemyślenia, dlatego jest popularne na routerach domowych, ale obciąża każdy protokół problemem jednego protokołu.
Wyłączenie zachowania nie-fragmentuj ukrywa objaw, pozwalając na fragmentację, i zwykle pogarsza opóźnienie, jednocześnie psując informację zwrotną, która znalazłaby właściwy rozmiar. Unikaj tego jako trwałej poprawki.
Mierz kompromis, a nie jedną liczbę
Znajdź limit ścieżki sondą nie-fragmentuj, zacznij wysoko i schodź, aż przyjdzie odpowiedź:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Potem porównaj rzeczywiste zadanie na obu ustawieniach: ten sam transfer pliku, ten sam punkt końcowy i tę samą sieć. Zapisz czas ukończenia i retransmisje, na przykład za pomocą nstat -az TcpRetransSegs, i obserwuj procesor urządzenia, jeśli tunel kończy się na małym routerze. Krótki syntetyczny test przepustowości może pominąć zatrzymanie, które pojawia się dopiero po kilku megabajtach.
Liczniki pakietów wzrosną po zmniejszeniu, bo ten sam transfer zużywa teraz więcej pakietów. To oczekiwane i nie jest dowodem wyższej przepustowości. Porównuj ukończone dane aplikacji, liczbę retransmisji i responsywność, a nie tylko szybkość pakietów.
Wprowadzaj zmianę etapami i utrzymuj ją w ograniczonym zakresie
Zapisz pierwotną wartość, zmień jeden mechanizm i powtórz pomiar, zanim uczynisz go trwałym. Jeśli dowody nie pokazują korzyści, przywróć poprzednią wartość tym samym poleceniem interfejsu, którego użyłeś do jej ustawienia:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Ogranicz wynik do sieci, która go potrzebowała. Profil, który musi działać w Wi-Fi hotelowym, w mobilnym hotspocie i w biurowej sieci LAN, nie powinien dziedziczyć najniższej wartości wymaganej przez którąkolwiek z nich, chyba że klient nie potrafi wykryć ścieżki.
Właściwa wartość to największe MTU, które przetrwa ścieżkę, a nie najmniejsze, które usuwa objaw. Udokumentuj ścieżkę, wynik sondy i wycofanie, i przejrzyj ustawienie, gdy zmieni się sieć dostępu.