MTU, MSS и PMTUD: класс багов, который объясняет половину «зависаний» сайтов

Этот класс багов узнаваем сразу: TCP-соединение устанавливается, ping проходит, мелкие HTTP-запросы выполняются успешно — но как только сайт пытается отдать крупный ответ (картинку, JSON-файл, тяжёлую страницу), соединение зависает. У одних сайтов всё работает, у других — нет. Иногда после долгого ожидания страница загружается частично, иногда совсем не открывается.

В 80% случаев это история про MTU и MSS. Пять минут понимания превращают «загадочный» баг в очевидную проблему — и вы будете находить его руками за минуту, а не за часы. Разбираем механику от Ethernet-фреймов до мобильных GTP-туннелей.

Цепочка размеров: MTU → MSS

Ethernet frame                                MTU = 1500 байт
├─ IP header                                  20 байт
├─ TCP header                                 20 байт
└─ TCP payload (полезная нагрузка)             1460 байт ←─ это и есть MSS

Если на пути туннель добавляет 50 байт служебных заголовков:
  Реальный путь MTU = 1500 - 50 = 1450
  Допустимый MSS  = 1450 - 20 - 20 = 1410
  Если MSS не уменьшен → пакет 1500 байт уходит и теряется.

MTU: максимальный размер кадра

MTU (Maximum Transmission Unit) — максимальное количество байт, которое можно передать в одном кадре конкретного канального уровня. Стандартные значения:

• Ethernet — 1500 байт. Де-факто стандарт интернета. Большая часть мира работает с этим числом.
• Jumbo frames — 9000 байт. Бывает в дата-центрах, между серверами, на 10G/40G/100G. В публичный интернет не проходит.
• PPPoE — 1492 байт. Минус 8 байт PPP-заголовков. Типично для DSL-провайдеров.
• IPsec ESP transport — около 1438 байт. Минус ~62 байта на ESP-заголовок и аутентификацию.
• GRE-туннель — 1476 байт. Минус 24 байта GRE-заголовка.
• GTP-U в мобильной сети — около 1438–1448 байт. Минус ~52 байта GTP-заголовка поверх UDP.

MSS: сколько полезных байт TCP помещается

MSS (Maximum Segment Size) — максимальный размер TCP-сегмента, без IP- и TCP-заголовков. Формула простая:

MSS = MTU − IP-header − TCP-header

• IPv4 без TCP options: 1500 − 20 − 20 = 1460 байт. Стандарт для большинства соединений.
• IPv6 без TCP options: 1500 − 40 − 20 = 1440 байт. IPv6-заголовок на 20 байт длиннее IPv4.
• С TCP options (timestamps, SACK): вычесть ещё 12–20 байт.

MSS обменивается в SYN-пакетах: каждая сторона объявляет свой MSS, и используется минимум из двух. Это работает идеально, пока на пути нет туннелей с меньшим MTU.

Path MTU Discovery: как клиент находит реальный потолок

PMTUD (RFC 1191) — механизм автоматического обнаружения минимального MTU по всему пути. Логика:

