Так как 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% быстрее). Общее количество раз в миллисекундах для данного конкретного теста было следующим:
Общая сумма переданных данных была примерно одинаковой для IP и TCP. У нас есть дополнительные накладные расходы с UDP-коммуникациями, потому что у нас есть те же самые вещи, которые вы получаете за "свободный" с TCP/IP (контрольные суммы, порядковые номера и т.д.). Например, Wireshark показал, что запрос для следующего набора записей составлял 80 байт с UDP и 84 байта с TCP.
UDP - это протокол без подключения и используется в таких приложениях, как SNMP (Simple Network Management Protocol), DNS (система доменных имен), где пакеты данных поступают не по порядку, ненадежны и не беспокоят, и немедленная передача пакета данных дело...
Так как UDP не требует установления соединения, перед такими приложениями, как DNS, где необходимо избегать установления соединения, UDP предпочтительнее TCP.
Используется в SNMP, поскольку сетевое управление часто необходимо выполнять, когда сеть находится в состоянии стресса, то есть когда надежная передача данных с перегрузкой затруднена.
веселит
UDP имеет меньше накладных расходов и хорош для того, чтобы делать такие вещи, как потоковые данные в реальном времени, такие как аудио или видео, или в любом случае, когда это нормально, если данные теряются.
Один из лучших ответов, которые я знаю для этого вопроса, исходит от пользователя zAy0LfpBZLC8mAC в Hacker News. Этот ответ настолько хорош, что я просто процитирую его как есть.
TCP имеет блокировку заголовка очереди, поскольку он гарантирует полное и упорядоченное доставки, поэтому, когда пакет теряется в пути, ему приходится ждать повторной передачи недостающего пакета, тогда как UDP передает пакеты в по мере их поступления, включая дубликаты и без каких-либо гарантировать, что пакет поступит во все или какой заказ они прибудут (это действительно является по существу IP с номерами портов и (необязательной) полезной нагрузкой контрольная сумма), но это нормально для телефонии, например, где обычно просто не имеет значения, когда несколько миллисекунд аудио отсутствует, но задержка очень раздражает, поэтому вы не беспокоитесь ретранслирует, вы просто бросаете любые дубликаты, сортируете переупорядоченные пакеты в правильный порядок на несколько сотен миллисекунд буфера дрожания и если пакеты не отображаются во времени или вообще, они просто пропущены, возможно, интерполируется там, где поддерживается кодеком.
Кроме того, основная часть TCP - это управление потоком, чтобы убедиться, что вы получаете насколько это возможно, но без перегрузки сети (которая является избыточным, поскольку перегруженная сеть будет падать ваши пакеты, что означает, что вам придется делать ретрансляции, что приводит к увеличению пропускной способности), UDP не имеет ничего такого, что имеет смысл для таких приложений, как телефонии, поскольку телефония с данным кодеком нуждается в определенном количестве пропускной способности, вы не можете "замедлить ее", а дополнительная полоса пропускания также не ускоряет вызов.
В дополнение к приложениям с постоянной и низкой задержкой UDP имеет смысл для действительно небольшие транзакции, такие как DNS-запросы, просто потому, что они не имеет установленных TCP-соединений и издержек, как с точки зрения латентности, так и с точки зрения использования полосы пропускания. Если ваш запрос меньше, чем типичный MTU, и, возможно, ответ, тоже, вы можете сделать это в одном обратном направлении, без необходимости поддерживать какое-либо состояние на сервере и управление потоком, а также порядок, и все, что возможно не особенно полезно для такого использования.
И затем вы можете использовать UDP для создания собственных TCP-замещений, конечно, но это, вероятно, не очень хорошая идея без глубоких понимание динамики сети, современные алгоритмы TCP довольно изощренными.
Кроме того, я думаю, следует упомянуть, что есть больше, чем UDP и TCP, например, SCTP и DCCP. В настоящее время единственная проблема заключается в том, что (IPv4) Интернет полна шлюзов NAT, что делает невозможным использовать протоколы, отличные от UDP и TCP, в приложениях конечного пользователя.
Здесь уже много хороших ответов, но я хотел бы добавить один очень важный фактор, а также резюме. UDP может достичь гораздо более высокой пропускной способности с правильной настройкой, потому что не использует контроль перегрузки. Управление перегрузками в TCP очень важно . Он контролирует скорость и пропускную способность соединения, чтобы минимизировать перегрузку сети, пытаясь оценить текущую емкость соединения. Даже когда пакеты отправляются по очень надежным ссылкам, например, в базовой сети, маршрутизаторы имеют ограниченные буферы. Эти буферы заполняются до их емкости, а затем пакеты отбрасываются, и TCP уведомляет об этом падение из-за отсутствия принятого подтверждения и снижает скорость соединения для оценки емкости. TCP также использует что-то, называемое медленным запуском, но пропускная способность (фактически окно перегрузки) медленно увеличивается до тех пор, пока пакеты не будут отброшены, а затем снижается и медленно увеличивается до тех пор, пока пакеты не будут удалены и т.д. Это приведет к колебаниям пропускной способности TCP. Это можно увидеть, когда вы загружаете большой файл.
Поскольку UDP не использует управление перегрузкой, он может быть как быстрее, так и медленнее, потому что он не будет стремиться максимизировать буферы до точки отбрасывания, то есть UDP-пакеты тратят меньше времени на буферы и быстрее туда быстрее с более низким задержка. Поскольку UDP не использует управление перегрузками, но TCP делает это, он может убрать пропускную способность от TCP, что приводит к потокам UDP.
UDP по-прежнему уязвим для перегрузок и падений пакетов, поэтому ваше приложение должно быть готово как можно меньше обрабатывать эти меньшие потери, вероятно, используя коды повторной передачи или исправления ошибок.
В результате UDP может:
Таким образом, UDP может использоваться для всех типов приложений, которые могут быть TCP, если вы также реализуете правильный механизм повторной передачи. UDP может быть очень быстрым, с низкой задержкой, не зависит от перегрузки на основе соединения, передает датаграммы с фиксированным размером и может использоваться для многоадресной рассылки.
UDP имеет более низкие накладные расходы, как уже говорилось, это хорошо для потоковой передачи таких вещей, как видео и аудио, где лучше просто потерять пакет, а затем попытаться отправить и догнать.
Нет никаких гарантий по доставке TCP, вам просто нужно сказать, отключен ли сокет или в основном, если данные не поступят. В противном случае он попадает туда, когда он туда попадает.
Большая проблема, которую люди забывают, заключается в том, что udp основан на пакетах, а tcp основан на потоке, нет гарантии, что отправленный вами пакет "tcp" - это пакет, который отображается на другом конце, его можно разложить на столько пакетов, сколько хотят маршрутизаторы и стеки. Таким образом, ваше программное обеспечение имеет дополнительные накладные расходы на обработку байтов обратно в пригодные для использования фрагменты данных, что может потребовать достаточного количества накладных расходов. UDP может быть не в порядке, поэтому вам нужно будет пронумеровать свои пакеты или использовать какой-либо другой механизм, чтобы переупорядочить их, если вы этого хотите. Но если вы получите этот udp-пакет, он поступает со всеми одинаковыми байтами в том же порядке, в каком он остался, никаких изменений. Таким образом, термин udp-пакет имеет смысл, но пакет tcp не обязательно. У TCP есть свой механизм повторной попытки и заказа, который скрыт от вашего приложения, вы можете повторно изобрести это с UDP, чтобы адаптировать его к вашим потребностям.
UDP гораздо проще писать код на обоих концах, в основном потому, что вам не нужно создавать и поддерживать соединения точка-точка. Мой вопрос, как правило, где ситуации, в которых вы хотите накладные расходы TCP? И если вы принимаете ярлыки, например, если получен пакет tcp "пакет" - это полный пакет, который был отправлен, вам лучше? (вы, вероятно, выбросите два пакета, если потрудитесь проверить длину/содержимое)
Потоковое видео является прекрасным примером использования UDP.
Сетевая связь для видеоигр почти всегда выполняется по протоколу UDP.
Скорость имеет первостепенное значение, и на самом деле не имеет значения, пропущены ли обновления, поскольку каждое обновление содержит полное текущее состояние того, что может видеть игрок.
В некоторых случаях, которые другие выделили, гарантированное прибытие пакетов не имеет значения, и, следовательно, использование UDP в порядке. Существуют и другие случаи, когда UDP предпочтительнее TCP.
Один уникальный случай, когда вы хотите использовать UDP вместо TCP, - это туннелирование TCP через другой протокол (например, туннели, виртуальные сети и т.д.). Если вы туннелируете TCP через TCP, элементы управления перегрузками каждого будут мешать друг другу. Следовательно, обычно предпочитается туннель TCP через UDP (или какой-либо другой протокол без сохранения состояния). См. Статью TechRepublic: Общие сведения о TCP через TCP: влияние туннелирования TCP на сквозную пропускную способность и задержку.
Ключевой вопрос был связан с "в каких ситуациях UDP был бы лучшим выбором [по tcp]"
Существует много замечательных ответов, но отсутствует какая-либо формальная объективная оценка влияния неопределенности транспорта на производительность TCP.
При массовом росте мобильных приложений и связанных с ними "случайно связанных" или "случайно отключенных" парадигмах, которые идут с ними, есть определенные ситуации, когда накладные расходы TCP пытаются поддерживать соединение, когда соединения трудно найти к сильному делу для UDP и его "ориентированному на сообщения" характеру.
Теперь у меня нет математики/исследований/номеров, но я создал приложения, которые работают более надежно, используя ACK/NAK и нумерацию сообщений по UDP, чем это можно было бы достичь с помощью 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 через TCP в тех случаях, когда потеря некоторых данных по пути не полностью разрушает передаваемые данные. Многие из них используются в приложениях реального времени, таких как игры (например, FPS, где вам не всегда нужно знать, где каждый игрок находится в любой момент времени, и если вы потеряете несколько пакетов на этом пути, новый данные будут правильно сообщать вам, где игроки в любом случае), и потоковое видео в реальном времени (один поврежденный кадр не собирается разрушать просмотр).
У нас есть веб-сервис с тысячами клиентов winforms на любом ПК. ПК не имеют связи с БД БД, все доступ осуществляется через веб-службу. Таким образом, мы решили создать центральный сервер регистрации, который прослушивает порт UDP, и все клиенты отправляют пакет журнала ошибок xml (с помощью приложения log4net UDP), который сбрасывается в таблицу DB после получения. Поскольку нам все равно, если пропустить несколько журналов ошибок и с тысячами клиентов это быстро, с помощью специальной службы ведения журнала, не загружающей основную веб-службу.
Сравнение TCP с UDP, протоколы без подключения, такие как UDP, обеспечивают скорость, но не надежность передачи пакетов. Например, в видеоиграх обычно не нужна надежная сеть, но скорость является самой важной, и использование UDP для игр имеет преимущество уменьшения задержки сети.
Я немного неохотно предлагаю UDP, когда TCP может работать. Проблема в том, что если TCP по какой-то причине не работает, поскольку соединение слишком отсталое или перегруженное, изменение приложения для использования UDP вряд ли поможет. Плохое соединение плохо для UDP тоже. TCP уже делает очень хорошую работу по минимизации перегруженности.
Единственный случай, когда я могу думать о том, где требуется UDP, - это широковещательные протоколы. В случаях, когда приложение включает в себя два известных хоста, UDP, скорее всего, будет предлагать лишь незначительные преимущества в производительности для значительного увеличения стоимости сложности кода.
Используйте только UDP, если вы действительно знаете, что делаете. В настоящее время UDP находится в крайне редких случаях, но количество (даже очень опытных) экспертов, которые будут пытаться использовать его везде, кажется, несоразмерно. Возможно, им нравится внедрять код обработки ошибок и код обслуживания подключения.
Ожидается, что TCP будет намного быстрее с современными картами сетевого интерфейса из-за того, что известно как отпечаток контрольной суммы. Удивительно, но при быстрой скорости соединения (например, 1 Гбит/с) вычисление контрольной суммы будет большой нагрузкой для процессора, поэтому она выгружается на аппаратное обеспечение NIC, которое распознает пакеты TCP для отпечатка, и оно не предложит вам та же услуга.
UDP идеально подходит для VoIP-адресов, куда должен быть отправлен пакет данных, что снижает его надежность... Видео-чат - пример UDP (вы можете проверить его путем захвата сети wirehark во время любого видеочата). Также TCP не работает с DNS и протоколами SNMP. UDP не имеет накладных расходов, в то время как TCP имеет много служебных