Транспортным называется коммуникационный протокол, отвечающий за трансляцию данных, передаваемых с помощью установленного соединения.

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

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

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

Приведенная ниже диаграмма описывает четыре этапа цепочки передачи видео в онлайн-режиме:

Ввод данных иногда называют «первой милей», а доставку — «последней милей». На данном этапе видеопотоки доставляются непосредственно конечным пользователям к выбранному ими устройству или телеэкрану. Однако протоколы доставки MPEG-DASH, CMAF и HLS, которые основаны на HTTP, не используются для потоковой передачи видео первой мили, поскольку они создают слишком большую задержку по времени при прямой трансляции.

Существуют проприетарные протоколы, принадлежащие одной компании и обычно требующие лицензии для использования клиентами или сторонними поставщиками.

Подобный протокол требует постоянных ежемесячных платежей, зависит от поставщика (не взаимодействует с устройствами других производителей) и рискует остаться «бесхозным» в случае прекращения выпуска линейки продуктов поставщиком или ликвидации бизнеса.

Существует два основных транспортных протокола, отвечающих за доставку информации.

TCP используется в Интернете чаще других. Он гарантирует поочередное получение адресатом пронумерованных пакетов.

Получатель посылает сообщения обратно отправителю, сигнализируя об их приеме. Если отправитель не дождется ответа, он отправляет пакеты повторно, чтобы убедиться, что они дошли до получателя. Из-за этих подтверждений надежность TCP возрастает. Пакеты также проходят проверку на наличие ошибок.

Передача через TCP направлена на сохранение целостности данных, а значит отправляемые с помощью TCP пакеты, отслеживаются таким образом, чтобы исключить потерю или повреждение данных при передаче. Такой подход приводит к увеличению временных задержек при ожидании неупорядоченных сообщений или повторной передаче потерянных, что делает протокол непригодным для приложений, работающих в реальном времени.

UDP-протокол работает аналогично TCP, но без проверки ошибок, которая замедляет работу. Пакеты («дейтаграммы») при использовании UDP отправляются получателю, но отправитель не ждет подтверждения о получении пакета адресатом — он просто продолжает отправку следующего. Минусы подобного подхода — пропуск некоторых UDP‑пакетов, отсутствие гарантии получения всех пакетов, а также возможности повторного запроса пропущенных. Основным преимуществом метода выступает быстрая и четкая работа (даже с чувствительными ко времени приложениями — онлайн-играми, прямыми трансляциями) в тех случаях, когда задержка по времени критичнее потери пакетов данных.

Протоколы, обеспечивающие взаимодействие сети и пользователя, делятся на несколько типов.

Первоначально собственный протокол RTMP был разработан Macromedia (Adobe) для потоковой трансляции видео, аудио и данных, передаваемых между сервером и Flash-плеером в реальном времени. Хотя Adobe объявила, что больше не будет поддерживать Flash, RTMP по-прежнему широко используется для потоковой онлайн-передачи.

Этот протокол, выполненный на базе TCP, представляет собой технологию непрерывной потоковой трансляции, основанной на сообщаемых получателем подтверждениях (АСК). Однако последние не уходят отправителю немедленно, что поддерживает сниженный уровень обратного трафика. Отчет об ACK или NACK (отрицательных подтверждениях) отправляется только после получения последовательности пакетов. Если в этой последовательности есть потерянные пакеты, вся цепочка будет передана повторно, начиная с последнего ACK. Этот процесс может значительно увеличить сквозную задержку.

Также RTMP не поддерживает HEVC-кодировку или расширенные разрешения, поскольку не используется при высоких скоростях передачи данных из-за ограничений пропускной способности. RTMP представлен нескольким вариантами, включая RTMPS, который работает через соединение TLS/SSL.

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

RTP также функционирует как транспортный протокол, используемый WebRTC — открытым одноранговым протоколом с JavaScript API для обмена видео между браузерами. Хотя WebRTC хорошо подходит для видеоконференций между небольшими группами или многоадресной потоковой передачи внутри закрытой сети, его возможности масштабирования и надежной потоковой передачи качественного видео ограничены.

