Який найбільший розмір безпечного пакету UDP в Інтернеті

201

Я прочитав ряд статей про розміри пакетів UDP, але не зміг прийти до висновку щодо правильності.

Ряд послуг обмежує найбільший пакет UDP до 512 байт (як dns)

З огляду на мінімальний MTU в Інтернеті - 576, а розмір заголовка IPv4 - 20 байт, а заголовка UDP - 8 байт. Це залишає 548 байтів доступними для даних користувачів

Чи зможу я використовувати пакети розміром до 548 без фрагментації пакетів? Або є щось, про що знали творці DNS, і тому вони обмежили його 512 байтами.

Чи можу я безпечно піднятися вище, ніж 548 байт?

— КМ
джерело

2

Дублікат см stackoverflow.com/questions/900697 / ...

— ChrisW

10

Це мало інше питання. Я запитую, який є найбільший пакет, який я можу надсилати через Інтернет (без будь-яких знань про інші мережі чи зондування), який не матиме фрагментації. По суті це максимальний безпечний розмір, який буде працювати на всіх, не турбуючись про зондування з'єднання.

— KM

2

Ви не можете усунути можливість фрагментації, але це не робить речі менш безпечними. Якщо фрагмент буде скинутий, це те саме, як якщо б весь пакет був скинутий, що в будь-якому випадку відбувається з UDP. Небезпечним було б, якби пакет перевищував мінімальний розмір, який маршрутизатори повинні підтримувати, і, таким чином, не гарантується його доставка (проти гарантованої доставки). Тут надходить 512-байтний показник.

— Beejor

129

Це правда, що типовий заголовок IPv4 становить 20 байт, а заголовок UDP - 8 байт. Однак можна включити параметри IP, які можуть збільшити розмір заголовка IP до 60 байт. Крім того, іноді для проміжних вузлів необхідно інкапсулювати дейтаграми всередині іншого протоколу, такого як IPsec (використовується для VPN тощо), щоб перенести пакет до місця призначення. Тож якщо ви не знаєте MTU на конкретному мережевому шляху, краще залишити розумний запас для іншої інформації заголовка, яку ви, можливо, не передбачали. Як правило, це вважається корисним навантаженням UDP 512 байтів, хоча навіть це не залишає достатньо місця для заголовка IP максимального розміру.

— mark4o
джерело

36

Щоб було зрозуміло: малий розмір, щоб уникнути фрагментації, не робить доставку пакету "Безпечним", все ще існує нескінченна кількість можливостей, що робить доставку недостовірною, наприклад, собака з'їв мій мережевий кабель. Це сказав; наявність менших фрагментів робить доставку "більш безпечною", тому що якщо їх було більше, і будь-хто з тих, хто ніколи цього не робив - весь пакет (дейтаграма) випадає з UDP.

— markmnl

3

Для цілей питання можна було б використовувати плакатне визначення "безпечний", а не якесь визначення у книзі стандартів, яке вони ніколи не бачили.

— Астара

Чи відомо, що маршрутизатори в реальному світі скидають пакети UDP, а не фрагментувати їх?

— користувач253751

60

Теоретичний межа (для Windows) для максимального розміру пакету UDP становить 65507 байт. Це задокументовано тут :

Правильний максимальний розмір повідомлення UDP - 65507, що визначається наступною формулою: 0xffff - (sizeof (IP Header) + sizeof (UDP Header)) = 65535- (20 + 8) = 65507

При цьому, більшість протоколів обмежуються значно меншими розмірами - як правило, або 512 або зрідка 8192. Ви часто можете надійно перевищувати 548, якщо ви користуєтеся надійною мережею - але якщо ви широко транслюєтесь через Інтернет, то більше Ви йдете, тим більше шансів на те, що у вас виникнуть проблеми та втрати передачі пакетів.

— Рід Копсі
джерело

39

Посилання Microsoft не є нормативним посиланням. RFC - це нормативна довідка; і те, що ви цитували, стосується лише IPv4.

— Маркіз Лорн

2

Тільки тому, що MS дозволяє це не означає, що це завжди гарна ідея, оскільки проміжні маршрутизатори тощо можуть бути змушені фрагментувати більші розміри пакетів (як ви вже згадували).

