минимальный TCP MSS в Linux

TCP MSS в Linux должен быть не менее 88 (include / net / tcp.h):

/* Minimal accepted MSS. It is (60+60+8) - (20+20). */ #define TCP_MIN_MSS 88U 

Мой вопрос: где они придумали «60 + 60 + 8» и почему? Я получаю, что 20 + 20 поступает из заголовка IP + заголовка TCP.

EDIT: после более пристального рассмотрения заголовков формула выглядит так:

 (MAX_IP_HDR + MAX_TCP_HDR + MIN_IP_FRAG) - (MIN_IP_HDR + MIN_TCP_HDR) 

Вопрос все еще стоит: почему ? Почему ядро ​​Linux использует эту формулу, тем самым запрещая (вынужденный поток) сегменты TCP, скажем, 20 байтов? Подумайте, iperf здесь.

EDIT2: Вот мой прецедент. Заставляя низкую MSS на сокет / соединение, все пакеты, отправленные стеком, будут иметь небольшой размер. Я хочу установить низкий MSS при работе с iperf для тестирования пакетов / вторых. Из-за этого нижнего предела для MSS я не могу получить IP-пакеты размером менее 128 байтов (Ethernet-кадры размером 142 байта). Я хотел бы приблизиться к размеру фрейма Ethernet размером 64 байта согласно RFC 2544. Теоретически это должно быть возможно: 18 + 20 + 20 <64.

2 Solutions collect form web for “минимальный TCP MSS в Linux”

Я не знаю, откуда это число, но я могу сказать, что это вне спецификации. Минимальный MTU, поддерживаемый для IP-сетей, составляет 576 байт, что составляет 512 байтов данных плюс до 64 байтов для заголовков IP + TCP и опций TCP. Это значение было выбрано так, чтобы в типичном случае давать прилично низкие накладные расходы.

Мое чтение бит кода ядра подсказывает, что отображаемое вами значение не является произвольным. TCP_MIN_MSS практика заключалась в том, чтобы просто использовать необработанную константу 64 вместо TCP_MIN_MSS . Поэтому я предполагаю, что есть какая-то странная сеть IP-over-Foo, с которой сталкиваются разработчики ядра, что заставило их решить, что они могут повысить ценность того, что вы видите.

Однако этот нестандартный тип сети я не могу сказать.

Реализация необходима для поддержки заголовков TCP и IP максимального размера, которые по 60 байт.

Реализация должна поддерживать 576-байтовые дейтаграммы, которые даже с максимальными заголовками означают более 8 байтов данных в дейтаграмме. Чтобы отправить датаграммы с более чем 8 байтами данных, фрагментация IP должна поместить не менее 8 байтов данных, по крайней мере, в один из пакетов, которые представляют фрагменты дейтаграммы. Таким образом, реализация должна поддерживать не менее 8 байтов данных в пакете.

Объединяя это, реализация должна поддерживать 60 + 60 + 8 байтовых пакетов.

Когда мы отправляем пакеты, которые являются частью потока TCP, у них есть 20-байтовый IP-заголовок (плюс опции) и 20-байтовый заголовок TCP (плюс опции). Это оставляет минимум (60 + 60 + 8) – (20 + 20) байтов, оставшихся для данных и опций. Следовательно, это максимум, который мы можем с уверенностью принять в TCP SSS реализации.

  • Как установить общий сетевой предел для каждого клиента + приоритет для подтверждений TCP
  • Linux «ip route» изменяет адрес источника TCP, но не UDP
  • открытие порта 7 (порт эха) на Linux / Debian
  • Захват данных с Fluke 1620a с помощью дескриптора файла Bash / dev / tcp
  • Как слушать все порты (UDP и TCP) или сделать их все открытыми в Debian
  • «Netstat -p» / «ss -p» не показывает процесс прослушивания порта
  • IPTables и прозрачные прокси
  • проверить прием пакетов tcp ниже уровня tcpdump
  • tcp6 в выходном netstat
  • Задержка FIN-ACK отправлена ​​по linux
  • Как «освободить» TCP-порт?
  • Linux и Unix - лучшая ОС в мире.