Когда целесообразно использовать UDP вместо TCP? [закрыто]

304

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

Я предполагаю, что UDP работает быстрее, поскольку у него нет накладных расходов на создание и поддержание потока, но разве это не имеет значения, если некоторые данные никогда не достигают места назначения?

Джефф Л
источник
55
Помимо того, что UDP страдает от возможной потери пакетов, он не гарантирует, что вы получите пакет только один раз. Если у вас запутанные или плохо настроенные сети, вы можете получать один и тот же пакет несколько раз. Просто один на один, потому что люди склонны забывать это!
Брайан Агнью
3
Это даже не гарантирует порядок пакетов.
Мехрдад Афшари
19
TCP не гарантирует доставку , он просто гарантирует, что если он сможет доставить пакеты, они будут в том же порядке, в котором они были отправлены.
Хаим Герец,
5
Кстати, я часто вижу, как люди приравнивают надежность / порядок доставки к повторным передачам TCP. Эти «эксперты» скажут вам, что для преодоления ошибок передачи по UDP, вы будете переопределять TCP (плохо), и поэтому вы могли бы также использовать TCP. Это неправда. Существуют и другие методы восстановления после ошибок, которые не страдают задержкой или экспоненциально сниженной пропускной способностью в результате небольших, но ненулевых частот ошибок.
Бен Фойгт
TCP также гарантирует, что вы будете знать, если пункт назначения не получил пакеты.
csga5000

Ответы:

354

Это один из моих любимых вопросов. UDP так неправильно поняли.

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

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

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

Еще один случай - многоадресный трафик. UDP может быть многоадресным для нескольких хостов, тогда как TCP вообще не может этого делать.

drudru
источник
Спасибо за интересный ответ. У нас есть сервер, который в настоящее время выполняет все в UDP (требование высокой пропускной способности), что нормально, потому что на самом деле есть один переход (маршрутизация отключена, ...), но мы заметили, что переупорядочение пакетов может стать проблемой на некоторых неисправных сетевых картах. Какой пользовательский стек TCP (или какой-либо другой поток, управляемый в пользовательском режиме) вы предлагаете?
дашесы
@dashesy - вы можете избавиться от требования заказа? Есть ли монотонно увеличивающееся число внутри полезной нагрузки, которое вы можете использовать? Если это так, вам не нужен полноценный стек TCP пользователя.
drudru
@ drudru- да есть порядковый номер, мне, возможно, придется буферизоваться и де-джиттер сам. Спасибо, исключение еще одного варианта всегда здорово.
Дашеси
64

Если пакет TCP потерян, он будет отправлен повторно. Это не удобно для приложений, которые полагаются на данные, обрабатываемые в определенном порядке в реальном времени.

Примеры включают потоковое видео и особенно VoIP (например, Skype ). В этих случаях, однако, отброшенный пакет не имеет большого значения: наши чувства не идеальны, поэтому мы можем даже не заметить. Вот почему эти типы приложений используют UDP вместо TCP.

Stephan202
источник
16
Я думаю, что у вас есть это задом наперед. TCP переупорядочивает пакеты так, чтобы данные доставлялись в отправленном порядке. UDP не переупорядочивает и доставляет данные в том порядке, в котором он их получил.
Ганс Малерб,
1
UDP не гарантирует порядок, однако вы можете нумеровать пакеты и переупорядочивать их после получения.
Кугель,
7
@ Stephan202: Думаю, мне не следует соглашаться с тем, чтобы не замечать пропущенные пакеты в Skype ;-)
Роберт С. Барнс
6
@ Кугель: Просто знайте, что вы можете реализовать новый стек TCP. Вряд ли вы справитесь с этой задачей лучше, чем ОС.
erikkallen
1
@erikkallen: Если бы кто-то использовал UDP для реализации протокола более высокого уровня с теми же требованиями, которым был разработан протокол TCP, вряд ли он будет намного лучше, чем существующие протоколы. С другой стороны, некоторые приложения выигрывают от добавления в протокол нескольких функций, которые оболочка UDP могла бы обрабатывать лучше, чем TCP.
Суперкат
56

«Ненадежность» UDP - это формализм. Передача не абсолютно гарантирована. На практике они почти всегда проходят. Они просто не признаются и повторяются после тайм-аута.

Затраты на согласование сокета TCP и квитирование TCP-пакетов огромны. Действительно огромный. Нет заметных накладных расходов UDP.

Самое главное, что вы можете легко дополнить UDP некоторым надежным рукопожатием при доставке, которое требует меньше затрат, чем TCP. Прочитайте это: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP полезен для трансляции информации в приложениях типа публикация-подписка. IIRC, TIBCO интенсивно использует UDP для уведомления об изменении состояния.

Любой другой вид односторонней активности «значимого события» или «регистрации» может быть хорошо обработан с помощью пакетов UDP. Вы хотите отправить уведомление без создания целого сокета. Вы не ожидаете никакого ответа от разных слушателей.

Системные сообщения «heartbeat» или «I'm alive» также являются хорошим выбором. Пропустить один не кризис. Пропал полдюжины (подряд) есть.

С. Лотт
источник
5
«На практике они почти всегда проходят». Сильно зависит от более низкого уровня надежности сети
m0skit0
кроме того, есть ли разница между планированием «нескольких» потерь пакетов и «слишком больших» потерь пакетов? потеря есть потеря. Вы все равно должны планировать это.
Седат Капаноглу
30

Я работаю над продуктом, который поддерживает как UDP (IP), так и TCP / IP связь между клиентом и сервером. Он начался с IPX более 15 лет назад с поддержкой IP, добавленной 13 лет назад. Мы добавили поддержку TCP / IP 3 или 4 года назад. Подходят дикие предположения: отношение кода UDP к TCP, вероятно, составляет около 80/20. Продукт является сервером базы данных, поэтому надежность имеет решающее значение. Мы должны решить все проблемы, связанные с UDP (потеря пакетов, удвоение пакетов, порядок пакетов и т. Д.), Уже упомянутые в других ответах. Есть редко какие-либо проблемы, но они иногда случаются и поэтому должны быть обработаны. Преимущество поддержки UDP состоит в том, что мы можем немного настроить его для нашего собственного использования и немного повысить его производительность.

Каждая сеть будет отличаться, но протокол связи UDP, как правило, немного быстрее для нас. Скептически настроенный читатель справедливо спросит, правильно ли мы все реализовали Кроме того, что вы можете ожидать от парня с 2-значным повторением? Тем не менее, я только что провела испытание из любопытства. Тест прочитал 1 миллион записей (выберите * из sometable). Я устанавливаю количество записей, которое нужно возвращать с каждым индивидуальным клиентским запросом, равным 1, 10, а затем 100 (три запуска теста с каждым протоколом). Сервер находился всего в двух прыжках по 100 Мбит локальной сети. Цифры, похоже, согласуются с тем, что другие находили в прошлом (в большинстве случаев UDP работает примерно на 5% быстрее). Общее время в миллисекундах было следующим для этого конкретного теста:

  1. 1 запись
    • IP: 390 760 мс
    • TCP: 416 903 мс
  2. 10 записей
    • IP: 91,707 мс
    • TCP: 95 662 мс
  3. 100 записей
    • IP: 29,664 мс
    • TCP: 30 968 мс

Общий объем передаваемых данных был примерно одинаковым для IP и TCP. У нас есть дополнительные накладные расходы на связь UDP, потому что у нас есть некоторые из тех вещей, которые вы получаете «бесплатно» с TCP / IP (контрольные суммы, порядковые номера и т. Д.). Например, Wireshark показал, что запрос следующего набора записей составляет 80 байтов с UDP и 84 байта с TCP.

Марк Уилкинс
источник
Что если бы вы разработали его только для TCP и купили бы более качественное оборудование, а не в 5 раз больше усилий по программированию?
inf3rno
2
Спасибо за конкретные цифры! Улучшение на 5% немного разочаровывает сложностью, которую он добавляет.
Сергей
1
Вероятно, 5%, потому что отправляется в локальной сети (две надежды)? Я думаю, что чем дальше, тем выше разница.
Леп
19

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

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

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