— rogerdpack

1

@EJP Вони не пояснюють це чітко за посиланням Microsoft, але, здається, це є необхідним наслідком IPv4: Поле загальної довжини IPv4 становить 16 біт, і це значення повинно включати довжину заголовка IP та довжину Заголовок UDP

— jtpereyda

@jtpereyda Я цілком усвідомлюю все це. Моя думка - це саме те, що я вже заявив: ви повинні навести нормативні посилання там, де вони існують.

— Маркіз Лорнський

Я не думаю, що максимальний розмір пакету UDP коли-небудь складе 65 507 байт, враховуючи, що моя wifi-карта (IEEE 802.3) може робити лише 1500 MTU, а рамки jumbo - лише 9 кбайт.

— Крістіан Стюарт

52

Максимальне безпечне завантаження UDP - 508 байт. Це розмір пакету 576, мінус максимальний 60-байтовий IP-заголовок і 8-байтовий заголовок UDP. Будь-який корисний вантаж UDP такого розміру або менший гарантовано буде доставлений через IP (хоча не гарантовано буде доставлений). Будь-який великий розмір може з будь-якої причини випадати прямо з будь-якого маршрутизатора. За винятком маршруту, призначеного лише для IPv6, де максимальне корисне навантаження становить 1212 байт. Як уже згадували інші, додаткові заголовки протоколу можуть бути додані за певних обставин. Натомість може віддавати перевагу більш консервативне значення, що становить близько 300-400 байт.

Будь-який пакет UDP може бути фрагментованим. Але це не надто важливо, оскільки втрата фрагмента має такий же ефект, як і втрата нефрагментованого пакету: весь пакет випадає. З UDP це станеться в будь-якому випадку.

Цікаво, що максимальний теоретичний розмір пакету становить близько 30 МБ (1500 Ethernet MTU - 60 IP заголовків x 65 536 максимальна кількість фрагментів), хоча ймовірність його потрапляння була б нескінченною.

Джерела: RFC 791, RFC 2460

— Beejor
джерело

2

Будь-який пакет UDP за замовчуванням вважається "_U_nreliable". Єдиний безпечний розмір пакету UDP, який ви могли б очікувати на отримання, буде 1, нефрагментований пакет. Якщо ви хочете "безпечні" пакети, використовуйте протокол пакетів поверх TCP.

— Астара

26

@Astara Щоправда, за своєю природою UDP є ненадійним. Але питання полягає в тому, чи гарантовано доставку пакету заданого розміру, чи не гарантовану доставку. Пакети з певним розміром можуть бути (і скинуті) будь-яким маршрутизатором з будь-якої причини, тоді як менші з них повинні докладати всіх зусиль, відповідно до галузевих стандартів. Тож "безпечний" в цьому випадку означає "чи мій автомобіль поміститься під мостом", а не "чи моя машина застрягне в трафіку".

— Beejor

1

Я рекомендую перестати повторювати те, що сказав якийсь випадковий хлопець, і перевірити факти, адже UDP насправді досить надійний. До речі, у мене є безпечні пакети поверх UDP без зайвих витрат на TCP. openmymind.net/How-Unreliable-Is-UDP

— Пабло Аріель

5

UDP не "ненадійний" через кількість випадених пакетів, а через те, що пакети можуть бути (і є) відкинуті. Ви не можете "покластися" на будь-який прихід, замовлення або підтвердження конкретного пакету. Дані неміцні, і це як би сказати, що керування автомобілем працює 99% часу і 89% у правильному напрямку - є надійним. Мало того, що UDP не дуже підходить для багатьох речей, просто для того, щоб вимагати, щоб ви в основному написали на ньому власну версію "TCP". Ось захоплюючий випадок із реального світу у грі Dev world (хоч трохи застарілий): gamasutra.com/view/feature/131781

— Beejor

