Протокол RTP¶

Протокол RTP (Real-time Transport Protocol, протокол транспортировки в реальном времени) — это сетевой протокол прикладного уровня, предназначенный для передачи аудио- и видеоданных в реальном времени через IP-сети. Он обеспечивает доставку потоковых медиаданных с минимальной задержкой, а также поддержку синхронизации, идентификации типа данных и восстановления последовательности пакетов. RTP обычно работает поверх протокола UDP, но может использоваться и с другими транспортными протоколами. В паре с RTP часто применяется протокол RTCP (Real-time Transport Control Protocol), который отвечает за мониторинг качества передачи и статистику.

¶История

Протокол RTP был разработан в начале 1990-х годов в рамках проекта Internet Engineering Task Force (IETF) под руководством Хеннинга Шульцринне (Henning Schulzrinne) и Стивена Каснера (Stephen Casner). Первая спецификация была опубликована в 1996 году как RFC 1889. В 2003 году вышла обновлённая версия RFC 3550, которая остаётся основной и поныне. Изначально RTP создавался для видеоконференций и потокового аудио, но со временем область его применения расширилась на VoIP, IP-телевидение, онлайн-игры и системы видеонаблюдения.

¶Архитектура и принцип работы

RTP работает в архитектуре клиент-сервер или peer-to-peer. Данные передаются в виде пакетов, каждый из которых содержит заголовок и полезную нагрузку. Заголовок RTP включает следующие поля:

Версия (V) — 2 бита, указывает версию протокола (текущая — 2).
Флаг заполнения (P) — 1 бит, указывает, содержит ли пакет дополнительные байты заполнения.
Флаг расширения (X) — 1 бит, указывает на наличие расширенного заголовка.
Число источников CSRC (CC) — 4 бита, количество идентификаторов источников.
Маркер (M) — 1 бит, используется для обозначения границ кадров (например, начало видеокадра).
Тип полезной нагрузки (PT) — 7 бит, определяет формат кодирования данных (например, H.264, G.711).
Порядковый номер (Sequence Number) — 16 бит, увеличивается на 1 для каждого отправленного пакета, позволяет восстановить порядок и обнаружить потери.
Временная метка (Timestamp) — 32 бита, отражает момент семплирования первого байта данных в пакете, используется для синхронизации и воспроизведения.
SSRC (Synchronization Source) — 32 бита, уникальный идентификатор источника потока.
CSRC (Contributing Sources) — до 15 идентификаторов по 32 бита, используется при микшировании потоков (например, в конференциях).

Полезная нагрузка может содержать сжатые аудио- или видеоданные, а также другие типы данных (например, текст, субтитры). RTP не гарантирует доставку пакетов и не управляет перегрузками — эти функции возлагаются на нижележащие протоколы и RTCP.

¶Взаимодействие с RTCP

RTCP (Real-time Transport Control Protocol) работает параллельно с RTP и использует отдельный порт (обычно на единицу больше порта RTP). RTCP выполняет следующие функции:

Мониторинг качества — передача статистики о потерях пакетов, джиттере, задержках.
Синхронизация — связь временных меток RTP с реальным временем (NTP).
Идентификация — передача информации об участниках сеанса (CNAME).
Управление — ограничение частоты отправки RTCP-пакетов для предотвращения перегрузки.

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

¶Форматы полезной нагрузки

RTP поддерживает множество форматов кодирования, которые идентифицируются полем PT. Некоторые распространённые типы:

Аудио: G.711 (PCM), G.722, G.729, Opus, MP3, AAC.
Видео: H.261, H.263, H.264, H.265, MPEG-4, VP8, VP9.
Текст: T.140 (для субтитров и чатов).
Данные: RFC 4733 (DTMF-тоны), RFC 6184 (H.264).

Форматы могут быть статическими (закреплённые номера PT) или динамическими (договариваются через протоколы управления, например SIP или RTSP).

¶Применение

RTP используется в широком спектре приложений и сервисов:

IP-телефония (VoIP) — передача голоса через интернет (например, в Skype, Zoom, Asterisk).
Видеоконференции — синхронная передача аудио и видео (например, WebRTC, Cisco Webex).
Потоковое вещание — live-трансляции (например, YouTube Live, Twitch).
IP-телевидение (IPTV) — доставка телеканалов через IP-сети.
Системы видеонаблюдения — передача видео с IP-камер.
Онлайн-игры — передача голосового чата и игровых данных.

¶Преимущества и недостатки

¶Преимущества

Низкая задержка — подходит для реального времени.
Гибкость — поддержка любых типов данных через динамические форматы.
Масштабируемость — может использоваться в многоточечных конференциях.
Открытый стандарт — спецификации бесплатны и широко доступны.

¶Недостатки

Отсутствие гарантий доставки — потеря пакетов может привести к искажениям.
Зависимость от UDP — не поддерживает надёжность TCP.
Сложность управления — требует дополнительных протоколов (RTCP, SIP, RTSP).

¶Безопасность

RTP сам по себе не обеспечивает шифрование или аутентификацию. Для защиты данных применяются расширения:

SRTP (Secure RTP) — добавляет шифрование, аутентификацию и защиту от повторных атак (RFC 3711).
ZRTP — протокол согласования ключей для SRTP.
DTLS-SRTP — использование DTLS для установления защищённого канала.

SRTP широко используется в современных системах (например, WebRTC, Zoom, Signal).

¶Альтернативы

Существуют другие протоколы для передачи потоковых данных, но RTP остаётся доминирующим:

RTMP (Real-Time Messaging Protocol) — проприетарный протокол Adobe, используется в Flash-приложениях.
HLS (HTTP Live Streaming) — основан на HTTP, использует RTP для live-вещания.
WebRTC — использует RTP как транспортный уровень, но добавляет собственные механизмы управления.

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

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

¶Критика

Основные нарекания к RTP связаны с его сложностью и отсутствием встроенных механизмов безопасности. Для защиты данных требуется дополнительная настройка SRTP, что увеличивает накладные расходы. Также критикуется зависимость от UDP, так как в некоторых сетях (например, корпоративных) UDP-трафик может блокироваться или ограничиваться. Кроме того, RTP не поддерживает адаптивное битрейт-кодирование (ABR) — эту функцию берут на себя прикладные протоколы (например, HLS, DASH).

¶Источники

RFC 3550 — RTP: A Transport Protocol for Real-Time Applications (2003).
RFC 3551 — RTP Profile for Audio and Video Conferences with Minimal Control (2003).
RFC 3711 — The Secure Real-time Transport Protocol (SRTP) (2004).
Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V. — RTP: A Transport Protocol for Real-Time Applications (1996).
Perkins, C. — RTP: Audio and Video for the Internet (2003).