Я прочитал ряд статей о размерах пакетов UDP, но не смог прийти к выводу о том, что правильно.
Ряд сервисов ограничивает наибольший пакет UDP 512 байтами (например, днс)
С учетом минимального значения MTU в Интернете 576, а размер заголовка IPv4 составляет 20 байтов, а заголовка UDP - 8 байтов. Это оставляет 548 байтов доступными для пользовательских данных.
Смогу ли я использовать пакеты размером до 548 без фрагментации пакета? Или есть что-то, о чем знали создатели DNS, и именно поэтому они ограничили его 512 байтами.
Могу ли я даже безопасно превысить 548 байт?
Ответы:
Это правда, что типичный заголовок IPv4 составляет 20 байтов, а заголовок UDP - 8 байтов. Однако можно включить параметры IP, которые могут увеличить размер заголовка IP до 60 байтов. Кроме того, иногда промежуточным узлам необходимо инкапсулировать дейтаграммы внутри другого протокола, такого как IPsec (используемый для VPN и т. П.), Чтобы направить пакет к месту назначения. Поэтому, если вы не знаете MTU на вашем конкретном сетевом пути, лучше оставить разумный запас для другой информации заголовка, которую вы, возможно, не ожидали. Обычно считается, что для этого используется полезная нагрузка UDP объемом 512 байт, хотя даже это не оставляет достаточно места для заголовка IP максимального размера.
источник
Теоретический предел (в Windows) для максимального размера пакета UDP составляет 65507 байт. Это задокументировано здесь :
При этом большинство протоколов ограничиваются намного меньшим размером - обычно либо 512, либо иногда 8192. Вы можете часто подняться выше 548, если находитесь в надежной сети, - но если вы вещаете через Интернет в целом, чем больше вы идете, тем больше вероятность того, что вы столкнетесь с проблемами передачи пакетов и потери.
источник
Максимальная безопасная полезная нагрузка 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
источник
576 - это минимальный максимальный размер буфера повторной сборки , то есть каждая реализация должна иметь возможность собирать пакеты, по крайней мере, такого размера. См. IETF RFC 1122 для деталей.
источник
В этой статье описывается максимальная единица передачи (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
источник
Минимальный размер буфера пересборки IPv4 - 576, в IPv6 - 1500. Отсюда вычтите размеры заголовков. См. Сетевое программирование в UNIX У. Ричарда Стивенса :)
источник
512 - ваша лучшая ставка. Он используется в другом месте и является хорошим четным числом (половина из 1024).
источник
Учитывая, что 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 байтов).
источник
Я прочитал несколько хороших ответов здесь; Однако есть небольшие ошибки. Некоторые ответили, что поле длины сообщения в заголовке 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.
источник
Я боюсь, что у меня будут расстроенные реакции, но, тем не менее, чтобы уточнить для меня, если я не прав или те, кто видит этот вопрос и заинтересованы в ответе:
мое понимание 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 ))
источник
UDP не "безопасен", поэтому вопрос не велик - однако -
Если вы отправляете 9217 или более (Mac) или 65508+ (Linux / Windows), функция отправки сокета возвращается с ошибкой.
Приведенные выше ответы, обсуждающие фрагментацию, MTU и т. Д., Не по теме - все это происходит на более низком уровне, «невидимо» для вас и не оказывает существенного влияния на «безопасность» типичных соединений.
Чтобы ответить на реальный вопрос, значение - не используйте UDP - используйте необработанные сокеты, чтобы лучше контролировать все; так как вы пишете игру, вам нужно углубиться во флаги, чтобы в любом случае получить приоритет для своего трафика, так что вы можете также избавиться от проблем с UDP одновременно.
источник