Протокол ethernet udp. Протокол UDP

09.04.2019

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

Основы TCP

Протокол TCP (Transmission Control Protocol - протокол управления передачей) был специально разработан для обеспечения надежного сквозного байтового потока по ненадежной интерсети. Объединенная сеть отличается от отдельной сети тем, что ее различные участки могут обладать сильно различающейся топологией, пропускной способностью, значениями времени задержки, размерами пакетов и другими параметрами. При разработке TCP основное внимание уделялось способности протокола адаптироваться к свойствам объединенной сети и отказоустойчивости при возникновении различных проблем.

Протокол TCP описан в RFC 793. Со временем были обнаружены различные ошибки и неточности, и по некоторым пунктам требования были изменены. Подробное описание этих уточнений и исправлений дается в RFC 1122. Расширения протокола приведены в RFC 1323.

Каждая машина, поддерживающая протокол TCP, обладает транспортной сущностью TCP, являющейся либо библиотечной процедурой, либо пользовательским процессом, либо частью ядра системы. В любом случае, транспортная сущность управляет TCP-потоками и интерфейсом с IP-уровнем. TCP-сущность принимает от локальных процессов пользовательские потоки данных, разбивает их на куски, не превосходящие 64 Кбайт (на практике это число обычно равно 460 байтам данных, что позволяет поместить их в один кадр Ethernet с заголовками IP и TCP), и посылает их в виде отдельных IP-дейтаграмм. Когда IP-дейтаграммы с TCP-данными прибывают на машину, они передаются TCP-сущности, которая восстанавливает исходный байтовый поток. Для простоты мы иногда будем употреблять «TCP» для обозначения транспортной сущности TCP (части программного обеспечения) или протокола TCP (набора правил). Из контекста будет понятно, что имеется в виду. Например, в выражении «Пользователь передает данные TCP» подразумевается, естественно, транспортная сущность TCP.

Уровень IP не гарантирует правильной доставки дейтаграмм, поэтому именно TCP приходится следить за истекшими интервалами ожидания и в случае необходимости заниматься повторной передачей пакетов. Бывает, что дейтаграммы прибывают в неправильном порядке. Восстанавливать сообщения из таких дейтаграмм обязан также TCP. Таким образом, протокол TCP призван обеспечить надежность, о которой мечтают многие пользователи и которая не предоставляется протоколом IP.

Модель службы TCP

В основе службы TCP лежат так называемые сокеты (гнезда или конечные точки), создаваемые как отправителем, так и получателем. Они обсуждались в разделе «Сокеты Беркли». У каждого сокета есть номер (адрес), состоящий из IP-адреса хоста и 16-битного номера, локального по отношению к хосту, называемого портом. Портом в TCP называют TSAP-адрес. Для обращения к службе TCP между сокетом машины отправителя и сокетом машины получателя должно быть явно установлено соединение.

Один сокет может использоваться одновременно для нескольких соединений. Другими словами, два и более соединений могут оканчиваться одним сокетом. Соединения различаются по идентификаторам сокетов на обоих концах - (socket1, socket2). Номера виртуальных каналов или другие идентификаторы не используются.

Номера портов со значениями ниже 1024, называемые популярными портами, зарезервированы стандартными сервисами. Например, любой процесс, желающий установить соединение с хостом для передачи файла с помощью протокола FTP, может связаться с портом 21 хоста-адресата и обратиться, таким образом, к его FTP-демону. Список популярных портов приведен на сайте www.iana.org.

Можно было бы, конечно, связать FTP-демона с портом 21 еще во время загрузки, тогда же связать демона telnet с портом 23, и т. д. Однако если бы мы так сделали, мы бы только зря заняли память информацией о демонах, которые, на самом деле, большую часть времени простаивают. Вместо этого обычно пользуются услугами одного демона, называемого в UNIX inetd, который связывается с несколькими портами и ожидает первое входящее соединение. Когда оно происходит, inetd создает новый процесс, для которого вызывается подходящий демон, обрабатывающий запрос. Таким образом, постоянно активен только inetd, остальные вызываются только тогда, когда для них есть работа. Inetd имеет специальный конфигурационный файл, из которого он может узнать о назначении портов. Это значит, что системный администратор может настроить систему таким образом, чтобы с самыми загруженными портами (например, 80) были связаны постоянные демоны, а с остальными - inetd.

