Руководство по UDP (протокол дейтаграмм пользователя)

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

История UDP

UDP существует почти столько же, сколько Интернет. Интернет возник в мае 1974 года, когда Институт инженеров по электротехнике и электронике опубликовал:Программа для межсетевого обмена пакетной сетью” по Винт Серф и Боб Хан. Концепция должна была быть разработана, и Хан и Серф продолжали совершенствовать свои идеи, работая на правительство США. Агентство оборонных перспективных исследовательских проектов, который также известен как DARPA. Джон Постел вмешался и предложил разделить единую структуру, предложенную в первоначальной идее Серфа и Хана. Это создало многоуровневую концепцию. Первоначальная Программа управления передачей, содержащаяся в набросках 1974 года, была разделена на Протокол управления передачей на более высоком уровне и Интернет-протокол на более низком уровне (следовательно, TCP / IP)..

Модульный подход Постела имел смысл, когда команда начала задумываться над реализацией теории. Было четкое разделение труда между тем, что стало известно как Транспортный уровень, где находится протокол управления передачей и Интернет-слой, где находится интернет-протокол. Тем не менее, Серф и Хан предусмотрели необходимость быстрого варианта. Они составили схему того, как данные будут подготовлены для передачи при передаче из одного уровня в другой. Задачи обработки были представлены в виде прямой вертикальной линии, спускаясь по их новой диаграмме стека, показывающей прогресс от приложение к TCP и к IP.

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

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

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

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

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

Уникальный идентификатор для каждого сеанса означал, что TCP добавил ценность для связи между двумя компьютерами. В конце 70-х и начале 80-х годов только крупные организации и академические учреждения имели компьютеры и сети. Таким образом, весьма вероятно, что двум организациям нужны их большие мэйнфреймы для одновременного соединения друг с другом для разных целей. Пока профессор отправлял файл коллеге в другом университете, исследователь может также захотеть открыть сеанс Telnet для компьютера в том же удаленном университете. Благодаря TCP два компьютера могут поддерживать несколько соединений одновременно, и каждый из этих сеансов может одновременно работать с несколькими каналами.. Эти параллельные соединения были бы невозможны, если бы связь регулировалась только интернет-протоколом с выделением одного IP-адреса на компьютер.. UDP, без какого-либо механизма сеанса, был неспособен управлять приложениями, которым требовался компьютер, с которым связались, чтобы отправить ответ.

Безопасность данных

Блестящие конструкции TCP сделали возможным соединение между сетями, и Интернет начал расширяться за пределы Академии в деловой мир. Создание Всемирная паутина, которая стала общедоступной в 1991 году, стала возможной только из-за легкости, с которой веб-страница с протоколом передачи гипертекста (HTTP) могла размещаться поверх TCP.

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

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

Основным препятствием для сбора платежей через Интернет было отсутствие безопасности. Несколько заголовков о краже данных в интернет-передачах закрывают возможность сделать Интернет коммерчески жизнеспособным. тем не мение, Netscape придумал HTTPS – безопасная версия HTTP, защищающая передачу. Идеальное расположение в стеке TCP / IP для этих процедур безопасности было во время процессов установления сеанса TCP. Так, TCP стал еще более важным для работы в Интернете и казалось еще более вероятным, что UDP никогда не будет использоваться.

UDP взлетает

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

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

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

Проблемы с TCP

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

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

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

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

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

Партнерские протоколы

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

Протокол инициации сеанса

Протокол инициации сеанса (SIP) был изобретен для приложений передачи голоса по IP (VoIP). Интернет-телефония не хотела буферизации TCP, но им нужно было подражать традиционным процедурам установления телефонных звонков – набрать, позвонить, занято, забрать и завершить вызов. Однако SIP не управляет всем сеансом, он просто заботится о функциях создания и разрыва соединения TCP. Каждый звонок, который проходит через Интернет, использует SIP. Настолько, что «SIP» почти стал взаимозаменяемым термином с «VoIP.»

Объемный голосовой трафик по высокоскоростным цифровым соединениям называется «SIP-транкинг.«Переключение вызова из Интернета на обычный стационарный телефон называется«SIP-терминация.«Индустрия цифровой телефонии использует SIP для идентификации своих технологий, но основой всей их деятельности является UDP.

Транспортный протокол в реальном времени

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

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

RTP способен переупорядочивать непоследовательные пакеты и замечать потерянные пакеты. Однако функция секвенирования не нуждается в реализации и ее невозможно реализовать без буферизации на транспортном уровне..

Протокол управления RTP

RTP всегда сотрудничает с RTCP, который является протоколом управления RTP. RTPC эмулирует некоторые функции управления сеансами TCP, за исключением того, что руководящим принципом протокола является не вмешиваться в поток и не замедлять передачу мультимедиа; поэтому его деятельность нечаста. Протокол будет собирать данные о производительности, включая потерю пакетов, и скорость передачи информации. Принимающий проигрыватель может использовать эту информацию, чтобы решить, следует ли перейти на видео с более низким разрешением или другой стандарт кодирования видео.

Если вы используете видео и аудио приложение, то почти наверняка задействованы RTP и RTCP. Существует “перемежения»В определении RTSP (см. Ниже), который будет переводить передачи RTP на TCP. Тем не менее, это необычное предложение, которое никогда не было реализовано за пределами лаборатории. Без этой спецификации все действия RTP и RTCP осуществляются по протоколу UDP..

Потоковый протокол в реальном времени

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

Приложения только для UDP

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

Если вы управляете сетью, вы будете знакомы с Сетевой протокол времени (NTP), Система доменных имен (DNS), Протокол динамической конфигурации хоста (DHCP), и Тривиальный протокол передачи файлов (TFTP). Все эти сервисы администрирования работают через UDP. Помимо этих приложений частной сети очень трудно найти какое-либо приложение, которое работает только по UDP.

UDP против TCP

Сравнение структуры заголовка UDP и структуры заголовка TCP показывает ограничения UDP.

Заголовок UDP имеет только четыре поля. Из этих четырех Порт источника поле не является обязательным и может быть оставлено пустым. В IPv4 Контрольная сумма поле также является необязательным, хотя оно обязательно для реализаций IPv6. Это означает, что в случае передач IPv4 заголовок UDP должен содержать только две части информации..

Заголовок TCP может нести гораздо больше информации.

Как видно из иллюстрации, заголовок пакета TCP имеет серию из девяти флагов, которые адаптируют значение заголовка. Это событие имеет «срочное» поле. Это дает системе TCP большую гибкость, чем UDP, и показывает, что гораздо больше времени было потрачено на процедуры для TCP и структуру заголовка пакета, чем было потрачено на разработку UDP..

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

Безопасность для UDP

Методы TCP, ориентированные на установление соединения, значительно упрощают реализацию защиты в этом протоколе в UDP. Однако для UDP существуют стандарты шифрования. Основной опцией, которая непосредственно направлена ​​на безопасность UDP, является протокол безопасности транспортного уровня датаграмм или DTLS..

к счастью, DTLS доступен в ряде бесплатных библиотек с открытым исходным кодом., поэтому вам не нужно прочесывать определение протокола и писать свою открытую программу для его реализации. OpenSSL, которая является библиотекой открытого исходного кода, является наиболее распространенным источником для реализации Transport Layer Security, которая является наиболее широко внедренной системой безопасности для TCP. Эта библиотека также включает реализацию DTLS, так что вы должны иметь возможность встретить защищенные параметры UDP в тех же приложениях, которые предлагают безопасные соединения TCP.

Другим вариантом для пользователей UDP является использование системы безопасности, которая была разработана для работы на интернет-уровне. Это IPSec, или Безопасность интернет-протокола. Поскольку IPSec работает ниже транспортного уровня, он не может работать с портами, и поэтому тот факт, что UDP не может поддерживать сеанс, не имеет значения, когда IPSec включен. – Протоколы IP-уровня также не могут создавать сеансы. Как система нижнего уровня, IPSec может поддерживать любой протокол транспортного уровня, включая UDP.

IPSec включает в себя методы аутентификации, а также шифрует пакеты, чтобы защитить их от прослушивания телефонных разговоров. ИТ предлагает такую ​​же безопасность, как и популярный TLS, но менее широко применяется. IPSec использует систему Internet Key Exchange (IKEv2) для настройки аутентификации, поэтому довольно часто IPSec выставляется как IKEv2. Методология IKEv2 использует Процедура обмена ключами Диффи-Хеллмана, которая точно такая же система, которую TLS использует для методологии сеанса безопасной веб-страницы HTTPS.

Kerberos и Kerberized Internet Negotiation of Keys (KINK) – это два элемента системы безопасности, которая обычно называется Kerberos. Процедуры установления сеанса Kerberos используют систему «билетов», которая аналогична методу TLS с использованием «сертификатов». В самом низу стека Kerberos опирается на IPSec. Одноименный уровень Kerberos расположен поверх UDP и использует сокеты UDP для облегчения связи. Так что это UDP-дружественная система безопасности. Интересным средством Kerberos является то, что он позволяет вам использовать шифрование AES для защиты ваших UDP-передач.. AES, вероятно, является наиболее безопасным шифром для общего пользования на сегодняшний день, и это рекомендуемый метод безопасности для лучших в мире систем защиты конфиденциальности VPN..

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

Будущее УДП

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

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

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

Надежный протокол дейтаграмм пользователя (RUDP), который имеет реализации Cisco и Microsoft.

Протокол передачи управления потоком (SCTP), который был безуспешно предложен в качестве замены комбо UDP / RTP / RTCP, но так и не сдвинулся с мертвой точки.

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

Какие способы передачи вы используете? Вы видите UDP-гадкого утенка как лебедя? Напишите о своем опыте в разделе комментариев ниже.

Связанный:
Полное руководство по TCP / IP
Что такое TCPdump?
Обзор TFTP сервера SolarWinds
TFTPD32 TFTP сервер обзор

Картинки:
Заголовок UDP от Devarshi в англоязычных Wikibooks под лицензией CC BY-SA 2.5
Макет пакета TCP с битовой шкалой. Автор: Quliyevferman, Wikimedia Commons. Лицензировано в соответствии с CC BY-SA 4.0