Как работает WebRTC?

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

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

Но это то, что я не понимаю. До сих пор я думал, что единственный способ создания подключений - прослушивать порт на компьютере A и подключаться к этому порту с компьютера B. Но это не похоже на WebRTC. Я думаю, что ни один из клиентов не начинает слушать порт. Так или иначе, они могут создавать соединение без прослушивания портов и приема соединений. Ни клиент A, ни клиент B не начинают действовать как сервер.

Но как? Какие данные обмениваются на сервере WebRTC, которые клиенты могут использовать для подключения друг к другу?

Спасибо за ваши объяснения для этого:)

Edit

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

Ответ 1

WebRTC предоставляет предложение SDP клиенту JS-приложению для отправки (однако приложение JS) на другое устройство, которое использует это для генерации ответа SDP.

Хитрость заключается в том, что SDP включает кандидатов ICE (эффективно "попробуйте поговорить со мной по этому IP-адресу и этому порту" ). ICE работает, чтобы открыть открытые порты в брандмауэрах; хотя, если обе стороны являются симметричными NAT, это будет невозможно вообще, и может быть использован альтернативный кандидат (на сервере TURN).

Как только они разговаривают напрямую (или через TURN, что фактически является зеркалом пакета), они могут открывать соединение DTLS и использовать его для подключения медиа-потоков SRTP-DTLS и отправки DataChannels через DTLS.

Изменить: Акронимы здесь: http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ для остальных, есть Google. Большинство из них определены IETF (http://ietf.org/)

Изменить 2: Firefox и Chrome (и спецификация) перешли к использованию "струйки" для кандидатов ICE, поэтому кандидаты ICE обычно добавляются после выхода на сайт PeerConnection и обмениваются независимо от начальной SDP (хотя вы можете подождать, пока первые кандидаты готовы перед отправкой предложения и связывают их вместе). См. https://webrtcglossary.com/trickle-ice/ и https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

Ответ 2

Очень хорошее объяснение можно найти в этой книге http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE который обеспечивает основы того, как WebRTC использует технологию ICE.

В частности, если предположить, что IP-адрес сервера STUN известен, приложение WebRTC сначала отправляет запрос привязки на сервер STUN. Сервер STUN отвечает ответом, который содержит общедоступный IP-адрес и порт клиента, как видно из общедоступной сети.

Теперь приложение обнаруживает свой общедоступный IP-адрес и кортеж портов, который может отправлять другому партнеру через SDP. (обратите внимание, что SDP отправляется по внешнему сигнальному каналу, f.i. websocket, установленному через веб-службу).

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

К сожалению, в некоторых случаях UDP может быть заблокирован брандмауэром. Чтобы решить эту проблему, всякий раз, когда STUN терпит неудачу, мы можем использовать протокол Traversal Using Relays вокруг протокола NAT (TURN) как резерв, который может работать через UDP и переключиться на TCP, если все остальное не работает.

Ответ 3

Установление соединения p2p WebRTC имеет 3 шага (обзор 10 000 футов):

Шаг 1: Сигнализация: оба одноранговых узла подключаются к серверу сигнализации (с использованием веб-карт более 80/443, кометы, SIP и т.д.) и обмениваются информацией (об их возможностях мультимедиа, общедоступные IP: пары портов, когда они становятся доступными, и т.д.)
Шаг 2: Обнаружение. Устройства, подключенные к локальной сети или мобильным сетям, не знают об их общедоступном IP (и порту), где они могут быть достигнуты, поэтому они используют STUN/TURN-серверы, расположенные в общедоступном Интернете, чтобы открыть свою пару ip: port (кандидаты ICE). В процессе они пробивают отверстие через NAT/маршрутизатор, который используется в шаге 3:
Шаг 3: Соединение P2P: после обмена ICE-кандидатами через начальный канал сигнализации каждому партнеру известно друг о друге ip: порт (и отверстия были пробиты в NAT/routers), поэтому можно установить соединение UDP с одноранговым доступом.

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