Для чего используется udp

Как работает User Datagram Protocol (UDP)

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

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

Востребованность UDP

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

Возможности User Datagram Protocol

Заголовок UDP

UDP-заголовок так же прост, как и его функция.

Заголовок UDP содержит четыре основных параметра:

Где используется UDP?

Вот несколько приложений, в которых UDP используется для передачи данных:

Источник

Протокол UDP — преимущества, недостатки и применение

А зачем протокол транспортного уровня, если он не обеспечивает надежность доставки выше чем IP, почему нельзя использовать просто IP для передачи данных?

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

Формат заголовка

Формат заголовка udp состоит из 4-х полей:

Преимущества и применение UDP

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

Ошибки в современных сетях происходят достаточно редко и сетевые приложения способны самостоятельно исправлять такие, редко возникающие ошибки.

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

Применение UDP: DNS

В качестве применения UDP рассмотрим систему доменных имен DNS. DNS позволяют определить по доменному имени соответствующий ему IP-адрес. Например к доменному имени www.cisco.com соответствует вот такой IP адрес 184.86.0.170. Система DNS использует протокол UDP, порт 53.

Рассмотрим пример сетевого взаимодействия в DNS. В системе DNS есть сервер, который знает какие IP-адреса соответствуют доменным именам и клиент, который хочет получить такую информацию. Клиент DNS направляет запрос серверу, какой IP у доменного имени www.cisco.com? Сервер DNS получает такой запрос, находит соответствующий IP-адрес и отправляет ответ (184.86.0.170) взаимодействие происходит с использованием протокола UDP и для получения IP-адреса достаточно всего две дейтаграммы.

Если бы для запроса IP-адреса использовался протокол TCP, то необходимо было бы передать гораздо больше сообщений. Перед тем как запрашивать IP-адрес необходимо было бы установить соединение TCP. Для этого нужно 3 сообщения, затем запросить IP-адрес, получить ответ (еще 2 сообщения) и после того, как ответ получен нужно разорвать соединение, для этого нужно 3 или 4 сообщения.

Недостаток UDP

Недостаток UDP в том, что он не обеспечивает надежности передачи данных, поэтому ошибки должно обрабатывать приложение. Рассмотрим, что произойдет, если запрос потерялся. Приложение клиента DNS при отправке запроса (www.cisco.com?) запускает таймер, если в течении какого-то времени ответ не приходит, таймер срабатывает и тот же самый запрос отправляется еще раз.

В этот раз запрос дошел (www.cisco.com) и DNS сервер в ответ отправил нам IP-адрес, который был необходим (184.86.0.170). Даже с учетом того, что произошла потеря данных ip-адрес все равно получен быстрее, чем если бы использовался протокол TCP. Однако существенным недостатком использования UDP является то, что приложение само должно обрабатывать ошибочные ситуации.

Выводы по протоколу UDP

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

UDP (User Datagram Protocol)

UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — один из ключевых элементов TCP/IP, набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (в данном случае называемые датаграммами) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных. Протокол был разработан Дэвидом П. Ридом в 1980 году и официально определён в RFC 768.

UDP использует простую модель передачи, без неявных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных. Таким образом, UDP предоставляет ненадёжный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не нужны, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. При необходимости исправления ошибок на сетевом уровне интерфейса приложение может задействовать TCP или SCTP, разработанные для этой цели.

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

Содержание

Служебные порты

UDP-приложения используют датаграммные сокеты для установки соединения между хостами. Приложение связывает сокет с его конечной точкой передачи данных, которая является комбинацией IP-адреса и порта службы. Порт — это программная структура, определяемая номером порта — 16-битным целочисленным значением (то есть от 0 до 65535). Порт 0 зарезервирован, хотя и является допустимым значением порта источника в случае, если процесс-отправитель не ожидает ответных сообщений.

IANA разбила номера портов на три группы.

Структура пакета

UDP — минимальный ориентированный на обработку сообщений протокол транспортного уровня, задокументированный в RFC 768.

UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. — Ненадёжный протокол датаграмм).

UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надёжная передача в случае необходимости должна реализовываться пользовательским приложением.

Заголовок UDP состоит из четырёх полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.

Порт отправителя

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

Порт получателя

Это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если хостом-получателем является клиент, то номер порта динамический, если получатель — сервер, то это будет «хорошо известный» порт.

Длина датаграммы

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

На практике также следует учитывать, что если длина IPv4 пакета с UDP будет превышать MTU (для Ethernet по умолчанию 1500 байт), то отправка такого пакета может вызвать его фрагментацию, что может привести к тому, что он вообще не сможет быть доставлен, если промежуточные маршрутизаторы или конечный хост не будут поддерживать фрагментированные IP пакеты. Также в RFC791 указывается минимальная длина IP пакета 576 байт, которую должны поддерживать все участники, и рекомендуется отправлять IP пакеты большего размера только в том случае если вы уверены, что принимающая сторона может принять пакеты такого размера. Следовательно, чтобы избежать фрагментации UDP пакетов (и возможной их потери), размер данных в UDP не должен превышать: MTU — (Max IP Header Size) — (UDP Header Size) = 1500 — 60 — 8 = 1432 байт. Для того чтобы быть уверенным, что пакет будет принят любым хостом, размер данных в UDP не должен превышать: (минимальная длина IP пакета) — (Max IP Header Size) — (UDP Header Size) = 576 — 60 — 8 = 508 байт.

В Jumbogram’мах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4 294 967 295 байт (232 — 1), из которых 8 байт соответствуют заголовку, а остальные 4 294 967 287 байт — данным.

Следует заметить, что большинство современных сетевых устройств отправляют и принимают пакеты IPv4 длиной до 10000 байт без их разделения на отдельные пакеты. Неофициально такие пакеты называют «Jumbo-пакетами», хотя понятие Jumbo официально относится к IPv6. Тем не менее, «Jumbo-пакеты» поддерживают не все устройства и перед организацией связи с помощью UDP/IP IPv4 посылок с длиной превышающей 1500 байт нужно проверять возможность такой связи опытным путём на конкретном оборудовании[1].

Контрольная сумма

Поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями. Поле не является обязательным для IPv4.

Расчет контрольной суммы

Метод для вычисления контрольной суммы определён в RFC 1071[2].

Перед расчётом контрольной суммы, если длина UDP-сообщения в байтах нечётна, то UDP-сообщение дополняется в конце нулевым байтом (псевдозаголовок и добавочный нулевой байт не отправляются вместе с сообщением, они используются только при расчёте контрольной суммы). Поле контрольной суммы в UDP-заголовке во время расчёта контрольной суммы принимается нулевым.

Значение контрольной суммы, равное 0х0000 (+0 в обратном коде), зарезервировано и означает, что для посылки контрольная сумма не вычислялась. В случае, если контрольная сумма вычислялась и получилась равной 0х0000, то в поле контрольной суммы заносят значение 0xffff(-0 в обратном коде).

Пример расчета контрольной суммы

Для этого можно сначала сложить попарно числа, рассматривая их как 16-разрядные беззнаковые числа с последующим приведением к дополнительному коду путём прибавления единицы к результату, если при сложении произошёл перенос в старший (17-й) разряд (т. е. де-факто, этой операцией мы переводим отрицательное число из дополнительного в обратный код). Или, что равноценно, можно считать, что перенос прибавляется к младшему разряду числа.

В конце выполняется инверсия всех битов получившегося числа

В документе RFC 1071[2] приведены и другие способы расчёта контрольной суммы, в частности, с использованием 32х-разрядной арифметики.

Псевдозагаловки

Псевдозагаловок для IPv4

Если UDP работает над IPv4, контрольная сумма вычисляется при помощи псевдозаголовка, который содержит некоторую информацию из заголовка IPv4. Псевдозаголовок не является настоящим IPv4-заголовком, используемым для отправления IP-пакета. В таблице приведён псевдозаголовок, используемый только для вычисления контрольной суммы.

Псевдозаголовок для IPv6

