МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего образования «САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ им. проф. М.А. БОНЧ-БРУЕВИЧА» (СПБГУТ) Факультет информационных сетей и систем Кафедра сетей связи и передачи данных
РЕФЕРАТ на тему
«Исследование протоколов потоковой передачи мультимедийных данных»
			Выполнил студент
			группы:
			Проверил:
			кандидат технических наук доцент кафедры СС и ПД
			Бородко Александр Владимирович

Оглавление

1. RTP и RTCP 6

2. RTMP 8

3. HLS 10

4. SRT 13

5. WebRTC 15

6. HESP 19

1. Введение

За последние два десятилетия наблюдается тенденция резкого увеличения развлекательного контента, что приводит к изменениям в способах их доставки конечным потребителям. В основе этих изменений лежит запрос на возможность получения контента вне контекста времени и расположения на любых платформах. Разумеется, главным инструментом удовлетворения таких запросов, в массовом порядке, стал Интернет. Почти все устройства для отображения мультимедийного контента – смартфоны, телевизоры, ПК, планшеты и т. д. – могут быть подключены к нему из в любой момент из любого места, поскольку они поддерживают интернет-протоколы IP, TCP и UDP.

История сложилась так, что основные транспортные протоколы Интернета (TCP и UDP) возникли задолго до этой тенденции. Это привело к необходимости передачи мультимедийного контента с их помощью, посредством создания новых решений на базе TCP и UDP. Первый широко развернутый экземпляр – транспортный протокол RTP, а также сопутствующий транспортный протокол RTCP, которые впервые были представлены в середине 90-х. С тех пор было разработано много других протоколов.

В современном мире аудио и видео стало неотъемлемой частью нашей жизни, и потоковая передача стала одним из самых популярных способов их распространения. Однако выбор подходящего протокола для передачи мультимедиа может быть сложным, учитывая различные требования к качеству, скорости и масштабируемости. Целью данной работы является изучение основных принципов и технологий, используемых для передачи потокового видео, исследование протоколов и их оценка.

Рис.1 Общая схема передачи потоковых данных

2. Основная часть

Термин «потоковое мультимедиа» впервые был использован для ленточных накопителей, изготовленных Data Electronics Inc. и предназначенных для медленного наращивания и запуска всей записанной информации; появление таких дорожек привело к снижению затрат на привод, что сделало продукт более конкурентоспособным. «Потоковое мультимедиа» было применено в начале 1990-х годов как лучший способ передачи видео по запросу. Впервые это было сделано Starlight Networks для потокового видео и Real Networks для потокового аудио.

Стриминговые мультимедиа (streaming media) – это видео- и аудиоданные, передаваемые через компьютерную сеть для мгновенного просмотра, а не для скачивания файлов и последующего воспроизведения в автономном режиме. Примерами стримингового видео и аудио являются YouTube, интернет-радио и телевизионные трансляции, а также корпоративные веб-трансляции.

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

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

• Битрейт: это количество данных, передаваемых в секунду. Чем выше битрейт, тем лучше качество видео. Однако высокий битрейт может вызывать задержки и буферизацию.

• Разрешение: это количество пикселей в изображении. Чем выше разрешение, тем более четкое изображение. Однако, высокое разрешение также требует большего объема данных и может вызвать задержки.

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

• Компрессия: это процесс сжатия данных для передачи их по сети. Хорошая компрессия может уменьшить объем данных, но может также привести к потере качества.

• Задержки: это время, необходимое для передачи данных по сети. Чем меньше задержка, тем быстрее и более плавно воспроизводится видео.

Для оценки качества стримингового видео можно использовать специальные инструменты, такие как Speedtest by Ookla или Video Quality Report от Google. Эти инструменты могут проверять скорость интернет-соединения, задержки, битрейт и другие параметры, которые влияют на качество стримингового видео. Также можно использовать специальные сервисы для тестирования качества видео, такие как Netflix, YouTube или Vimeo.

Рис.2 Полная схема передачи потоковых данных

