Для чего нужен UDP, если он не гарантирует доставку?

#udp

Раз UDP протокол не гарантирует доставку пакетов или сегментов как там, то зачем
его вообще использовать?
    

Ответы

Ответ 1

Гарантия доставки далеко не всегда является основным критерием выбора протокола.
Встает вопрос цены обеспечения этих гарантий. Протокол TCP требует установления соединения,
этот процесс состоит из обмена тремя пакетами. После того как соединение установлено
при передаче данных используются периодические подтверждения приема информации и повторные
отправки, в случае если она не дошла. Для этого ядру операционной системы необходимо
помнить состояние всех открытых TCP соединений и поддерживать буфера для принимаемой/передаваемой
информации. А приложению необходимо для общения с каждым клиентом использовать отдельное
соединение, при том что в большинстве ОC есть серьезные ограничения на количество одновременно
открытых процессом дескрипторов файлов/соединений (часто всего 255 штук). А например
Windows XP по умолчанию одновременно обслуживает не более 5 соединений, находящихся
в стадии открытия.

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

Рассмотрим некоторые применения UDP:


Протокол назначения IP-адресов DHCP. Используется UDP так как в начале процесса у
клиента еще нет IP и он не знает адреса сервера, который ему ответит. Поэтому необходимо
использовать многоадресную рассылку без указания реального адреса отправителя.
Мессенджеры. Требуется обмен короткими сообщениями с множеством клиентов. Зачастую
недостаточно максимального количества открытых TCP соединений на процесс. Передавать
информацию любому получателю с помощью одного общего сокета эффективное решение.
Многоадресная рассылка: так как не требуется установление соединения с конкретным
получателем то возможно использовать UDP при передаче multiсast/broadсast сообщений,
т.е. сообщений предназначенных сразу многим получателям.
Торрент клиенты. Так же как и мессанджерам требуется общаться с множеством получателей,
при том что для установления необходимости дальнейшего взаимодействия достаточно обмена
2мя пакетами. При передаче файла порядок принимаемых фрагментов и потеря каких то из
них не критична. Приложение само знает куда какой кусок положить и имеет поддержку
докачки потерянного (возможно из других источников).
SNMP (дословно: "Простой протокол управления сетью"). Используется повсеместно различным
сетевым оборудованием. Используется UDP так как его реализация в железе значительно
проще, чем TCP из за отсутствия необходимости поддерживать таблицы сессий и использовать
для этого оперативную память, которой на устройстве может быть крайне мало.
Передача потокового видео/голоса. У TCP есть серьезная проблема, при потере одного
фрагмента приложению не будет передана никакая информация до тех пор пока потеря не
будет компенсирована ядром OS. А для этого должен истечь таймаут ожидания пакета, отправлен
запрос повтора и получен ответ. Такая задержка при передаче видео потока реального
времени может быть не приемлемой. В то же время, т.к. в большинстве пакетов идут изменения
к предыдущему опорному кадру потеря одного пакета приведет только к невозможности отразить
изменения на небольшом участке, что не заметно для человеческого глаза. И когда передача
пакета будет повторена в нем уже не будет необходимости, так как за это время уже отрисовано
несколько последующих кадров. Приостановка же всего потока в ожидании повтора приведет
к несколько секундной задержке всего изображения.


Ответ 2

Для гарантированного ответа TCP использует так называемое  "тройное рукопожатие".
Таким образом если среднее время, требуемое на отправку данных из точки А в точку Б
составляет 10 мс, то для получения данных по TCP потребуется около 30 мс, в то время
как по UDP не проводятся рукопожатия и время сокращается. Помимо времени протокол TCP
использует больше служебной информации​. В некоторых случаях это критично, поэтому
используют UDP. Например, на протоколе UDP работают торрент-клиенты. В них каждая часть
файла подписывается и клиент получивший пакет проверяет нужен ли он ему или нет. UDP
пакет может придти два раза, а может и не придти вовсе. Это основная разница, но есть
конечно еще нюансы. Подробнее можете почитать здесь: http://thedifference.ru/chem-otlichaetsya-protokol-tcp-ot-udp/


Ответ 3

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

Что же касается гарантии доставки, то и с TCP тоже не все так просто.

Вы же не думаете, что если вызвать stream.Write(byte[],int) и тут произойдет обрыв
(достаточно длительный чтобы кончились несколько re-transmission), то будет выброшено
исключение?

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

Действительно надежен только HTTP. Именно благодаря этому у него такой отрыв в популярности.
Ну, и благодаря разным фичам тоже, но если мыслить глубже, то ясно, что это взаимосвязано.

Источник: опыт разработки клиент-серверной системы на TCP, работающей 24/7/365, с
максимальной надежностью и оперативностью информирования сервера о недоступных клиентах.