Быстрее ли VPN с меньшим MTU? Сравните реальные доказательства
Меньший MTU может обойти ограничение маршрута и всё равно стоить пропускной способности. Сравните реальное ограничение, накладные расходы заголовков и нагрузку, прежде чем оставлять изменение.
Туннель отбрасывает крупные передачи, но пропускает 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 и фрагментация — это разные регуляторы на разных уровнях, и смена не того оставляет симптом на месте.
| 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 |
Ограничение 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, на мобильной точке доступа и в офисной LAN, не должен наследовать наименьшее значение, которого требует любая из них, если только клиент не может обнаружить маршрут.
Правильное значение — это наибольший MTU, который выживает на маршруте, а не наименьший, который заставляет симптом исчезнуть. Задокументируйте маршрут, результат зонда и откат и пересматривайте настройку, когда сеть доступа меняется.