4.4.2 Протокол UDP
Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)
В RFC-768 говорится, что поле «Порт отправителя» является опционным, что вроде бы, позволяет его не заполнять. Действительно, если UDP-дейтограммы используются для передачи цифровой ТВ-программы через Интернет, номер порта отправителя получателю знать не обязательно. Но за 40 лет, прошедших с написания RFC-769 перечень приложений, использующих протокол UDP существенно расширился. Например, для многопользовательских видеоконференций стало важно, в какое из открытых окон следует адресовать содержимое UDP-дейтограммы, а это может зависеть от номера порта отправителя.
Область использования UDP
| Хотя протокол UDP не гарантирует доставки, по умолчанию предполагается, что вероятность потери пакета достаточно мала. |
Прикладные процессы и модули UDP взаимодействуют через UDP-порты. Эти порты нумеруются, начиная с нуля. Прикладной процесс, предоставляющий некоторые услуги (сервер), ожидает сообщений, направленных в порт, специально выделенный для этих услуг. Программа-сервер ждет, когда какая-нибудь программа-клиент запросит услугу.
Например, сервер SNMP всегда ожидает сообщения, адресованного в порт 161. Если клиент snmp желает получить услугу, он посылает запрос в UDP-порт 161 на машину, где работает сервер. На каждой машине может быть только один агент SNMP, т.к. существует только один порт 161. Данный номер порта является общеизвестным, т.е. фиксированным номером, официально выделенным в сети Internet для услуг SNMP. Общеизвестные номера портов определяются стандартами Internet (см. табл. 4.4.2.1).
Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс-отправитель производит 5 записей в порт, то процесс-получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно и не делит одно сообщение на части. Формат UDP-сообщений представлен ниже на рис. 4.4.2.1:
Формат UDP-дейтограмм
Рис. 4.4.2.1 Формат UDP-дейтограмм
Таблица 4.4.2.1 Номера UDP-портов (более полный перечень в RFC-1700; Если какой-то номер порта в перечне отсутствует, это не означает, что он не зарезервирован и его можно использовать, просто я сэкономил место). См. IANA, а также Приложения.
Стандартные номера портов UDP
| Десятич. номер порта | Обозначение порта | Описание | |
| в Интернет | в Unix | ||
| 0 | — | — | Зарезервировано |
| 1 | TCPmux | — | TCP Мультиплексор |
| 2 | Compressnet | — | Программа управления |
| 3 | Compressnet | — | Процесс сжатия |
| 5 | RJE | — | Вход в удаленную задачу |
| 7 | Echo | echo | Эхо |
| 9 | Discard | discard | Сброс |
| 11 | Users | systat | Активные пользователи |
| 13 | Daytime | daytime | Время дня |
| 15 | — | Netstat | Кто работает или netstat |
| 19 | Chargen | chargen | Генератор символов |
| 20 | FTP-data | ftp-data | FTP (данные) |
| 21 | FTP | ftp | Протокол пересылки файлов (управление) |
| 23 | telnet | telnet | Подключение терминала |
| 24 | — | — | Любая частная почтовая система |
| 25 | SMTP | SMTP | Протокол передачи почтовых сообщений |
| 31 | MSG-auth | Распознавание сообщения (аутентификация) | |
| 35 | — | — | Любой частный принт-сервер |
| 37 | Time | time | Время |
| 39 | RLP | — | Протокол поиска ресурсов |
| 41 | Graphics | Графика | |
| 42 | nameserver | name | Сервер имен |
| 43 | Nicname | whois | Кто это? (whois-сервис) |
| 45 | MPM | — | Блок обработки входных сообщений |
| 46 | MPM-snd | — | Блок обработки выходных сообщений |
| 48 | Auditd | — | Демон цифрового аудита |
| 49 | login | — | Протокол входа в ЭВМ |
| 50 | RE-mail-ck | — | Протокол удаленного контроля почтовым обменом |
| 53 | Domain | nameserver | Сервер имен доменов (dns) |
| 57 | — | — | Любой частный терминальный доступ |
| 59 | — | — | Любой частный файл-сервер |
| 64 | covia | — | Коммуникационный интегратор (ci) |
| 66 | SQL*net | — | Oracle SQL*net |
| 67 | Bootps | Bootps | Протокол загрузки сервера |
| 68 | Bootpc | bootpc | Протокол загрузки клиента |
| 69 | TFTP | tftp | Упрощенная пересылка файлов |
| 70 | Gopher | — | Gopher (поисковая система) |
| 71 | — | Netrjs-1 | Сервис удаленных услуг |
| 77 | — | rje | Любой частный RJE-сервис |
| 79 | Finger | finger | finger |
| 80 | WWW-HTTP | World Wide Web HTTP | |
| 81 | Hosts2-NS | — | Сервер имен 2 |
| 87 | — | — | Любая частная терминальная связь |
| 88 | Kerberos | Kerberos | |
| 92 | NPP | — | Протокол сетевой печати |
| 93 | DCP | — | Протокол управления приборами |
| 95 | Supdup | supdup | Supdup протокол |
| 97 | Swift-rvf | — | swift-протокол удаленных виртуальных файлов |
| 101 | Hostname | hostnames | Сервер имен ЭВМ для сетевого информационного центра |
| 102 | ISO-Tsap | iso-tsap | ISO-Tsap |
| 103 | GPPitnp | Сети точка-точка | |
| 104 | ACR-nema | ACR-nema digital IMAG. & comm. 300 | |
| 108 | Snagas | sna-сервер доступа | |
| 109 | POP2 | — | Почтовый протокол pop2 |
| 110 | POP3 | — | Почтовый протокол POP3 |
| 111 | SUNRPC | sunrpc | SUN microsystem RPC |
| 113 | Auth | auth | Служба распознавания |
| 114 | Audionews | Аудио-новости | |
| 115 | SFTP | Простой протокол передачи файлов | |
| 117 | UUCP-path | uucp-path | Служба паролей UUCP |
| 118 | SQLserv | SQL-сервер | |
| 119 | NNTP | NNTP | Протокол передачи новостей |
| 123 | NTP | NTP | Сетевой протокол синхронизации |
| 129 | PWDgen | Протокол генерации паролей | |
| 130-132 | Cisco | ||
| 133 | Statsrv | Сервер статистики | |
| 134 | Ingres-net | Ingres-net-сервис | |
| 135 | LOC-srv | Поисковый сервис | |
| 137 | Netbios-SSN | — | Служба имен Netbios |
| 138 | Netbios-DGM | Служба дейтограмм netbios | |
| 139 | Netbios-SSN | Служба сессий Netbios | |
| 147 | ISO-IP | ISO-IP | |
| 150 | SQL-net | SQL net | |
| 152 | BFTP | Протокол фоновой пересылки файлов | |
| 156 | SQLsrv | SQL-сервер | |
| 158 | PCmail-srv | PC почтовый сервер | |
| 161 | — | SNMP | Сетевой монитор SNMP |
| 162 | — | SNMP-trap | SNMP-ловушки |
| 170 | Print-srv | postscript сетевой сервер печати | |
| 179 | BGP | Динамический протокол внешней маршрутизации | |
| 191 | Prospero | Служба каталогов Prospero | |
| 194 | IRC | Протокол Интернет для удаленных переговоров | |
| 201-206 | Протоколы сетей Apple talk | ||
| 213 | IPX | ipx | |
| 348 | CSI-SGWP | Протокол управления cabletron | |
| 396 | Netware-IP | Novell-Netware через IP | |
| 398 | Kryptolan | Kryptolan | |
| 414 | Infoseek | Infoseek (информационный поиск) | |
| 418 | Hyper-g | Hyper-g | |
| 444 | SNPP | Простой протокол работы со страницами | |
| 512 | — | biff (exec) | Unix Comsat (удаленное исполнение) |
| 513 | — | Who | Unix Rwho daemon |
| 514 | — | syslog | Дневник системы |
| 515 | Printer | Работа с буфером печати (spooler) | |
| 525 | — | Timed | Драйвер времени |
Зарегистрировано ряд портов для стандартного применения и в диапазоне 1024-65535. Например:
| Номер порта | Обозначение | Назначение |
| 1397 | Аudio-activmail | Активная звуковая почта |
| 1398 | Video-activmail | Активная видео-почта |
| 5002 | RFE | Радио-Ethernet |
| 6000-6063 | X11 | Система X Window |
| 7008 | AFS3-update | Сервер-сервер актуализация |
Схема вычисления контрольных сумм
Модуль IP передает поступающий IP-пакет модулю UDP, если в заголовке этого пакета указан код протокола UDP. Когда модуль UDP получает дейтограмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, это означает, что отправитель ее не подсчитал. ICMP, IGMP, UDP и TCP протоколы имеют один и тот же алгоритм вычисления контрольной суммы (RFC-1071). Но вычисление контрольной суммы для UDP имеет некоторые особенности. Во-первых, длина UDP-дейтограммы может содержать нечетное число байт, в этом случае к ней добавляется нулевой байт, который служит лишь для унификации алгоритма и никуда не пересылается. Во-вторых, при расчете контрольной суммы для UDP и TCP добавляются 12-байтные псевдо-заголовки, содержащие IP-адреса отправителя и получателя, код протокола и длину дейтограммы (см. рис. 4.4.2.2). Как и в случае IP-дейтограммы, если вычисленная контрольная сумма равна нулю, в соответствующее поле будет записан код 65535.
Рис. 4.4.2.2. Псевдозаголовок, используемый при расчете контрольной суммы
Если контрольная сумма правильная (или равна 0), то проверяется порт назначения, указанный в заголовке дейтограммы. Если прикладной процесс подключен к этому порту, то прикладное сообщение, содержащиеся в дейтограмме, становится в очередь к прикладному процессу для прочтения. В остальных случаях дейтограмма отбрасывается. Если дейтограммы поступают быстрее, чем их успевает обрабатывать прикладной процесс, то при переполнении очереди сообщений поступающие дейтограммы отбрасываются модулем UDP. Следует учитывать, что во многих посылках контрольное суммирование не охватывает адреса отправителя и места назначения. При некоторых схемах маршрутизации это приводит к зацикливанию пакетов в случае повреждения его адресной части (адресат не признает его «своим»).
Может возникнуть вопрос, зачем вычислять и проверять контрольную сумму, если подтверждение доставки и повторная пересылка в рамках протокола не предусмотрены. Дело в том, что UDP используется не только для мультимедийных задач но и некоторыми другими протоколами (DNS, SNMP и др.), где повторные запросы и отклики могут выполняться на прикладном уровне.
Так как максимальная длина IP-дейтограммы равна 65535 байтам, максимальная протяженность информационного поля UDP-дейтограммы составляет 65507 байт. На практике большинство систем работает с UDP-дейтограммами с длиной 8192 байта или менее (Ethernet допускает 1508 байт). Детальное описание форматов, полей пакетов и пр. читатель может найти в RFC-768. Смотри также RFC-2147 (IPv6 Jumbo), RFC-2508 (компрессия заголовков) и RFC-3828 (Lightweight UDP).
Нашел применение UDP и в протоколе Teredo (туннелирование IPv6 для систем NAT).
Udp port что это
User Datagram Protocol
TCP/IP (иногда называют UDP/IP)
Ядра Windows, Linux, UNIX
Ядра Windows, Linux, UNIX
UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — один из ключевых элементов Internet Protocol Suite (более известного как TCP/IP), набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (в данном случае называемые датаграммами) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных. Протокол был разработан Дэвидом П. Ридом в 1980 году и официально определен в RFC 768.
UDP использует простую модель передачи, без неявных «рукопожатий» для обеспечения надежности, упорядочивания или целостности данных. Таким образом, UDP предоставляет ненадежный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не необходимы, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. При необходимости исправления ошибок на сетевом уровне интерфейса приложение может задействовать TCP или SCTP, разработанные для этой цели.
Природа UDP как протокола без сохранения состояния также полезна для серверов, отвечающих на небольшие запросы от огромного числа клиентов, например DNS и потоковые мультимедийные приложения вроде IPTV, Voice over IP, протоколы туннелирования IP и многие онлайн-игры.
Содержание
Служебные порты
IANA разбила номера портов на три группы.
Структура пакета
UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надежная передача в случае необходимости должна реализовываться пользовательским приложением.
Заголовок UDP состоит из четырех полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.
В этом поле указывается номер порта отправителя. Предполагается, что это значение задает порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, эфемерным. Если источником является сервер, то его порт будет одним из «хорошо известных».
Поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями. Поле не является обязательным для IPv4.
Расчёт контрольной суммы
Метод для вычисления контрольной суммы определен в RFC 768.
Перед расчетом контрольной суммы UDP-сообщение дополняется в конце нулевыми битами до длины, кратной 16 битам (псевдозаголовок и добавочные нулевые биты не отправляются вместе с сообщением). Поле контрольной суммы в UDP-заголовке во время расчета контрольной суммы отправляемого сообщения принимается нулевым.
Для расчета контрольной суммы псевдозаголовок и UDP-сообщение разбивается на слова (1 слово = 2 байта (октета) = 16 бит). Затем рассчитывается поразрядное дополнение до единицы суммы всех слов с поразрядным дополнением. Результат записывается в соответствующее поле в UDP-заголовке.
Нулевое значение контрольной суммы зарезервировано, и означает что датаграмма не имеет контрольной суммы. В случае, если вычисленная контрольная сумма получилась равной нулю, поле заполняют двоичнымим единицами.
При получении сообщения получатель считает контрольную сумму заново (уже учитывая поле контрольной суммы), и, если в результате получится двоичное число из шестнадцати единиц (то есть 0xffff ), то контрольная сумма считается сошедшейся. Если сумма не сходится (данные были повреждены при передаче), датаграмма уничтожается.
Пример расчёта контрольной суммы
Различие между IPv4 и IPv6 в данных, используемых для вычисления контрольной суммы.
Псевдозаголовки
Псевдозаголовок для IPv4
Если UDP работает над IPv4, контрольная сумма вычисляется при помощи псевдозаголовка, который содержит некоторую информацию из заголовка IPv4. Псевдозаголовок не является настоящим IPv4-заголовком, используемым для отправления IP-пакета. В таблице приведен псевдозаголовок, используемый только для вычисления контрольной суммы.
| Биты | 0 – 7 | 8 – 15 | 16 – 23 | 24 – 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Адрес источника | |||||||||||||||||||||||||||||||
| 32 | Адрес получателя | |||||||||||||||||||||||||||||||
| 64 | Нули | Протокол | Длина UDP | |||||||||||||||||||||||||||||
| 96 | Порт источника | Порт получателя | ||||||||||||||||||||||||||||||
| 128 | Длина | Контрольная сумма | ||||||||||||||||||||||||||||||
| 160+ | Данные | |||||||||||||||||||||||||||||||
Адреса источника и получателя берутся из IPv4-заголовка. Значения поля «Протокол» для UDP равно 17 (0x11). Поле «Длина UDP» соответствует длине заголовка и данных.
Вычисление контрольной суммы для IPv4 необязательно, если она не используется, то значение равно 0.
Псевдозаголовок для IPv6
При работе UDP над IPv6 контрольная сумма обязательна. Метод для ее вычисления был опубликован в RFC 2460:
При вычислении контрольной суммы опять используется псевдозаголовок, имитирующий реальный IPv6-заголовок:
| Биты | 0 – 7 | 8 – 15 | 16 – 23 | 24 – 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Адрес источника | |||||||||||||||||||||||||||||||
| 32 | ||||||||||||||||||||||||||||||||
| 64 | ||||||||||||||||||||||||||||||||
| 96 | ||||||||||||||||||||||||||||||||
| 128 | Адрес получателя | |||||||||||||||||||||||||||||||
| 160 | ||||||||||||||||||||||||||||||||
| 192 | ||||||||||||||||||||||||||||||||
| 224 | ||||||||||||||||||||||||||||||||
| 256 | Длина UDP | |||||||||||||||||||||||||||||||
| 288 | Нули | Следующий заголовок | ||||||||||||||||||||||||||||||
| 320 | Порт источника | Порт получателя | ||||||||||||||||||||||||||||||
| 352 | Длина | Контрольная сумма | ||||||||||||||||||||||||||||||
| 384+ | Данные | |||||||||||||||||||||||||||||||
Надежность и решения проблемы перегрузок
Из-за недостатка надежности, приложения UDP должны быть готовыми к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надежности на прикладном уровне.
Более серьезной потенциальной проблемой является то, что в отличие от TCP, основанные на UDP приложения не обязательно имеют хорошие механизмы контроля и избежания перегрузок. Чувствительные к перегрузкам UDP-приложения, которые потребляют значительную часть доступной пропускной способности, могут поставить под угрозу стабильность в Интернете.
Приложения
Голосовой и видеотрафик обычно передается с помощью UDP. Протоколы потокового видео в реальном времени и аудио разработаны для обработки случайных потерь пакетов так, что качество лишь незначительно уменьшается вместо больших задержек при повторной передаче потерянных пакетов. Поскольку и TCP, и UDP работают с одной и той же сетью, многие компании замечают, что недавнее увеличение UDP-трафика из-за этих приложений реального времени мешает производительности TCP-приложений вроде систем баз данных или бухгалтерского учета. Так как и бизнес-приложения, и приложения в реальном времени важны для компаний, развитие качества решений проблемы некоторыми рассматривается в качестве важнейшего приоритета.
Сравнение UDP и TCP
Протокол UDP
— это простой, ориентированный на дейтаграммы протокол без организации соединения, предоставляющий быстрое, но необязательно надежное транспортное обслуживание. Он поддерживает взаимодействия «один со многими» и поэтому часто применяется для широковещательной и групповой передачи дейтаграмм.
Internet Protocol (IP) является основным протоколом Интернета. Transmission Control Protocol (TCP) и UDP — это протоколы транспортного уровня, построенные поверх лежащего в основе протокола.
TCP/IP — это набор протоколов, называемый также «пакетом протоколов Интернета» (Internet Protocol Suite), состоящий из четырех уровней. Запомните, что TCP/IP не просто один протокол, а семейство или набор протоколов, который состоит из других низкоуровневых протоколов, таких, как IP, TCP и UDP. UDP располагается на транспортном уровне поверх IP (протокола сетевого уровня). Транспортный уровень обеспечивает взаимодействие между сетями через шлюзы. В нем используются IP-адреса для отправки пакетов данных через Интернет или другую сеть с помощью разнообразных драйверов устройств.
Прежде чем приступать к изучению работы UDP, обратимся к основной терминологии, которую нужно хорошо знать. Ниже вкратце определим основные термины, связанные с UDP:
Пакеты
В передаче данных пакетом называется последовательность двоичных цифр, представляющих данные и управляющие сигналы, которые передаются и коммутируются через хост. Внутри пакета эта информация расположена в соответствии со специальным форматом.
Дейтаграммы
Дейтаграмма — это отдельный, независимый пакет данных, несущий информацию, достаточную для передачи от источника до пункта назначения, поэтому никакого дополнительного обмена между источником, адресатом и транспортной сетью не требуется.
MTU (Maximum Transmission Unit)
MTU характеризует канальный уровень и соответствует максимальному числу байтов, которое можно передать в одном пакете. Другими словами MTU — это самый большой пакет, который может переносить данная сетевая среда. Например, Ethernet имеет фиксированный MTU, равный 1500 байтам. В UDP, если размер дейтаграммы больше MTU, протокол IP выполняет фрагментацию, разбивая дейтаграмму на более мелкие части (фрагменты) так, чтобы каждый фрагмент был меньше MTU.
Порты
Чтобы поставить в соответствие входящим данным конкретный процесс, выполняемый в компьютере, UDP использует порты. UDP направляет пакет в соответствующее место, используя номер порта, указанный в UDP-заголовке дейтаграммы. Порты представлены 16-битными номерами и, следовательно, принимает значения в диапазоне от 0 до 65 535. Порты, которые также называют конечными точками логических соединений, разделены на три категории:
Регистрируемые порты — от 1024 до 49151
Динамические / частные порты — от 49152 до 65535
Заметим, что порты UDP могут получать более одного сообщения в каждый промежуток времени. В некоторых случаях сервисы TCP и UDP могут использовать одни и те же номера портов, например 7 (Echo) или 23 (Telnet).
UDP использует следующие известные порты:
Перечень портов UDP и TCP поддерживается агентством IANA (Internet Assigned Numbers Authority).
IP-адреса
Дейтаграмма IP состоит из 32-битных IP-адресов источника и назначения. IP-адрес назначения задает конечную точку для дейтаграммы UDP, а IP-адрес источника используется для получения информации о том, кто отправил сообщение. В пункте назначения пакеты фильтруются, и те из них, адреса источников которых не входят в допустимый набор адресов, отбрасываются без уведомления отправителя.
Однонаправленный IP-адрес уникально определяет хост в сети, тогда как групповой IP-адрес определяет конкретную группу адресов в сети. Широковещательные IP-адреса получаются и обрабатываются всеми хостами локальной сети или конкретной подсети.
Значение времени жизни, или TTL (time-to-live), позволяет установить верхний предел числа маршрутизаторов, через которые может пройти дейтаграмма. Значение TTL не дает пакетам попасть в бесконечные циклы. Оно инициализируется отправителем и уменьшается на единицу каждым маршрутизатором, обрабатывающим дейтаграмму. Когда значение TTL становится нулевым, дейтаграмма отбрасывается.
Групповая рассылка
Групповая рассылка — это открытый, базирующийся на стандартах, метод одновременного распространения идентичной информации нескольким пользователям. Групповая рассылка является основным средством протокола UDP, она невозможна для протокола TCP. Групповая рассылка позволяет добиться взаимодействия одного со многими, например, делает возможными такие использования, как рассылка новостей и почты нескольким получателям, интернет-радио или демонстрационные программы реального времени. Групповая рассылка не так сильно нагружает сеть, как широковещательная передача, поскольку данные отправляются сразу нескольким пользователям:
Принцип работы UDP
Когда приложение, базирующееся на UDP, отправляет данные другому хосту в сети, UDP дополняет их восьмибитным заголовком, содержащим номера портов адресата и отправителя, общую длину данных и контрольную сумму. Поверх дейтаграммы UDP свой заголовок добавляет IP, формируя дейтаграмму IP:
На предыдущем рисунке указано, что общая длина заголовка UDP составляет восемь байтов. Теоретически максимальный размер дейтаграммы IP равен 65 535 байтам. С учетом 20 байтов заголовка IP и 8 байтов заголовка UDP длина данных пользователя может достигать 65 507 байтов. Однако большинство программ работают с данными меньшего размера. Так, для большинства приложений по умолчанию установлена длина приблизительно 8192 байта, поскольку именно такой объем данных считывается и записывается сетевой файловой системой (NFS). Можно устанавливать размеры входного и выходного буферов.
Контрольная сумма нужна, чтобы проверить были ли данные доставлены в пункт назначения правильно или были искажены. Она охватывает как заголовок UDP, так и данные. Байт-заполнитель используется, если общее число октетов дейтаграммы нечетно. Если полученная контрольная сумма равна нулю, получатель фиксирует ошибку контрольной суммы и отбрасывает дейтаграмму. Хотя контрольная сумма является необязательным средством, ее всегда рекомендуется включать.
На следующем шаге уровень IP добавляет 20 байтов заголовка, включающего TTL, IP-адреса источника и получателя и другую информацию. Это действие называют IP-инкапсуляцией.
Как упоминалось ранее, максимальный размер пакета равен 65 507 байтам. Если пакет превышает установленный по умолчанию размер MTU, то уровень IP разбивает пакет на сегменты. Эти сегменты называются фрагментами, а процесс разбиения данных на сегменты — фрагментацией. Заголовок IP содержит всю информацию о фрагментах.
Когда приложение-отправитель «выбрасывает» дейтаграмму в сеть, она направляется по IP-адресу назначения, указанному в заголовке IP. При проходе через маршрутизатор значение времени жизни (TTL) в заголовке IP уменьшается на единицу.
Когда дейтаграмма прибывает к заданному назначению и порту, уровень IP по своему заголовку проверяет, фрагментирована ли дейтаграмма. Если это так, дейтаграмма собирается в соответствии с информацией, имеющейся в заголовке. Наконец прикладной уровень извлекает отфильтрованные данные, удаляя заголовок.
Недостатки UDP
По сравнению с TCP UDP имеет следующие недостатки:
Отсутствие сигналов квитирования. Перед отправкой пакета UDP, отправляющая сторона не обменивается с получающей стороной квитирующими сигналами. Следовательно, у отправителя нет способа узнать, достигла ли дейтаграмма конечной системы. В результате UDP не может гарантировать, что данные будут действительно доставлены адресату (например, если не работает конечная система или сеть).
Напротив, протокол TCP ориентирован на установление соединений и обеспечивает взаимодействие между подключенными к сети хостами, используя пакеты. В TCP применяются сигналы квитирования, позволяющие проверить успешность транспортировки данных.
Использование сессий. Ориентированность TCP на соединения поддерживается сеансами между хостами. TCP использует идентификатор сеанса, позволяющий отслеживать соединения между двумя хостами. UDP не имеет поддержки сеансов из-за своей природы, не ориентированной на соединения.
Надежность. UDP не гарантирует, что адресату будет доставлена только одна копия данных. Чтобы отправить конечной системе большой объем данных, UDP разбивает его на небольшие части. UDP не гарантирует, что эти части будут доставлены по назначению в том же порядке, в каком они создавались в источнике. Напротив, TCP вместе с номерами портов использует порядковые номера и регулярно отправляемые подтверждения, гарантирующие упорядоченную доставку данных.
Безопасность. TCP более защищен, чем UDP. Во многих организациях брандмауэры и маршрутизаторы не пропускают пакеты UDP. Это связано с тем, что хакеры могут воспользоваться портами UDP, не устанавливая явных соединений.
Управление потоком. В UDP управление потоком отсутствует, в результате плохо спроектированное UDP-приложение может захватить значительную часть пропускной способности сети.
Преимущества UDP
По сравнению с TCP UDP имеет следующие преимущества:
Нет установки соединения. UDP является протоколом без организации соединений, поэтому он освобождает от накладных расходов, связанных с установкой соединений. Поскольку UDP не пользуется сигналами квитирования, то задержек, вызванных установкой соединений, также удается избежать. Именно поэтому DNS отдает предпочтение UDP перед TCP — DNS работала бы гораздо медленнее, если бы она выполнялась через TCP.
Скорость. UDP работает быстрее TCP. По этой причине многие приложения предпочитают не TCP, a UDP. Те же средства, которые делают TCP более устойчивым (например сигналы квитирования), замедляют его работу.
Топологическое разнообразие. UDP поддерживает взаимодействия «один с одним» и «один с многими», в то время как TCP поддерживает лишь взаимодействие «один с одним».
Накладные расходы. Работа с TCP означает повышенные накладные расходы, издержки, налагаемые UDP, существенно ниже. TCP по сравнению с UDP использует значительно больше ресурсов операционной системы, и, как следствие, в таких средах, где серверы одновременно обслуживают многих клиентов, широко используют UDP.
Размер заголовка. Для каждого пакета заголовок UDP имеет длину всего лишь восемь байтов, в то время как TCP имеет 20-байтовые заголовки, и поэтому UDP потребляет меньше пропускной способности сети.