1. Клиент отправляет TCP-пакет с битом DF (Don't Fragment) и размером, равным своему локальному MTU.
2. Если по пути встречается узел с меньшим MTU, он не может фрагментировать пакет (DF запрещает) и отбрасывает его.
3. Этот узел отправляет назад ICMP-сообщение Type 3, Code 4 — «Fragmentation Needed and DF set», с указанием максимального MTU.
4. Клиент получает ICMP, обновляет своё представление о Path MTU и пересылает пакет нужного размера.
5. Все последующие пакеты этой TCP-сессии идут с новым размером.

В идеальном мире это всё работает само и пользователь ничего не замечает. Реальный мир, к сожалению, выглядит иначе.

PMTUD blackhole: главная боль

Многие администраторы блокируют ICMP «по соображениям безопасности» — это распространённая ошибка, потому что она ломает PMTUD. Если ICMP «Fragmentation Needed» не доходит до клиента, происходит следующее:

1. Клиент шлёт пакет 1500 байт. По дороге он теряется на узле с MTU 1450.
2. Клиент не получает ICMP — он не знает, что произошло.
3. TCP retransmit timer срабатывает через 200–600 мс, клиент шлёт тот же 1500-байтный пакет снова.
4. Снова потеря. Снова retransmit. Снова потеря.
5. Через 30–60 секунд TCP-соединение умирает по таймауту.

А вот мелкие пакеты (TCP SYN, ACK без данных, мелкие GET-запросы) проходят без проблем. Поэтому пользователь видит «часть сайтов работает, часть нет», «соединение есть, но страницы не грузятся», «текст пришёл, картинок нет».

Это и есть классический PMTUD blackhole. Лекарство — либо разрешить ICMP Type 3 Code 4 на пути, либо корректировать MSS на границе сети.

MSS clamping: лекарство для всей сети сразу

MSS clamping — механизм принудительного переписывания MSS в SYN-пакетах. Граничный маршрутизатор смотрит SYN, видит объявленный MSS (например, 1460), и если он больше его собственного потолка (например, 1410 для IPsec), переписывает MSS на 1410. Обе стороны получают уже скорректированное значение и не отправляют слишком больших сегментов.

На Linux это делается одной командой iptables:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

Или явно:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --set-mss 1410

Это стандартное лекарство на корпоративных шлюзах с IPsec, на мобильных PGW/UPF и на любых граничных узлах с туннелями. Работает на любом TCP-соединении, проходящем через шлюз. UDP таким образом не лечится — для него надо PMTUD UDP (RFC 4821) и поддержку приложением.

Каждый туннель снижает MTU

Сводная таблица overhead'а для популярных туннелей:

Реальный путь часто проходит через несколько слоёв инкапсуляции. Если каждый из них не корректирует MSS, накапливаются проблемы.

IPv6 строже относится к MTU

IPv6 принципиально отличается от IPv4 в этом вопросе: маршрутизаторы НЕ ИМЕЮТ ПРАВА фрагментировать IPv6-пакеты. Если пакет больше Path MTU, маршрутизатор обязан вернуть ICMPv6 «Packet Too Big» (Type 2) и дропнуть пакет. Поэтому в IPv6 PMTUD не опционален, а обязателен — и блокировка ICMPv6 ломает связь катастрофически.

Минимальный MTU для IPv6 — 1280 байт. Это значит, что любой IPv6-узел должен уметь принимать пакеты как минимум 1280 байт без фрагментации.

Почему это особенно актуально для мобильных сетей

Мобильная инфраструктура добавляет несколько слоёв инкапсуляции:

• GTP-U (User Plane) поверх UDP/IP в радиосети — ~52 байта overhead.
• В роуминге — дополнительный туннель home routing.
• Иногда PPPoE на стороне абонента, если используется carrier грейд.

Поэтому на мобильных операторах эффективный MTU часто 1438–1448 байт. Хороший оператор настраивает MSS clamping автоматически на UPF, и пользователь ничего не замечает. Плохой — оставляет ICMP резаным, и абоненты жалуются на «зависания тяжёлых сайтов». Симптомы на конкретном телефоне разбираются в статье про скачки скорости мобильного интернета.

Диагностика: команды и тесты

Подозреваете MTU? За 30 секунд проверяете:

• Linux/macOS: ping -s 1472 -M do 8.8.8.8. Размер 1472 + 8 байт ICMP + 20 байт IP = 1500. Если ping проходит, путь поддерживает MTU 1500.
• Если не проходит — уменьшайте: ping -s 1450 -M do 8.8.8.8, потом 1400, и так до прохождения.
• Windows: ping -f -l 1472 8.8.8.8.
• tracepath: tracepath 8.8.8.8 — показывает PMTU по каждому хопу автоматически.
• Проверка ICMP: tracepath -m 30 8.8.8.8 — если на каком-то хопе пишет «no reply», это потенциальная проблема.

Если ваш MTU работает только на 1400 — это сигнал, что на пути есть туннель и стоит включить MSS clamping (на роутере или прописать в /etc/sysctl: net.ipv4.tcp_mtu_probing=1).

Итого

MTU и MSS — это базовый параметр, который отвечает за половину «загадочных» сетевых проблем. Если соединение устанавливается, но крупные страницы зависают, начинайте именно отсюда: проверьте PMTUD руками, посмотрите на ICMP, при необходимости включите MSS clamping. Это пятиминутная работа, которая экономит часы поисков «того сайта, который тормозит». В мире мобильных сетей и облачных туннелей MTU становится только важнее, и базовое понимание этой механики — гигиена сетевого инженера.