@Beejor Ви були на правильному шляху, але "це вимагає, щоб ви в основному писали власну версію" TCP "на вершині", явно неправильно. UDP чудово підходить для трансляції та чудово для швидкого надсилання «некритичних» даних. (Що стосується ігор), ви можете відкрити (LAN) сервери / послуги за допомогою UDP та використовувати UDP для швидкого надсилання локацій гравців. Якщо один пакет скидається; вам все одно, оскільки наступний пакет матиме більш сучасне місце розташування інших гравців. TCP може мати пакети "поза замовленням", мати накладні витрати і не дуже добре підключати один до багатьох. У деяких випадках UDP може застосовуватися більше.

— Пол

46

576 - мінімальний максимальний розмір буфера для повторної збірки , тобто кожна реалізація повинна мати можливість збирати пакети принаймні такого розміру. Докладніше див. У IETF RFC 1122 .

— user607811
джерело

2

Якщо і лише якщо у вас є мережа, яка не підтримує IPv6. Якщо він несе IPv6, використовуйте максимальний розмір пакета заголовків IPv6, а потім віднімайте заголовки інкапсуляції для виконання IPv4 над IPv6. ;-)

— Астара

@Astara У IPv6 фрагментацію виконує відправник, тому немає проблем із хитрими несумісними проміжними маршрутизаторами. І якщо одержувач не є вбудованим розміром обмеженим пам’яттю, він, ймовірно, може зібрати пакети до 64 кБ принаймні.

— користувач253751

@ user253751 Фрагменти можуть не лише несумісні маршрутизатори. Існує Path MTU Discovery, але навіть цього недостатньо для повного усунення фрагментації.

— dstromberg

@dstromberg У яких ситуаціях маршрутизаторам IPv6 дозволяється фрагментувати дейтаграми?

— користувач253751

@ user253751 У мене ще не так багато IPv6, але ось один приклад: уявіть собі мережу IPv6, що надсилає перемички (> 65536 байт) в іншу мережу IPv6, яка також підтримує перемикання. Далі припустимо, що Path MTU Discovery каже, що ці джембограми повинні підтримуватися без фрагментації. Але тоді маршрутизатор замикається на живлення, і частина мережевого шляху замінюється обладнанням, не налаштованим для перемичок.

— dstromberg

14

У цій статті описано максимальний блок передачі (MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit . У ньому йдеться про те, що хости IP повинні мати можливість обробляти 576 байт для IP-пакету. Однак він зазначає, що мінімум дорівнює 68. RFC 791: "Кожен Інтернет-модуль повинен мати можливість пересилати дейтаграму на 68 октетів без подальшої фрагментації. Це тому, що заголовок Інтернету може бути до 60 октетів, а мінімальний фрагмент - 8 октетів. . "

Таким чином, безпечний розмір пакета 508 = 576 - 60 (IP заголовок) - 8 (udp заголовок) є розумним.

Як зазначає user607811, фрагментацію інших мережевих шарів необхідно повторно зібрати. https://tools.ietf.org/html/rfc1122#page-56 3.3.2 Повторна збірка IP-рівень ОБОВ'ЯЗКОВО здійснити повторний монтаж IP-дейтаграм. Ми позначаємо найбільший розмір дейтаграми, який можна повторно зібрати EMTU_R ("Ефективний MTU для отримання"); це іноді називається "розміром буфера для повторної збірки". EMTU_R ОБОВ'ЯЗКОВО бути більшим або рівним 576

— edW
джерело

11

Мінімальний розмір буфера IPv4 - 576, IPv6 - 1500. Звідси віднімайте розміри заголовків. Дивіться мережеве програмування UNIX від W. Richard Stevens :)

— Микола Фетисов
джерело

1

Мінімум, звичайно. Дякуємо, що помітили його. Поняття не маю, як ніхто не помітив помилки протягом багатьох років.

— Микола Фетисов

1

Хоча IPv6 може мати мінімальний буфер для повторного складання 1500, пакетів IPv6 не можна фрагментувати, а мінімальний IPv6 MTU - 1280. Кінцевому пристрою ніколи не потрібно збирати фрагментований пакет IPv6.

— Рон Моупін

1

Пакети @RonMaupin IPv6 можуть бути фрагментовані кінцевими точками. Тільки не маршрутизаторами між ними.

— Навін

3

