Jak działa WebRTC?

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 widziałem Schematy na ten temat i teraz jest dla mnie jasne, że połączenie działa przez serwer. Serwer wydaje się wymieniać pewne dane między Klientem, który jest gotów połączyć się ze sobą, tak, że mogą rozpocząć bezpośrednie połączenie, które jest niezależne od serwera.

Ale to dokładnie 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 podłączenie się do tego portu z komputera B. Ale tak nie jest w WebRTC. Myślę, że żaden z klientów nie zaczyna słuchać na porcie. W jakiś sposób mogą stworzyć połączenie bez nasłuchiwania portów i przyjmowania połączeń. Ani klient A, ani klient B nie zaczyna działać jako serwer.

Ale jak? Jakie dane są wymieniane przez serwer WebRTC, że klienci mogą używać do łączenia się ze sobą?

Dzięki za wyjaśnienia:)

Edit

Znalazłem Ten artykuł. To nie jest związane z WebRTC, ale myślę, że to odpowiedź na część mojego pytania. Nie jestem pewien, twardzielu. I tak byłoby fajnie, gdyby ktoś mi to wyjaśnił i podał jakieś dodatkowe linki.

 40
Author: Van Coding, 2012-10-03

3 answers

WebRTC daje SDP ofertę aplikacji klienta js do wysłania (jednak aplikacja JS chce) do innego urządzenia, które używa tego do generowania odpowiedzi SDP.

Sztuczka polega na tym, że SDP obejmuje kandydatów ICE(skutecznie "spróbuj porozmawiać ze mną pod tym adresem IP i tym portem"). ICE pracuje nad otwieraniem otwartych portów w zaporach; jeśli obie strony są symetryczne, nie będzie to ogólnie możliwe i można użyć alternatywnego kandydata (na serwerze TURN).

Gdy już rozmawiają bezpośrednio (lub za pośrednictwem TURN, który w rzeczywistości jest lustrzanką pakietów), mogą otworzyć połączenie DTLS i użyć go do kluczowania strumieni mediów SRTP-DTLS i wysyłania kanałów danych przez DTLS.

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

Edycja 2: Firefox i Chrome (i spec) przenieśli się do korzystania z" trickle " dla kandydatów na ICE, więc ICE kandydaci są zazwyczaj dodawani po spotkaniu do PeerConnection i wymieniani niezależnie od początkowego SDP (chociaż możesz poczekać, aż początkowi kandydaci będą gotowi przed wysłaniem oferty i połączyć je razem). Zobacz https://webrtcglossary.com/trickle-ice / i https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

 42
Author: jesup,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-03-15 14:05:58

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

Tutaj wpisz opis obrazka

W szczególności zakładając, że adres IP serwera STUN jest znany, aplikacja WebRTC wysyła najpierw wiążące żądanie do serwera STUN. Serwer STUN odpowiada z odpowiedzią, która zawiera publiczny adres IP i port Klienta, jak widać z sieci publicznej.

Teraz aplikacja odkrywa swój publiczny adres IP i krotkę portów, które można wysłać do drugiego peera przez SDP. (należy pamiętać, że SDP są wysyłane przez zewnętrzny kanał sygnalizacyjny, np. websocket ustanowiony przez usługę internetową)

Z tym mechanizmem, za każdym razem, gdy dwóch rówieśników chce rozmawiać ze sobą przez UDP, mogą następnie używać ustalonych krotek publicznego adresu IP i portu do wymiany danych.

Niestety, w niektórych przypadkach UDP może zostać zablokowane przez firewall. Aby rozwiązać ten problem, za każdym razem, gdy STUN nie powiedzie się, możemy użyć protokołu Traversal przy użyciu przekaźników wokół protokołu NAT (TURN), który może działać przez UDP i przełączyć się na TCP, jeśli Wszystko inne zawiedzie.

 4
Author: gaetano,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-13 14:22:38

Ustanowienie połączenia P2P WebRTC ma 3 kroki (przegląd 10.000 stóp):

  1. Krok 1: Signaling: oba Peery łączą się z serwerem sygnalizacyjnym (używając websockets ponad 80/443, comet, SIP itp..) i wymiany informacji (o ich możliwościach medialnych, publicznych parach IP: port, gdy staną się dostępne, itp.)

  2. Krok 2: Discovery : urządzenia podłączone do SIECI LAN lub sieci komórkowych nie są świadome swojego publicznego adresu IP (i portu), z którego można się do nich dostać w ten sposób używają serwerów STUN/TURN znajdujących się w publicznym Internecie, aby odkryć swoją parę portów ip: (kandydaci ICE). W procesie dziurkują otwór przez NAT/router, który jest używany w kroku 3:

  3. Krok 3: połączenie P2P : gdy kandydaci ICE są wymieniani przez początkowy kanał sygnalizacyjny, każdy peer jest świadomy swojego portu ip: (i dziury zostały wybite w Natach / routerach), więc połączenie peer to peer UDP może być ustalone.

Tutaj wpisz opis obrazka

Powyższy schemat wyjaśnia proces z 2 urządzeniami podłączonymi do sieci lokalnych. Jest to część artykułu, który napisałem, że zajmuje się rozwiązywaniem problemów z połączeniem , ale dobrze wyjaśnia, jak działa WebRTC.

 3
Author: Octavian Naicu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-06-08 10:57:54