Мы регулярно рассказываем о новых стандартах, протоколах и сетевых технологиях. Одну такую технологию как раз развивает рабочая группа IETF. Речь о стеке протоколов для передачи мультимедиа поверх QUIC — Media over QUIC (MoQ).
Разработка началась еще в 2022 году, однако сегодня проект получает новую порцию внимания на ИТ-площадках. Также о Media over QUIC говорят облачные провайдеры и региональные интернет-регистраторы, участвующие в развитии протокола.
Зачем понадобился еще один протокол
Стриминговые платформы и видеохостинги, обслуживающие многомиллионную аудиторию, сталкиваются с задержкой передачи данных. В то же время сервисы для видеоконференций обеспечивают низкие задержки, но не всегда способны эффективно масштабироваться. Media over QUIC должен решить обе эти проблемы. В уставе рабочей группы IETF его описывают как единый протокол для отправки и получения аудио, видео и метаданных с ультранизкой задержкой. «Мы хотим объединить лучшее из обоих миров и заменить два изолированных технологических стека единой универсальной архитектурой», — отмечает Каллен Дженнингс, технический директор Cisco, который принимает непосредственное участие в деятельности рабочей группы IETF.
По словам авторов, ключевая «фишка» Media over QUIC — работа с медиаконтентом в формате publish/subscribe. По сути, это асинхронный механизм обмена данными, при котором издатели (publishers) публикуют сообщения в определенных каналах, а подписчики (subscribers) их получают. В контексте MoQ издатели объявляют именованные медиадорожки — отдельные аудио- или видеопотоки — к которым подписчики могут обращаться по мере необходимости.
Среди других преимуществ MoQ выделяют интеграцию с WebCodecs API, которые предоставляют низкоуровневый доступ к кодекам для обработки аудио- и видеоданных. Еще одно достоинство — механизмы интеллектуальной ретрансляции, позволяющие адаптироваться к работе в сетях с ограниченной пропускной способностью. «MoQ вдохновлен рядом существующих архитектурных подходов, — говорит Каллен Дженнингс. — Мы использовали накопленный опыт взаимодействия с потоковым контентом в рамках RTP, позаимствовали идеи масштабирования из HLS, DASH и HTTP-CDN».
Почему именно QUIC
Дело в проблеме head-of-line blocking (HOL blocking) — когда потеря одного пакета блокирует передачу последующих, вызывая скачки задержек и «подвисания» при воспроизведении. Как пишет Робин Маркс, исследователь сетевых протоколов из Университета Хасселта в Бельгии, «это была одна из самых сложных проблем, связанных с производительностью классического веба» — и протокол QUIC ее решает.
В случае с QUIC данные поступают по нескольким независимым потокам, поэтому потеря пакета в одном из них (скажем, на аудиодорожке) не блокирует другие (например, видеоряд). Такой подход устраняет «заикания» при воспроизведении — типичную проблему протоколов вроде RTMP, предназначенных для непрерывной потоковой передачи. Небольшие потери пакетов в QUIC не должны приводить к джиттеру при воспроизведении. Как пишет один из разработчиков MoQ, на стороне клиента работают буферы сглаживания, а проигрыватель знает, как синхронизировать аудио и видео.
Еще одно важное преимущество QUIC — бесшовная миграция между сетями, например, при переключении с Wi-Fi на мобильные данные. Он поддерживает так называемую «миграцию соединения» — оно остается активным даже при смене IP-адреса пользователя, а это может быть важно при передаче тяжеловесного видеоконтента. Наконец, третья причина — ускоренное установление соединения. Механизм 0-RTT в QUIC позволяет быстро возобновить защищенное соединение. В контексте MoQ такой подход позволит быстрее начинать просмотр видео.
Что обо всем этом думают в сообществе
Каллен Дженнингс из Cisco отмечает, что главными бенефициарами внедрения Media over QUIC станут приложения для видеоконференций. Сейчас в рамках одного звонка могут общаться сотни людей, в то время как количество зрителей у стримеров на игровых платформах составляет сотни тысяч. Возможность увеличить число пользователей может открыть новые рынки для таких видеоприложений и новые юзкейсы.
Похожего мнения придерживается и Уилл Лоу, член рабочей группы MoQ и главный архитектор программного обеспечения в Akamai Technologies. Однако он подчеркивает, что в выигрыше окажутся операторы CDN: «Сегодня операторы CDN вынуждены поддерживать отдельные сети для доставки контента в реальном времени, видео по запросу и прямых спортивных трансляций — из-за различий в протоколах и форматах». И по его словам, MoQ сможет обслуживать сразу несколько сегментов рынка.
Тем не менее сообщество выражает сомнения касательно адаптации нового протокола и возможных недостатков, связанных с использованием QUIC. Так, в конце мая вышло исследование, в рамках которого специалисты попытались оценить уровень задержек и джиттера протоколов Media over QUIC (MoQ), RTP over QUIC (RoQ) и WebRTC в сетях Wi-Fi и 5G. В одном из тестов видеопоток кодировался с использованием H.264 в 1080p, при 30 кадрах в секунду и битрейте 15 Мбит/с. Лучше всего себя проявил WebRTC — как в сетях Wi-Fi, так и в 5G. Исследователи отметили, что он обладает более эффективными механизмами управления входящими пакетами и системой компенсации задержек. RTP over QUIC и Media over QUIC показали более высокий уровень джиттера в Wi-Fi-сетях. Авторы исследования отметили, что эти протоколы еще не достигли зрелости, а сам QUIC остается на ранних этапах эволюции.
Проводились и другие исследования, которые указали на некоторые ограничения QUIC. Например, в прошлом году вышла публикация американских специалистов из университетов Мичигана, Миннесоты и Южной Калифорнии. Они показали, что QUIC проигрывает TCP при нагрузках свыше 600 Мбит/с. Его производительность снижается, а требования к вычислительным ресурсам — возрастают. К слову, это и другие исследования по теме мы обсуждали ранее.
Сообщество также отмечает потенциальные трудности, связанные с адаптацией QUIC в целом. Согласно данным сервиса для визуализации интернет-трафика, на него приходится около 30% защищенных HTTP-запросов. Однако многие системные администраторы относятся к протоколу скептически из-за того, что он основан на UDP: «Stateless-природа UDP значительно усложняет распределение ресурсов, защиту и поиск неполадок». Кроме того, можно встретить мнение, что стек UDP менее оптимизирован сам по себе. Учитывая этот контекст, в ближайшее время MoQ вряд ли будет стремительно развиваться. Тем не менее его реализации уже появляются — например, на Go и на Rust — даже несмотря на тот факт, что MoQ еще не оформлен в RFC как официальный стандарт.
Дополнительное чтение — в нашем блоге на Хабре:
IPv6, Wi-Fi и ситуации в сфере ИБ — что почитать о беспроводных технологиях и сетевой инфраструктуре. Это — подборка наших технических материалов о беспроводных технологиях, управлении трафиком и тематических инструментах.
Что с IPv6? Вопрос dual-stack'а на DNS-резолверах. Есть мнение, что распространению протокола нового поколения препятствует стандарт, описанный еще двадцать лет назад в RFC 3901. Согласно этому документу, авторитетные и рекурсивные DNS-серверы обязаны поддерживать IPv4, но не IPv6. В статье обсуждаем решение проблемы, которое предлагает ряд исследователей.
В копилку уязвимостей BGP — как устроена атака Kirin. Протокол BGP за годы существования «накопил» немало уязвимостей. Рассказываем про атаку Kirin, которая направлена на перегрузку маршрутизаторов: чем она опасна, как ей противостоять. Также говорим о проектах, авторы которых предлагают полностью пересмотреть архитектуру интернета: MobilityFirst, NEBULA и SCION.