Некоторые зарезирвированные порты
	Протокол	Использование
21	FTP	Передача файлов
23	Telnet	Дистанционный вход в систему
25	SMTP	Электронная почта
69	TFTP	Простейший протокол передачи файлов
79	Finger	Поиск информации о пользователе
80	HTTP	Мировая Паутина
110	POP-3	Удаленный доступ к электронной почте
119	NNTP	Группы новостей

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

TCP-соединение представляет собой байтовый поток, а не поток сообщений. Границы между сообщениями не сохраняются. Например, если отправляющий процесс записывает в TCP-поток четыре 512-байтовых порции данных, эти данные могут быть доставлены получающему процессу в виде четырех 512-байтовых порций, двух 1024-байтовых порций, одной 2048-байтовой порции или как-нибудь еще. Нет способа, которым получатель смог бы определить, каким образом записывались данные.

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

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

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

Последней особенностью службы TCP, о которой следует упомянуть, являются срочные данные. Когда пользователь, взаимодействующий с программой в интерактивном режиме, нажимает клавишу Delete или Ctrl-C, чтобы прервать начавшийся удаленный процесс, посылающее приложение помещает в выходной поток данных управляющую информацию и передает ее TCP-службе вместе с флагом URGENT (срочно). Этот флаг заставляет TCP-сущность прекратить накопение данных и без промедления передать в сеть все, что у нее есть для данного соединения.

Когда срочные данные прибывают по назначению, получающее приложение прерывается (то есть «получает сигнал», в терминологии UNIX), после чего оно может считать данные из входного потока и найти среди них срочные. Конец срочных данных маркируется, так что приложение может распознать, где они заканчиваются. Начало срочных данных не маркируется. Приложение должно само догадаться. Такая схема представляет собой грубый сигнальный механизм, оставляя все прочее приложению.

Протокол TCP

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

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

Отправляющая и принимающая TCP-сущности обмениваются данными в виде сегментов. Сегмент состоит из фиксированного 20-байтового заголовка (плюс необязательная часть), за которой могут следовать байты данных. Размер сегментов определяется программным обеспечением TCP. Оно может объединять в один сегмент данные, полученные в результате нескольких операций записи, или, наоборот, распределять результат одной записи между несколькими сегментами. Размер сегментов ограничен двумя пределами. Во-первых, каждый сегмент, включая TCP-заголовок, должен помещаться в 65 515-байтное поле полезной нагрузки IP-пакета. Во-вторых, в каждой сети есть максимальная единица передачи (MTU, Maximum Transfer Unit), и каждый сегмент должен помещаться в MTU. На практике размер максимальной единицы передачи составляет обычно 1500 байт (что соответствует размеру поля полезной нагрузки Ethernet), и таким образом определяется верхний предел размера сегмента.

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

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

Хотя этот протокол кажется простым, в нем имеется несколько деталей, которые следует рассмотреть подробнее. Сегменты могут приходить в неверном порядке. Так, например, возможна ситуация, в которой байты с 3072-го по 4095-й уже прибыли, но подтверждение для них не может быть выслано, так как байты с 2048-го по 3071-й еще не получены. К тому же сегменты могут задерживаться в сети так долго, что у отправителя истечет время ожидания и он передаст их снова. Переданный повторно сегмент может включать в себя уже другие диапазоны фрагментов, поэтому потребуется очень аккуратное администрирование для определения номеров байтов, которые уже были приняты корректно. Тем не менее, поскольку каждый байт в потоке единственным образом определяется по своему сдвигу, эта задача оказывается реальной.

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

Заголовок ТСР-сегмента

Каждый сегмент начинается с 20-байтного заголовка фиксированного формата. За ним могут следовать дополнительные поля. После дополнительных полей может располагаться до 65 535 - 20 - 20 = 65 495 байт данных, где первые 20 байт - это IP-заголовок, а вторые - TCP-заголовок. Сегменты могут и не содержать данных. Такие сегменты часто применяются для передачи подтверждений и управляющих сообщений.

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

Поля Порядковый номер и Номер подтверждения выполняют свою обычную функцию. Обратите внимание: поле Номер подтверждения относится к следующему ожидаемому байту, а не к последнему полученному. Оба они 32-разрядные, так как в TCP-потоке нумеруется каждый байт данных.

