Каков оптимальный размер пакета UDP для максимальной пропускной способности?

Question

Мне нужно отправлять пакеты с одного хоста на другой по сети с потенциальными потерями . Чтобы минимизировать задержку пакетов, я не рассматриваю TCP / IP. Но я хочу максимально увеличить пропускную способность UDP. Какой должен быть оптимальный размер UDP-пакета для использования?

Вот некоторые из моих соображений:

• Размер MTU коммутаторов в сети равен 1500. Если я использую большой пакет, например 8192, это приведет к фрагментации. Потеря одного фрагмента приведет к потере всего пакета, верно?

• Если я использую меньшие пакеты, я буду нести издержки заголовка UDP и IP

• Если я использую действительно большой пакет, какой самый большой пакет я могу использовать? Я прочитал, что самый большой размер датаграммы - 65507. Какой размер буфера я должен использовать, чтобы разрешить мне отправлять такие размеры? Поможет ли это увеличить мою пропускную способность?

• Какой типичный максимальный размер дейтаграммы поддерживается общими ОС (например, Windows, Linux и т.

Обновлен:

Некоторые получатели данных являются встроенными системами, для которых стек TCP / IP не реализован.

Я знаю, что это место заполнено людьми, которые очень любят использовать то, что доступно. Но я надеюсь получить лучшие ответы, чем просто сосредоточиться только на MTU.

Answer 1

Альтернативный ответ: будьте осторожны, чтобы не изобретать велосипед.

TCP - продукт многолетнего опыта работы в сети. Существует резонанс для каждой или почти каждой вещи, которую он делает. У него есть несколько алгоритмов, о которых большинство людей часто не задумываются (контроль перегрузки, повторная передача, управление буфером, работа с переупорядоченными пакетами и т. Д.).

Если вы начнете переопределять все алгоритмы TCP, вы рискуете получить (перефразируя Десятое правило Гринспуна ) "специальную, неофициально заданную, ошибочную медленную реализацию TCP". *

Если вы еще этого не сделали, было бы неплохо рассмотреть некоторые недавние альтернативы TCP / UDP, такие как SCTP или DCCP. Они были разработаны для ниш, где ни TCP, ни UDP не подходили друг другу, именно для того, чтобы люди могли использовать уже отлаженный протокол вместо того, чтобы заново изобретать колесо для каждого нового приложения.

Answer 2

Лучший способ найти идеальный размер датаграммы - это сделать именно то, что делает сам TCP, чтобы найти идеальный размер пакета: Обнаружение MTU пути .

У TCP также есть широко используемая опция, когда обе стороны сообщают друг другу, каково их MSS (в основном, MTU минус заголовки).

Answer 3

Самый простой способ найти mtu в c # - это отправить пакеты udp с установленным в true флагом dontfragment. если это вызывает исключение, попробуйте уменьшить размер пакета. делайте это, пока не будет выброшено исключение. Вы можете начать с 1500 размера пакета.

Answer 4

Ну, у меня есть ответ без MTU для вас. Использование подключенного сокета UDP должно ускорить процесс. Есть две причины для вызова connect на вашем UDP-сокете. Первое - это эффективность. Когда вы вызываете sendto на неподключенном сокете UDP, происходит следующее: ядро ​​временно подключает сокет, отправляет данные, а затем отключает их. Я читал об исследовании, указывающем, что при отправке это занимает почти 30% времени обработки. Другая причина вызова connect заключается в том, что вы можете получать сообщения об ошибках ICMP. В неподключенном сокете UDP ядро ​​не знает, в какое приложение доставлять ошибки ICMP, поэтому они просто отбрасываются.

Answer 5

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

Максимальная пропускная способность определяется не только размером пакета (хотя это, конечно, способствует). Минимизация задержки и максимальная пропускная способность часто расходятся друг с другом. В TCP у вас есть алгоритм Nagle, который разработан (частично) для увеличения общей пропускной способности. Однако некоторые протоколы (например, telnet) часто отключают Nagle (т. Е. Устанавливают бит No Delay) для улучшения задержки.

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

Существует множество других факторов, которые влияют на это, и (как было предложено в другом ответе) в какой-то момент вы получаете плохую реализацию TCP. Тем не менее, если вы хотите достичь низкой задержки и можете терпеть потери, используя UDP с общим размером пакета, установленным в MTU PATH (обязательно установите размер полезной нагрузки для учета заголовков), скорее всего, оптимальное решение (особенно если вы может гарантировать, что UDP может добраться от одного конца до другого.

Answer 6

Э-э-э, Джейсон, TCP не использует UDP. TCP использует IP, поэтому его часто называют TCP / IP. UDP также использует IP, поэтому технически UDP - это UDP / IP. Уровень IP управляет передачей данных от конца к концу (по разным сетям), поэтому он называется Межсетевым протоколом. TCP и UDP обрабатывают сегментацию самих данных. Нижние уровни, такие как Ethernet или PPP или все, что вы используете, управляют передачей данных между компьютерами (то есть в пределах одной сети).

Answer 7

IP-заголовок составляет> = 20 байт, но в основном 20, а UDP-заголовок составляет 8 байт. Это оставляет вам 1500 - 28 = 1472 байта для ваших данных. Обнаружение PATH MTU обнаруживает наименьшее возможное значение MTU на пути к месту назначения. Но это не обязательно означает, что при использовании наименьшего MTU вы получите максимально возможную производительность. Я думаю, что лучший способ - это сделать тест. Или, может быть, вам вообще не нужно заботиться о наименьшем MTU в пути. Сетевое устройство вполне может использовать небольшой MTU, а также очень быстро передавать пакеты. И его ценность вполне может измениться в будущем. Таким образом, вы не можете обнаружить это и сохранить его где-нибудь, чтобы использовать позже, вы должны делать это периодически. На вашем месте я бы установил MTU на что-то вроде 1440 и протестировал приложение ...

Answer 8

Несмотря на то, что MTU на коммутаторе 1500, у вас могут быть ситуации (например, туннелирование через VPN), которые оборачивают несколько дополнительных заголовков вокруг пакета - вы могли бы лучше немного их уменьшить и перейти к 1450 или около того.

Можете ли вы смоделировать сеть и протестировать производительность с различными размерами пакетов?

Answer 9

«Стек» (TCP использует (использует UDP (использует IPv4 (ETHERNET)))) ... или же «Стек» (TCP использует (использует UDP (использует IPv6 (ETHERNET)))) ...

Все эти заголовки добавлены в TCP. IPv6 просто тупой. Каждый компьютер не требует своего IP. IPv6 - это просто нежелательное раздувание пакетов. У вас более 65 000 портов, вы не будете использовать их все, когда-либо ... Добавьте это к MAC-адресу отдельной машины в заголовке ETHERNET, и у вас появятся миллиарды адресов.

Сосредоточьтесь на заголовках (UDP использует (IPv4 использует (ETHERNET))), и все будет хорошо. Ваша программа должна иметь возможность «проверять» размер пакета, получая 65 000-байтовый буфер по UDP, устанавливая все NULL CHR (0) и отправляя 65 000 пакетов CHR (255) байтов. Вы можете увидеть, были ли потеряны ваши данные UDP, потому что вы никогда не получите их. Это будет прервано. UDP не передает несколько пакетов. Вы отправляете один, вы получаете один. Вы просто получаете меньше, если оно не подходит. Или вы ничего не получите, если его уронят.

TCP будет хранить ваши соединения в чистилище, пока все данные не будут получены. Он использует пакеты UDP и говорит другому компьютеру повторно отправить эти пропущенные пакеты. Это связано с дополнительными издержками и вызывает LAG, если какой-либо пакет отброшен, потерян, короток или вышел из строя.

UDP дает вам полный контроль. Используйте UDP, если вы отправляете «критические» и «некритические» данные и хотите использовать систему нумерации с уменьшенным порядком пакетов, которая не зависит от последовательного поступления. Используйте только TCP для надежных данных WEB или SECURE, которые требуют постоянства и 100% полноты. В противном случае вы просто теряете нашу пропускную способность сети и добавляете раздутый беспорядок в сеть. Чем меньше ваш поток данных, тем меньше вы потеряете на этом пути. Используйте TCP, и вы гарантируете дополнительную LAG, связанную со всеми повторно отправленными и раздутыми заголовками, которые добавляются в заголовок TCP, для «управления потоком».

Серьезно, управление потоком данных не так сложно, как и приоритет, и обнаружение пропущенных данных. TCP ничего не предлагает. Вот почему это отдается бесплатно. Это не приправлено, это просто тупо и легко. Это старая пара шлепанцев. Вам нужна хорошая пара кроссовок. TCP был и остается взломом.