@Navin, ні, пакети IPv6 не будуть фрагментовані, дані повинні бути фрагментовані, перш ніж вони будуть упаковані в пакети IPv6, але самі пакети не фрагментовані. Є різниця. На відміну від заголовків пакетів IPv4, у яких є поля для вирішення фрагментації, заголовки пакетів IPv6 не мають нічого спільного з фрагментацією. Заголовок пакетів IPv6 набагато простіше, ніж заголовок пакету IPv4.

— Рон Моупін

6

512 - ваша найкраща ставка. Він використовується в іншому місці і є хорошим парним числом (половина 1024).

— Джастін Нісснер
джерело

6

Зважаючи на те, що розмір IPV6 має розмір 1500, я запевняю, що оператори не надаватимуть окремі шляхи для IPV4 та IPV6 (вони обидва IP різних типів), примушуючи їх до обладнання для ipv4, яке було б старим, надмірним та дорожчим для обслуговування і менш надійний. Це не мало б сенсу. Крім того, це може бути легко вважати наданням пільгового режиму для деякого трафіку - ні ні, згідно з правилами, вони, ймовірно, не надто піклуються (якщо не потрапляють).

Тож 1472 має бути безпечним для зовнішнього використання (хоча це не означає, що додаток на зразок DNS, який не знає про EDNS, прийме його), і якщо ви говорите про внутрішні мережі, ви, швидше за все, зможете дізнатись вашу мережеву розкладку. розміри пакетів jumbo застосовуються як для не фрагментованих пакетів, так і для 4096 - 4068 байт, а для карт Intel з 9014 байтними буферами, розмір пакету ... зачекайте ... 8086 байт, було б максимум ... збігом? снайпер

**** ОНОВЛЕННЯ ****

Різноманітні відповіді дають максимальні значення, дозволені одним постачальником SW або різні відповіді, припускаючи інкапсуляцію. Користувач не запитував найменше можливе значення (наприклад, "0" для безпечного розміру UDP), але найбільший розмір безпечного пакета.

Значення інкапсуляції для різних шарів можуть бути включені кілька разів. Оскільки після того, як ви інкапсулювали потік, нічого не забороняє, скажімо, шар VPN нижче цього і повне дублювання шарів інкапсуляції вище цього.

Оскільки питання стосувався максимально безпечних значень, я припускаю, що вони говорять про максимальне безпечне значення для пакету UDP, який можна отримати. Оскільки жоден пакет UDP не гарантується, якщо ви отримуєте UDP-пакет, найбільший безпечний розмір буде 1 пакет за IPv4 або 1472 байти.

Примітка - якщо ви використовуєте IPv6, максимальний розмір складе 1452 байт, оскільки розмір заголовка IPv6 становить 40 байт проти 20-ти байтного розміру IPv4 (і в будь-якому випадку потрібно все ж дозволити 8 байт для заголовка UDP).

— Астара
джерело

1

як ти обчислюєш 1472? ethernet має MTU 1500, це те, про що ви маєте на увазі?

— rogerdpack

4

@rogerdpack Я думаю, що він означає, що оскільки IPv4 та IPv6, ймовірно, мають багато інфраструктури, і що IPv6 набуває відносно популярності, слід безпечно вважати обмеження IPv6 (таким чином, 1500). Наскільки обґрунтовані ці міркування, однак, я не можу сказати.

— Томас

2

1500 повинні підтримуватися сумісними компонентами IPv6 в мережевій "ланцюжку" - якщо використовується IPv4, який може пересуватися по ланцюгу, що підтримує IPv6 (хоча зворотне значення не відповідає дійсності), то оскільки розмір заголовка IPv4 становить 20 байт, і Розмір заголовка UDP становить 8 байт, що дозволить залишити 1500-20-8 = 1472 як максимально безпечний розмір (оскільки IPv6 не дозволяє фрагментувати). Зауважте - якщо люди додають достатню кількість шарів капсулювання, можливо, не може бути місця для DATA. Оскільки ви попросили MAX, ви припускаєте, що кілька шарів інкапсуляції накладні НЕ використовуються.

— Астара

" 1500 повинні підтримуватися компонентами, сумісними з IPv6 в мережевій мережі. Ні, мінімальний IPv6 MTU - 1280. Ethernet MTU - 1500.