При работе UDP над IPv6 контрольная сумма обязательна. Метод для её вычисления был опубликован в RFC 2460:

При вычислении контрольной суммы опять используется псевдозаголовок, имитирующий реальный IPv6-заголовок:

Адрес источника такой же, как и в IPv6-заголовке. Адрес получателя — финальный получатель; если в IPv6-пакете не содержится заголовка маршрутизации (Routing), то это будет адрес получателя из IPv6-заголовка, в противном случае, на начальном узле, это будет адрес последнего элемента заголовка маршрутизации, а на узле-получателе — адрес получателя из IPv6-заголовка. Значение «Следующий заголовок» равно значению протокола — 17 для UDP. Длина UDP — длина UDP-заголовка и данных.

Надёжность и решения проблемы перегрузок

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

Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP — примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надёжности, то можно использовать другой протокол (TCP) или воспользоваться методами помехоустойчивого кодирования (en:Erasure code).

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

Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol — протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.

Приложения

Многочисленные ключевые Интернет-приложения используют UDP, в их числе — DNS (где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа), Простой Протокол Управления Сетями (SNMP), Протокол Маршрутной Информации (RIP), Протокол Динамической Конфигурации Узла (DHCP).

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

Сравнение UDP и TCP

TCP — ориентированный на соединение протокол, что означает необходимость «рукопожатия» для установки соединения между двумя хостами. Как только соединение установлено, пользователи могут отправлять данные в обоих направлениях.

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

Источник

Протоколы TCP и UDP: в чем разница

Говоря о безопасности информации, мы имеем в виду конфиденциальность, целостность и доступность информации в каждый момент времени. И если с конфиденциальностью и доступностью все понятно, то как обеспечить целостность информации при ее передаче по сети? Для решения этой задачи нам пригодится знание сетевых протоколов.

В данной статье мы рассмотрим протоколы TCP и UDP: что из себя представляет каждый из этих протоколов, в чем их отличие и когда целесообразнее использовать UDP подключение, а когда TCP.Они входят в стек протоколов TCP/IP, относятся к транспортному уровню модели OSI и используются для передачи информации от узла к узлу.

UDP protocol – протокол, обеспечивающий передачу данных (датаграмм) без предварительного создания соединения между хостами. При отправке датаграмм нет уверенности в существовании получателя и его готовности к обмену. Сетевой протокол UDP не обеспечивает также упорядочивание датаграмм при получении. Он используется приложениями для которых существенное значение имеет время доставки, когда нет возможности ждать задержавшиеся или запрашивать потерянные пакеты, например, в системах реального времени. Датаграммы могут доставляться не в заданном порядке, дублироваться или вовсе не доставляться. Поэтому протокол UDP называют «ненадёжным протоколом датаграмм».

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

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

Перед началом передачи пакетов через TCP соединение устанавливается сессия с получателем, в рамках которой затем производится передача данных. Это позволяет убедиться в том, что получатель существует и готов принимать данные. После завершения передачи сессия закрывается, получатель извещается о том, что данных больше не будет, а отправитель извещается о том, что получатель извещён.

Каждый пакет при обмене имеет свой порядковый номер. TCP автоматически упорядочивает пакеты, используя порядковый номер, и передает после склейки на уровень приложений. После отправки нескольких пакетов, ожидается подтверждение и порядковый номер следующего пакета. Если подтверждение не получено, отправка повторяется, если попытки не увенчались успехом, сессия разрывается. Количество пакетов данных, на которые будет запрашиваться подтверждение, зависит от надежности сети. Если данные теряются, то подтверждение автоматически запрашивается чаще. Это называется механизмом скользящего окна (sliding window), благодаря которому TCP может работать с сетями, независимо от уровня их надежности.

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

TCP и UDP отличия

Означает ли это, что протокол UDP не стоит использовать? Вовсе нет. За счет отсутствия «гарантии доставки» протокол UDP обеспечивает более высокую скорость передачи данных, чем TCP. По этой причине UDP оптимален для сетевых и онлайн игр, просмотра потокового видео, организации видео-связи и IP телефонии.

Как сделать выбор: TCP или UDP для vpn?

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

