Маленькие ответы проходят, большие зависают: как проверить PMTUD

Если короткая страница открывается, а большой ответ зависает, проверьте зависимость сбоя от размера передачи и сети клиента. Один из возможных виновников — сломанный PMTUD: отправитель не узнаёт, что пакеты слишком велики для участка маршрута. Но сам симптом ещё не доказывает проблему MTU.

Начните с двух статических файлов на одном узле, затем сравните IPv4 и IPv6 и только после этого проверяйте размер пакетов. Так вы отделите сетевую гипотезу от медленной генерации ответа, ошибки сжатия и тайм-аута приложения.

Почему соединение есть, а загрузка стоит

MTU — максимальный размер IP-пакета, который проходит через конкретный канал без фрагментации. Path MTU — наименьшее такое ограничение по пути. Размер HTTP-файла и MTU не равны: большой файл передаётся множеством пакетов.

Классический PMTUD использует обратные сообщения сети. Для IPv4 это ICMP «Fragmentation Needed» при запрете фрагментации, для IPv6 — ICMPv6 «Packet Too Big». Если такие сообщения теряются или блокируются, отправитель может продолжать передачу неподходящими пакетами. Механизм описан в RFC 2923 и RFC 8201.

Небольшой обмен при установлении TCP-соединения при этом может проходить. Зависание начинается при передаче данных, иногда уже во время TLS. Поэтому успешный ping или установленное соединение не гарантируют загрузку страницы.

1. Сравните маленький и большой ответ в одинаковых условиях

Выберите два безопасных статических файла разного размера на своём сайте. Они должны обслуживаться одним доменом и по возможности одним узлом; не сравнивайте короткий ответ из кеша CDN с тяжёлым отчётом, который строит база данных.

Из проблемной сети выполните GET для каждого файла. Ниже пример для Linux/macOS: замените URL на существующий публичный файл без токенов.

curl -4 --http1.1 --connect-timeout 5 --max-time 30 \
  -sS -o /dev/null \
  -w 'ip=%{remote_ip} code=%{http_code} bytes=%{size_download} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/test-large.bin

Команда читает тело, а не только заголовки; параметры описаны в документации curl. Предел 30 секунд здесь — ограничение диагностического запуска, а не норматив скорости сайта.

Запишите IP, HTTP-код, полученные байты, время первого байта и сообщение об ошибке. Код 200 при тайм-ауте не означает, что файл скачан полностью. Не добавляйте -k: ошибка сертификата должна оставаться видимой.

Повторите сравнение из другой сети, затем замените -4 на -6, если у сайта и клиента есть IPv6. При нескольких адресах используйте проверку каждого A/AAAA-узла с сохранением имени HTTPS. Иначе разные попытки могут попасть на разные серверы.

2. Определите, есть ли основание проверять PMTUD

• Оба файла долго ждут первый байт. Сначала смотрите приложение, очередь обработки и upstream.
• Большой статический файл зависает только из одной сети. Проверяйте маршрут, туннели и сетевую фильтрацию; PMTUD становится рабочей гипотезой.
• Сбой есть только при сжатии или только в одном HTTP-протоколе. Отдельно проверяйте соответствующий слой. Это не доказательство неверного MTU.
• Есть явный HTTP-отказ. Разберите его причину в серверных журналах, прежде чем менять сеть.

Сравнение с HTTP/1.1 помогает сузить диагностику TCP-пути, но не проверяет HTTP/3 поверх QUIC. Успех через VPN тоже неоднозначен: меняются маршрут, адрес выхода и параметры туннеля.

3. Проверьте размер пакета, не меняя настройки сервера

В Linux с iputils можно послать несколько IPv4-проб с запретом фрагментации. Используйте тот адрес своего сервера, который участвовал в HTTP-проверке:

ping -4 -c 3 -W 2 -M do -s 1472 example.com
ping -4 -c 3 -W 2 -M do -s 1200 example.com

В iputils ping параметр -s задаёт размер данных. Для обычного IPv4 без IP-опций 1472 байта данных плюс 8 байт ICMP и 20 байт IP дают пакет 1500 байт. Это тестовый размер, а не рекомендация выставить MTU 1500 на любом интерфейсе.

Если меньшая проба проходит, а большая получает «message too long» или сообщение о необходимости фрагментации, ограничение размера обнаружено. При локальном «message too long» пакет мог вообще не выйти на маршрут. Если большая проба просто молчит, возможны как потеря пакета, так и фильтрация ICMP; одного результата недостаточно.

Эти ключи относятся к Linux iputils, а не к ping в macOS или Windows. ICMP-пробы также могут идти иначе, чем HTTPS. Для дополнительного разбора маршрута пригодится руководство по чтению MTR, но обычный MTR не доказывает исправность PMTUD.

4. Подтвердите причину и проверьте исправление

Администратору нужны захваты трафика на доступных концах проблемного участка: повторные передачи TCP, размеры пакетов и сообщения ICMP/ICMPv6. Важно выяснить, приходит ли уведомление о слишком большом пакете именно отправителю данных; при скачивании это сервер или CDN. Отсутствие сообщения в одной точке ещё не показывает, где оно пропало.

После подтверждения проверяют MTU туннелей и правила пропуска необходимых ICMP-сообщений. Не отключайте межсетевой экран целиком и не уменьшайте MTU на всех серверах наугад. Коррекция TCP MSS может быть обходным решением для конкретного туннеля, но не исправляет UDP/QUIC.

Критерий результата — полная загрузка того же большого файла из ранее проблемной сети, на нужном IP и протоколе, без обрывов. Повторите маленький и большой запросы и сравните с исходными замерами.

Что передать специалисту

Web-Puls помогает наблюдать доступность публичного URL, однако успешная проверка короткого ответа из внешней точки не исключает сбой PMTUD у отдельного клиента.

Если требуется разбор сетевого участка, отправьте заявку на диагностику: укажите публичные URL, время и часовой пояс, сеть, IPv4/IPv6, размеры ответов и результаты сравнений. Это позволит оценить задачу и согласовать формат работ; пароли, cookies и необработанные дампы с пользовательскими данными к заявке не прикладывайте.