В результате UDP может:

  • Достигайте более высокой пропускной способности, чем TCP, если скорость сброса сети находится в пределах, которые приложение может обрабатывать.
  • Доставляйте пакеты быстрее, чем TCP, с меньшей задержкой.
  • Устанавливайте соединения быстрее, поскольку нет первоначального рукопожатия для настройки соединения
  • Передавать многоадресные пакеты, тогда как TCP должен использовать несколько соединений.
  • Передача пакетов фиксированного размера, тогда как TCP передает данные в сегментах. Если вы передадите пакет UDP размером 300 байт, вы получите 300 байт на другом конце. С помощью протокола TCP вы можете передать отправляющему сокету 300 байт, но получатель читает только 100 байт, и вам нужно как-то выяснить, что на пути еще 200 байт. Это важно, если ваше приложение передает сообщения фиксированного размера, а не поток байтов.

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

Энди
источник
1
Когда сети становятся достаточно перегруженными, чтобы вызвать потерю пакетов, TCP пытается минимизировать его влияние на других пользователей сети, в то время как многие реализации на основе UDP этого не делают. Это позволяет им захватить большую долю уменьшающегося пирога, но также уменьшает общий объем доступного периода полезной полосы пропускания (например, вследствие ненужной повторной передачи в случаях, когда данные фактически будут доставлены, но отправитель не поймет этого)
Суперкат
Прежде всего, спасибо за отличный ответ, я действительно многому научился от него! Но у меня есть вопрос: не происходит ли сегментация на уровне 3 (IP) из-за ограничений адаптера Ethernet для всех пакетов, полученных с уровня 4 (как TCP, так и UDP)? Вы имеете в виду любой другой вид сегментации, который происходит в TCP, но не происходит в UDP? Буду очень признателен, если вы мне это объясните.
РусланШ
1
@Freezy. Вы правы, фрагментация пакетов, которые превышают MTU канала (уровень 2), происходит на уровне 3-IP. Однако TCP - это потоковый протокол, который обрабатывает данные как поток байтов. TCP отправляет свои данные в сегментах, чтобы соответствовать внутренним IP-пакетам, размер которых соответствует MSS, поэтому сегментация также происходит в TCP. Сколько данных TCP помещает в сегмент или сколько данных читает ваш сокет, зависит от многих факторов; это может быть 1 байт или байты MSS. При использовании UDP получатель всегда получает точное количество байтов, отправленных передатчиком, если пакет не потерян в пути.
Энди
15

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

Дана Холт
источник
15

UDP является протоколом без установления соединения и используется в таких протоколах, как SNMP и DNS, в которых пакеты данных, поступающие не по порядку, являются приемлемыми и имеет значение немедленная передача пакета данных.

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

Он используется в DNS, поскольку он не включает установление соединения, что позволяет избежать задержек при установлении соединения.

ура

Arnkrishn
источник
12

Один из лучших ответов на этот вопрос, который я знаю, получен от пользователя zAy0LfpBZLC8mAC из Hacker News . Этот ответ настолько хорош, что я просто процитирую его как есть.

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

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

В дополнение к приложениям реального времени / с малой задержкой, UDP имеет смысл для действительно небольших транзакций, таких как поиск DNS, просто потому, что у него нет установления соединения TCP и накладных расходов на разрыв, как с точки зрения задержки, так и с точки зрения использования пропускной способности. Если ваш запрос меньше, чем типичный MTU, и ответ, скорее всего, тоже есть, вы можете выполнить его в один прием, без необходимости сохранять какое-либо состояние на сервере, а также управлять потоками и упорядочивать их, и все это, вероятно, не особенно полезно. для таких целей либо.

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

Кроме того, я думаю, следует упомянуть, что существует больше, чем UDP и TCP, такие как SCTP и DCCP. Единственная проблема в настоящее время состоит в том, что Интернет (IPv4) полон шлюзов NAT, которые делают невозможным использование протоколов, отличных от UDP и TCP, в приложениях конечного пользователя.

Шиталь шах
источник
Вы можете запускать SCTP и DCCP через UDP.
Деми
9

Потоковое видео является прекрасным примером использования UDP.

Даниэль А. Уайт
источник
Пожалуйста, приведите несколько примеров.
Гаурав Сингх
«Потоковое видео» является примером. Подумайте о том, чтобы в прямом эфире транслировались горячие звезды.
Сисир
8

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

На доставку TCP нет никаких гарантий, вам просто нужно сообщить, отключен ли сокет или, в основном, если данные не поступят. В противном случае он попадает туда, когда туда попадает.

Большая вещь, о которой забывают люди, это то, что udp основан на пакетах, а tcp основан на байтовом потоке, нет никакой гарантии, что отправленный вами «пакет tcp» является пакетом, который обнаруживается на другом конце, он может быть разбит на столько пакетов по желанию роутеров и стеков. Таким образом, ваше программное обеспечение имеет дополнительные издержки, связанные с синтаксическим анализом байтов обратно в пригодные для использования куски данных, что может потребовать значительных затрат. UDP может быть не в порядке, поэтому вы должны нумеровать ваши пакеты или использовать какой-то другой механизм, чтобы переупорядочить их, если вы захотите это сделать. Но если вы получите этот пакет udp, он прибудет со всеми теми же байтами в том же порядке, что и ушел, без изменений. Таким образом, термин пакет udp имеет смысл, но пакет tcp не обязательно. TCP имеет свой собственный механизм повторных попыток и упорядочения, который скрыт от вашего приложения,

UDP гораздо проще писать код для обеих сторон, в основном потому, что вам не нужно создавать и поддерживать двухточечные соединения. Мой вопрос, как правило, в каких ситуациях вы бы хотели получить издержки TCP? И если вы воспользуетесь сочетаниями клавиш, например, предположив, что принятый пакет tcp - это полный пакет, который был отправлен, вам лучше? (вы, скорее всего, выбросите два пакета, если потратитесь на проверку длины / содержимого)

Старожил
источник
TCP имеет гарантию доставки: чанк A будет доставлен приложению до чанка B, поэтому, если приложение подтверждает (на уровне приложения) чанк B, вы знаете, что оно получило чанк A. Но это также происходит на уровне обработки TCP.
Симеон Пилигрим
В TCP можно безопасно разграничивать порции данных, просто добавляя к каждой префиксу их длину. В зависимости от приложения каждый префикс может иметь фиксированную длину в один байт, два байта или четыре байта или каждый префикс с размером 128 ^ N или меньше может иметь длину N байтов. Не совсем огромные накладные расходы. Такой дизайн был бы плох с протоколами, которые не гарантируют доставку по порядку без пробелов, но при использовании TCP такой дизайн просто прекрасен.
суперкат
если вы ищете фиксированную длину данных, вам даже не нужна длина, которую вы просто считаете байтами по мере их поступления ...
old_timer
1
@supercat. Ты абсолютно прав. Это также означает, что вы увеличиваете сложность своего приложения; сложность, которая на самом деле нужна в UDP. По этой причине TCP лучше подходит для передачи потоков, например файлов. Но я делаю именно то, что вы делаете, когда мне нужна надежность фрагментированных данных и, возможно, дополнительная безопасность TLS поверх TCP.
Энди
5

Сетевое взаимодействие для видеоигр почти всегда осуществляется через UDP.

Скорость очень важна, и не имеет значения, пропущены ли обновления, поскольку каждое обновление содержит полное текущее состояние того, что может видеть игрок.

17 из 26
источник
5
обычно не полное состояние, а дельта с момента последнего подтверждения, поэтому обновления становятся все больше.
Симеон Пилигрим
5

Ключевой вопрос был связан с тем, «какие ситуации UDP будет лучшим выбором [по tcp]»

