PMTUD и чёрные дыры

Отправитель не знает заранее, какой размер пакета пролезет через весь путь. Он выясняет это по ходу дела, и обычно всё держится на ICMP.

Как задумано

Пакет уходит с флагом DF. Если на каком-то участке он больше допустимого, маршрутизатор отбрасывает его и отвечает «ICMP fragmentation needed» с указанием нового размера. Отправитель уменьшает пакет и запоминает значение для этого маршрута.

Как ломается

Достаточно, чтобы ICMP зарезали на одном участке. Тогда отправитель ничего не узнаёт, продолжает слать пакеты по 1500, а они тихо исчезают. Соединение устанавливается, мелкие данные проходят, крупные зависают. Со стороны это выглядит как «сайт открылся, картинка не грузится» или «сессия в ssh встаёт на выводе большого файла».

Проверить свою сторону просто: ping -M do -s 1472 до нужного адреса. Если этот пинг не проходит, а с меньшим размером проходит, вопрос уже не в приложении.

Что с этим делают

Вариантов три: разрешить ICMP на всём пути, править MSS на маршрутизаторе, либо уменьшить MTU на интерфейсе. Первый вариант правильный, второй быстрый, третий грубый: он режет скорость всем соединениям сразу.

Отдельно стоит помнить про IPv4 против IPv6: в шестой версии маршрутизатор фрагментировать не должен, там PMTUD не роскошь, а обязательная часть работы стека.