RTSP — протокол управления прикладного уровня, который взаимодействует напрямую с сервером потокового видео. RTSP позволяет зрителям удаленно воспроизводить, приостанавливать, останавливать видеопотоки через Интернет без необходимости локальной загрузки. RTSP ранее использовался RealNetworks RealPlayer и до сих пор применяется для различных целей, включая прием потоков с удаленных камер, онлайн‑обучение, интернет‑радио. RTSP требует отдельного сервера для потоковой передачи и не поддерживает шифрование контента или повторную рассылку потерянных пакетов, поскольку он использует протокол RTP вместе с RTCP для доставки медиапотока.

Технология SRT, впервые разработанная Haivision, обеспечивает производительность UDP с низкой задержкой при потере данных внутри ​​сети с помощью высокопроизводительного модуля отправителя / получателя, который максимально увеличивает доступную полосу пропускания. Независимый от кодеков, бесплатный протокол SRT с открытым исходным кодом гарантирует, что частота пакетов (сжатых видеосигналов), поступающих в сеть, идентична тем, которые принимаются декодером, что значительно упрощает процесс декодирования.

Технология имеет дополнительные функции, включая встроенное шифрование AES, поэтому управление безопасностью потока происходит на уровне канала. Это также позволяет пользователям легко обходить брандмауэры на протяжении всего рабочего процесса, поддерживая режимы отправки и получения, в отличие от RTMP и HTTP, функционирующего только в одном направлении. Кроме того, SRT может объединять несколько потоков видео, аудио и данных для поддержки сложных рабочих процессов, что упрощает работу сетевых администраторов. В модуль отправителя / получателя добавлена возможность определения производительности сети на предмет задержки, потери пакетов, джиттера и доступной полосы пропускания. Расширенные интеграции SRT могут использовать эту информацию для управления запуском потока или адаптации конечных точек к изменяющимся условиям сети.

WebRTC — технология с открытым исходным кодом, созданная Google, стандартизированная в январе 2021 года, которая часто используется для видеоконференций. WebRTC состоит из трех API-интерфейсов HTML5 («RTCPeerConnection», «getUserMedia» и «RTCDataChannel»), обеспечивает потоковую передачу голоса, видео с малой задержкой между браузерами, позволяющей имитировать личное общение. Технология также помогает захватывать и воспроизводить как видео, так и аудио без необходимости установки каких-либо дополнительных плагинов. Недостаток использования WebRTC — отсутствие масштабируемости: крупным проектам с большим количеством подключенных пользователей потребуется дополнительный сервер или какое-то технологическое решение для снижения нагрузки на браузер.

WebRTC поддерживают большинство основных браузеров, включая Microsoft Edge, Mozilla Firefox и Google Chrome. Технология используется для работы популярных приложений с видеочатом, таких как Microsoft Teams, Facebook Messenger и Google Hangouts.

HLS — протокол потоковой передачи, оснащенный адаптивным битрейтом от Apple, созданный в 2009 году, который используется для доставки видео к конечному устройству пользователя.

До попадания на видеоплеер данные HLS доставляются с веб-сервера или исходного сервера (часто через CDN). Видеоконтент HLS разбивается на отдельные фрагменты продолжительностью 10 секунд, которые дублируются, кодируются параллельно с различными битрейтами, разрешениями (или профилями). В качестве адаптивного протокола битрейта видеоплеер ищет изменения в условиях пропускной способности. При наличии колебаний устройство может плавно переключаться на наиболее подходящий в данный момент профиль ABR. HLS поддерживает видео, зашифрованное с помощью кодеков H.264 или H.265 (HEVC).

Теперь, когда технология Adobe Flash устарела, HLS стала основным методом доставки видео через Интернет с поддержкой ​​основными веб‑браузерами, медиаплеерами, мобильными устройствами, серверами, телеприставками. Как технология Apple, HLS выступает основным протоколом доставки для устройств iOS.

Протокол с открытым исходным кодом MPEG-DASH, разработанный группой специалистов MPEG, в ноябре 2011 года стал международным стандартом. MPEG-DASH поддерживается приставками, смартфонами, планшетами, другими устройствами. Принцип трансляции аналогичен HLS, поскольку контент так же разбивается на части или фрагменты с каскадом различных кодировок, что делает его адаптируемым к доставке видео от провайдера к устройству без прямого контакта с оператором (OTT).

MPEG-DASH не зависит от кодека, то есть не ограничивается использованием H.264 или HEVC. Технология поддерживает экономически выгодные кодеки, такие, как VP8 или VP9, ​​которые используются для высококачественного вещания с низким уровнем битрейта. Как протокол ABR, выступающий альтернативой HLS, MPEG-DASH широко применяется на устройствах Android.