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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я работаю над продуктом, который поддерживает как 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.

Здесь уже есть много хороших ответов, но я хотел бы добавить один очень важный фактор, а также резюме. 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 может быть очень быстрым, иметь меньшую задержку, не подвержен перегрузкам на основе соединения, передает дейтаграммы фиксированного размера и может использоваться для многоадресной рассылки.

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

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

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

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

ура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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