Поле Длина TCP-заголовка содержит размер TCP-заголовка, выраженный в 32-разрядных словах. Эта информация необходима, так как поле Факультативные поля, а вместе с ним и весь заголовок, может быть переменной длины. По сути, это поле указывает смещение от начала сегмента до поля данных, измеренное в 32-битных словах. Это то же самое, что длина заголовка.

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

Затем следуют шесть 1-битовых флагов. Бит URG устанавливается в 1 в случае использования поля Указатель на срочные данные, содержащего смещение в байтах от текущего порядкового номера байта до места расположения срочных данных. Таким образом в протоколе TCP реализуются прерывающие сообщения. Как уже упоминалось, протокол TCP лишь обеспечивает доставку сигнала пользователя до получателя, не интересуясь причиной прерывания.

Если бит АСК установлен в 1, значит, поле Номер подтверждения содержит осмысленные данные. В противном случае данный сегмент не содержит подтверждения, и поле Номер подтверждения просто игнорируется.

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

Бит RST используется для сброса состояния соединения, которое из-за сбоя хоста или по другой причине попало в тупиковую ситуацию. Кроме того, он используется для отказа от неверного сегмента или от попытки создать соединение. Если вы получили сегмент с установленным битом RST, это означает наличие какой-то проблемы.

Бит SYN применяется для установки соединения. У запроса соединения бит SYN= 1, а бит АСК = 0, что означает, что поле подтверждения не используется. В ответе на этот запрос содержится подтверждение, поэтому значения этих битов в нем равны: SYN= 1, ACK- 1. Таким образом, бит SYN используется для обозначения сегментов CONNECTION REQUEST и CONNECTION ACCEPTED, а бит АСК - чтобы отличать их друг от друга.

Бит FIN используется для разрыва соединения. Он указывает на то, что у отправителя больше нет данных для передачи. Однако, даже закрыв соединение, процесс может продолжать получать данные в течение неопределенного времени. У сегментов с битами FIN и SYN есть порядковые номера, что гарантирует правильный порядок их выполнения.

Управление потоком в протоколе TCP осуществляется при помощи скользящего окна переменного размера. Поле Размер окна сообщает, сколько байт может быть послано после байта, получившего подтверждение. Значение поля Размер окна может быть равно нулю, что означает, что все байты вплоть до Номер подтверждения-1 получены, но у получателя в данный момент какие-то проблемы, и остальные байты он пока принять не может. Разрешение на дальнейшую передачу может быть получено путем отправки сегмента с таким же значением поля Номер подтверждения и ненулевым значением поля Размер окна.

В некоторых протоколах, подтверждения приема кадров связаны с разрешениями на продолжение передачи. Эта связь следствие жестко закрепленного размера скользящего окна в этих протоколах. В TCP подтверждения отделены от разрешений на передачу данных. В сущности, приемник может сказать: «Я получил байты вплоть до k-ro, но я сейчас не хочу продолжать прием данных». Такое разделение (выражающееся в скользящем окне переменного размера) придает протоколу дополнительную гибкость. Далее мы обсудим этот аспект более детально.

Поле Контрольная сумма служит для повышения надежности. Оно содержит контрольную сумму заголовка, данных и псевдозаголовка. При выполнении вычислений поле Контрольная сумма устанавливается равным нулю, а поле данных дополняется нулевым байтом, если его длина представляет собой нечетное число. Алгоритм вычисления контрольной суммы просто складывает все 16-разрядные слова в дополнительном коде, а затем вычисляет дополнение для всей суммы. В результате, когда получатель считает контрольную сумму всего сегмента, включая поле Контрольная сумма, результат должен быть равен 0.

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

Поле Факультативные поля предоставляет дополнительные возможности, не покрываемые стандартным заголовком. С помощью одного из таких полей каждый хост может указать максимальный размер поля полезной нагрузки, который он может принять. Чем больше размер используемых сегментов, тем выше эффективность, так как при этом снижается удельный вес накладных расходов в виде 20-байтных заголовков, однако не все хосты способны принимать очень большие сегменты. Хосты могут сообщить друг другу максимальный размер поля полезной нагрузки во время установки соединения. По умолчанию этот размер равен 536 байтам. Все хосты обязаны принимать TCP-сегменты размером 536 + 20 = 556 байт. Для каждого из направлений может быть установлен свой максимальный размер поля полезной нагрузки.

