02 UDP vs TCP для медиа
UDP и TCP в медиапередаче: как выбор протокола влияет на видео и звук
При передаче аудио и видео по сети один из ключевых инженерных решений — выбор транспортного протокола. От него напрямую зависят задержка, надёжность и общее качество восприятия потока зрителем или слушателем.
В этом тексте мы разберём:
- Чем отличаются протоколы UDP и TCP.
- Почему для живых трансляций обычно выбирают UDP.
- Почему веб‑платформы стриминга чаще используют TCP.
- Как это связано с задержкой, потерями пакетов и качеством изображения/звука.
1. Транспортный протокол и его роль в передаче медиа
Транспортный протокол — это уровень сетевого стека, который отвечает за доставку данных между двумя конечными точками: отправителем (например, IP‑камера, стриминговый кодер) и получателем (плеер, сервер, записывающее устройство).
При работе с мультимедиа (аудио и видео) у нас всегда есть конфликт между:
- Надёжностью передачи (дошли ли все данные, ничего ли не потерялось);
- Задержкой (через сколько миллисекунд или секунд зритель увидит/услышит то, что происходит сейчас).
В разных задачах приоритеты различаются:
- Для живой трансляции (онлайн‑ивент, видеоконференция, мониторинг камер) критична минимальная задержка.
- Для веб‑стриминга по запросу (видео на сайте, запись трансляции, просмотр архива) важнее, чтобы всё доехало без потерь, а небольшая задержка не так страшна.
Именно поэтому на транспортном уровне чаще всего рассматриваются два основных протокола — UDP и TCP.
2. UDP: скорость важнее гарантии
2.1. Что такое UDP
UDP (User Datagram Protocol) — это транспортный протокол, который:
- Не устанавливает соединение в явном виде (нет механизма “рукопожатия” перед началом передачи).
- Не гарантирует доставку пакетов (нет подтверждений, нет повторной отправки).
- Не гарантирует порядок доставки (пакеты могут прийти не по порядку или не прийти вообще).
- Работает максимально просто и быстро: «отправил — и забыл».
Пакет UDP иногда называют датаграммой — это самостоятельная единица данных, которую сеть старается доставить по указанному адресу, но без гарантий.
2.2. Почему UDP подходит для живого видео и аудио
Для живых трансляций (live‑стриминг) важна низкая задержка. Зритель должен видеть и слышать происходящее как можно ближе к “сейчас”.
UDP идеально подходит под эту задачу:
- Нет ожидания подтверждений
Отправитель не ждёт ответа от получателя на каждый пакет. Это сокращает время доставки и убирает дополнительный сетевой трафик. - Нет повторных передач «отстающих» пакетов
Если пакет потерялся, UDP не пытается его отправить заново. Потерянный пакет уже «пропустил свой момент» во времени — пока мы бы его ждали, реальный поток ушёл бы вперёд, и задержка увеличилась бы. - Постоянный поток данных
Видео и аудио при live‑стриминге — это непрерывный поток. Лучше иногда потерять часть данных, но сохранить плавность и актуальность потока, чем замораживать картинку из‑за ожидания старых пакетов.
2.3. Что происходит при потере пакетов в UDP
При использовании UDP часть пакетов может не дойти до получателя. Это называется потерей пакетов.
В мультимедийных приложениях основной принцип такой:
«Лучше показать слегка испорченный кадр вовремя, чем идеальный, но сильно с опозданием.»
Декодер (программа или устройство, которое расшифровывает сжатое видео и аудио) может:
- Интерполировать недостающие данные — то есть “додумать” содержимое кадра на основе предыдущих и последующих кадров.
- Сгладить артефакты, сделать плавные переходы, замазать или “растянуть” информацию во времени.
Для зрителя это выглядит, например, как:
- Кратковременное небольшое «смазывание» картинки.
- Едва заметный скачок или потеря детали в движении.
Но поток продолжает идти без остановок, и большая часть аудитории не замечает этих проблем.
2.4. RTP и UDP
На практике для переноса медиаданных часто используется протокол RTP (Real-time Transport Protocol).
Он:
- Работает поверх UDP в большинстве систем реального времени.
- Добавляет к каждому пакету метку времени и номер последовательности, чтобы получатель мог собрать поток в правильном порядке и синхронизировать аудио/видео.
Таким образом:
- UDP даёт быстрый, “лёгкий” транспорт.
- RTP добавляет структуру и синхронизацию, необходимые для реального времени.
3. TCP: надёжность важнее задержки
3.1. Что такое TCP
TCP (Transmission Control Protocol) — это транспортный протокол, который:
- Устанавливает логическое соединение между отправителем и получателем (трёхшаговое “рукопожатие”).
- Гарантирует доставку всех пакетов (если пакет потерялся, запрашивается повторная передача).
- Гарантирует порядок доставки (получатель видит данные в том порядке, в котором они были отправлены).
- Управляет скоростью передачи (чтобы не перегружать сеть).
TCP предназначен для ситуаций, где нельзя терять данные: файлы, веб‑страницы, API‑запросы, банковские транзакции и т.п.
3.2. Механизм надёжности и его цена
TCP обеспечивает надёжность за счёт нескольких механизмов:
- Подтверждения (ACK)
Получатель регулярно отправляет отправителю подтверждения о том, какие данные он получил. - Повторная передача (retransmission)
Если подтверждение не пришло за заданное время, отправитель предполагает, что пакет потерялся, и отправляет его заново. - Гарантированный порядок
TCP собирает поток байт в правильной последовательности. Если какой-то пакет задерживается, получатель ждёт его, прежде чем передавать данные дальше приложению.
Из-за этих механизмов при проблемах в сети возникает эффект, который критичен для мультимедиа.
3.3. Head-of-line blocking: что это и почему это плохо для “реального времени”
Head-of-line blocking — это ситуация, когда:
- Один потерявшийся или сильно задержавшийся пакет блокирует передачу всех последующих, даже если они уже дошли.
- Получатель не может отдать приложению новые данные, пока не получит пропущенный фрагмент, чтобы сохранить правильный порядок.
В мультимедийных условиях это приводит к:
- Задержке увеличенной на сотни миллисекунд или даже секунды.
- Подвисанию картинки, “фризам” (картинка стоит, звук может прерваться или тоже зависнуть).
Для реального времени это неприемлемо. Пользователь лучше проглотит мелкие визуальные артефакты, чем длительную паузу.
::: warn На практике, например, при работе с источниками RTSP-потоков даже в компактной локальной сети, не говоря о корпоративной сети вроде зданий ВШЭ, лучше использовать TCP: при передаче потоков по UDP поток разваливается очень часто. Это наблюдается как в коммерческом ПО (видеомикшер VMix), так и в известных open source приложениях (OBS, gstreamer, ffmpeg, vlc).
Это противоречит теоретическим положениям (действительно, во всех учебниках пишут, что в реальном времени видео лучше передавать по UDP, не будем с ними спорить), но когда вам понадобится, чтобы картинка не сыпалась хотя бы в домашней системе видеонаблюдения, не говоря о производственном видеокомплексе, вспомните это примечание. :) Один кадр = 40 мс, за это время TCP много раз обернется с переотправкой потерянных пакетов.
:::
4. Где TCP всё-таки уместен: веб‑стриминг и HTTP‑протоколы
Несмотря на проблемы с задержкой, TCP имеет большое преимущество — надёжность и предсказуемость доставки. Это особенно важно для:
- Веб‑стриминга через браузер.
- Видео по запросу (VOD), когда пользователь смотрит уже записанный контент.
- Масштабируемых публичных трансляций через CDN (Content Delivery Network).
Большинство веб‑сервисов работают поверх протокола HTTP, а HTTP, в свою очередь, использует TCP как транспорт.
4.1. HLS и DASH поверх TCP
Протоколы HLS (HTTP Live Streaming) и MPEG‑DASH:
- Разбивают видео на короткие сегменты (обычно от 2 до 10 секунд).
- Каждый сегмент — это по сути небольшой файл (часть видеофайла), который загружается по HTTP.
- Клиент (браузер или плеер) скачивает один сегмент за другим по TCP.
Преимущества такого подхода:
- Все сегменты доходят до клиента полностью и без искажений.
- Можно легко кэшировать сегменты на серверах и в CDN.
- Легко масштабировать трансляцию на миллионы зрителей, используя стандартную веб‑инфраструктуру.
Недостаток:
- Суммарная задержка вырастает из‑за:
- буферизации нескольких сегментов;
- особенностей TCP (подтверждения, возможные повторные передачи).
Но для массового веб‑просмотра задержка в 10–30 секунд чаще всего приемлема.
5. Сравнение подходов: UDP vs TCP для медиа
Ниже приведена компактная таблица, обобщающая ключевые различия:
| Характеристика | UDP + RTP (типичные live‑системы) | TCP + HTTP (HLS, DASH и др.) |
|---|---|---|
| Гарантия доставки | Нет (возможны потери пакетов) | Да (пакеты доставляются или переотправляются) |
| Порядок доставки | Не гарантирован протоколом | Гарантирован |
| Задержка | Минимальная, оптимально для real‑time | Выше, зависит от буферизации и сети |
| Реакция на потерю пакета | Пакет игнорируется, плеер интерполирует | Повторная отправка, ожидание (head-of-line blocking) |
| Качество при плохой сети | Могут быть артефакты, но поток продолжает идти | Возможны фризы, остановки из‑за ожидания |
| Типичные сценарии | Видеоконференции, мониторинг, студийные фиды | Веб‑стриминг, VOD, массовые онлайн‑трансляции |
6. Выбор протокола в зависимости от задачи
На практике сложился следующий подход:
- Живые системы (live‑системы), где критична низкая задержка
Примеры: видеоконференции, онлайн‑игры с видеопотоком, прямые эфиры с минимальным отставанием, системы видеонаблюдения для оперативного реагирования.- Чаще всего используют UDP как транспорт.
- Поверх UDP обычно работают протоколы типа RTP, а также решения для реального времени с собственными надстройками (коррекция потерь, адаптация битрейта и т.п.).
- Веб‑платформы и массовые стриминговые сервисы
Примеры: стриминговые сайты, видеоархивы, трансляции через браузер, встроенные плееры на веб‑страницах.- Используют TCP для надёжности и совместимости с существующей веб‑инфраструктурой.
- Протоколы вроде HLS и DASH работают поверх HTTP, а HTTP поверх TCP.
Итого:
- UDP выбирают там, где важнее быстрота и актуальность сигнала.
- TCP выбирают там, где важнее надёжность и масштабируемость, а задержка может быть больше.
Выбор между UDP и TCP в задачах медиапередачи — это выбор между:
- Низкой задержкой, но возможными искажениями (UDP, live‑сценарии).
- Гарантированной доставкой, но более высокой задержкой (TCP, веб‑стриминг).