Кратко

  • В исходной модели IPv4 шлюз мог фрагментировать дейтаграмму, не помещавшуюся в следующий канал, а получатель собирал части. Неоднородность сетей скрывалась, но потеря одного фрагмента губила целое.
  • Классическая PMTUD велела источнику ставить DF и уменьшать размер после ICMP «нужна фрагментация». Если ответ отфильтровывался, малые пакеты проходили, а большие исчезали в чёрной дыре.
  • PLPMTUD дала пакетизирующему уровню возможность начинать с рабочего размера и подтверждать более крупные пробы. Путь даёт ограниченное свидетельство, отправитель хранит и пересматривает решение.

Дейтаграмма шире следующей сети

Объединённые Интернетом сети допускали разные максимальные пакеты. RFC 791, опубликованный в сентябре 1981 года, назвал адресацию и фрагментацию двумя основными функциями IP. Если дальше встречалась сеть с меньшим пределом, шлюз мог разделить дейтаграмму.

Identification, Fragment Offset и More Fragments позволяли назначению собрать части. Транспорт не обязан был знать физику каждого участка. Но цена оставалась: больше пакетов в узком месте, работа маршрутизатора, состояние сборки у получателя и незавершённая дейтаграмма при потере одной части.

Флаг Don't Fragment предлагал иной выбор. Слишком большой пакет с DF следовало отбросить. Источник получал возможность адаптировать пакетизацию, но лишь полезное объяснение отличало ограничение размера от перегрузки или случайной потери.

Path MTU — минимум MTU каналов на текущем пути. Это не вечное свойство назначения. Смена маршрута, заголовки туннеля и другая ветвь ECMP меняют доступный предел.

Вариант, который должен исправить каждый шлюз

В июле 1988 года RFC 1063 предложил записывать минимум в самом пакете. Probe MTU начинал со значения первого канала. Каждый шлюз сравнивал вход и выход, снижая поле. Reply MTU возвращал результат источнику.

Документ точно описывал компромисс: малые пакеты тратят ёмкость и заголовки, большие догадки вызывают фрагментацию, дополнительные пробы нагружают сеть и устаревают после смены пути. TCP MSS был отделён от PMTU: MSS — объём полезных данных TCP, принимаемый пиром, PMTU — размер IP-пакета, переносимый путём.

Точность требовала общей модернизации. RFC признавал, что некоторые шлюзы при обработке IP-опции ещё не знали нужных интерфейсов и поддержка могла потребовать крупных изменений программы.

Пусть говорит только отказавший канал

RFC 1191 в ноябре 1990 года уменьшил работу ядра. Источник начинает с MTU первого перехода и ставит DF. Маршрутизатор, не способный передать пакет целиком, отбрасывает его и возвращает ICMP Destination Unreachable с кодом «нужна фрагментация при DF». Источник снижает оценку.

Ранее пустое поле ICMP стало сообщать MTU следующего перехода, вызвавшего отказ. Маршрутизатор не правил каждый пакет, а свидетельствовал лишь при неудаче. Сохранение DF позволяло обнаружить последующее сужение маршрута.

Старые устройства возвращали ноль. Тогда хост спускался по вероятным «плато» MTU. Ошибиться на несколько процентов вниз было лучше, чем на один байт вверх. Таблица была советом своей эпохи, а не неизменным реестром каналов.

Путь может стать шире. Кэш должен стареть, а большие значения — проверяться нечасто. Сообщение об ошибке вправе снизить оценку, но не повысить её само по себе. Рост требует наблюдаемой доставки.

Рукопожатие проходит, данные проваливаются

Классическая PMTUD зависит от возврата ICMP. RFC 2923 в 2000 году описал чёрную дыру, возникающую, когда маршрутизатор не создаёт сообщение или межсетевой экран блокирует ICMP. Отправитель повторяет тот же слишком большой DF-пакет, не узнавая о необходимости уменьшить его.

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

Защитный откат возвращает сервис, одновременно скрывая плохую политику и закрепляя потерю производительности. Причина не всегда в фильтре: туннели добавляют заголовки, асимметрия разрывает путь данных и ответа, ICMP ограничивается по частоте, а ошибка второго уровня может отбросить кадр без полезного сообщения.

Действующая спецификация IPv6 RFC 8201 описывает то же успешное рукопожатие и остановку данных при блокировке Packet Too Big. IPv6-маршрутизаторы не фрагментируют транзит; размер выбирает источник, он же при необходимости создаёт фрагменты.

Проверить успех с края

RFC 4821 в 2007 году предложил не только ждать объяснения провала. Packetization Layer PMTUD начинает с работающего размера и посылает всё более крупные пробы. Подтверждение поднимает нижнюю границу, доказанный изолированный провал снижает верхнюю.

Пакетизирующий уровень превращает данные приложения в пакеты — обычно это TCP — и знает, какая проба подтверждена. Обычные данные остаются безопасного размера. Но тайм-аут или другие потери делают вывод неопределённым, и обычное управление перегрузкой сохраняется. Потеря не равна доказательству MTU.

Успех тоже ограничен. Одна проба подтверждает прохождение одного пакета по наблюдаемому пути в данный момент, не будущий маршрут и не все ветви multipath. Нужны интервалы, повторы, таймеры и устаревающее состояние.

PLPMTUD может использовать ICMP, но не обязана зависеть от него. Знание маршрутизатора не обесценивается; отсутствующий канал ответа теряет абсолютное право остановить поток. За устойчивость конечный узел платит логикой подтверждения, поиска, учёта заголовков и связи с congestion control.

Дейтаграммам нужен собственный ответ

IPv6 не устраняет поиск. Работа на минимуме IPv6 обходится в недоиспользование широких путей; отправка большего требует устойчивости к отсутствующему PTB.

RFC 8899, опубликованный в 2020 году, определил DPLPMTUD для дейтаграммных транспортов и приложений, включая протоколы поверх UDP, SCTP и QUIC. Если транспорт не подтверждает получение, приложение должно дать способ распознать доставленную пробу.

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

Это не одномоментное изгнание функций из ядра. Фрагментация скрывала разнообразие и усиливала цену потери. Опция 1988 года собирала точное локальное знание, требуя всех устройств. ICMP говорил лишь при ошибке, но зависел от обратного пути. Пробы конечного узла добавили факт доставки и сузили эту зависимость.

Размер как решение со сроком годности

MTU легко свести к 1500 или 1280. История показывает поверхность управления. Оператор задаёт локальный предел, маршрутизатор применяет и может сообщить его, firewall может удалить сообщение, хост хранит состояние, транспорт формирует следующий пакет. Никто не владеет всем путём.

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

Источники и границы доказательств

RFC 791 задаёт фрагментацию IPv4 и DF; RFC 1063 — опции шлюзов; RFC 1191 — классическую PMTUD, next-hop MTU, плато и старение. RFC 2923 описывает TCP-чёрные дыры. RFC 4821 задаёт пробы уровня пакетизации, RFC 8201 — IPv6, RFC 8899 — дейтаграммы.

Документы подтверждают спецификации и известные виды отказов, но не единую дату внедрения, не мировую долю использования и не текущую конфигурацию каждой сети.