Для линий с большой скоростью передачи и/или большой задержкой окно размером в 64 Кбайт оказывается слишком маленьким. Так, для линии ТЗ (44,736 Мбит/с) полное окно может быть передано в линию всего за 12 мс. Если значение времени распространения сигнала в оба конца составляет 50 мс (что типично для трансконтинентального оптического кабеля), 3/4 времени отправитель будет заниматься ожиданием подтверждения. При связи через спутник ситуация будет еще хуже. Больший размер окна мог бы улучшить эффективность, но 16-битовое поле Размер окна не позволяет этого сделать. В RFC 1323 был предложен новый параметр Масштаб окна, о значении которого два хоста могли договориться при установке соединения. Это число позволяет сдвигать поле Размер окна до 14 разрядов влево, обеспечивая расширение размера окна до 230 байт (1 Гбайт). В настоящее время большинство реализаций протокола TCP поддерживают эту возможность.

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

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

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

Существует три типа номеров портов: назначенные (assigned ), зарегистрированные (registered ) идинамические (dynamic ) . Назначенные номера портов располагаются в диапазоне 0 – 1023 и полностью контролируются Комиссией по константамInternet. Они применяются для общеизвестных и стандартизированных сетевых служб. Зарегистрированные номера портов от 1024 до 65535 предназначены для регистрации производителями сетевого ПО своих приложений, работающих с данными портами. Динамические номера портов присваиваются сетевым ПО на локальной машине и могут повторяться от станции к станции для различных приложений.

Протокол udp

Протокол UDP(UserDatagramProtocol– протокол дейтаграмм пользователя) является не ориентированным на соединение транспортным протоколом с ненадежной доставкой данных. Т.е. он не обеспечивает подтверждение доставки пакетов, не сохраняет порядок входящих пакетов, может терять пакеты или дублировать их. ФункционированиеUDPпохоже наIP, за исключением введения понятия портов.UDPобычно работает быстрееTCPза счет меньших «накладных расходов». Он применяется приложениями, которые не нуждаются в надежной доставке, либо реализуют их сами. Например, сервера имен (NameServers), службаTFTP(TrivialFileTransferProtocol, тривиальный протокол передачи данных),SNMP(SimpleNetworkManagementProtocol, простой протокол управления сетью), системы аутентификации. ИдентификаторUDPпротокола в полеProtocol заголовкаIP– число 17.

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


			Destination Port

Рис. Формат заголовка UDP-пакета

Назначение полей udp пакета:

Номер порта отправителя – Source Port (16 бит) – содержит номер порта, с которого был отправлен пакет, когда это имеет значение (например, отправитель ожидает ответа). Если это поле не используется, оно заполняется нулями.

Номер порта назначения – Destination Port (16 бит) – содержит номер порта, на который будет доставлен пакет.

Длина – Length (16 бит) – содержит длину данной дейтаграммы в байтах, включая заголовок и данные.

Поле контрольной суммы – Checksum (16 бит) – представляет собой побитное дополнение 16-битной суммы 16-битных слов. В вычислении суммы участвуют: данные пакета с полями выравнивания по 16-битной границе (нулевые), заголовокUDP-пакета, псевдозаголовок (информация отIP-протокола).

Протоколы TCP и UDP

TCP- Transmission Control Protocol

Обмен данными, ориентированный на соединения, может использовать надежную связь, для обеспечения которой протокол уровня 4 посылает подтверждения о получении данных и запрашивает повторную передачу, если данные не получены или искажены. Протокол TCP использует именно такую надежную связь. TCP используется в таких прикладных протоколах, как HTTP, FTP, SMTP и Telnet.

Протокол TCP требует, чтобы перед отправкой сообщения было открыто соединение. Серверное приложение должно выполнить так называемое пассивное открытие (passive open) , чтобы создать соединение с известным номером порта, и, вместо того чтобы отправлять вызов в сеть, сервер переходит в ожидание поступления входящих запросов. Клиентское приложение должно выполнить активное открытие (active open) , отправив серверному приложению синхронизирующий порядковый номер (SYN), идентифицирующий соединение. Клиентское приложение может использовать динамический номер порта в качестве локального порта.