Для потоковой передачи видео используются протоколы такие как RTP (Real-time Transport Protocol), RTCP (Real-Time Transport Control Protocol), RTSP (Real-Time Streaming Protocol), RIST (Reliable Internet Stream Transport), HLS (HTTP Live Streaming), MPEG-DASH (Dynamic Adaptive Streaming over HTTP), WebRTC (Web Real-Time Communication), SRT (Secure Reliable Transport), HESP (High Efficiency Stream Protocol).

Распространенность каждого из них может зависеть от конкретной области применения.

RTP – широко используется в IP-телефонии, видеоконференциях и потоковой передаче мультимедиа контента, также в области видеонаблюдения.

RTMP – был популярен во время расцвета Flash-технологии и использовался для передачи видео- и аудиоконтента на платформе YouTube, но сейчас уступает место более современным протоколам.

HLS – широко используется для потоковой передачи видео и аудио контента на мобильных устройствах, также в IPTV и других приложениях, требующих высокой надежности передачи данных.

SRT – используется для передачи видео и аудио контента в условиях неблагоприятных сетевых условий, таких как плохое соединение или низкая пропускная способность.

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

HESP – на данный момент не получил широкого распространения и используется в основном в научных исследованиях и экспериментах.

Таким образом, можно сделать вывод, что RTP, HLS, SRT и WebRTC являются наиболее распространенными и популярными протоколами в различных областях применения. В зависимости от контекста и области применения, популярность протоколов может варьироваться. Например, протокол HLS широко используется для вещания видео на мобильных устройствах и веб-страницах, в то время как протокол HESP в основном применяется в сфере безопасности.

В целом, протоколы RTP, RTMP, HLS, SRT, WebRTC и HESP являются достаточно популярными и широко используются в различных областях, таких как трансляция видео, видеоконференции, видеонаблюдение и т.д.

1. RTP и RTCP

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

Ключевые различия между RTP и RTCP

• Протокол RTP является стандартом для передачи данных приложения в режиме реального времени. С другой стороны, RTCP используется вместе с RTP для отслеживания статистики передачи и качества обслуживания для гарантированной передачи.

• RTP использует четный номер порта, в то время как RTCP использует нечетный номер порта.

• RTP помогает в достижении совместимой среды. В отличие от этого, RTCP контролирует производительность обмена данными путем создания обратных связей.

• RTCP обычно содержит отчеты отправителя и получателя, тогда как RTP содержит такие поля, как тип полезной нагрузки, временная метка, порядковый номер и так далее.

• Идентификация источника в RTP выполняется с помощью 32-разрядного случайного идентификатора. В отличие от этого, в RTCP используются глобально уникальные идентификаторы, которые также могут быть поняты человеком.

Пакеты протокола RTP содержат поля порядкового номера и метки времени. Первое используется для идентификации каждого пакета данных в потоке. Это поле содержит уникальный числовой идентификатор, который увеличивается на единицу для каждого последующего пакета. Порядковый номер позволяет получателю правильно восстановить поток данных, если несколько пакетов были переданы в неправильном порядке или были потеряны в сети. Поле порядкового номера имеет размер 16 бит, что позволяет идентифицировать до 65535 пакетов в потоке. Если поток данных содержит больше пакетов, то порядковый номер начинается сначала с нуля после достижения максимального значения. Поле метки времени используется для синхронизации потока данных между отправителем и получателем. Оно содержит временную отметку, которая указывает на момент отправки пакета данных. Получатель может использовать метку времени для вычисления задержки между отправкой и получением пакета, а также для восстановления потока данных в правильном порядке, если были переданы несколько потоков данных одновременно. Поле метки времени имеет размер 32 бита и может содержать значение времени в миллисекундах или других единицах измерения времени. Оно также может быть использовано для синхронизации разных типов медиа-данных, таких как звук и видео, при их одновременной передаче. Например, если видео передается вместе со звуком, то поле метки времени может использоваться для синхронизации звука с соответствующим кадром видео, чтобы получатель мог воспроизводить контент в правильной последовательности.

Рис.3 Структура заголовка RTP

Протокол RTP широко используется в различных приложениях, таких как видеоконференции, онлайн-игры и потоковое видео. Однако, по умолчанию протокол RTP не обеспечивает защиту данных, поэтому часто используются дополнительные протоколы, такие как SRTP (Secure Real-time Transport Protocol) и SRTCP (Secure Real-time Transport Control Protocol), для обеспечения безопасности передачи данных.

Основными преимуществами данного протокола являются:

• Надежность передачи. RTP использует механизмы обнаружения ошибок и восстановления данных, что делает передачу медиа-данных более надежной.

• Гибкость. Протокол RTP позволяет использовать различные алгоритмы сжатия данных, что позволяет достичь оптимального соотношения качества и скорости передачи.

• Синхронизация. Поле метки времени в RTP позволяет синхронизировать передачу разных типов медиа-данных (например, звук и видео) и восстановить поток данных в правильном порядке.

• Масштабируемость. RTP может использоваться для передачи медиа-данных на различных уровнях сетевой архитектуры, от локальных сетей до глобальных сетей Интернет.

• Поддержка многопользовательских сессий. RTP поддерживает многопользовательские сессии, что позволяет передавать потоковые медиа-данные нескольким пользователям одновременно.

• Расширяемость. RTP имеет возможность расширения функциональности за счет добавления новых типов данных и расширений протокола.

• Совместимость. RTP совместим со многими другими протоколами, такими как RTSP (Real-Time Streaming Protocol), SIP (Session Initiation Protocol) и другими, что делает его универсальным решением для передачи потоковых медиа-данных.

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

2. RTMP

RTMP (Real-Time Messaging Protocol) является протоколом передачи потоковых медиа-данных в режиме реального времени. Он был разработан компанией Adobe Systems и широко используется для передачи видео и аудио в интернете, включая стриминговые платформы и сервисы онлайн-трансляций.

Рис.4 Схема передачи данных через RTMP

Принцип работы RTMP основан на установлении соединения между клиентом и сервером. Клиент отправляет запрос на сервер для подключения к определенному потоку данных. После этого сервер начинает передачу потока данных в режиме реального времени. Протокол обеспечивает гарантированную доставку данных за счет использовании подтверждений (ACK) и повторных передачах (retransmissions). Когда клиент отправляет пакет данных на сервер, сервер отправляет подтверждение о получении этого пакета обратно клиенту. Если клиент не получил подтверждение в течение определенного времени, он повторно отправляет пакет данных. Этот процесс повторяется до тех пор, пока клиент не получит подтверждение от сервера о получении пакета данных. Таким образом, механизм гарантированной доставки данных обеспечивает надежную передачу данных в сети. Далее данные передаются по принципу пакетной передачи. Каждый пакет содержит информацию о временной метке, типе данных и размере пакета. Эта информация используется для определения скорости передачи данных и синхронизации потока.

Протокол RTMP также поддерживает динамическую регулировку битрейта, что позволяет оптимизировать качество передачи данных при изменении скорости интернет-соединения. Когда скорость снижается, механизм динамического изменения битрейта уменьшает битрейт потока, чтобы предотвратить задержки и прерывания воспроизведения. Когда она повышается, механизм увеличивает битрейт потока для улучшения качества воспроизведения. Что позволяет обеспечивать оптимальное качество воспроизведения при любой скорости интернет-соединения.

Кроме того, RTMP обеспечивает безопасность передачи данных с помощью шифрования. Это делает его надежным и безопасным для использования в различных сферах, включая медиаиндустрию, онлайн-игры и трансляции событий в режиме реального времени. Конкретно, RTMP поддерживает два вида шифрования: SSL и RTMPE. SSL используется для защиты соединения между клиентом и сервером, что позволяет предотвратить перехват информации. RTMPE (Real-Time Messaging Protocol Encrypted) используется для шифрования потока данных посредством асимметричного шифрования. Сервер генерирует публичный и приватный ключи, которые используются для шифрования и дешифрования данных. Публичный ключ распространяется на клиентскую сторону, а приватный ключ хранится на сервере. Когда клиент отправляет запрос на получение потока, сервер отправляет публичный ключ клиенту, который используется для шифрования потока данных. Затем клиент отправляет зашифрованные данные обратно на сервер, который дешифрует и передает поток данных клиенту. RTMPE обеспечивает достаточно высокий уровень безопасности, но может замедлить процесс передачи данных из-за дополнительной нагрузки на сервер и клиентскую сторону. Тем не менее, шифрование в RTMP является необходимым для защиты контента от несанкционированного доступа и копирования.

