Какой самый большой размер безопасного UDP-пакета в Интернете


201

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

Ряд сервисов ограничивает наибольший пакет UDP 512 байтами (например, днс)

С учетом минимального значения MTU в Интернете 576, а размер заголовка IPv4 составляет 20 байтов, а заголовка UDP - 8 байтов. Это оставляет 548 байтов доступными для пользовательских данных.

Смогу ли я использовать пакеты размером до 548 без фрагментации пакета? Или есть что-то, о чем знали создатели DNS, и именно поэтому они ограничили его 512 байтами.

Могу ли я даже безопасно превысить 548 байт?



10
Это немного другой вопрос. Я спрашиваю, какой самый большой пакет я могу отправить через Интернет (без каких-либо знаний о других сетях или исследования), который не будет иметь фрагментации. По сути, максимальный безопасный размер, который будет работать на все, не беспокоясь о проверке соединения.
KM

2
Вы не можете исключить возможность фрагментации, но это не делает вещи менее безопасными. Если фрагмент отброшен, это так же, как если бы весь пакет был отброшен, что в любом случае происходит с UDP. Небезопасно было бы, если бы пакет превышал минимальный размер, который требовался для поддержки маршрутизаторов, и, следовательно, не гарантированно был доставлен (в отличие от гарантированной доставки). Вот где появляется 512-байтовая фигура.
Beejor

Ответы:


129

Это правда, что типичный заголовок IPv4 составляет 20 байтов, а заголовок UDP - 8 байтов. Однако можно включить параметры IP, которые могут увеличить размер заголовка IP до 60 байтов. Кроме того, иногда промежуточным узлам необходимо инкапсулировать дейтаграммы внутри другого протокола, такого как IPsec (используемый для VPN и т. П.), Чтобы направить пакет к месту назначения. Поэтому, если вы не знаете MTU на вашем конкретном сетевом пути, лучше оставить разумный запас для другой информации заголовка, которую вы, возможно, не ожидали. Обычно считается, что для этого используется полезная нагрузка UDP объемом 512 байт, хотя даже это не оставляет достаточно места для заголовка IP максимального размера.


36
Просто чтобы быть ясным: небольшой размер, чтобы избежать фрагментации, не делает доставку пакета «безопасной», есть еще бесконечное количество возможностей, делающих доставку ненадежной, такой как собака съела мой сетевой кабель. Это сказал; меньшее количество фрагментов делает доставку «более безопасной», потому что если их было больше одного, и ни один из них так и не сделал этого - весь пакет (датаграмма) отбрасывается по UDP.
markmnl

3
Для целей вопроса можно предположить использование постерного определения «безопасно», а не какого-то определения в какой-либо книге стандартов, которое они никогда не видели.
Астара

Известно ли, что реальные маршрутизаторы отбрасывают UDP-пакеты, а не фрагментируют их?
user253751

60

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

Правильный максимальный размер сообщения UDP составляет 65507, что определяется по следующей формуле: 0xffff - (sizeof (заголовок IP) + sizeof (заголовок UDP)) = 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 байтам, учитывая, что моя карта Wi-Fi (IEEE 802.3) может работать только с 1500 MTU, а объемные кадры составляют всего 9 Кбайт.
Кристиан Стюарт

52

Максимальная безопасная полезная нагрузка UDP составляет 508 байт. Это размер пакета 576 минус максимальный 60-байтовый заголовок IP и 8-байтовый заголовок UDP. Любая полезная нагрузка UDP такого размера или меньше гарантированно доставляется по IP (хотя не гарантируется, что она будет доставлена). Все, что больше, может быть удалено любым маршрутизатором по любой причине. За исключением маршрута только для IPv6, где максимальная полезная нагрузка составляет 1212 байт. Как уже упоминалось, дополнительные заголовки протокола могут быть добавлены в некоторых случаях. Вместо этого может быть предпочтительным более консервативное значение около 300-400 байт.

