tgoop.com/prog_way_blog/346
Create:
Last Update:
Last Update:
Галопом по теории WebRTC
Тема большая, но попробую максимально сжато рассказать в текстовом посте
WebRTC — Web Real Time Communications — стандарт, который описывает прямую передачу потоковых аудиоданных, видеоданных и контента между клиентами в режиме реального времени. На основе этого стандарта работают всякие зумы, телемосты, google meet и прочие площадки
Для реализации такого соединения в браузерах используется нативный JS класс RTCPeerConnection
Причем акцент тут на фразе "прямая передача", так как
WebRTC в идеале, пусть и не всегда, представляет собой p2p соединениеp2p — peer-to-peer — это такое сетевое соединение, которое позволяет двум или более устройствам общаться между собой напрямую без сервера-посредника. Ещё такие соединения называют одноранговыми
Однако, если мы можем общаться между устройствами без посредника, это не значит, что мы можем установить соединение без посредника
Для того чтобы установить прямое соединение между двумя клиентами, нужно знать их IP адреса. А мы, как пользователи какого-нибудь ноутбука не можем напрямую узнать IP адрес ноутбука нашего друга, потому что скорее всего у его устройства нет публичного статичного IP адреса
У каждого устройства в сети гарантированно может быть только локальный IP адрес, который далее через NAT транслируется во внешнюю сеть
NAT — Network Address Translation — механизм TCP/IP, который позволяет транслировать внутренние локальные IP адреса во внешние IP адреса за пределами нашего маршрутизатора (можно назвать роутером), который будет выступать в роли межсетевого экрана (файрвол)
Короче, чтобы решить всю эту сетевую кашу, существует STUN, который позволяет каждому клиенту узнать свой публичный адрес и инициатору соединения сформировать две сущности —
Offer и ICE CandidateSTUN — Session Traversal Utilities for NAT (перевод "утилиты обхода сеансов для NAT") — это протокол, который позволяет каждому устройству узнать свой внешний IP адрес даже за файрволом
Клиент отправляет STUN серверу запрос, затем сервер STUN отправляет клиенту обратно информацию о том, каков внешний адрес маршрутизатора NAT, и какой порт открыт на NAT для приема входящих запросов обратно во внутреннюю сеть
Offer — это предложение открыть прямое соединение на основе параметров связи, то есть Offer описывает используемые кодеки для передачи контента, информацию о медиа-потоках (видео, аудио) и тдICE Candidate — это метаданные устройства в p2p сети: его IP, порт и прочие параметрыДалее две эти сущности отправляются сигнальному серверу, и уже через сигнальный сервер инициатор получит
Answer (то же самое, что и Offer, только от второго клиента)Прямое соединение откроется только после выполнения всех этих шагов, но для открытия соединения нужен сервер-посредник
Сигнальный сервер — это то, что мы можем реализовать сами на любых удобных технологиях. Тут вообще не важно как Offer, Answer и ICE Candidate будут передаваться между клиентами — REST API, сокеты... хоть голубями отправляйте
Немного задушил теорией и надеюсь, что нигде не ошибся, пишите если что
Спасибо за прочтение, это важно для меня
@prog_way_blog — чат — #web #theory #data