Преимущества протокола RTMP включают:

• Низкая задержка и высокая скорость передачи данных, что позволяет достичь плавного воспроизведения видео и аудио.

• Поддержка динамической регулировки битрейта, что обеспечивает оптимальное качество воспроизведения при любой скорости интернет-соединения.

• Шифрование данных, что обеспечивает безопасность передачи информации.

• Возможность использования для передачи видео и аудио на мобильных устройствах и компьютерах.

• Легкость интеграции с другими технологиями и платформами.

• Высокая надежность и стабильность при передаче данных.

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

3. HLS

HLS (HTTP Live Streaming) – это протокол потоковой передачи данных, разработанный компанией Apple. Он используется для вещания видео- и аудиоконтента в интернете и позволяет обеспечить высокое качество передачи данных при любой скорости интернет-соединения.

Рис.5 Схема передачи данных через HLS

В технологии HLS контент разбивается на небольшие фрагменты, которые имеют фиксированную продолжительность, обычно от 2 до 10 секунд. Каждый фрагмент содержит информацию о видео или аудио, такую как кодек, разрешение, битрейт и т.д. Затем, когда пользователь запрашивает видео или аудио, сервер HLS передает ему файл манифеста, который содержит список доступных фрагментов и их URL-адреса. Пользователь выбирает начальный фрагмент и начинает его загрузку и воспроизведение. Во время воспроизведения, HLS использует алгоритм буферизации, который загружает следующий фрагмент заранее, чтобы убедиться, что пользователь не столкнется с задержкой во время проигрывания. Если скорость интернет-соединения пользователя уменьшается, HLS автоматически переключается на более низкий битрейт и качество видео или аудио, чтобы обеспечить более плавное воспроизведение без прерываний. Таким образом, технология HLS обеспечивает более быструю и эффективную загрузку и воспроизведение контента, а также более гладкое воспроизведение при изменении скорости интернет-соединения пользователя.

Одним из главных преимуществ HLS является его поддержка многоканальной передачи данных, что позволяет обеспечить высокое качество потока для большого количества пользователей. Многоканальная передача осуществляется путем создания нескольких потоков для разных разрешений и битрейтов одного и того же видео или аудио контента. Эти потоки обычно называются вариантами или альтернативами. Варианты могут содержать различные разрешения, битрейты и кодеки, чтобы обеспечить наилучшее качество воспроизведения на разных устройствах и соединениях. Например, один вариант может иметь высокое разрешение и битрейт для пользователей с быстрым интернет-соединением и большими экранами, а другой – низкое разрешение и битрейт для пользователей с медленным интернетом или маленькими экранами. Когда пользователь запрашивает контент, HLS автоматически выбирает наилучший вариант в зависимости от скорости интернет-соединения и устройства пользователя. Если скорость интернет-соединения увеличивается или уменьшается во время воспроизведения, HLS может автоматически переключаться на другой вариант с более высоким или низким битрейтом и разрешением, чтобы обеспечить более плавное воспроизведение без прерываний. Таким образом, многоканальная передача в HLS обеспечивает оптимальное качество воспроизведения для каждого пользователя и устройства, что делает эту технологию очень популярной для стримингового видео и аудио.

Протокол HLS (HTTP Live Streaming) имеет несколько преимуществ:

• Адаптивная потоковая передача. HLS адаптируется к ширине полосы пропускания, доступной на устройстве конечного пользователя. Это означает, что видео будет показываться с максимально возможным качеством, которое может обеспечить доступная полоса пропускания, что обеспечивает более плавный просмотр видео без буферизации.

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

• Простота использования. Чтобы начать использовать HLS, вам не нужно устанавливать специальное программное обеспечение или покупать дополнительное оборудование. Все, что нужно – это настроить сервер для передачи потокового видео по протоколу HTTP.

