DevGang
Авторизоваться

Заменит ли WebTransport WebRTC в ближайшем будущем? 

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

В 2010 году инженеры Google представили WebRTC для решения некоторых из этих проблем. Сегодня мы используем его практически везде.

Представляем WebRTC

WebRTC, Интернет Связь в реальном времени - это протокол (набор API), который позволяет осуществлять прямую связь между браузерами. Эти API поддерживают обмен файлами, информацией или любыми данными. Похоже на WebSockets. Однако это не так.

Как мы уже обсуждали, связь между браузерами происходит без прямого участия сервера. Однако вначале серверу необходимо облегчить совместное использование IP-адресов друг друга. Тем не менее, это быстрее, чем связь через сервер.

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

Итак, каковы ограничения WebRTC?

Когда дело доходит до WebRTC, возникает несколько ограничений.

Проблемы масштабируемости

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

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

Качество трансляции

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

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

Клиенты должны инициировать соединение

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

Однако HTTP push попытался избавиться от этого, создав новый поток. Здесь сервер создает новый поток, а затем отправляет контент клиенту. Однако это не увенчалось успехом. Так недавно Google удалил этот подход из Chrome.

Итак, для решения этих проблем предлагается совершенно новый WebTransport.

Что такое WebTransport?

WebTransport - это подключаемый протокол для взаимодействия клиент-сервер, построенный на основе HTTP/2, HTTP/3 и QUIC. Он разработан, чтобы заменить WebSockets, становящиеся «QUIC-native».

Вы можете думать об этом как о WebRTC, но оптимизированным для правила 80/20.
QUIC - это веб-API, который использует протокол QUIC в двунаправленном транспорте, отличном от HTTP, который обслуживается через UDP, аналогично независимому TCP, что значительно сокращает задержку установки соединения. Основная функциональность - это двусторонняя связь между веб-клиентом и сервером QUIC с API Steam.

Кроме того, WebTransport поддерживает несколько потоков, однонаправленные потоки, доставку вне очереди, надежный и ненадежный транспорт.

Преодоление проблем с WebTransport

WebTransport поверх QUIC

WebTransport - это интерфейс, который может взаимодействовать с протоколами на основе HTTP/2, HTTP/3 и QUIC. Таким образом, у него есть то преимущество, что HTTP-трафик и не-HTTP-трафик могут использовать один и тот же сетевой порт.

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

WebTransport поддерживает несколько протоколов

WebTransport поддерживает однонаправленные потоки (неограниченно длинные потоки байтов в одном направлении), двунаправленные потоки (полнодуплексные потоки) и датаграммы (небольшие / неупорядоченные / ненадежные сообщения). Итак, есть несколько ключевых применений WebTransport, а именно:

  1. WebTransport может запросить через HTTP и прием pushed out-of-order (надежно и ненадежно) по одной и той же сети.
  2. WebTransport может отправлять данные (надежные и ненадежные) на сервер, используя однонаправленный поток отправки QUIC.
  3. WebTransport может получать данные, отправленные с сервера, с помощью однонаправленных потоков приема.

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

Заключение

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

WebRTC на основе WebSocket - уже не самый быстрый подход.

В этом случае мощный WebTransport решит проблему WebRTC на основе веб-сокетов. Учитывая все эти преимущества, я считаю, что WebTransport заменит WebRTC. Но людям потребуется время, чтобы адаптироваться.

Источник:

Комментарии
Чтобы оставить комментарий, необходимо авторизоваться

Присоединяйся в тусовку

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

Попробовать

Оплатив хостинг 25$ в подарок вы получите 100$ на счет

Получить