Что такое WebRTC

  —  4 минуты

#theory#web#data
Читать статью в Telegram

WebRTCWeb Real Time Communications — стандарт, который описывает прямую передачу потоковых аудиоданных, видеоданных и контента между клиентами в режиме реального времени. На основе этого стандарта работают всякие зумы, телемосты, google meet и прочие площадки

Для реализации такого соединения в браузерах используется нативный JS класс RTCPeerConnection

Причем акцент тут на фразе "прямая передача", так как WebRTC в идеале, пусть и не всегда, представляет собой p2p соединение

p2ppeer-to-peer — это такое сетевое соединение, которое позволяет двум или более устройствам общаться между собой напрямую без сервера-посредника. Ещё такие соединения называют одноранговыми

Если хотя бы у одного из клиентов прям очень медленный интернет или есть ещё какие-то проблемы, которые не позволяют открыть p2p соединение, то p2p соединения и не получится

В таких случаях соединение организуется через TURN сервер и WebRTC становится не p2p, а уже клиент-сервер-клиент способом коммуникации

TURNTraversal Using Relay NAT — это протокол, который позволяет узлу за NAT или брандмауэром получать входящие данные через TCP или UDP соединения

TURN схема

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

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

У каждого устройства в сети гарантированно может быть только локальный IP адрес, который далее через NAT транслируется во внешнюю сеть

NATNetwork Address Translation — механизм TCP/IP, который позволяет транслировать внутренние локальные IP адреса во внешние IP адреса за пределами нашего маршрутизатора (можно назвать роутером), который будет выступать в роли межсетевого экрана (файрвол)

Короче, чтобы решить всю эту сетевую кашу, существует STUN, который позволяет каждому клиенту узнать свой публичный адрес и инициатору соединения сформировать две сущности — Offer и ICE Candidate

STUNSession Traversal Utilities for NAT (перевод "утилиты обхода сеансов для NAT") — это протокол, который позволяет каждому устройству узнать свой внешний IP адрес даже за файрволом

Клиент отправляет STUN серверу запрос, затем сервер STUN отправляет клиенту обратно информацию о том, каков внешний адрес маршрутизатора NAT, и какой порт открыт на NAT для приема входящих запросов обратно во внутреннюю сеть

Offer — это предложение открыть прямое соединение на основе параметров связи, то есть Offer описывает используемые кодеки для передачи контента, информацию о медиа-потоках (видео, аудио) и тд

ICE Candidate — это метаданные устройства в p2p сети: его IP, порт и прочие параметры

Далее две эти сущности отправляются сигнальному серверу, и уже через сигнальный сервер инициатор получит Answer (то же самое, что и Offer, только от второго клиента)

Прямое соединение откроется только после выполнения всех этих шагов, но для открытия соединения нужен сервер-посредник

Сигнальный сервер — это то, что мы можем реализовать сами на любых удобных технологиях. Тут вообще не важно как Offer, Answer и ICE Candidate будут передаваться между клиентами — REST API, сокеты... хоть голубями отправляйте

Статья была полезной?