RFC 768¶

RFC 768 — это документ, опубликованный в 1980 году в серии «Request for Comments», определяющий протокол UDP (User Datagram Protocol) — один из основных транспортных протоколов стека TCP/IP. Данный протокол обеспечивает простую и ненадёжную доставку дейтаграмм между приложениями в компьютерных сетях, работающих поверх IP.

¶История

Протокол UDP был разработан Дэвидом П. Ридом (David P. Reed) в 1980 году как часть проекта ARPANET — предшественника современного Интернета. В то время потребность в протоколах передачи данных росла по мере развития сетевых технологий. TCP, разработанный ранее (RFC 793), предлагал надёжную передачу с установлением соединения, но для некоторых приложений, таких как потоковое аудио или DNS-запросы, издержки TCP (установка соединения, подтверждения, повторные передачи) были избыточны. RFC 768 ввёл лёгкий альтернативный протокол без установления соединения, ориентированный на скорость и минимальный накладной расход.

Документ был зарегистрирован как STD 6 в системе стандартов IETF (Internet Engineering Task Force) и остаётся действующим стандартом по сей день.

¶Характеристики протокола

¶Основные принципы

• Без установления соединения (connectionless): перед отправкой данных не требуется рукопожатие; отправитель просто посылает дейтаграмму на указанные IP-адрес и порт получателя.
• Ненадёжность (unreliable): UDP не гарантирует доставку дейтаграмм, их порядок или отсутствие дубликатов. Проверка целостности выполняется только опционально через контрольную сумму.
• Ориентация на дейтаграммы (datagram-oriented): каждое сообщение обрабатывается как отдельный пакет с сохранением границ — не поддерживается сегментация и сборка потока (в отличие от TCP).

¶Заголовок UDP

Заголовок UDP состоит из 4 полей по 2 байта каждое (всего 8 байт):

1. Порт источника (Source Port) — (необязательно) порт отправителя; если не используется, заполняется нулями.
2. Порт назначения (Destination Port) — порт получателя, обязательное поле.
3. Длина (Length) — длина всей дейтаграммы (заголовок + данные) в байтах. Минимальное значение — 8 (пустой заголовок).
4. Контрольная сумма (Checksum) — опциональный код для проверки целостности заголовка и данных. Расчёт применяется к псевдозаголовку IP (включая IP-адреса) и полному UDP-пакету. В IPv4 это поле может быть нулевым, если проверка не выполняется; в IPv6 (RFC 2460) контрольная сумма обязательна.

Поле данных может иметь длину от 0 до 65 507 байт (максимальный IP-пакет 65 535 минус 20 байт IP-заголовка минус 8 байт UDP-заголовка). Однако в реальности ограничения MTU (Maximum Transmission Unit) часто уменьшают этот размер.

¶Применение

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

¶Службы, построенные поверх UDP

• DNS (Domain Name System) — большинство запросов и ответов (кроме зонных трансферов) используют порт 53 UDP из-за малого размера сообщений и требования быстрого ответа.
• DHCP (Dynamic Host Configuration Protocol) — протокол получения IP-адреса и настроек (порты 67/68) работает поверх UDP.
• NTP (Network Time Protocol) — синхронизация времени через порт 123 использует UDP для минимальной задержки.
• TFTP (Trivial File Transfer Protocol) — упрощённая передача файлов без аутентификации (порт 69), базирующаяся на UDP.
• RTP (Real-time Transport Protocol) — передача аудио- и видеопотоков в реальном времени (например, VoIP, видео-конференции) — обычно работает поверх UDP.

¶Мультимедиа и игры

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

¶IoT и сенсорные сети

Протокол CoAP (Constrained Application Protocol) поверх UDP используется в устройствах с ограниченными ресурсами (интернет вещей).

¶Сравнение с TCP

UDP не имеет встроенных механизмов контроля перегрузок, что в некоторых сценариях может приводить к несправедливому использованию полосы пропускания по сравнению с TCP. Для решения этой проблемы в современных системах применяются адаптивные алгоритмы на уровне приложений или специализированные протоколы (например, QUIC поверх UDP, который добавляет надёжность и контроль перегрузок).

¶Критика и ограничения

Несмотря на свою эффективность, UDP страдает от ряда уязвимостей:

• Отсутствие аутентификации: злоумышленник может подделать адрес источника (IP-спуфинг), что чревато атаками типа amplification (усиление) с использованием открытых DNS- или NTP-серверов.
• Нет защиты от дублирования пакетов: приложение должно самостоятельно обрабатывать возможные повторения.
• Ограниченная контрольная сумма: в IPv4 она не является обязательной, а её отключение делает пакеты уязвимыми к повреждениям.

¶Интересные факты

• RFC 768 — один из самых коротких документов в серии (всего 3 страницы), что отражает простоту протокола.
• UDP используется как основа для протокола QUIC (RFC 9000), разработанного Google и стандартизированного IETF для уменьшения задержек в HTTP/3.
• Стандартный порт для UDP может быть назначен IANA; многие популярные приложения (например, BitTorrent, OpenVPN) используют динамические порты.

¶См. также

• RFC 793 (TCP)
• RFC 2460 (IPv6)
• RFC 768 (оригинальный текст)
• Протокол QUIC

¶Источники

• RFC 768 — User Datagram Protocol. J. Postel. ISI. 28 августа 1980.
• Stevens, W. Richard. «TCP/IP Illustrated, Volume 1: The Protocols». Addison-Wesley, 1994.
• Comer, Douglas E. «Internetworking with TCP/IP: Principles, Protocols, and Architecture». Prentice Hall, 2006.
• IANA — Service Name and Transport Protocol Port Number Registry.