Любой пакет UDP может быть фрагментирован. Но это не так важно, потому что потеря фрагмента имеет тот же эффект, что и потеря нефрагментированного пакета: весь пакет отбрасывается. С UDP это произойдет в любом случае.

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

Источники: RFC 791, RFC 2460


2
Любой пакет UDP по умолчанию считается "_U_nreliable". Единственный безопасный размер UDP-пакета, который вы можете ожидать получить, - это 1 нефрагментированный пакет. Если вы хотите «безопасные» пакеты, используйте пакетный протокол поверх TCP.
Астара

27
@Astara Правда, по своей природе UDP ненадежен. Но вопрос в том, гарантированно ли будет доставлен пакет данного размера, а не будет ли он гарантированно доставлен. Пакеты более определенного размера могут (и удаляются) любым маршрутизатором по любой причине, в то время как меньшие пакеты должны наилучшим образом обрабатываться всеми маршрутизаторами в соответствии с отраслевыми стандартами. Поэтому в данном случае «безопасный» означает «подойдет ли моя машина под мост», а не «застрянет в пробке».
Бежор

1
Я рекомендую перестать повторять то, что сказал какой-то случайный парень, и проверить факты, потому что UDP на самом деле довольно надежен. Кстати, у меня есть безопасные пакеты поверх UDP без ненужных издержек TCP. openmymind.net/How-Unreliable-Is-UDP
Пабло Ариэль

5
UDP не является «ненадежным» из-за количества отброшенных пакетов, но потому что пакеты могут быть (и являются) отброшенными. Вы не можете «полагаться» на какое-либо конкретное прибытие пакета, заказ или подтверждение. Данные хрупки, и это все равно, что сказать, что рулевое управление автомобиля работает 99% времени, а 89% в правильном направлении, надежно. Нельзя сказать, что UDP не подходит для многих вещей, просто он требует от вас написать свою собственную версию «TCP» поверх него. Вот увлекательный пример из реальной жизни в игровом мире разработчиков (хотя и немного устаревший): gamasutra.com/view/feature/131781
Beejor

@Beejor Вы были на правильном пути, но «это требует, чтобы вы в основном написали свою собственную версию« TCP »поверх него», это явно неправильно. UDP отлично подходит для вещания и для быстрой отправки «некритических» данных. (В отношении игр) вы можете обнаруживать (LAN) серверы / сервисы, используя UDP, и использовать UDP для быстрой отправки местоположений игроков. Если один пакет отбрасывается; вам все равно, потому что в следующем пакете будет более актуальная информация о местонахождении других игроков. TCP может иметь пакеты «не по порядку», накладные расходы и не совсем подключается один-ко-многим. В некоторых случаях UDP может быть более применимым.
Пол

46

576 - это минимальный максимальный размер буфера повторной сборки , то есть каждая реализация должна иметь возможность собирать пакеты, по крайней мере, такого размера. См. IETF RFC 1122 для деталей.


2
Если и только если у вас есть сеть, которая не поддерживает IPv6. Если он содержит IPv6, используйте максимальный размер пакета заголовков IPv6, затем вычтите заголовки инкапсуляции для выполнения IPv4 поверх IPv6. ;-)
Астара

@Astara В IPv6 фрагментация выполняется отправителем, поэтому нет проблем с хитрыми несовместимыми промежуточными маршрутизаторами. И если получатель не имеет встроенного размера, ограниченного памятью, он может собрать пакеты размером до 64 КБ как минимум.
user253751

@ user253751 Фрагментировать могут не только несовместимые маршрутизаторы. Существует Path MTU Discovery, но даже этого недостаточно, чтобы полностью устранить фрагментацию.
Дстромберг

@dstromberg В каких ситуациях маршрутизаторам IPv6 разрешается фрагментировать дейтаграммы?
user253751

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

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) является разумным.

Как упомянуто пользователем 607811, фрагментация по другим сетевым уровням должна быть повторно собрана. https://tools.ietf.org/html/rfc1122#page-56 3.3.2 Повторная сборка Уровень IP ДОЛЖЕН осуществлять повторную сборку дейтаграмм IP. Мы определяем самый большой размер датаграммы, который может быть повторно собран EMTU_R («Эффективный MTU для приема»); это иногда называют «размером буфера сборки». EMTU_R ДОЛЖЕН быть больше или равен 576