• Возможность использования CDN. HLS можно использовать с CDN (Content Delivery Network), чтобы обеспечить более быструю передачу видео и уменьшить нагрузку на сервер.

• Безопасность. HLS поддерживает шифрование, что обеспечивает безопасность передачи видео.

• Аналитика. HLS предоставляет возможность получать аналитические данные о просмотре видео, что может быть полезно для улучшения качества контента и повышения эффективности маркетинговых кампаний.

Несмотря на то, что протокол HLS имеет множество преимуществ, у него также есть некоторые недостатки:

• Задержка передачи. HLS имеет задержку передачи видео из-за разделения контента на небольшие фрагменты и передачи их по HTTP. Это может быть проблематично для интерактивного контента, такого как видеоконференции или онлайн-игры.

• Дополнительные затраты на хранение и передачу. Поскольку видео контент разбивается на фрагменты, это требует дополнительных затрат на хранение и передачу, по сравнению с другими протоколами потокового видео.

• Ограничения в качестве видео. Несмотря на то, что HLS позволяет передавать видео с высоким разрешением, максимальное качество, которое можно достичь, ограничено доступной полосой пропускания устройства конечного пользователя.

• Проблемы совместимости. Некоторые старые браузеры и устройства могут не поддерживать протокол HLS, что может привести к проблемам с отображением видео контента.

• Ограниченная поддержка DRM. Некоторые DRM-системы могут иметь ограниченную поддержку в HLS, что может быть проблематично для контент-провайдеров, которые хотят защитить свой контент от незаконного копирования и распространения.

4. SRT

SRT (Secure Reliable Transport) – это протокол передачи видео контента, который обеспечивает высокую надежность и безопасность при передаче потокового видео через интернет. Протокол был разработан компанией Haivision в 2013 году с целью улучшения передачи контента. Он был создан на основе опыта, накопленного компанией в области трансляции в реальном времени. SRT использует уникальный механизм передачи данных, который позволяет ему обеспечивать высокую надежность и стабильность. Он основывается на нескольких принципах:

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

• Контроль потока данных. SRT использует механизм контроля потока данных, который позволяет ему адаптироваться к условиям сети и обеспечивать высокую надежность передачи данных. Контроль потока данных SRT состоит из двух частей: управление буфером и управление пропускной способностью.

Рис.6 Схема передачи данных через SRT

Одним из преимуществ SRT является возможность управление пропускной способностью. SRT оптимизирует использование сети, прежде всего, за счет управления потоком данных. Он автоматически регулирует скорость передачи данных в реальном времени в соответствии с условиями сети и доступной пропускной способностью. Это позволяет максимально эффективно использовать доступную пропускную способность сети и избегать задержек и потерь данных. Кроме того, SRT использует буфер для временного хранения данных, что позволяет избежать скачков в скорости передачи данных в случае потери пакетов или снижения пропускной способности сети. Буфер также обеспечивает регулирование задержки в передаче данных, что позволяет снизить вероятность появления задержек и мерцания при просмотре видео. Кроме того, он использует механизмы контроля целостности и повторной передачи данных в случае потери или повреждения пакетов. Это обеспечивает полную и точную передачу данных и снижает необходимость повторных передач, что снижает нагрузку на сеть и повышает эффективность использования ее ресурсов.

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

Основные преимущества протокола SRT:

• Надежность передачи данных. SRT использует различные механизмы для обеспечения надежной передачи данных, такие как повторная отправка пакетов и управление пропускной способностью.

• Высокая скорость передачи данных. SRT использует оптимизированные алгоритмы для передачи данных, что позволяет уменьшить задержки и улучшить качество видео.

• Низкая задержка. SRT обеспечивает низкую задержку, что особенно важно при передаче видео в реальном времени.

• Кроссплатформенность. SRT может быть использован на различных операционных системах и устройствах, что делает его удобным инструментом для передачи данных.

• Безопасность передачи данных. SRT поддерживает шифрование данных и механизмы аутентификации, что обеспечивает защиту данных от несанкционированного доступа.

• Адаптивность к изменениям в сети. SRT автоматически регулирует пропускную способность, что позволяет ему адаптироваться к изменениям в сети и обеспечивать высокое качество передачи данных.

