Кратко

  • MSS в SYN сообщает, какой объём TCP-данных способен принять отправитель этого SYN. Для двух направлений существуют независимые пределы, а общего выбора нет.
  • Реальную эффективную MSS отправитель получает, совместив удалённый предел с размером, разрешённым IP, и вычтя опции, присутствующие именно в данном пакете.
  • MSS не равна Path MTU, окну приёма, границе сообщения приложения или обещанному размеру каждого сегмента.

Число ограничивало собеседника

RFC 793 определил Maximum Segment Size как TCP-опцию вида 2 длиной четыре октета. Её 16-битное поле сообщало максимальный размер приёма у TCP, отправившего сегмент с SYN. Опция разрешалась только в SYN.

Если клиент объявил 1460, сервер обязан учитывать этот предел в направлении сервер→клиент. Если сервер объявил 1200, он ограничил клиент→сервер. Разные интерфейсы, буферы и политики делают разные значения нормальными.

RFC 879 в 1983 году назвал MSS объявлением, которое часто ошибочно называют согласованием. Согласование породило бы один общий параметр. TCP не сравнивал две цифры и не выбирал победителя: каждый приёмник отвечал только за собственную способность.

Поле «negotiated MSS» в телеметрии уничтожает автора и направление. После такой агрегации корректную асимметрию легко принять за сбой или применить предел не к тому потоку.

Почему по умолчанию было 536

Исторический минимум IPv4 требовал принимать и собирать датаграмму 576 октетов. После фиксированных 20 октетов IPv4 и 20 TCP оставалось 536 октетов данных. RFC 879 уточнил: MSS считает данные, не заголовки.

SYN и FIN занимают позиции последовательности, но не становятся данными MSS. Длина полезной нагрузки, длина IP-пакета и движение sequence number — разные величины.

RFC 1122 потребовал поддерживать отправку и приём MSS. Если опция не пришла при установлении, следовало считать send MSS равной 536. Современный RFC 9293 сохраняет 536 для IPv4 и задаёт 1220 для IPv6: 1280 минус 40 IPv6 и 20 TCP.

Отсутствие опции не означает неограниченное разрешение. Оно включает консервативный default. Эти значения не измеряют современный маршрут и не задают оптимальный размер каждого пакета.

Удалённый предел был только одним входом

RFC 1122 и RFC 9293 отделяют полученную SendMSS от effective send MSS. Отправитель должен взять меньший предел между возможностью удалённого приёмника и максимальным размером, разрешённым IP, а затем учесть текущие заголовки.

Приёмник может выдержать 9000, хотя туннель по пути не пропустит соответствующую датаграмму. Широкий путь, наоборот, не разрешает нарушить объявленные 1200. Конечный узел и путь дают разные свидетельства.

Path MTU Discovery посвящена тому, как отправитель пересматривает размер пути по ошибкам и пробам доставки. MSS даёт отдельное направленное ограничение приёмника. Существующая статья PMTUD прямо исключила учебник MSS.

Наблюдаемые сегменты могут быть меньше из-за объёма данных приложения, окон, перегрузки, повторной передачи, опций и планирования. Малый payload сам по себе не доказывает MSS clamping.

Переменные заголовки считал тот, кто создавал пакет

Заголовки IP и TCP меняются. Нужно ли заранее вычесть из объявления все опции, которые могут появиться позже? RFC 6691 связал расчёт с обладателем знания.

Из эффективного MTU для объявляемой MSS вычитаются только фиксированные заголовки IP и TCP. При создании конкретного пакета отправитель уменьшает данные на фактическую длину его опций. Приёмник во время SYN не знает будущих сочетаний, а постоянное поле не может их выразить.

Если приёмник оставит запас и отправитель вычтет его повторно, сегменты станут неоправданно малы. Если никто не учтёт опции, пакет окажется чрезмерным и может фрагментироваться или исчезнуть.

RFC 6691 отверг основу старого примера RFC 879, где IP Security вычиталась прямо из объявления. Verified erratum исправлял выравнивание в арифметике примера, но более позднее правило показало, что вычитание относилось к другой стадии. RFC 9293 консолидировал современную норму.

Erratum 6381 к RFC 1122 предлагал убрать якобы двойное вычитание IP-опций, но был отклонён. Проверяющие различили место, зарезервированное IP, и опции, переданные TCP. Статус erratum нельзя опускать.

Слишком малый предел тоже имеет цену

RFC 6691 предупреждает: малая MSS может помешать PMTUD использовать более широкий путь. Связь работает, но число пакетов и overhead растут, а скрытая возможность перестаёт наблюдаться.

Для интерфейса с переменным эффективным MTU нельзя объявлять только лучший случай. Сжатие заголовков иногда возвращает полный заголовок для синхронизации, в том числе при повторе. Рекомендован наименьший эффективный MTU.

В IPv6 jumbogram значение 65535 трактуется как бесконечность, а реальный максимум определяет PMTUD. Это выход из 16-битного поля, не бесконечная способность пути.

Реестр хранит синтаксис

Реестр TCP Parameters IANA сохраняет вид 2, длину 4 и имя Maximum Segment Size со ссылкой на RFC 9293. Он подтверждает общий синтаксис, но не текущие значения, переписывание или доставку.

RFC 9293 заменил RFC 793, 879, 6691 и TCP-требования RFC 1122. Разделение осталось: приёмник объявляет своё; отправитель объединяет это с IP; переменный расход учитывает создатель пакета.

MSS — предел с источником и направлением. Надёжная запись хранит два объявления и два эффективных расчёта, а не одно вымышленное соглашение.

Источники и границы

Источники доказывают спецификацию, изменения и регистрацию, но не долю внедрения, defaults систем, частоту clamping, MTU реального пути или причину инцидента.