Вопрос по sockets, udp, networking, ipv4 – Какой самый большой размер безопасного UDP-пакета в Интернете

180

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

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

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

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

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

это не должно быть на ServerFault? Nathan Koop
Дублируйте, смотритеstackoverflow.com/questions/900697/… ChrisW
Это немного другой вопрос. Я спрашиваю, какой самый большой пакет я могу отправить через Интернет (без каких-либо знаний о других сетях или прощупывания), который не будет иметь фрагментации. По сути, максимальный безопасный размер, который будет работать на все, не беспокоясь о проверке соединения. Kingsley
Вы не можете исключить возможность фрагментации, но это не делает вещи менее безопасными. Если фрагмент отброшен, он такой же, как если бы весь пакет был отброшен, что в любом случае происходит с UDP. Небезопасно было бы, если бы пакет превышал минимальный размер, который требовался для поддержки маршрутизаторов, и, следовательно, не гарантированно был доставлен (в отличие от гарантированной доставки). Вот где появляется 512-байтовая фигура. Beejor

Ваш Ответ

9   ответов
6

512 - ваша лучшая ставка. Оно используется в другом месте и является хорошим четным числом (половина из 1024).

114

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

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

В этой статье описывается максимальная единица передачи (MTU)http://en.wikipedia.org/wiki/Maximum_transmission_unit, В нем говорится, что IP-хосты должны иметь возможность обрабатывать 576 байтов для IP-пакета. Тем не менее, он отмечает, что минимальное значение равно 68. RFC 791: «Каждый интернет-модуль должен иметь возможность пересылать дейтаграмму из 68 октетов без дальнейшей фрагментации. Это связано с тем, что заголовок Интернета может содержать до 60 октетов, а минимальный фрагмент - 8 октетов. & Quot;

Таким образом, безопасный размер пакета 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

54

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

The correct maximum UDP message size is 65507, as determined by the following formula: 0xffff - (sizeof(IP Header) + sizeof(UDP Header)) = 65535-(20+8) = 65507

При этом большинство протоколов ограничиваются гораздо меньшим размером - обычно либо 512, либо иногда 8192. Вы можете часто подняться выше 548, если находитесь в надежной сети - но если вы вещаете через Интернет в целом, чем больше чем больше, тем больше вероятность того, что вы столкнетесь с проблемами и потерями при передаче пакетов.

Ссылка Microsoft не является нормативной ссылкой. RFC являются нормативным справочным документом; и то, что вы цитировали, относится только к IPv4.
Я не думаю, что максимальный размер пакета UDP будет когда-либо равен 65 507 байтам, учитывая, что моя карта Wi-Fi (IEEE 802.3) может работать только с 1500 MTU, а объемные кадры составляют всего 9 Кбайт.
@EJP Они не объясняют это ясно в ссылке Microsoft, но это, кажется, является необходимым следствием IPv4: поле общей длины IPv4 составляет 16 битов, и это значение должно включать длину заголовка IP и длину Заголовок UDP.
@jtpereyda Я полностью осознаю все это. Моя точка зрения в точности соответствует тому, что я уже сказал: вы должны ссылаться на нормативные ссылки там, где они существуют.
То, что MS допускает это, не означает, что это всегда хорошая идея, поскольку промежуточные маршрутизаторы и т. Д. Могут быть вынуждены фрагментировать пакеты больших размеров (как вы упомянули).
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.

Вы не ответили на вопрос. Спрашивающий хотел знать, какой максимальный размер они могли бы использовать, чтобы избежать фрагментации пакета.
40

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

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

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

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

Я рекомендую прекратить повторять то, что сказал какой-то случайный парень, и проверить факты, потому что UDP на самом деле довольно надежен. Кстати, у меня есть безопасные пакеты поверх UDP без ненужных издержек TCP.openmymind.net/How-Unreliable-Is-UDP
Любой пакет UDP по умолчанию считается "_U_nreliable". Единственный безопасный размер UDP-пакета, который вы можете ожидать получить, - это 1 нефрагментированный пакет. Если вы хотите "безопасно" пакеты, используйте пакетный протокол поверх TCP.
@Astara Правда, по своей природе UDP ненадежен. Но вопрос в том, гарантированно ли будет доставлен пакет данного размера или нет. Пакеты более определенного размера могут быть (и отброшены) любым маршрутизатором по любой причине, тогда как меньшиеmust быть оптимальным для всех маршрутизаторов в соответствии с отраслевыми стандартами. Так что "безопасно" в данном случае означает «подойдет ли моя машина под мост»? и не "моя машина застрянет в пробке".
@Beejor Вы были на правильном пути, но "это требует, чтобы вы в основном написали свою собственную версию" TCP " на вершине & quot; это явно неправильно. UDP отлично подходит для вещания и отлично подходит для быстрой отправки «некритических»; данные. (В отношении игр) вы можете обнаруживать (LAN) серверы / сервисы, используя UDP, и использовать UDP для быстрой отправки местоположений игроков. Если один пакет отбрасывается; вам все равно, потому что в следующем пакете будет более актуальное местоположение других игроков. TCP может иметь «не в порядке» пакеты, имеет служебные данные и не вполне соединяет один-ко-многим. В некоторых случаях UDP может быть более применимым.
UDP не является "ненадежным" из-заamount из отброшенных пакетов, но потому что пакетыcan be (и есть) упал. Вы не можете & quot; полагаться & quot; на любое конкретное прибытие пакета, заказ или подтверждение. Данные хрупки, и это похоже на то, что рулевое управление автомобилем, которое работает 99% времени и 89% в правильном направлении, является надежным. Не то, чтобы UDP не подходит для многих вещей, просто требуется, чтобы вы в основном написали свою собственную версию «TCP». на вершине Вот увлекательный пример из реальной жизни в игровом мире разработчиков (хотя и немного устаревший):gamasutra.com/view/feature/131781
6