• Открытый и бесплатный. SRT является открытым протоколом, что означает, что его можно использовать бесплатно и настраивать в соответствии с потребностями пользователя.

Несмотря на то, что протокол SRT имеет множество преимуществ, у него также есть некоторые недостатки, среди которых можно выделить:

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

• Зависимость от качества сети. Как и любой другой протокол передачи данных, SRT зависит от качества сети, в которой он используется. Плохое качество сети может снизить скорость передачи данных и ухудшить качество видео.

• Требует дополнительных ресурсов. SRT может потреблять больше ресурсов на устройстве для обработки и передачи данных, чем другие протоколы, что может быть проблемой для устройств с ограниченными ресурсами.

• Ограниченная совместимость с некоторым оборудованием. Некоторое оборудование может не поддерживать протокол SRT, что может ограничить его применение в некоторых ситуациях.

• Риск возникновения проблем при работе с сетевыми настройками. Неправильная настройка сетевых параметров может привести к некорректной работе протокола SRT, что может повлиять на качество передачи данных.

5. WebRTC

WebRTC (Web Real-Time Communication) – это бесплатный и открытый проект, который позволяет реализовывать видео- и голосовую связь в режиме реального времени между браузерами и другими устройствами через интернет. Этот протокол был разработан в 2011 году консорциумом W3C, а в настоящее время поддерживается группой компаний, включая Google, Mozilla, Opera и Microsoft.

WebRTC использует протокол UDP (User Datagram Protocol), который обеспечивает быструю передачу данных в режиме реального времени. По сравнению с протоколом TCP (Transmission Control Protocol), который используется в других протоколах для передачи данных, UDP не имеет механизма контроля ошибок и гарантий доставки данных, что позволяет достичь более низкой задержки. Кроме того, для снижения задержки используется протокол SRTP (Secure Real-time Transport Protocol), который обеспечивает безопасную передачу данных и позволяет уменьшить задержки.

Рис.7 Схема организации сети для передачи данных через WebRTC

WebRTC использует технологии JavaScript и HTML5 для обеспечения удобного взаимодействия между устройствами и браузерами, что позволяет создавать приложения для видео- и голосовой связи прямо в браузере без необходимости устанавливать дополнительное программное обеспечение. Это обеспечивает простоту и удобство использования приложений, а также облегчает доступность их для пользователей.

Для установления связи между устройствами используется технология Peer-to-Peer (P2P), которая позволяет устройствам обмениваться данными напрямую без необходимости передачи их через центральный сервер. Это обеспечивает быстрое установление связи и уменьшает задержки в передаче данных. В процессе работы WebRTC используется набор протоколов и кодеков, которые обеспечивают сжатие и передачу аудио- и видеоданных в режиме реального времени. В частности, для сжатия видео используется кодек VP8, который позволяет достичь высокого качества изображения при низкой задержке.

Для обеспечения безопасности передаваемых данных в протоколе WebRTC используется шифрование с использованием протокола DTLS (Datagram Transport Layer Security), который обеспечивает защиту данных от перехвата и взлома.

Рис.8 Схема передачи данных через WebRTC

Протокол WebRTC обеспечивает безопасность передачи данных с помощью нескольких механизмов:

• Шифрование данных. Все данные, передаваемые через WebRTC, шифруются с помощью протокола SRTP (Secure Real-time Transport Protocol). Это обеспечивает конфиденциальность передаваемой информации и защищает ее от несанкционированного доступа.

• Аутентификация. Передача данных между устройствами осуществляется только после прохождения процесса аутентификации. Для этого используется протокол DTLS (Datagram Transport Layer Security), который обеспечивает защиту от атак типа «Man-in-the-middle» и гарантирует подлинность устройств, участвующих в передаче данных.

• Ограничение доступа к устройствам. Протокол WebRTC ограничивает доступ к камере и микрофону устройства, чтобы предотвратить несанкционированный доступ к данным. Пользователь должен дать разрешение на использование камеры и микрофона, чтобы протокол мог использовать их во время передачи данных.