Выше много хороших ответов, но не хватает какой-либо формальной, объективной оценки влияния транспортной неопределенности на производительность TCP.

В условиях массового роста мобильных приложений и сопровождающих их «иногда подключаемых» или «иногда отключаемых» парадигм, безусловно, возникают ситуации, когда накладные расходы на попытки TCP поддерживать соединение, когда соединения трудно установить, приводят к сильному случай для UDP и его "ориентированная на сообщения" природа.

Теперь у меня нет математики / исследований / чисел по этому вопросу, но я создал приложения, которые работали более надежно, используя и ACK / NAK, и нумерацию сообщений по UDP, чем это могло быть достигнуто с помощью протокола TCP, когда связь обычно была плохой и плохой старый TCP просто потратил свое время и деньги моего клиента просто пытаясь соединиться. Вы получаете это в региональных и сельских районах многих западных стран ....

Роб фон Нессельроде
источник
3

В некоторых случаях, которые другие подчеркнули, гарантированное прибытие пакетов не важно, и, следовательно, использование UDP - это нормально. Есть и другие случаи, когда UDP предпочтительнее TCP.

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

Брайан М. Хант
источник
2

UDP может использоваться, когда приложение больше заботится о данных в реальном времени, а не о точной репликации данных. Например, VOIP может использовать UDP, и приложение будет беспокоиться о переупорядочении пакетов, но, в конце концов, VOIP не нужен каждый отдельный пакет, а что более важно, требуется непрерывный поток многих из них. Может быть, у вас здесь есть «сбой» в качестве голоса, но главная цель заключается в том, чтобы вы получили сообщение, а не чтобы оно идеально воссоздано на другой стороне. UDP также используется в ситуациях, когда затраты на создание соединения и синхронизацию с TCP перевешивают полезную нагрузку. DNS-запросы являются прекрасным примером. Один пакет, один пакет назад, на запрос. При использовании TCP это было бы намного интенсивнее. Если вы не получили ответ DNS, просто повторите попытку.

RC.
источник
2

UDP, когда скорость необходима, и точность, если пакеты не, и TCP, когда вам нужна точность.

UDP часто сложнее, потому что вы должны писать свою программу таким образом, чтобы она не зависела от точности пакетов.

BGW
источник
2

Это не всегда ясно. Однако если вам нужна гарантированная доставка пакетов без потерь и в правильной последовательности, то, вероятно, вам нужен TCP.

С другой стороны, UDP подходит для передачи коротких пакетов информации, где последовательность информации менее важна или где данные могут помещаться в один пакет.

Это также уместно, если вы хотите транслировать одну и ту же информацию многим пользователям.

В других случаях это уместно, когда вы отправляете упорядоченные данные, но если некоторые из них пропадают, вы не слишком обеспокоены (например, приложение VOIP).

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

Примеры того, где это можно / можно использовать 1) Сервер времени, передающий правильное время группе машин в локальной сети. 2) протоколы VOIP 3) поиск DNS 4) запрашивание услуг локальной сети, например, где вы находитесь? 5) интернет радио 6) и многие другие ...

В unix вы можете набрать grep udp / etc / services, чтобы получить список реализованных сегодня протоколов UDP ... их сотни.

Matt
источник
2

Посмотрите на раздел 22.4 Сетевого программирования Стивена « Unix , когда использовать UDP вместо TCP».

Также см. Этот другой ответ SO о неправильном представлении, что UDP всегда быстрее, чем TCP .

То, что говорит Стивен, можно подытожить следующим образом:

  • Используйте UDP для широковещательной и многоадресной рассылки, поскольку это единственный вариант (используйте многоадресную рассылку для любых новых приложений).
  • Вы можете использовать UDP для простых приложений запроса / ответа, но вам нужно будет встроить свои собственные подтверждения, тайм-ауты и повторные передачи
  • Не используйте UDP для массовой передачи данных.