Наши клиенты часто спрашивают, какой протокол лучше: tcp или udp для vpn. Прочитав этой статье о tcp и udp протоколах, вы сами можете решить, какой из них лучше подходит именно вам. OpenVPN приложения работают как с UDP, так и с TCP, и оба протокола безопасны и обеспечивают анонимность. Какой из них использовать, зависит от того, для чего вы используете VPN.

В дополнение к собственному впн-клиенту, мы предоставляем нашим пользователям Openvpn конфиги для использования с любым подходящим клиентом на выбранной платформе. Рекомендуем вам посмотреть видео-инструкцию Меняем TCP на UDP в OpenVPN на нашем youtube-канале, если вы используете OpenVPN клиент.

Подписывайтесь на нас в соцсетях, задавайте вопросы и делитесь полезной информацией с друзьями и близкими!

Источник

Протокол пользовательской датаграммы (UDP)

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

Cодержание

Функциональность

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

Видео в прямом эфире

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

Онлайн игры

Аналогично, онлайн игры реализуют аналогичную концепцию. Символы проигрывателя могут появляться при телепортации по картам, когда вы получаете новые UDP-пакеты при пропуске некоторых из предыдущих передач данных. Игра продолжается, и пользователям не нужно извлекать старые и потерянные пакеты. Отмена коррекции ошибок TCP снижает задержки и улучшает скорость игрового соединения. [5] Отсутствие UDP пакетов во время игры приведет к незначительным сбоям, но не обязательно изменит ее производительность. В то время как игра продолжается в UDP, TCP зависимые игры будут иметь другой результат, который является целым замораживанием игры. В онлайн-играх важно то, что происходит в режиме реального времени. [6]

Эффекты

Как уникальный протокол, протокол User Datagram Protocol имеет свои плюсы и минусы. Некоторые из наиболее распространенных, с которыми вы столкнетесь, объясняются ниже.

Преимущества

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

Недостатки

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

Протоколы и порты

Каждому устройству или компьютеру в Интернете присвоен свой уникальный номер, известный как IP-адрес. Это для конкретного компьютера, который должен быть идентифицирован, когда вы находитесь в Интернете. Информация, передаваемая через Интернет с компьютера, теперь принимается с помощью портов. Как и TCP, UDP также имеет свои специфические функции и порты. Ниже приведены некоторые из наиболее часто используемых для UDP.

Система доменных имен (DNS RFC 1034-1035: порт 53)

Протокол DNS является одним из широко используемых протоколов как в публичных, так и в частных сетях. Его основной целью является преобразование доменных имен в IP-адреса для маршрутизации по сети. широко используется в публичном интернете и частных сетях для преобразования доменных имен в IP-адреса, обычно для маршрутизации сети. DNS-серверы могут быть настроены внутри частной сети, не будучи частью глобальной системы.

Протокол динамической конфигурации хоста (DHCP RFC 2131: порт 67/68)

Этот протокол в основном используется в сетях, не использующих статические назначения IP-адресов. Сервер может быть настроен либо инженером, либо администратором, у которого есть доступный для назначения пул адресов. Клиент может включить устройство и запросить IP-адрес с локального DHCP-сервера, когда есть доступный адрес, он будет назначен устройству. Однако это не является постоянным назначением и истекает через определенный промежуток времени. Срок действия договора аренды истекает, если не подается запрос на продление, и он будет возвращен в пул для передачи другим устройствам.

Тривиальный протокол передачи файлов (TFP RFC 1350: порт 69)

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

Простой протокол сетевого управления (SNMP RFC 1901-1908, 3411-3418: порт 161-/162)

Протокол сетевого времени (NTP RFC 5905: порт 123)

Основной целью NTP является синхронизация устройств в Интернете, и считается одним из наиболее игнорируемых протоколов. Для поддержания точных часов в большинстве современных операционных систем используется протокол NTP. Устройство позволяет без особых усилий устранять неполадки на разных устройствах, поскольку часы точны, что делает NTP жизненно важной частью сетевых систем. [7]

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

Источник