• Безопасный обмен ключами. Для обеспечения шифрования данных используется безопасный обмен ключами с помощью протокола DTLS-SRTP. Этот механизм позволяет убедиться в подлинности ключей и защитить их от несанкционированного доступа.

• Поддержка HTTPS. Протокол WebRTC поддерживает HTTPS (HTTP Secure), что позволяет защитить передаваемые данные от атак типа «Man-in-the-middle» и предотвратить их изменение или подмену в процессе передачи.

WebRTC имеет несколько преимуществ:

• Низкая задержка. WebRTC использует сокеты UDP для передачи потоковых данных, что обеспечивает низкую задержку передачи и мгновенную передачу аудио и видео.

• Простота использования. Для использования WebRTC не требуется установка дополнительного программного обеспечения или настройка сетевых параметров, что делает его доступным для широкой аудитории.

• Кроссплатформенность. Протокол поддерживается на различных операционных системах, включая Windows, macOS, Linux, Android и iOS.

• Открытый исходный код. WebRTC – это открытый стандарт с открытым исходным кодом, что позволяет разработчикам создавать на его основе свои собственные решения.

• Высокая степень взаимодействия. WebRTC позволяет создавать решения для связи, работающие на любых устройствах и с любым типом сетевого подключения.

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

• Безопасность. WebRTC обеспечивает безопасность передачи данных, используя шифрование и механизмы аутентификации, что делает его надежным и безопасным для использования в коммерческих приложениях.

Протокол WebRTC имеет несколько недостатков:

• Ограниченные возможности для многопользовательской связи. WebRTC был разработан в первую очередь для пиринговой связи между двумя пользователями, поэтому его возможности для многопользовательской связи ограничены.

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

• Необходимость в высокой скорости интернет-соединения. Поскольку WebRTC использует потоковые данные, для обеспечения хорошего качества передачи и минимизации задержки требуется достаточно высокоскоростное интернет-соединение.

• Ограниченные возможности для работы в условиях ограниченной пропускной способности. WebRTC не является идеальным для работы в условиях с ограниченной пропускной способностью, так как он использует потоковые данные и требует достаточно высокой пропускной способности для обеспечения качества связи.

• Ограниченные возможности для интеграции со сторонними приложениями. WebRTC ограничен в возможностях интеграции со сторонними приложениями, что может создать проблемы для разработчиков при создании собственных решений на основе этого протокола.

6. HESP

Протокол HESP (HTTP Event Stream Protocol) – это протокол передачи потока событий, основанный на протоколе HTTP, который позволяет клиенту получать обновления данных с сервера в режиме реального времени. HESP использует формат сообщений SSE (Server-Sent Events), предназначенный для отправки потока событий на клиент. Он поддерживает передачу различных типов данных, включая текст, JSON и бинарные данные.

Протокол HESP позволяет установить длительное соединение между клиентом и сервером, что позволяет серверу отправлять обновления данных на клиент без необходимости, чтобы клиент постоянно отправлял запросы на их обновление. Это позволяет сократить нагрузку на сеть и сервер, а также снизить задержку передачи данных. Однако, в отличие от протокола WebSocket, HESP не поддерживает двустороннюю связь между клиентом и сервером, что означает, что клиент не может отправлять данные на сервер. Также HESP может быть менее надежным, чем протоколы, основанные на WebSocket, из-за более ограниченной поддержки со стороны серверов и браузеров.

Протокол HESP был разработан в ответ на необходимость передачи потоков данных между клиентом и сервером в режиме реального времени с минимальной задержкой и нагрузкой на сеть. Он был представлен в 2014 году в виде прототипа и был реализован в некоторых библиотеках и фреймворках, таких как Flask, Tornado и Bottle, однако не получил широкого распространения и не стал популярным в сравнении с протоколом WebSocket и другими альтернативными протоколами передачи данных в реальном времени. HESP основан на формате SSE (Server-Sent Events), который был стандартизирован в 2015 году в спецификации HTML5.

Работа с протоколом HESP происходит в следующем порядке:

• Клиент отправляет запрос на сервер по протоколу HTTP, указывая заголовок Accept: text/event-stream.

