3.3.3 Фрагментация
Уровень IP может реализовать механизм преднамеренной фрагментации дейтаграмм.
Будем обозначать максимальный размер передаваемой дейтаграммы IP для конкретной комбинации отправитель — получатель (и возможно TOS), как EMTU_S (Effective MTU for sending — эффективное значение MTU для передачи).
Хост должен реализовать механизм, позволяющий транспортному уровню выяснять значение MMS_S (максимальный размер сообщения транспортного уровня, которое может быть передано) для данной комбинации {отправитель, получатель, TOS} (см. функцию GET_MAXSIZES в параграфе 3.4). Если локальной фрагментации не производится, должно выполняться условие:
MMS_S = EMTU_S - <размер заголовка IP>
и значение EMTU_S не должно быть больше MTU для сетевого интерфейса, соответствующего адресу отправителя дейтаграммы.
Отметим, что значение <размер заголовка IP> в этом выражении будет равно 20, если IP не резервирует пространство для вставки опций IP в дополнение к опциям, устанавливаемым на транспортном уровне.
Хост, не реализующий локальную фрагментацию, должен обеспечивать получение транспортным (для TCP) или прикладным (для UDP) уровнем значения MMS_S от уровня IP и передачу дейтаграмм, размер которых не превышает MMS_S.
В общем случае желательно избегать локальной фрагментации и выбирать значение EMTU_S достаточно небольшим для того, чтобы избежать фрагментации на любом из шлюзов по пути доставки. При отсутствии актуальной информации о минимальном значении MTU для пути уровень IP должен использовать значение EMTU_S <= 576, если получатель не находится в подключенной сети (для этого случая используется принятое в сети значение MTU).
Значение MTU для каждого физического интерфейса должно быть настраиваемым.
Реализация уровня IP может использовать флаг конфигурации All-Subnets-MTU (MTU для всех подсетей), показывающий, что значение MTU в подключенной сети будет использоваться и для других подсетей этой сети (но не для других сетей). Таким образом, этот флаг заставляет использовать маску сети взамен маски подсети для выбора значения EMTU_S. Для многодомных хостов флаг All-Subnets-MTU требуется для каждого сетевого интерфейса.
- Обсуждение:
Выбор корректного размера дейтаграмм для передачи данных является сложной задачей [IP:9].
- В общем случае от хоста не требуется прием дейтаграмм IP размером более 576 байтов (включая заголовок) и хост не должен передавать дейтаграмм большего размера без предварительного явного согласования с хостом-получателем. Таким образом, MMS_S задает только верхнюю границу размера дейтаграмм, которые может передавать транспортный уровень. Даже при MMS_S > 556 транспортный уровень должен ограничивать свои сообщения размером 556 байтов при отсутствии информации от хоста-получателя о возможности принимать более крупные сообщения.
Некоторые транспортные протоколы (например, TCP) обеспечивают возможность явного уведомления отправителя о максимальном размере дейтаграмм, которые другая сторона может принимать и собирать [RFC879]. На уровне IP подобного механизма не существует.
Транспортный протокол, предполагающий EMTU_R > 576 (см. параграф 3.3.2), может передавать дейтаграммы большого размера другим хостам, поддерживающим такой же протокол.
- В идеальном случае хост должен ограничивать свое значение EMTU_S для данного получателя до минимального значения MTU во всех сетях на пути к получателю во избежание фрагментации. Фрагментация IP, будучи формально корректной, может существенно снижать производительность протокола транспортного уровня, поскольку потеря одного фрагмента будет требовать повторной передачи всех фрагментов сообщения [IP:9].
Поскольку практически все сети в среде Internet поддерживают MTU=>576, настоятельно рекомендуется использовать значение 576 для дейтаграмм, передаваемых за пределы локальной сети.
Для определения MTU на данном пути предлагается передавать фрагмент дейтаграммы с нулевым смещением и ожидать отклика ICMP Time Exceeded в результате тайм-аута при сборке (остальные фрагменты не передаются). Такое сообщение будет содержать заголовок самого большого из оставшихся фрагментов в своем теле. Ведутся эксперименты и с более прямыми механизмами, но они еще не адаптированы (см. например RFC 1063).