минимальный 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 реализации.

  • netstat показать номер порта вместо имени процесса
  • Не опаснее ли подключаться к сети как root?
  • SIGSEGV: 0x0000000000000000 in ?? ()
  • Как мне зарезервировать порты для моего приложения?
  • Socksifying qemu-kvm с использованием tsocks
  • Я хочу статический IP-адрес для моего (сетевого или компьютерного)?
  • Сервер ретрансляции для общего трафика TCP?
  • Есть ли способ настроить TCP на потерю пакетов и повторную передачу?
  • Есть ли способ имитировать сокет, застрявший в CLOSE_WAIT или FIN_WAIT2?
  • Мониторинг портов на маршрутизаторе NAT на основе GNU / Linux
  • Проблема с сетью в IBM x3650 после установки Ubuntu 14.04.1
  • Linux и Unix - лучшая ОС в мире.