Учитывая, что IPV6 имеет размер 1500, я бы сказал, что операторы связи не будут предоставлять отдельные пути для IPV4 и IPV6 (они оба являются IP с разными типами), заставляя их использовать оборудование для ipv4, которое будет старым, избыточным, более дорогим в обслуживании и менее надежный. Это не имело бы никакого смысла. Кроме того, это может легко рассматриваться как предоставление преференциального режима для некоторого трафика - нет, нет по правилам, о которых они, вероятно, не заботятся (если их не поймают).

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

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

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

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

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

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

& Quot;1500 must be supported by IPv6 compatible components in the network chain.& Quot; Нет, минимальный MTU для IPv6 - 1280. Сетевой MTU - 1500.
как вы рассчитываете 1472? Ethernet имеет MTU 1500, это то, на что вы ссылаетесь?
@rogerdpack Я думаю, он имеет в виду, что, поскольку IPv4 и IPv6, вероятно, совместно используют большую инфраструктуру, и что IPv6 становится относительно популярным, следует с уверенностью предположить ограничения IPv6 (таким образом, 1500). Насколько обоснованны эти рассуждения, я не могу сказать.
@RonMaupin - оригинальный Q был самым большим безопасным размером UDP-пакета, а не MTU. См. RFC2460. Помимо упоминания MTU в 1280 октетов, в нем говорится: Узлыmust быть в состоянии принять фрагментированный пакет, который при повторной сборке составляет до 1500 октетов. Обработка пакетов больше 1500 не является обязательной.
1500 должно поддерживаться IPv6-совместимыми компонентами в сети «цепочка» - если использовать IPv4, который может проходить по цепочке, поддерживающей IPv6 (хотя обратное неверно), то, поскольку размер заголовка IPv4 составляет 20 байтов, а размер заголовка UDP составляет 8 байтов, из него уйдет 1500-20-8 = 1472 в качестве максимального безопасного размера (поскольку IPv6 не допускает фрагментирование). Обратите внимание: если люди добавят достаточно слоев инкапсуляции, возможно, не хватит места для данных. Поскольку вы запросили MAX, можно предположить, что несколько уровней издержек инкапсуляции НЕ используются.
42

576 этоminimum maximum reassembly buffer sizeкаждая реализация должна иметь возможность собирать пакетыat least этот размер. УвидетьIETF RFC 1122 для деталей.

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

IPv4minimum reassembly buffer size 576, IPv6 имеет 1500. Вычтите размеры заголовков отсюда. УвидетьСетевое программирование в UNIX У. Ричарда Стивенса :)

@ Navin, нет, пакеты IPv6 не будут фрагментированы, данные должны быть фрагментированы, прежде чем они будут упакованы в пакеты IPv6, но сами пакеты не фрагментированы. Есть разница. В отличие от заголовков пакетов IPv4, в которых есть поля, предназначенные для фрагментации, заголовки пакетов IPv6 не имеют ничего общего с фрагментацией. Заголовок пакета IPv6 намного проще, чем заголовок пакета IPv4.
@RonMaupin IPv6-пакеты могут быть фрагментированы конечными точками. Только не маршрутизаторами между ними.
Минимум, конечно. Спасибо, что заметили это. Понятия не имею, как никто не заметил ошибку за эти годы.
Хотя минимальный буфер повторной сборки IPv6 может составлять 1500, фрагменты пакетов IPv6 не допускаются для фрагментации, а минимальный MTU IPv6 равен 1280. Конечное устройство никогда не должно повторно собирать фрагментированный пакет IPv6.

Похожие вопросы