— Рон Маупін,

@RonMaupin - оригінальний Q був найбільшим розміром безпечного пакету UDP, а не MTU. Див. RFC2460. Окрім згадування про MTU у 1280 октетів, він зазначає: Вузли повинні мати можливість приймати фрагментований пакет, що при повторному зібранні становить до 1500 октетів. Поводження з пакетами більше 1500 не є обов'язковим.

— Астара

6

Я прочитав тут кілька хороших відповідей; однак, є деякі незначні помилки. Деякі відповіли, що поле Довжина повідомлення в заголовку UDP становить максимум 65535 (0xFFFF); це технічно вірно. Деякі відповіли, що фактичний максимум (65535 - IPHL - UDPHL = 65507). Помилка полягає в тому, що поле Довжина повідомлення в заголовку UDP включає все корисне навантаження (Шари 5-7) плюс довжину заголовка UDP (8 байт). Це означає, що якщо поле довжини повідомлення становить 200 байт (0x00C8), корисне навантаження фактично становить 192 байти (0x00C0).

Що важко і швидко, це те, що максимальний розмір IP-дейтаграми - 65535 байт. Це число надходить на загальну суму заголовків L3 і L4, плюс корисні навантаження шарів 5-7. IP-заголовок + заголовок UDP + шари 5-7 = 65535 (макс.)

Найбільш правильна відповідь на те, який максимальний розмір файлу даних UDP - це 65515 байт (0xFFEB), оскільки дейтаграма UDP містить заголовок UDP. Найбільш правильна відповідь на те, який максимальний розмір корисної навантаження UDP - це 65507 байт, оскільки корисна навантаження UDP не містить заголовка UDP.

— Свиня
джерело

1

Ви не відповіли на запитання. Опитуючий хотів дізнатися, який найбільший розмір вони могли використовувати, щоб уникнути фрагментації пакету.

— Астара

0

Я боюся, що я зазнаю засмучених реакцій, але, тим не менш, для того, щоб уточнити, чи я помиляюся, або ті, хто бачить це питання і цікавлять відповідь:

моє розуміння https://tools.ietf.org/html/rfc1122 , статус якого є "офіційною специфікацією", і як такий є посиланням на термінологію, що використовується в цьому питанні, і яка не замінена іншим RFC, ні помилкою, що суперечить наступне:

теоретично, тобто. виходячи з письмових специфікацій, UDP, подібний даному https://tools.ietf.org/html/rfc1122#section-4, не має "розміру пакету". Таким чином, відповідь може бути "невизначеною"

На практиці, що саме ці питання, ймовірно, задаються (і які можуть бути оновлені для діючих технологій в дії), це може бути інакше, і я не знаю.

Прошу вибачення, якщо я викликав засмучення. https://tools.ietf.org/html/rfc1122#page-8 "Набір протоколу Internet" та "Архітектурні припущення" не дають мені зрозуміти "припущення", на якому я базувався, виходячи з того, що я чув, що шари розділені . Тобто У UDP-шарі шару немає, що стосується IP-шару, що знаходиться в (і в IP-шарі є такі речі, як повторна збірка, EMTU_R, фрагментація та MMS_R ( https://tools.ietf.org/html/rfc1122#page- 56 ))

— користувач5588495
джерело

1

У заголовку UDP є поле довжини дейтаграми, яке становить 16 біт, це означає, що найбільша теоретична дейтаграма UDP - 65 555, але цього ніколи не можна досягти, оскільки UDP інкапсульований всередині IP-пакету, який має загальну теоретичну довжину 65,535 ( те саме), але ви повинні відняти заголовки IP та UDP від цього розміру, щоб зрозуміти максимальний теоретичний розмір даних.

— Рон Мопін

Я давно це запитував, але він шукав прагматичну відповідь (що працює в реальному житті), а не те, що йдеться в специфікаціях / або теоретично. Мені хотілося отримати пакети від a до b з фрагментацією, це було проблемою мережевих ігор в реальному часі - я думаю, що зараз існує багато рішень, розроблених розумнішими людьми :)

— KM