11

Минимальный размер буфера пересборки IPv4 - 576, в IPv6 - 1500. Отсюда вычтите размеры заголовков. См. Сетевое программирование в UNIX У. Ричарда Стивенса :)


1
Минимум, конечно. Спасибо, что заметили это. Понятия не имею, как никто не заметил ошибку за эти годы.
Николай Фетиссов

1
Хотя минимальный буфер повторной сборки IPv6 может составлять 1500, фрагменты пакетов IPv6 не допускаются для фрагментации, а минимальный MTU IPv6 равен 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-байтовыми буферами размер пакета ... wait ... 8086 байт будет максимальным ... совпадением? ржание

****ОБНОВИТЬ****

Различные ответы дают максимальные значения, разрешенные одним поставщиком ПО, или различные ответы, предполагающие инкапсуляцию. Пользователь запрашивает не самое низкое возможное значение (например, «0» для безопасного размера UDP), но самый большой безопасный размер пакета.

Значения инкапсуляции для различных слоев могут быть включены несколько раз. Поскольку после того, как вы инкапсулировали поток, ничто не запрещает, скажем, уровень VPN ниже этого уровня и полное дублирование уровней инкапсуляции выше этого уровня.

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

Примечание. Если вы используете IPv6, максимальный размер будет 1452 байта, так как размер заголовка IPv6 составляет 40 байтов против 20 байтов IPv4 (и в любом случае, для заголовка UDP по-прежнему необходимо разрешить 8 байтов).


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 не допускает фрагментирование). Обратите внимание: если люди добавят достаточно слоев инкапсуляции, возможно, не хватит места для данных. Поскольку вы запросили MAX, можно предположить, что несколько уровней издержек инкапсуляции НЕ используются.
Астара

« 1500 должно поддерживаться совместимыми с IPv6 компонентами в цепочке сети. Нет, минимальный MTU IPv6 составляет 1280. Сетевой 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 « Пакет интернет-протоколов» и «Архитектурные предположения» не проясняют мне «предположение», на котором я основывался, исходя из того, что я слышал, что что слои разделены . То есть. Уровень UDP, в котором находится, не должен беспокоиться о том, в каком уровне IP находится (а уровень IP имеет такие вещи, как Reassembly, EMTU_R, Fragmentation and MMS_R ( https://tools.ietf.org/html/rfc1122#page- 56 ))


1
Заголовок UDP имеет поле длины дейтаграммы, которое составляет 16 битов, что означает, что наибольшая теоретическая дейтаграмма UDP составляет 65 535, но этого никогда не достичь, поскольку UDP инкапсулирован в IP-пакет, который имеет теоретическую максимальную общую длину 65 535 ( то же самое), но вы должны вычесть заголовки IP и UDP из этого размера, чтобы вычислить теоретический максимальный размер данных.
Рон Мопин

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

0

UDP не "безопасен", поэтому вопрос не велик - однако -

  • если вы используете Mac, максимальный размер, который вы можете отправить по умолчанию, составляет 9216 байт.
  • если вы используете Linux (CentOS / RedHat) или Windows 7, то максимальный размер составляет 65507 байт.

Если вы отправляете 9217 или более (Mac) или 65508+ (Linux / Windows), функция отправки сокета возвращается с ошибкой.

Приведенные выше ответы, обсуждающие фрагментацию, MTU и т. Д., Не по теме - все это происходит на более низком уровне, «невидимо» для вас и не оказывает существенного влияния на «безопасность» типичных соединений.

Чтобы ответить на реальный вопрос, значение - не используйте UDP - используйте необработанные сокеты, чтобы лучше контролировать все; так как вы пишете игру, вам нужно углубиться во флаги, чтобы в любом случае получить приоритет для своего трафика, так что вы можете также избавиться от проблем с UDP одновременно.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.