По-бърз ли е по-малкият MTU на VPN? Сравнете реалните доказателства

Тунелът изпуска големи трансфери, но пропуска ping, затова съветът идва бързо: намалете MTU. Поправката понякога работи и после се прилага към всеки профил във всяка мрежа. Точно тогава насочената поправка се превръща в постоянен данък върху производителността. Сравнението, което трябва да се направи, е между реалното ограничение на пътя и цената да свием всеки пакет под него.

Какво наистина се свива, когато намалите MTU

Всеки пакет носи заглавки, преди да носи вашите данни. По път Ethernet от 1500 байта IPv4 и TCP заемат 40 байта и оставят 1460 за полезния товар; капсулирането добавя отгоре външни заглавки IP, UDP и тунел, така че вътрешният бюджет за товар отново пада. Намаляването на MTU на интерфейса умишлено свива този бюджет.

Цената е пропорционална на броя пакети, не на броя байтове. Същият файл, разделен на повече пакети, изисква повече прекъсвания, повече решения за маршрутизиране и повече обработка на пакет във всяко устройство по пътя. На рутер, който вече е близо до лимита си пакети в секунда, това е реално забавяне, а не грешка при закръгляване. Цената се вижда дори когато самият трансфер успее.

Ето защо по-малкият MTU е заобикаляне на ограничение, а не обща оптимизация. Той купува надеждност срещу път, който не може да носи по-голямата рамка, и начислява разходи за всеки пакет, който не се е нуждаел от свиването.

Кога по-малкият MTU е правилната поправка

Класическият симптом е конкретен: TCP ръкостискането завършва, малки отговори пристигат, а голямо изтегляне засича или се нулира. Ping с бит „не фрагментирай“ при 1472 байта се проваля, докато ping от 1400 байта успява, което сочи към път, който не може да носи пакет с пълен размер и не доставя ICMP съобщението, което би казало на подателя да намали.

Откриването на MTU на пътя зависи от тези ICMP съобщения за необходима фрагментация. Когато защитна стена ги изхвърля, подателят продължава да опитва големия пакет и връзката изглежда увиснала. Намаляването на MTU от страната на тунела избягва повторението и това е законна поправка за тази мрежа.

Технологиите за достъп също налагат свои ограничения: PPPoE обикновено се ограничава до 1492, някои мобилни и DSL пътища са по-ниски, а вложените тунели изваждат разходите два пъти. Измерете реалния път, вместо да копирате число от ръководство, и помнете, че IPv6 изисква поне 1280 байта MTU на всяка връзка, която го носи, както определя RFC 8200.

Сравнете трите средства за управление, преди да промените едно

MTU, MSS и фрагментацията са различни копчета на различни слоеве и смяната на грешното оставя симптома на място.

Ограничаването на MSS често е най-малко инвазивната поправка, защото засяга само TCP и оставя интерфейса свободен за друг трафик. По-нисък MTU на интерфейса е по-широк и по-лесен за обмисляне, затова е разпространен при потребителските рутери, но начислява на всеки протокол проблема на един протокол.

Изключването на поведението „не фрагментирай“ скрива симптома, като разрешава фрагментация, и обикновено влошава закъснението, като същевременно чупи обратната връзка, която би намерила правилния размер. Избягвайте го като постоянно решение.

Измерете компромиса, а не едно число

Намерете ограничението на пътя със сонда „не фрагментирай“, започвайки високо и слизайки, докато дойде отговорът:

ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10

След това сравнете реалната задача при двете настройки: същия файлов трансфер, същата крайна точка и същата мрежа. Запишете времето за завършване и повторните предавания, например с nstat -az TcpRetransSegs, и следете процесора на устройството, ако тунелът завършва на малък рутер. Кратък синтетичен тест на пропускателната способност може да пропусне засичането, което се появява само след няколко мегабайта.

Броячите на пакети ще се покачат след намаляване, защото същият трансфер сега използва повече пакети. Това е очаквано и не е доказателство за по-висока пропускателна способност. Сравнявайте завършените данни на приложението, броя повторни предавания и отзивчивостта, а не само честотата на пакетите.

Въведете промяната на етапи и я дръжте ограничена

Запишете първоначалната стойност, променете едно средство за управление и повторете измерването, преди да го направите постоянно. Ако доказателствата не показват полза, възстановете предишната стойност със същата интерфейсна команда, с която сте я задали:

ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500

Ограничете резултата до мрежата, която се нуждаеше от него. Профил, който трябва да работи в хотелски Wi-Fi, мобилен hotspot и офис LAN, не бива да наследява най-ниската стойност, която изисква който и да е от тях, освен ако клиентът не може да открие пътя.

Правилната стойност е най-големият MTU, който оцелява на пътя, а не най-малкият, който кара симптома да изчезне. Документирайте пътя, резултата от сондата и връщането назад и преразгледайте настройката, когато мрежата за достъп се промени.