Jak działa WebRTC?

Question

Jestem zainteresowany połączeniami Peer-to-Peer w przeglądarce. Ponieważ wydaje się to możliwe z WebRTC, zastanawiam się, jak to działa exaclty.

Przeczytałem kilka wyjaśnień i zobaczyłem diagramy na ten temat i teraz jest dla mnie jasne, że połączenie działa na serwerze. Wydaje się, że serwer wymienia niektóre dane między klientem, który chce się ze sobą połączyć, aby mogli nawiązać bezpośrednie połączenie, niezależne od serwera.

Ale to jest to, czego nie rozumiem. Do tej pory myślałem, że jedynym sposobem na tworzenie połączeń jest nasłuchiwanie na porcie na komputerze A i łączenie się z tym portem z komputera B. Ale tak się nie dzieje w WebRTC. Myślę, że żaden z klientów nie zaczyna nasłuchiwać na porcie. W jakiś sposób mogą utworzyć połączenie bez słuchania na portach i akceptowania połączeń. Ani klient A, ani klient B nie zaczyna działać jako serwer.

Ale jak? Jakie dane są wymieniane na serwerze WebRTC, z którego klienci mogą się łączyć?

Dzięki za wyjaśnienia dla tego :)

Edit

znalazłem this artykuł. Nie ma związku z WebRTC, ale myślę, że odpowiada na część mojego pytania. Nie jestem pewien, twardy. Wciąż byłoby fajnie, gdyby ktoś mógł mi to wyjaśnić i podać mi dodatkowe linki.

Answer 1

WebRTC oferuje SDP Oferta aplikacji klienckiej JS do wysłania (jednak aplikacja JS chce) do drugiego urządzenia, które wykorzystuje to do wygenerowania odpowiedzi SDP.

Podstępem jest to, że SDP zawiera kandydatów ICE (efektywnie "spróbuj ze mną rozmawiać pod tym adresem IP i tym portem"). ICE działa w celu otwarcia portów w zaporach; jeśli jednak obie strony są symetrycznymi translatorami NAT, nie będzie to możliwe ogólnie i można użyć alternatywnego kandydata (na serwerze TURN).

Po rozmowie bezpośrednio (lub za pośrednictwem TURN, która jest faktycznie lustrem pakietowym), mogą otworzyć połączenie DTLS i użyć go do kluczowania strumieni multimediów SRTP-DTLS oraz do wysyłania kanałów DataChannel przez DTLS.

Edytuj: Skróty tutaj: http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ dla reszty, jest Google. Większość z nich jest zdefiniowany przez IETF (http://ietf.org/)

Edycja 2: Firefox i chrom (i widmo), zostały przeniesione do korzystania z „sączyć” ICE kandydatów, to kandydaci ICE są zwykle dodawane po-twarzy do PeerConnection i wymieniane niezależnie od początkowego SDP (choć możesz poczekać, aż kandydaci będą gotowi przed wysłaniem oferty i połączyć ją razem). Zobacz https://webrtcglossary.com/trickle-ice/ i https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

Answer 2

Bardzo dobre wyjaśnienie można znaleźć w tej książce http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE która zapewnia podstawy dotyczące WebRTC wykorzystuje technologię ICE.

W szczególności przy założeniu, że adres IP serwera STUN jest znana aplikacja WebRTC najpierw wysyła wiążącą żądanie do serwera STUN. Serwer STUN odpowiada odpowiedzią zawierającą publiczny adres IP i port klienta widziany z sieci publicznej.

Teraz aplikacja wykrywa swój publiczny adres IP i krotkę portową, które mogą wysyłać do innego urządzenia równorzędnego za pośrednictwem SDP. (pamiętaj, że SDP są wysyłane przez zewnętrzny kanał sygnalizacyjny, sieć internetowa utworzona za pośrednictwem usługi internetowej)

Gdy ten mechanizm działa, gdy dwóch rówieśników chce rozmawiać ze sobą przez UDP, może wtedy użyć ustalonego publicznego adresu IP i port krotki do wymiany danych.

Niestety, w niektórych przypadkach protokół UDP może być blokowany przez zaporę. Aby rozwiązać ten problem, za każdym razem, gdy STUN ulegnie awarii, możemy użyć przełącznika Traversal Using Relays around NAT (TURN) jako awaryjnego, który może działać przez UDP i przełączać się na TCP, jeśli wszystko inne zawiedzie.

Answer 3

Ustanowienie połączenia P2P WebRTC ma 3 etapach (10.000 stóp ogólny):

1. Krok 1: Sygnalizacja: obie peerów połączyć się z serwerem sygnalizacji (stosując WebSockets na 80/443, Comet SIP itd ..) i wymiany informacji (na temat ich możliwości mediów, publiczny IP: pary portów, gdy staną się dostępne, itd.)

2. Krok 2: Discovery: Urządzenia podłączone do sieci LAN lub sieci telefonii komórkowej nie są świadomi ich publiczny adres IP (i port) Można do nich dotrzeć, wykorzystując serwery STUN/TURN znajdujące się w publicznym Internecie, aby odkryć ich parę ip: port (kandydaci ICE). W procesie uderzenie one otwór, przez NAT/routerem, który jest używany w kroku 3:

3. Etap 3: P2P połączenie: po kandydaci ICE są wymieniane przez początkowego kanału sygnalizacyjnego Każdy równorzędny jest świadomy wzajemnie ip : port (i dziury zostały dziurkowane w NAT/routerach), więc można ustanowić połączenie UDP peer to peer.

powyższym schemacie opisano proces z 2 urządzeń podłączonych do sieci lokalnej. Jest to część artykułu, który napisałem, który zajmuje się troubleshooting connection issues, ale dobrze wyjaśnia, w jaki sposób działa WebRTC.