Роберт С. Барнс
источник
1
Немного больше информации об этом последнем пункте, для всех, кто придет. TCP работает для массовой передачи данных, но если вас не волнует, что ваши данные поступают в сквозном порядке, вы можете написать протокол по UDP, который может быть быстрее - намного быстрее в очень специфических патологических случаях. Дело не в том, что вы не можете выполнять массовую передачу в UDP, дело не в том, что это всегда хуже; это просто такая боль в заднице, чтобы реализовать, что это редко стоит беспокоиться.
ijw
1
Да, вы можете использовать UDP для массовой передачи, и вы должны реализовать свой собственный механизм управления. Если это боль в заднице или нет, зависит от ваших навыков программирования, но это определенно не всегда хуже исполнителя. Вы должны знать, что вы делаете; если нет, то да, вы можете страдать.
Энди
2

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

  1. подходит для процесса, который требует простой связи запрос-ответ.
  2. подходит для процесса, который имеет внутренний поток, контроль ошибок
  3. подходит для широкого литья и многоадресной передачи

Конкретные примеры:

  • используется в SNMP
  • используется для некоторых протоколов обновления маршрута, таких как RIP
Викки
источник
2

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

введите описание изображения здесь

Jorgesys
источник
1

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

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

У нас есть веб-сервис с тысячами клиентов winforms на стольких ПК. ПК не связаны с БД, все доступ осуществляется через веб-сервис. Поэтому мы решили разработать центральный сервер журналирования, который прослушивает порт UDP, и все клиенты отправляют пакет журнала ошибок xml (с помощью приложения UDP log4net), который после получения сбрасывается в таблицу БД. Поскольку нас не волнует, пропущены ли несколько журналов ошибок, а с тысячами клиентов, это быстро с выделенным сервисом регистрации, не загружающим основной веб-сервис.

softveda
источник
0

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

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

SingleNegationElimination
источник
Одно приложение, в котором вы получите лучшие результаты от UDP, - это сквозной тест, если промежуточный узел выполняет контроль трафика, так как вы можете легче контролировать скорость передачи пакетов, стих TCP, который будет быстро передавать пакеты, и взаимодействие TCP Окно негативно взаимодействует с полицейскими.
Симеон Пилигрим
Это все еще оптимизация, которая должна следовать из фактического тестирования. Мой аргумент состоит в том, что вы все равно должны сначала попытаться использовать TCP, и пробовать альтернативы, только когда обнаружите, что TCP по какой-то причине не работает. Выбор UDP, поскольку он теоретически поддерживает лучшее использование полосы пропускания, является формой преждевременной оптимизации.
SingleNegationElimination
Ой, согласитесь на фронт оптимизации. Но знание того, когда TCP может быть проблемой, может помочь, когда вы пытаетесь решить эту проблему производительности.
Симеон Пилигрим
-1

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

Ожидается, что TCP будет намного быстрее с современными сетевыми картами из-за того, что известно как отпечаток контрольной суммы . Удивительно, но при высоких скоростях соединения (например, 1 Гбит / с) вычисление контрольной суммы было бы большой нагрузкой для ЦП, поэтому она выгружается на оборудование NIC, которое распознает TCP-пакеты для печати, и не будет предлагать вам ту же услугу.

Павел Радзивиловский
источник
2
Разгрузка контрольной суммы UDP доступна так же, как разгрузка контрольной суммы TCP.
Бен Фойгт
но не проверка контрольной суммы.
Павел Радзивиловский
1
Даже сетевые адаптеры потребительского уровня сегодня имеют разгрузку контрольной суммы UDP для передачи и приема (разгрузка приема выполняет проверку). И я видел эту функцию в оборудовании Prosumer десять лет назад, я уверен, что она была в сетевых адаптерах серверного класса еще дольше.
Бен Фойгт
-2

UDP идеально подходит для VoIP-адресов, где пакет данных должен быть отправлен, несмотря на его надежность ... Видеочат является примером UDP (вы можете проверить его с помощью захвата сети wireshark во время любого видеочата). Также TCP не работает с Протоколы DNS и SNMP. У UDP нет накладных расходов, в то время как у TCP много служебных

Химаншу Саксена
источник