мінімальний 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.

EDIT: Після більш детального розгляду заголовків, формула шукає мене так:

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

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

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

— Мірча Герзан
джерело

Як це забороняє сегменти 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, дозволений ядром.

— Mircea Gherzan

Відповіді:

Потрібна реалізація для підтримки заголовків 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показується двічі

— Michael Mrozek

Реалізація повинна мати можливість підтримувати пакет із заголовком максимального розміру, але ми не надсилаємо заголовок максимального розміру. Різниця між максимальним і тим, що ми насправді надсилаємо, є доступною для даних і повинна бути додана до 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-байтну дейтаграму.

— David Schwartz