• Сервер отвечает на запрос клиента с заголовками Content-Type: text/event-stream и Cache-Control: no-cache, что говорит браузеру не кэшировать ответ и обрабатывать его как поток данных.

• Сервер отправляет клиенту поток событий, разделяя каждое событие символом переноса строки \n. Каждое событие состоит из двух частей: идентификатора события и данных события. Идентификаторы и данные разделяются символом двоеточия. Идентификатор может быть пустым, а данные могут быть любым текстом, закодированным в UTF-8.

• Клиент обрабатывает поток событий, выполняя необходимые действия в зависимости от полученных данных.

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

Кроме того, HESP использует простой и легковесный формат передачи данных, что также способствует уменьшению задержки. Заголовки ответа сервера минимизированы, а формат событий состоит из двух частей: идентификатора события и данных события, разделенных символом двоеточия. Это позволяет уменьшить объем передаваемых данных и снизить нагрузку на сеть.

Протокол HESP имеет несколько механизмов обработки ошибок.

• Коды состояния HTTP. При возникновении ошибок сервер может отправлять клиенту соответствующий код состояния HTTP (например, 404 "Not Found" или 500 "Internal Server Error"). Это позволяет клиенту понять, что произошла ошибка и принять соответствующие меры.

• Таймауты. Протокол HESP предусматривает возможность установки таймаутов на запросы и ответы. Если сервер не отвечает на запрос клиента в течение определенного времени, то клиент может считать, что произошла ошибка и прервать соединение.

• Проверка целостности данных. Протокол HESP использует встроенные механизмы проверки целостности передаваемых данных. Если клиент получает данные, которые не соответствуют ожидаемому формату, то он может считать, что произошла ошибка и принять соответствующие меры.

• Логирование. Протокол HESP предусматривает возможность логирования всех запросов и ответов. Это позволяет отслеживать возможные ошибки и принимать меры по их устранению.

• Обработка ошибок на уровне приложения. Наконец, протокол HESP позволяет обрабатывать ошибки на уровне приложения. Например, приложение может обрабатывать ошибки и отправлять соответствующие сообщения клиенту, чтобы тот мог принять меры по их устранению.

Рис.з Схема передачи данных через HESP

HESP (High-speed ESP) не предусматривает механизмов шифрования, аутентификации и управления ключами, так как предназначен для использования только в локальных сетях. Поэтому он не обеспечивает никакой защиты от перехвата или изменения данных при передаче по открытому каналу. Однако HESP может быть использован в сочетании с другими протоколами, такими как IPSec, для обеспечения безопасности в сетях с распределенной инфраструктурой. В этом случае HESP обеспечивает высокую скорость передачи данных, а IPSec обеспечивает безопасность передачи. Кроме того, HESP может использоваться для защиты данных в локальных сетях, когда требуется высокая скорость передачи данных, но нет необходимости в шифровании или аутентификации.

Основные преимущества протокола HESP включают:

• Высокая скорость передачи данных. Протокол HESP обеспечивает высокую производительность и эффективность при передаче данных, что делает его идеальным для использования в высоконагруженных сетях.

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

• Простота и эффективность. HESP является простым и эффективным протоколом, который не требует больших вычислительных мощностей и ресурсов.

• Независимость от операционной системы. Протокол HESP может быть использован на различных операционных системах и платформах.

• Возможность интеграции с другими протоколами. HESP может быть использован в сочетании с другими протоколами для обеспечения безопасности передачи данных в сетях с распределенной инфраструктурой.

Некоторые из основных недостатков протокола HESP включают:

• Ограниченность функций. HESP не поддерживает многие функции, которые предоставляются более сложными протоколами, что может ограничивать его возможности.

• Неэффективность при работе с большими файлами. Протокол HESP не оптимизирован для передачи больших файлов, поэтому может быть неэффективен при работе с такими файлами.

• Ограниченная поддержка устройств. HESP может быть несовместим с некоторыми устройствами, что ограничивает его использование в некоторых сценариях.

• Недостаточная безопасность при работе в открытых сетях. Протокол HESP обеспечивает надежную защиту при передаче данных в локальных сетях, но может быть недостаточно безопасным при работе в открытых сетях, таких как интернет.