Сервер должен отправить клиенту подтверждение (ACK) вместе с порядковым номером (SYN) сервера. В свою очередь клиент отвечает АСК, и соединение устанавливается.

После этого может начаться процесс отправки и получения сообщений. При получении сообщения в ответ всегда отправляется сообщение АСК. Если до получения АСК отправителем истекает тайм-аут, сообщение помещается в очередь на повторную передачу.

Поля заголовка TCP перечислены в следующей таблице:

Заголовок TCP

Поле	Длина	Описание
Порт источника	2 байта	Номер порта источника
Порт назначения	2 байта	Номер порта назначения
Последовательный номер	4 байта	Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
Номер подтверждения	4 байта	Если установлен бит АСК поля "Управление", в данном поле содержится следующий ожидаемый последовательный номер.
Смещение данных	4 бита	Информация о начале пакета данных.
Резерв	6 битов	Резервируются для будущего использования.
Управление	6 битов	Биты управления содержат флаги, указывающие, верны ли поля подтверждения (АСК), указателя срочности (URG), следует ли сбрасывать соединение (RST), послан ли синхронизирующий последовательный номер (SYN) и т. д.
Размер окна	2 байта	В этом поле указывается размер приемного буфера. Используя подтверждающие сообщения, получатель может информировать отправителя о максимальном размере данных, которые тот может отправить.
Контрольная сумма	2 байта	Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
Указатель срочности	2 байта	В этом поле целевое устройство получает информацию о срочности данных.
Опции	переменная	Необязательные значения, которые указываются при необходимости.
Дополнение	переменная	В поле дополнения добавляется столько нулей, чтобы заголовок заканчивался на 32-битной границе.

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

Протокол TCP имеет встроенную возможность надежной доставки. Если сообщение не отправлено корректно, мы получим сообщение об ошибке. Протокол TCP определен в RFC 793.

UDP - User Datagram Protocol

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

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

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

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

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

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

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

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

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

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

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

Для расчета контрольной суммы псевдозаголовок и UDP-сообщение разбивается на слова (1 слово = 2 байта (октета) = 16 бит). Затем рассчитывается поразрядное дополнение до единицы суммы всех слов с поразрядным дополнением. Результат записывается в соответствующее поле в UDP-заголовке.

Нулевое значение контрольной суммы зарезервировано, и означает что датаграмма не имеет контрольной суммы. В случае, если вычисленная контрольная сумма получилась равной нулю, поле заполняют двоичнымим единицами.

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

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

Для примера рассчитаем контрольную сумму нескольких 16-битных слов: 0x398a, 0xf802, 0x14b2, 0xc281 . Находим их сумму с поразрядным дополнением.
0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
Теперь находим поразрядное дополнение до единицы полученного результата:

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e или, иначе - 0xffff − 0x08c1 = 0xf73e . Это и есть искомая контрольная сумма.

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

Биты	0 – 7	16 – 23	24 – 31
0	Адрес источника
32
64
96
128	Адрес получателя
160
192
224
256	Длина UDP
288	Нули		Следующий заголовок
320	Порт источника	Порт получателя
352	Длина	Контрольная сумма
384+	Данные

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

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

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

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

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

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

Приложения

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

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

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

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

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

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

Тяжеловесность - TCP необходимо три пакета для установки сокет-соединения перед тем, как отправить данные. TCP следит за надежностью и перегрузками.

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

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

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

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

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

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

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

Ссылки на RFC

RFC 768 – Протокол Пользовательских Датаграмм
RFC 2460 – Интернет протокол, спецификация версии 6 (IPv6)
RFC 2675 - IPv6 Jumbograms
RFC 4113 – Management Information Base for the UDP
RFC 5405 – Unicast UDP Usage Guidelines for Application Designers

См. также

Ссылки

Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3 .
Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
[email protected]. "UDP Protocol Overview". Ipv6.com. Retrieved 17 August 2011.
Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
Postel, J. (August 1980). RFC 768 : User Datagram Protocol. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc768
Deering S. & Hinden R. (December 1998). RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc2460
"The impact of UDP on Data Applications". Networkperformancedaily.com. Retrieved 17 August 2011.
Д. Комер. Межсетевой обмен с помощью TCP/IP. Глава 11. Протокол UDP.