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

Ответ 1

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

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

Если вы начнете переопределять все алгоритмы TCP, вы рискуете оказаться в (paraphasing Genthpound Tenth Rule) "ad hoc, неформально, с ошибкой, медленная реализация TCP".

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

"Стек" (используется TCP (использование UDP (использование IPv4 (ETHERNET))))... или "Стек" (используется TCP (использование UDP (использование IPv6 (ETHERNET))))...

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

Фокус на (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 был и остается взломом.