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

TCP MSS в Linux должно быть не менее 88 (включая / 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.

РЕДАКТИРОВАТЬ: После более пристального взгляда на заголовки, формула выглядит для меня следующим образом:

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

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

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

linux networking tcp linux-kernel Мирча Герцан
источник

Как это запрещает сегменты TCP 20 байтов?

Дэвид Шварц

MSS означает Максимальный размер сегмента, его верхний предел (не нижний) для размера сегмента в конкретном соединении. TCP_MIN_MSS определяет нижнюю границу для этого предела. Таким образом, он никоим образом не запрещает сегменты размером менее 88 байтов, он просто заявляет, что MSS для любого соединения должен быть> = 88 байтов.

gelraen

Конечно! Извините, что не достаточно ясно. Пожалуйста, смотрите последние изменения.

Мирча Герзан,

Почему вы дали срок действия награды? Ответ Дэвида, по крайней мере, проясняет ситуацию. Разница между его ответом и моим заключается в том, что мы говорим о разных минимумах. Для чего это стоит, есть третий минимум, который составляет 41, или 20 + 20 + 1 байт данных TCP. Таким образом, минимальный размер пакета зависит от причины, по которой вы спрашиваете. Я ожидаю, что 68 - правильный ответ в тех случаях, когда ядро использует TCP_MIN_MSS.

Уоррен Янг

Я все еще не удовлетворен ответом. Я до сих пор не вижу причины, по которой ядро не позволяет мне навязывать произвольную маленькую MSS приложению. Я хотел бы иметь (постоянный поток TCP-загруженных) IP-пакетов 41 байта, но я не могу, из-за TCP_MIN_MSS. Почему это не может быть 1? Какой RFC это нарушит? Какую теоретическую / практическую проблему это вызовет? Вы уверены, что это "за пределами спецификации"? "Разные минимумы"? Здесь есть только один минимум интереса: самый маленький MSS, разрешенный ядром.

Мирча Герзан,

Ответы:

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

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

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

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

Дэвид Шварц
источник

Хотя MSS не включает заголовок (это просто полезная нагрузка), и 60шоу появляется дважды

Майкл Мрозек

Реализация должна поддерживать пакет с заголовком максимального размера, но мы не отправляем заголовок максимального размера. Таким образом, разница между максимумом и тем, что мы действительно посылаем, доступна для данных и должна быть добавлена в MSS.

Дэвид Шварц

Итак, вы объяснили 8 байтов. Я не знаю, что вы подразумеваете под заголовком «TCP / IP». Я знаю заголовок IP и TCP. И, как указал Майкл, 60 появляется дважды. И RFC обсуждает только «эффективную MSS», а не минимальную.

Мирча Герзан,

60 отображается дважды, один раз для заголовка IP и один раз для заголовка TCP.

Дэвид Шварц

68 это просто фрагментация. «60 + 60 + 8» может быть фрагментированным, так зачем тогда заботиться о фрагментации? Даже «68 + 20» могут быть фрагментированы. И почему «должна» другая сторона «принять» «60 + 60 + 8»? «Принять» как в «без фрагментации»? Итог: почему я не могу отправить "20 + 20" + 10 байт данных?

Мирча Герзан

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

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

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

Уоррен Янг
источник

576 - это MTU для дейтаграмм . В этом случае важны ограничения пакетов, а не датаграммы, поскольку пакеты TCP устанавливают бит DF.

Дэвид Шварц

Минимальный MTU, определенный для дейтаграмм IP, и пакеты TCP также являются дейтаграммами IP.

gelraen

Правильно, но это ограничение TCP для пакетов, а не для дейтаграмм, потому что дейтаграммы TCP никогда (обычно) не фрагментируются. Единственный смысл, в котором имеет значение 576-байтовое правило дейтаграммы, состоит в том, что оно означает, что реализация должна поддерживать не менее 8 байтов данных в пакете (отсюда 8 в формуле). В противном случае было бы невозможно фрагментировать 576-байтовую дейтаграмму.

Дэвид Шварц