System Design Space
Граф знанийНастройки

Обновлено: 24 марта 2026 г. в 11:23

UDP протокол

medium

Лёгкий протокол без соединения: низкая задержка, минимум накладных расходов и скорость.

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

В реальной работе это помогает проектировать realtime, telemetry и media-сценарии, где важны задержка и простота, а подтверждения, порядок доставки и recovery нужно собирать самостоятельно.

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

Практическая польза главы

Latency-first подход

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

App-level reliability

Учит проектировать подтверждения, reorder handling и recovery на уровне приложения.

Сценарии применения

Показывает границы применимости для realtime, streaming и telemetry потоков.

Interview trade-offs

Дает ясный ответ, почему и как компенсировать слабые гарантии UDP в архитектуре сервиса.

RFC

RFC 768 (UDP)

Базовая спецификация UDP: формат заголовка, семантика доставки и checksum.

Перейти на сайт

UDP - транспортный протокол с минимальными накладными расходами. Он не гарантирует доставку, порядок и повторную передачу, поэтому ключевая логика устойчивости переносится на уровень приложения.

Особенности UDP

Connectionless transport

UDP не делает handshake перед передачей: датаграмма отправляется сразу.

Best-effort доставка

Протокол не гарантирует доставку, порядок и повторную передачу потерянных пакетов.

Минимальный overhead

Заголовок UDP компактный: меньше накладных расходов на транспортный уровень.

Границы сообщений

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

Надёжность на уровне приложения

Если нужны retries, reorder-buffering, FEC или rate adaptation, это реализуется выше transport-слоя.

Визуализация содержимого UDP датаграммы

Компактный заголовок UDP делает протокол быстрым, но не включает встроенные механизмы надёжности.

UDP Datagram Header

8 bytes + payload

Source Port

16 bits

Destination Port

16 bits

Length

16 bits

Checksum

16 bits

Payload (variable length)

32 bits

UDP header фиксированный (8 байт), поэтому протокол быстро обрабатывается и часто используется для latency-sensitive трафика.

Жизненный цикл UDP обмена

Формирование датаграммы

Приложение формирует сообщение и передаёт его UDP-сокету вместе с destination IP:port.

Передача через IP сеть

Датаграмма маршрутизируется best-effort: может потеряться, прийти позже или не по порядку.

Обработка на стороне получателя

Приложение само решает, что делать с loss/jitter/reorder: буферизация, FEC, дроп устаревших сообщений.

Как происходит обмен в UDP

В UDP нет установления соединения: каждое сообщение - отдельная датаграмма, которая отправляется в сеть сразу и может дойти, потеряться или прийти не в порядке.

Как работает обмен в UDP

UDP отправляет датаграммы без установки соединения и подтверждений.

ОтправительСетьПолучатели
Клиент
UDP datagram
Service A
Service B
Service C
Нет handshake и подтверждений — отправка происходит сразу.

Динамика UDP под реальной нагрузкой

Пошагово смотрите, как потери, jitter и reorder меняют качество доставки в UDP.

ШагИнтервал 1 (1 из 7)
Полезная доставка (%)Потери (%)Jitter (ms)

Фаза

Стабильный линк

Полезная доставка

99.7%

Скорость отправки

180 kpps

Потери

0.2%

Jitter

3 ms

Reorder

0.4%

Стратегия приложения: Без восстановления

Что происходит: Сеть стабильна: поток идёт с минимальными потерями и почти без вариаций задержки.

Расшифровка обозначений

  • kpps (kilo packets per second) — тысячи пакетов в секунду.
  • Jitter — вариация задержки между соседними пакетами.

Что означают метрики

  • Variation задержки между пакетами; критична для real-time аудио/видео и игр.
  • Пакеты приходят не в исходном порядке; требует буферизации или reorder-логики.
  • Доля пакетов, пригодных для немедленной обработки приложением.

Связанная глава

IPv4 и IPv6: эволюция IP-адресации

Как маршрутизация, MTU и свойства сети влияют на UDP-качество доставки.

Открыть главу

Как сеть и маршрутизация меняют качество UDP

Jitter и очереди

Даже при невысоких потерях рост queueing delay ухудшает качество голоса/видео и real-time событий.

Потери burst-ами

Для UDP критичны короткие всплески loss: приложение должно использовать concealment/FEC или снижать bitrate.

Reorder из-за ECMP/NAT

Смена пути и асимметрия маршрутов повышают reorder и усложняют обработку realtime-потока.

NAT/LB mapping timeout

Stateful middleboxes могут разрывать поток при idle-периодах; keepalive нужно настраивать явно.

MTU и фрагментация

Крупные UDP datagrams чаще фрагментируются и теряются; лучше ограничивать размер сообщений.

Broadcast и multicast в UDP

UDP можно использовать для широковещательной рассылки: отправитель шлёт датаграмму на broadcast-адрес (например, адрес подсети), и её получают все узлы в сегменте. На практике это работает только в пределах локальной сети и часто требует явного разрешения на broadcast в сокете; маршрутизаторы обычно блокируют такие пакеты. Если нужна рассылка “один ко многим” за пределами сегмента, используют multicast (если он поддерживается сетью) либо прикладную рассылку через сервер.

Где UDP подходит лучше всего

  • Real-time мультимедиа (VoIP, видеосвязь, стриминг)
  • Онлайн-игры и интерактивные приложения
  • DNS и другие короткие запросы
  • Телеметрия и метрики
  • Широковещание и мультикаст

Связанная глава

TCP протокол

Надёжная доставка, handshake, контроль потока и перегрузок в transport-слое.

Открыть главу

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

TCP

  • Надёжная доставка и порядок
  • Соединение перед передачей
  • Контроль потока и перегрузок
  • Больше накладных расходов

UDP

  • Best-effort доставка без гарантий
  • Нет handshake, отправка сразу
  • Минимальный overhead
  • Лучше для real-time

Почему это важно для System Design

  • UDP критичен в latency-sensitive системах, где важнее свежесть данных, чем идеальная доставка.
  • Надёжность переносится в application-протокол: ACK/FEC/retry должны быть осознанно спроектированы.
  • Наблюдаемость должна включать loss/jitter/reorder, иначе деградация качества будет невидима до инцидента.
  • Выбор между TCP/UDP напрямую влияет на UX, стоимость трафика и устойчивость системы под нагрузкой.

Частые ошибки

Пытаться использовать UDP как TCP без прикладной логики recovery и адаптации канала.

Игнорировать jitter/reorder и смотреть только на средний packet loss.

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

Не контролировать rate на отправителе, провоцируя self-inflicted congestion и деградацию качества.

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки