Większość materiału włączona WebRTC skupia się na poziomie aplikacji pisania kodu i nie przyczynia się do zrozumienia technologii. Spróbujmy wejść głębiej i dowiedzieć się, jak zachodzi połączenie, jaki jest deskryptor sesji i kandydaci, czym są OSZOŁOMIĆ oraz SKRĘCAĆ serwer.

WebRTC

Wstęp

WebRTC to technologia oparta na przeglądarce, która umożliwia połączenie dwóch klientów w celu transmisji danych wideo. Główne cechy to obsługa wewnętrznej przeglądarki (nie ma potrzeby korzystania z wbudowanych technologii innych firm, takich jak Adobe Flash ) oraz możliwość łączenia klientów bez użycia dodatkowych serwerów - połączenie peer-to-peer(Dalej, p2p).

Nawiąż połączenie p2p- dość trudne zadanie, ponieważ komputery nie zawsze mają publiczność IP adresy, czyli adresy w Internecie. Ze względu na niewielką ilość IPv4 adresy (i ze względów bezpieczeństwa) opracowano mechanizm NAT, który umożliwia tworzenie sieci prywatnych, np. do użytku domowego. Wiele routerów domowych obsługuje teraz NAT i dzięki temu wszystkie urządzenia domowe mają dostęp do Internetu, choć dostawcy Internetu zazwyczaj taki udostępniają IP adres. publiczny IP Adresy są unikalne w Internecie, ale adresy prywatne nie. Więc połącz się p2p- trudny.

Aby lepiej to zrozumieć, rozważ trzy sytuacje: oba węzły znajdują się w tej samej sieci (Obrazek 1), oba węzły znajdują się w różnych sieciach (jeden w sieci prywatnej, drugi w publicznej) (Zdjęcie 2) a oba węzły znajdują się w różnych sieciach prywatnych z tym samym IP adresy (Rysunek 3).

Rysunek 1: Oba węzły w tej samej sieci

Rysunek 2: Węzły w różnych sieciach (jeden prywatny, jeden publiczny)

Rysunek 3: Węzły w różnych sieciach prywatnych, ale z numerami równymi adresami

Na powyższych rysunkach pierwsza litera w dwuznakowym zapisie wskazuje typ węzła (p = rówieśnik, r = router). Na pierwszym rysunku sytuacja jest korzystna: węzły w ich sieci są całkowicie identyfikowane przez sieć IP adresy i dlatego mogą łączyć się ze sobą bezpośrednio. Na drugim rysunku mamy dwie różne sieci, które mają podobne numery węzłów. Tutaj pojawiają się routery (routery), które mają dwa interfejsy sieciowe - wewnątrz swojej sieci i poza jej siecią. Dlatego mają dwa IP adresy. Zwykłe węzły mają tylko jeden interfejs, przez który mogą komunikować się tylko we własnej sieci. Jeśli przekazują dane do kogoś spoza swojej sieci, to tylko z pomocą NAT wewnątrz routera (routera), a zatem widoczne dla innych pod IP adres routera jest ich zewnętrzny IP adres. Zatem węzeł p1 jest wnętrze IP = 192.168.0.200 oraz zewnętrzny IP = 10.50.200.5 , przy czym ostatni adres jest również zewnętrzny w stosunku do wszystkich innych hostów w jego sieci. Podobnie sytuacja wygląda w przypadku węzła p2. Dlatego ich połączenie jest niemożliwe, jeśli tylko ich wewnętrzne (własne) IP adresy. Możesz używać adresów zewnętrznych, czyli adresów routerów, ale ponieważ wszystkie węzły w tej samej sieci prywatnej mają ten sam adres zewnętrzny, jest to dość trudne. Ten problem rozwiązuje mechanizm NAT

Co się stanie, jeśli nadal zdecydujemy się połączyć węzły przez ich adresy wewnętrzne? Dane nie opuszczą sieci. Aby wzmocnić efekt, można sobie wyobrazić sytuację pokazaną na ostatnim rysunku - oba węzły mają te same adresy wewnętrzne. Jeśli użyją ich do komunikacji, każdy węzeł będzie komunikował się ze sobą.

WebRTC z powodzeniem radzi sobie z takimi problemami korzystając z protokołu LÓD, co jednak wymaga użycia dodatkowych serwerów ( OSZOŁOMIĆ, SKRĘCAĆ). Wszystko to poniżej.

Dwie fazy WebRTC

Aby połączyć dwa węzły za pomocą protokołu WebRTC(lub po prostu RTC jeśli dwa są połączone iPhone„a) należy podjąć pewne wstępne kroki w celu ustanowienia połączenia. To jest pierwsza faza - nawiązanie połączenia. Druga faza to transmisja danych wideo.

Należy od razu powiedzieć, że chociaż technologia WebRTC w swojej pracy wykorzystuje wiele różne drogi komunikacja ( TCP oraz UDP) i ma elastyczne przełączanie między nimi, ta technologia nie posiada protokołu do przekazywania danych połączenia. Nic dziwnego, bo połącz dwa węzły p2p nie tak łatwe. Dlatego konieczne jest posiadanie kilku dodatkowy sposób przesyłania danych, niezwiązany z WebRTC. Może to być transfer gniazda, protokół HTTP, może to być nawet protokół SMTP lub Poczta Rosyjska. Ten mechanizm transmisji podstawowy dane nazywają się sygnał. Nie trzeba przesyłać zbyt wielu informacji. Wszystkie dane są przesyłane jako tekst i są podzielone na dwa typy − SDP oraz Lodowy kandydat. Pierwszy typ służy do ustanowienia połączenia logicznego, a drugi do połączenia fizycznego. Więcej o tym później, ale na razie warto o tym pamiętać WebRTC da nam pewne informacje, które będą musiały zostać przesłane do innego węzła. Jak tylko przeniesiemy wszystko niezbędne informacje, węzły będą mogły się połączyć i nasza pomoc nie będzie już potrzebna. A więc mechanizm sygnalizacji, który musimy wdrożyć osobno, będzie użyty tylko po podłączeniu i nie będą używane podczas przesyłania danych wideo.

Przyjrzyjmy się więc pierwszej fazie, fazie konfiguracji połączenia. Składa się z kilku pozycji. Rozważ tę fazę najpierw dla węzła, który inicjuje połączenie, a następnie dla oczekującego.

• Inicjator (rozmówca - gość):
  1. Oferta rozpoczęcia transmisji danych wideo (createOffer)
  2. Zdobycie swojego SDP SDP)
  3. Zdobycie swojego Kandydat na lód Kandydat na lód)
• Połączenie oczekujące ( Callee):
  1. Pobranie lokalnego (własnego) strumienia mediów i ustawienie go do transmisji (getUserMediaStream)
  2. Otrzymaj ofertę rozpoczęcia transferu danych wideo i utwórz odpowiedź (createAnswer)
  3. Zdobycie swojego SDP obiekt i przepuszczenie go przez mechanizm sygnalizacyjny ( SDP)
  4. Zdobycie swojego Kandydat na lód obiektów i ich transmisji przez mechanizm sygnalizacyjny ( Kandydat na lód)
  5. Odbieranie zdalnego (obcego) strumienia multimediów i wyświetlanie go na ekranie (onAddStream)

Jedyna różnica dotyczy akapitu drugiego.

Pomimo pozornej złożoności kroków, tak naprawdę są trzy z nich: wysyłanie własnego strumienia mediów (s. 1), ustawianie parametrów połączenia (s. 2-4), odbieranie strumienia mediów innej osoby (s. 5). Najtrudniejszy jest krok drugi, ponieważ składa się z dwóch części: ustanowienia fizyczny oraz logiczny znajomości. Pierwszy wskazuje ścieżka, wzdłuż której muszą przejść pakiety, aby dostać się z jednego węzła sieci do drugiego. Drugi wskazuje parametry wideo/audio- jakiej jakości użyć, jakich kodeków użyć.

Mentalna scena tworzenie oferty lub utwórz odpowiedź powinny być połączone z etapami transferu SDP oraz Kandydat na lód przedmioty.

Podmioty podstawowe

Strumienie multimediów (MediaStream)

Głównym podmiotem jest strumień mediów, czyli strumień danych wideo i audio, obrazu i dźwięku. Istnieją dwa rodzaje strumieni mediów - lokalny i zdalny. Lokalny odbiera dane z urządzeń wejściowych (kamera, mikrofon), a zdalny przez sieć. W ten sposób każdy węzeł ma zarówno wątek lokalny, jak i zdalny. V WebRTC jest interfejs dla strumieni strumień mediów i jest też podinterfejs Lokalny strumień mediów specjalnie dla wątku lokalnego. V JavaScript możesz spotkać się tylko z pierwszym, a jeśli użyjesz dżingle libów, wtedy można spotkać również drugą.

V WebRTC w wątku istnieje dość zagmatwana hierarchia. Każdy strumień może składać się z kilku ścieżek multimedialnych ( ścieżka multimedialna), które z kolei może składać się z kilku kanałów medialnych ( MediaChannel). Może też istnieć kilka strumieni multimediów.

Rozważmy wszystko w porządku. Aby to zrobić, pamiętajmy o jakimś przykładzie. Załóżmy, że chcemy przekazać nie tylko wideo nas samych, ale także wideo naszego stołu, na którym leży kartka papieru, na której zamierzamy coś napisać. Będziemy potrzebować dwóch filmów (my + stół) i jednego audio (my). Oczywiste jest, że my i tabelę powinniśmy podzielić na różne wątki, ponieważ te dane są prawdopodobnie słabo od siebie zależne. Dlatego będziemy mieli dwa strumień mediów„a – jedna dla nas i jedna na stół. Pierwszy będzie zawierał zarówno dane wideo, jak i audio, a drugi tylko wideo (Rysunek 4).

Rysunek 4: Dwa różne strumienie mediów. Jeden dla nas, jeden dla naszego stołu

Od razu widać, że strumień multimediów musi przynajmniej zawierać zdolność do przechowywania danych różne rodzaje- wideo i audio. Jest to brane pod uwagę w technologii i dlatego każdy rodzaj danych jest implementowany przez ścieżkę medialną. ścieżka multimedialna. Ścieżka multimedialna ma specjalną właściwość uprzejmy, który określa, co jest przed nami - wideo czy audio (Rysunek 5)

Rysunek 5: Strumienie multimediów składają się ze ścieżek multimediów

Jak wszystko pójdzie w programie? Stworzymy dwa strumienie mediów. Następnie utworzymy dwie ścieżki wideo i jedną ścieżkę audio. Uzyskajmy dostęp do kamer i mikrofonu. Powiedzmy każdej ścieżce, którego urządzenia użyć. Dodajmy ścieżkę wideo i audio do pierwszego strumienia multimediów, a ścieżkę wideo z innej kamery do drugiego strumienia multimediów.

Ale jak odróżnić strumienie mediów na drugim końcu połączenia? Aby to zrobić, każdy strumień multimediów ma właściwość etykieta– etykieta strumienia, jej nazwa (Rysunek 6). Ścieżki multimedialne mają tę samą właściwość. Chociaż na pierwszy rzut oka wydaje się, że wideo można odróżnić od dźwięku na inne sposoby.

Rysunek 6: Strumienie i ścieżki multimediów są oznaczone etykietami

A zatem, jeśli ścieżki multimedialne można zidentyfikować za pomocą etykiety, to dlaczego w naszym przykładzie musimy używać dwóch strumieni multimediów zamiast jednego? W końcu możesz przesyłać jeden strumień multimediów i używać w nim różnych ścieżek. Doszliśmy do ważnej właściwości strumieni mediów - one synchronizowaćścieżki multimedialne. Różne strumienie multimediów nie są ze sobą zsynchronizowane, ale w każdym strumieniu multimediów wszystkie utwory grał w tym samym czasie.

Jeśli więc chcemy, aby nasze słowa, emocje na twarzy i kartka papieru były odtwarzane w tym samym czasie, warto skorzystać z jednego strumienia mediów. Jeśli nie jest to takie ważne, bardziej opłaca się korzystać z różnych strumieni - obraz będzie płynniejszy.

Jeśli utwór musi zostać wyłączony podczas transmisji, możesz skorzystać z właściwości włączonyścieżki multimedialne.

W końcu powinieneś pomyśleć o dźwięku stereo. Jak wiesz, dźwięk stereo to dwa inny dźwięk. A także trzeba je wysłać osobno. Służą do tego kanały. MediaChannel. Ścieżka multimedialna audio może mieć wiele kanałów (na przykład 6, jeśli potrzebujesz dźwięku 5+1). Na ścieżce medialnej, oczywiście także na kanałach zsynchronizowany. W przypadku wideo zwykle wykorzystywany jest tylko jeden kanał, ale można wykorzystać kilka, na przykład do nakładek reklamowych.

Podsumowując: używamy strumienia mediów do przesyłania danych wideo i audio. W każdym strumieniu mediów dane są synchronizowane. Możemy korzystać z wielu strumieni multimediów, jeśli nie potrzebujemy synchronizacji. W każdym strumieniu multimediów istnieją dwa rodzaje ścieżek multimedialnych - dla wideo i dla audio. Zwykle jest nie więcej niż dwa utwory, ale może być ich więcej, jeśli musisz przenieść kilka różnych filmów (rozmówcy i jego stołu). Każda ścieżka może składać się z kilku kanałów, które są zwykle używane tylko do dźwięku stereo.

W najprostszej sytuacji czatu wideo będziemy mieć jeden lokalny strumień mediów, który będzie składał się z dwóch ścieżek - ścieżki wideo i ścieżki audio, z których każda będzie składać się z jednego kanału głównego. Ścieżka wideo odpowiada za kamerę, ścieżka dźwiękowa za mikrofon, a strumień multimediów jest pojemnikiem obu.

Deskryptor sesji (SDP)

Na różne komputery zawsze będą różne kamery, mikrofony, karty graficzne i inny sprzęt. Istnieje wiele opcji, które mają. Wszystko to musi być skoordynowane w celu przesyłania danych multimedialnych między dwoma węzłami sieci. WebRTC robi to automatycznie i tworzy specjalny obiekt - uchwyt sesji SDP. Przekaż ten obiekt do innego węzła i możesz wysyłać dane multimedialne. Tylko że nie ma jeszcze połączenia z innym węzłem.

W tym celu wykorzystywany jest dowolny mechanizm sygnalizacyjny. SDP może być przesyłany nawet przez gniazda, nawet przez osobę (poinformuj o tym inny węzeł telefonicznie), nawet przez pocztę rosyjską. Wszystko jest bardzo proste - otrzymasz gotowy SDP i musi zostać wysłany. A po odbiorze po drugiej stronie - przenieś do wydziału WebRTC. Uchwyt sesji jest przechowywany jako tekst i możesz go zmienić w swoich aplikacjach, ale zwykle nie jest to konieczne. Na przykład podczas podłączania telefonu stacjonarnego czasami trzeba wymusić wybór żądanego kodeka audio.

Zwykle podczas nawiązywania połączenia musisz podać jakiś adres, na przykład URL. Nie ma takiej potrzeby, ponieważ sam wyślesz dane do miejsca docelowego za pośrednictwem mechanizmu sygnalizacyjnego. Wskazać WebRTC co chcemy zainstalować p2p połączenie musisz wywołać funkcję createOffer. Po wywołaniu tej funkcji i nadaniu jej specjalnego oddzwonić„będzie stworzony” SDP obiekt i przekazany do tego samego oddzwonić. Wystarczy, że przeniesiesz ten obiekt przez sieć do innego węzła (rozmówcy). Następnie, na drugim końcu, dane przejdą przez mechanizm sygnalizacyjny, a mianowicie ten SDP obiekt. Ten deskryptor sesji dla tego węzła jest obcy i dlatego zawiera przydatna informacja. Otrzymanie tego obiektu jest sygnałem do rozpoczęcia połączenia. Dlatego musisz się na to zgodzić i wywołać funkcję createAnswer. Jest to kompletny analog createOffer. Powrót do twojego oddzwonić przekaże lokalny deskryptor sesji i będzie musiał zostać przekazany z powrotem przez mechanizm sygnalizacji.

Warto zauważyć, że funkcję createAnswer można wywołać dopiero po otrzymaniu cudzej SDP obiekt. Czemu? Ponieważ lokalne SDP obiekt, który zostanie wygenerowany po wywołaniu metody createAnswer, musi polegać na zdalnym SDP obiekt. Tylko w tym przypadku możliwe jest skoordynowanie ustawień wideo z ustawieniami rozmówcy. Nie wywołuj także createAnswer i createOffer, dopóki nie zostanie odebrany lokalny strumień multimediów - nie będą mieli do czego pisać SDP obiekt .

Ponieważ w WebRTC można edytować SDP obiekt, to po uzyskaniu lokalnego dojścia należy go ustawić. Przejście może wydawać się trochę dziwne WebRTC co sama nam dała, ale taki jest protokół. Po otrzymaniu pilota należy go również ustawić. Dlatego musisz zainstalować dwa deskryptory na jednym węźle - własny i cudzy (czyli lokalny i zdalny).

Po takim uściski dłoni węzły wiedzą o swoich życzeniach. Na przykład, jeśli węzeł 1 obsługuje kodeki A oraz b, a węzeł 2 obsługuje kodeki b oraz C, to ponieważ każdy węzeł zna deskryptory własne i innego, oba węzły wybiorą kodek b(Rysunek 7). Logika połączenia jest już ustanowiona i strumienie mediów mogą być przesyłane, ale jest jeszcze jeden problem - węzły są nadal połączone tylko mechanizmem sygnalizacyjnym.

Rysunek 7: Negocjacja kodeka

Kandydaci (kandydat lodowy)

Technologia WebRTC próbując zmylić nas swoją nową metodologią. Podczas nawiązywania połączenia nie jest określony adres węzła, z którym chcesz się połączyć. Zainstalowany jako pierwszy logiczny połączenie, nie fizyczny, chociaż zawsze robiono coś przeciwnego. Ale nie będzie to wydawać się dziwne, jeśli nie zapomnimy, że korzystamy z mechanizmu sygnalizacji innej firmy.

Czyli połączenie zostało już nawiązane (połączenie logiczne), ale nie ma jeszcze możliwości przesyłania danych przez węzły sieci. To nie jest takie proste, ale zacznijmy prosto. Niech węzły będą w tej samej sieci prywatnej. Jak już wiemy, mogą łatwo łączyć się ze sobą poprzez swoje wewnętrzne IP adresy (a może jakieś inne, jeśli nie są używane) TCP/IP).

Przez niektórych oddzwonić'oraz WebRTC Powiedz nam Kandydat na lód przedmioty. Występują również w formie tekstowej i podobnie jak deskryptory sesji, wystarczy je przesłać przez mechanizm sygnalizacyjny. Jeżeli deskryptor sesji zawierał informacje o naszych ustawieniach na poziomie kamery i mikrofonu, to kandydaci zawierają informacje o naszej lokalizacji w sieci. Przekaż je do innego węzła, a on będzie mógł się z nami fizycznie połączyć, a skoro ma już deskryptor sesji, może logicznie się połączyć i dane popłyną. Jeśli nie zapomni przesłać nam swojego obiektu kandydującego, czyli informacji o tym, gdzie się znajduje w sieci, wtedy będziemy mogli się z nim połączyć. Zauważamy tutaj jeszcze jedną różnicę w stosunku do klasycznej interakcji klient-serwer. Komunikacja z serwerem HTTP odbywa się według schematu żądanie-odpowiedź, klient przesyła dane do serwera, który je przetwarza i przesyła za pośrednictwem adres podany w pakiecie żądania. V WebRTC potrzebuję wiedzieć dwa adresy i połącz je po obu stronach.

Różnica w stosunku do uchwytów sesji polega na tym, że należy ustawić tylko kandydatów zdalnych. Edycja jest tutaj zabroniona i nie może przynieść żadnych korzyści. W niektórych realizacjach WebRTC kandydatów należy ustawić dopiero po ustawieniu uchwytów sesji.

I dlaczego był tylko jeden deskryptor sesji, a kandydatów może być wielu? Ponieważ lokalizację w sieci można określić nie tylko jej wewnętrzną IP adres, ale także zewnętrzny adres routera, niekoniecznie jeden, a także adresy SKRĘCAĆ serwery. Pozostała część akapitu zostanie poświęcona szczegółowemu omówieniu kandydatów i sposobu łączenia węzłów z różnych sieci prywatnych.

Tak więc dwa węzły znajdują się w tej samej sieci (rysunek 8). Jak je zidentyfikować? Przez IP adresy. Żaden inny sposób. To prawda, że ​​nadal możesz korzystać z różnych transportów ( TCP oraz UDP) i różne porty. To są informacje zawarte w obiekcie kandydującym - IP, PORT, TRANSPORT i kilka innych. Niech na przykład użyj UDP transport i 531 Port.

Rysunek 8: Dwa węzły znajdują się w tej samej sieci

Wtedy jeśli jesteśmy w węźle p1, następnie WebRTC da nam taki kandydat na przedmiot - . To nie jest dokładny format, a jedynie diagram. Jeśli jesteśmy w suple p2, wtedy kandydatem jest . Poprzez mechanizm sygnalizacyjny p1 otrzyma kandydata p2(tj. lokalizacja węzła p2, a mianowicie jego IP oraz PORT). Następnie p1 może połączyć się z p2 bezpośrednio. Bardziej poprawne, p1 wyśle ​​dane na adres 10.50.150.3:531 w nadziei, że dotrą p2. Nie ma znaczenia, czy ten adres należy do węzła p2 lub jakiś pośrednik. Ważne jest tylko to, że dane będą przesyłane przez ten adres i mogą dotrzeć p2.

Dopóki węzły znajdują się w tej samej sieci - wszystko jest proste i łatwe - każdy węzeł ma tylko jeden kandydujący obiekt (zawsze oznaczający swój własny, czyli jego lokalizację w sieci). Ale kandydatów będzie znacznie więcej, gdy węzły będą w inny; różny sieci.

Przejdźmy do bardziej skomplikowanego przypadku. Jeden węzeł będzie za routerem (dokładniej za NAT), a drugi węzeł będzie w tej samej sieci z tym routerem (na przykład w Internecie) (Rysunek 9).

Rysunek 9: Jeden host za NAT, inny nie

Ta sprawa ma szczególne rozwiązanie problemu, który teraz rozważamy. Domowy router zwykle zawiera stół NAT. Jest to specjalny mechanizm zaprojektowany, aby umożliwić węzłom w prywatnej sieci routera dostęp na przykład do stron internetowych.

Załóżmy, że serwer WWW jest bezpośrednio podłączony do Internetu, czyli ma public IP* adres. Niech to będzie węzeł p2. Węzeł p1(klient webowy) wysyła zapytanie na adres 10.50.200.10 . Najpierw dane trafiają do routera r1, a raczej na jego wnętrze berło 192.168.0.1 . Następnie router zapamiętuje adres źródłowy (adres p1) i umieszcza go w specjalny stół NAT, następnie zmienia adres źródłowy na własny ( p1 → r1). Ponadto, zgodnie z zewnętrzny interfejs, router wysyła dane bezpośrednio do serwera WWW p2. Serwer WWW przetwarza dane, generuje odpowiedź i odsyła ją z powrotem. Wysyła do routera r1, ponieważ to on jest w adresie zwrotnym (router zmienił adres na własny). Router odbiera dane, patrzy na tabelę NAT i wysyła dane do węzła p1. Router pełni tutaj rolę pośrednika.

Ale co, jeśli kilka węzłów z sieci wewnętrznej jednocześnie uzyskuje dostęp do sieci zewnętrznej? W jaki sposób router zrozumie, do kogo odesłać odpowiedź? Ten problem został rozwiązany za pomocą porty. Gdy router zastępuje adres hosta własnym, zastępuje również port. Jeśli dwa węzły mają dostęp do Internetu, router zastępuje ich porty źródłowe: inny; różny. Następnie, gdy pakiet z serwera WWW wróci do routera, router rozpozna port, do którego ten pakiet jest przypisany. Przykład znajduje się poniżej.

Powrót do technologii WebRTC, a raczej do jego części, która używa LÓD protokół (stąd lód kandydatów). Węzeł p2 ma jednego kandydata (jego lokalizacja w sieci - 10.50.200.10 ) i węzeł p1, który znajduje się za routerem z NAT, będzie miał dwóch kandydatów - lokalny ( 192.168.0.200 ) i kandydata na router ( 10.50.200.5 ). Pierwsza z nich nie jest przydatna, ale mimo to jest generowana, ponieważ WebRTC nie wie jeszcze nic o zdalnym hoście — może, ale nie musi, znajdować się w tej samej sieci. Przyda się drugi kandydat, a jak już wiemy port będzie odgrywał ważną rolę (przebicie się NAT).

Wpis tabeli NAT generowane tylko wtedy, gdy dane wychodzą z sieci wewnętrznej. Dlatego węzeł p1 musi najpierw przesłać dane, a dopiero potem dane węzła p2 może dostać się do węzła p1.

Na praktyce oba węzły będzie w tyle NAT. Aby utworzyć wpis w tabeli NAT z każdym routerem węzły muszą coś wysłać do zdalnego węzła, ale tym razem ani pierwszy nie może dotrzeć do drugiego, ani odwrotnie. Wynika to z faktu, że węzły nie znają swoich zewnętrznych IP adresy, a wysyłanie danych na adresy wewnętrzne jest bez znaczenia.

Jeśli jednak znane są adresy zewnętrzne, połączenie będzie można łatwo nawiązać. Jeśli pierwszy węzeł wysyła dane do routera drugiego węzła, router je zignoruje, ponieważ jego tabela NAT gdy jest pusty. Jednak w routerze pierwszego węzła w tabeli NAT istniała potrzeba nagrania. Jeśli teraz drugi węzeł wyśle ​​dane do routera pierwszego węzła, router pomyślnie prześle je do pierwszego węzła. Teraz stół NAT drugi router ma potrzebne dane.

Problem polega na tym, że aby poznać swoje zewnętrzne IP adres, potrzebujesz węzła zlokalizowanego w wspólna sieć. Aby rozwiązać ten problem, używane są dodatkowe serwery, które są bezpośrednio połączone z Internetem. Z ich pomocą tworzone są również cenne rekordy w tabeli. NAT.

Serwery STUN i TURN

Przy inicjalizacji WebRTC dostępny OSZOŁOMIĆ oraz SKRĘCAĆ serwery, które będziemy określać jako LÓD serwery. Jeśli serwery nie są określone, to tylko węzły w tej samej sieci (podłączone do niej bez NAT). Należy od razu zauważyć, że dla 3g-sieci muszą być używane SKRĘCAĆ serwery.

OSZOŁOMIĆ serwer to po prostu serwer w Internecie, który zwraca adres zwrotny, czyli adres hosta nadawcy. Węzeł za routerem uzyskuje dostęp OSZOŁOMIĆ serwer do przejścia NAT. Pakiet, który przyszedł do OSZOŁOMIĆ server, zawiera adres źródłowy - adres routera, czyli zewnętrzny adres naszego węzła. Ten adres OSZOŁOMIĆ serwer i odsyła. W ten sposób węzeł otrzymuje swoją zewnętrzną IP adres i port, przez który jest dostępny z sieci. Dalej, WebRTC użycie tego adresu tworzy dodatkowego kandydata (adres i port routera zewnętrznego). Teraz w tabeli NAT router ma wpis, który przekazuje pakiety wysyłane do routera na wymaganym porcie do naszego węzła.

Spójrzmy na ten proces na przykładzie.

Przykład (działanie serwera STUN)

OSZOŁOMIĆ serwer będzie oznaczony przez s1. Router, jak poprzednio, przez r1, a węzeł przez p1. Będziesz także musiał postępować zgodnie z tabelą NAT- oznaczmy to jako r1_nat. Ponadto tabela ta zwykle zawiera wiele wpisów z różnych węzłów podsieci - nie zostaną one podane.

Czyli na początku mamy pusty stolik r1_nat.

Tabela 2: Nagłówek pakietu

Węzeł p1 wysyła ten pakiet do routera r1(niezależnie od tego, różne technologie mogą być używane w różnych podsieciach). Router musi dokonać zamiany adresu źródłowego src IP, ponieważ adres podany w pakiecie z pewnością nie jest odpowiedni dla podsieci zewnętrznej, ponadto adresy z tego zakresu są zarezerwowane, a żaden adres w Internecie nie ma takiego adresu. Router dokonuje podstawienia w pakiecie i tworzy nowy rekord w twoim stole r1_nat. Aby to zrobić, musi wymyślić numer portu. Przypomnijmy, że skoro kilka węzłów w podsieci może uzyskać dostęp do sieci zewnętrznej, to w tabeli NAT muszą być przechowywane dodatkowe informacje, aby router mógł określić, dla którego z tych kilku hostów jest przeznaczony pakiet zwracany z serwera. Niech router wymyśli port 888 .

Zmieniony nagłówek pakietu:

Tabela 4: Tabela NAT zaktualizowana o nowy wpis

Tutaj IP adres i port podsieci są dokładnie takie same jak w oryginalnym pakiecie. Rzeczywiście, podczas ogłaszania zwrotnego musimy mieć sposób na ich całkowite przywrócenie. IP adres dla sieci zewnętrznej to adres routera, a port zmienił się na wymyślony przez router.

Prawdziwy port, do którego węzeł p1 akceptuje połączenie - to oczywiście 35777 , ale serwer wysyła dane do fikcyjny Port 888 , który zostanie zmieniony przez router na rzeczywisty 35777 .

Tak więc router zmienił adres źródłowy i port w nagłówku pakietu i dodał wpis do tabeli NAT. Teraz pakiet jest wysyłany przez sieć do serwera, czyli węzła s1. przy wejściu, s1 ma ten pakiet:

Tabela 5: Serwer STUN odebrał pakiet

Całkowity OSZOŁOMIĆ serwer wie, że otrzymał pakiet z adresu 10.50.200.5:888 . Teraz serwer odsyła ten adres z powrotem. Warto się tu zatrzymać i wrócić do tego, co właśnie rozważyliśmy. Powyższe tabele są częścią nagłówek pakiet, wcale nie z niego zawartość. Nie rozmawialiśmy o treści, bo to nie jest takie ważne - jest to jakoś opisane w protokole OSZOŁOMIĆ. Teraz oprócz tytułu rozważymy także treść. Będzie prosty i będzie zawierał adres routera - 10.50.200.5:888 chociaż wzięliśmy to z nagłówek pakiet. Nie jest to często robione, zwykle protokoły nie dbają o informacje o adresach węzłów, ważne jest tylko, aby pakiety były dostarczane do miejsca przeznaczenia. Rozważamy tutaj protokół, który ustanawia ścieżkę między dwoma węzłami.

Więc teraz mamy drugą partię idącą w przeciwnym kierunku:

Tabela 7: Serwer STUN wysyła pakiet z tą zawartością

Następnie pakiet przechodzi przez sieć, aż dotrze do interfejs zewnętrzny router r1. Router rozumie, że pakiet nie jest przeznaczony dla niego. Jak on to rozumie? Można to znaleźć tylko przy porcie. Port 888 nie używa do celów osobistych, ale używa do mechanizmu NAT. Dlatego router zagląda do tej tabeli. Patrzy na kolumnę PORT ZEWNĘTRZNY i szuka pasującego ciągu PORT DOCELOWY z paczki przychodzącej, czyli 888 .

Tabela 8: Tabela NAT

Mamy szczęście, że taka linia istnieje. Gdyby nie miał szczęścia, pakiet zostałby po prostu odrzucony. Teraz musisz zrozumieć, który z węzłów podsieci powinien wysłać ten pakiet. Nie spieszmy się, podsumujmy znaczenie portów w tym mechanizmie. Jednocześnie dwa węzły w podsieci mogą wysyłać żądania do sieci zewnętrznej. Następnie, jeśli dla pierwszego węzła router wymyślił port 888 , potem przez sekundę wymyślał port 889 . Załóżmy, że tak się stało, czyli stół r1_nat na to wygląda:

Tabela 10: Adres odbiorcy fałszowania routera

Tabela 11: Router zmienił adres odbiorcy

Pakiet pomyślnie dociera do węzła p1 a patrząc na zawartość pakietu, węzeł dowiaduje się o jego zewnętrznym IP adres, czyli adres routera w sieci zewnętrznej. Zna również port, przez który przechodzi router NAT.

Co dalej? Jaki jest pożytek z tego wszystkiego? Korzyścią jest wpis w tabeli r1_nat. Jeśli teraz ktoś wyśle ​​do routera r1 pakiet portowy 888 , router przekaże ten pakiet do hosta p1. W ten sposób utworzono małe wąskie przejście do ukrytego węzła p1.

Z powyższego przykładu możesz zorientować się, jak to działa. NAT i esencja OSZOŁOMIĆ serwer. Ogólnie mechanizm LÓD oraz OGŁUSZENIE/OBROT serwery mają na celu tylko pokonanie ograniczeń NAT.

Między węzłem a serwerem może być więcej niż jeden router, ale kilka. W takim przypadku węzeł otrzyma adres routera, który jako pierwszy wejdzie do tej samej sieci co serwer. Innymi słowy, otrzymujemy adres routera podłączonego do OSZOŁOMIĆ serwer. Do p2p komunikacja jest właśnie tym, czego potrzebujemy, jeśli nie zapomnimy o tym, że w każdym routerze potrzebna nam linia zostanie dodana do tabeli NAT. Więc droga powrotna znów będzie równie gładka.

SKRĘCAĆ serwer jest ulepszony OSZOŁOMIĆ serwer. Z tego wynika od razu, że każdy SKRĘCAĆ serwer może działać i jak OSZOŁOMIĆ serwer. Jednak są też korzyści. Jeśli p2p komunikacja nie jest możliwa (jak w 3g sieci), serwer przełącza się w tryb repeatera ( przekaźnik), czyli działa jako pośrednik. Oczywiście o każdym p2p to nie jest pytanie, ale poza ramami mechanizmu LÓD węzły myślą, że komunikują się bezpośrednio.

W jakich przypadkach jest to konieczne SKRĘCAĆ serwer? Dlaczego nie wystarczy? OSZOŁOMIĆ serwery? Faktem jest, że istnieje kilka rodzajów NAT. Zastępują to samo IP adres i port, ale niektóre z nich mają wbudowane dodatkowa ochrona od „fałszowania”. Na przykład w symetryczny Tabela NAT Zapisano jeszcze 2 parametry - IP i port zdalnego hosta. Przechodzi pakiet z sieci zewnętrznej NAT do sieci wewnętrznej tylko wtedy, gdy adres źródłowy i port są zgodne z zapisanymi w tabeli. Dlatego nacisk OSZOŁOMIĆ serwer nie działa - tabela NAT przechowuje adres i port OSZOŁOMIĆ serwer i kiedy router otrzyma pakiet z WebRTC rozmówca, odrzuca go, ponieważ jest „sfałszowany”. Nie pochodził z OSZOŁOMIĆ serwer.

W ten sposób SKRĘCAĆ serwer jest potrzebny, gdy obaj rozmówcy są z tyłu symetryczny NAT(każdy dla siebie).

Krótkie podsumowanie

Oto kilka stwierdzeń dotyczących podmiotów WebRTC o czym zawsze należy pamiętać. Zostały one szczegółowo opisane powyżej. Jeśli którekolwiek ze stwierdzeń nie wydaje Ci się całkowicie jasne, przeczytaj ponownie odpowiednie akapity.

• strumień mediów
  • Dane wideo i audio są pakowane w strumienie multimediów
  • Strumienie multimediów synchronizują ścieżki multimediów, które tworzą
  • Różne strumienie multimediów nie są zsynchronizowane
  • Strumienie mediów mogą być lokalne i zdalne, kamera i mikrofon są zwykle podłączone do lokalnego, zdalne odbierają dane z sieci w postaci zaszyfrowanej
  • Istnieją dwa rodzaje ścieżek multimedialnych - dla wideo i dla audio.
  • Ścieżki multimedialne mają możliwość włączania/wyłączania
  • Ścieżki medialne składają się z kanałów medialnych
  • Ścieżki multimedialne synchronizują kanały multimedialne, które tworzą
  • Strumienie multimediów i ścieżki multimediów mają etykiety, dzięki którym można je rozróżnić
• Uchwyt sesji
  • Deskryptor sesji służy do logicznego połączenia dwóch węzłów sieci
  • Deskryptor sesji przechowuje informacje o dostępne sposoby kodowanie danych wideo i audio
  • WebRTC wykorzystuje zewnętrzny mechanizm sygnalizacji - zadanie przekazywania deskryptorów sesji ( sdp) przypada na wniosek
  • Mechanizm logicznego połączenia składa się z dwóch etapów - propozycji ( oferta) i odpowiedź ( odpowiedź)
  • Generowanie deskryptora sesji nie jest możliwe bez wykorzystania lokalnego strumienia mediów w przypadku oferty ( oferta) i nie jest możliwe bez użycia zdalnego deskryptora sesji w przypadku odpowiedzi ( odpowiedź)
  • Otrzymany deskryptor należy podać implementacji WebRTC i nie ma znaczenia, czy ten uchwyt jest uzyskiwany zdalnie, czy lokalnie z tej samej implementacji WebRTC
  • Istnieje możliwość nieznacznej edycji deskryptora sesji
• Kandydaci
  • Kandydat ( Kandydat na lód) to adres węzła w sieci
  • Adres węzła może być Twój, może to być adres routera lub SKRĘCAĆ serwery
  • Kandydatów zawsze jest dużo
  • Kandydat składa się z IP adres, port i rodzaj transportu ( TCP lub UDP)
  • Kandydaci służą do ustalenia fizyczne połączenie dwa węzły w sieci
  • Kandydaci również muszą zostać wysłani przez mechanizm sygnalizacyjny
  • Kandydaci również muszą przejść wdrożenia WebRTC, ale tylko zdalny
  • W niektórych realizacjach WebRTC Kandydatów można zaliczyć dopiero po ustaleniu deskryptora sesji
• OGŁUSZENIE/TURN/LÓD/NAT
  • NAT– mechanizm zapewniający dostęp do sieci zewnętrznej
  • Routery domowe obsługują specjalny stół NAT
  • Router zastępuje adresy w pakietach - adres źródłowy własnym, jeśli pakiet trafia do sieci zewnętrznej, a adres docelowy adresem hosta w sieci wewnętrznej, jeśli pakiet pochodzi z sieci zewnętrznej
  • Aby zapewnić wielokanałowy dostęp do sieci zewnętrznej NAT używa portów
  • LÓD- mechanizm obejściowy NAT
  • OSZOŁOMIĆ oraz SKRĘCAĆ serwery - serwery pomocnicze do omijania NAT
  • OSZOŁOMIĆ serwer umożliwia tworzenie niezbędnych wpisów w tabeli NAT, a także zwraca zewnętrzny adres węzła
  • SKRĘCAĆ serwer generalizuje OSZOŁOMIĆ mechanizm i sprawia, że ​​zawsze działa
  • W najgorszych przypadkach SKRĘCAĆ serwer pełni rolę pośrednika ( przekaźnik), to jest p2p zamienia się w połączenie klient-serwer-klient.

Witajcie przyjaciele, jak już wiecie, regularnie aktualizujemy was o nowe technologie, dzisiaj przedstawię WebRTC, technologię opracowaną przez Google, która pozwala użytkownikom rozmawiać bezpośrednio w przeglądarce wideo i audio bez konieczności korzystania z wtyczek- Strony internetowe lub aplikacje . Bezpośrednie połączenie wideo i audio między użytkownikami odbywa się bezpośrednio w przeglądarce.
Technologia WebRTC jest obsługiwana w Mozilla Firefox Przeglądarki Google Chrome i dowolne system operacyjny, Opera wkrótce dołączy.
Co to jest WebRTC i co?
WebRTC to skrót od Web Real Time Communication, technologia ta umożliwia otwieranie rozmów audio i wideo bezpośrednio w przeglądarce bez potrzeby korzystania z innych wtyczek, aplikacji lub usług w Internecie. Połączenie jest nawiązywane bezpośrednio z przeglądarki do przeglądarki.
Tam, gdzie znane usługi (Skype, Yahoo Messenger, Apple FaceTime, Google Hago itp.) wymagają serwera, który łączy użytkowników w celu inicjowania ruchu i zarządzania nim. Korzystając z tych usług musimy się zarejestrować i założyć listę klientów i kontaktów.
Dzięki WebRTC nie potrzebujemy serwerów, aplikacji ani serwerów, które łączą się w celu interweniowania.
Zalety WebRTC:
1. Nigdy więcej aplikacji zużywających zasoby i zużycie baterii.
2. Czaty są bardziej prywatne (stosunkowo).
3. Kontakt można nawiązać lokalnie, a nie na serwerach Flos US w przypadku połączeń lokalnych.
4. Prostota, łatwość użytkowania.
5. Możliwość dalszego rozwoju iw innych kierunkach.
6. Komunikacja jest stabilna i nie zależy od zewnętrznych połączeń, które czasami są wyjątkowo niestabilne.
W tutorialu wykorzystałem demo, które opracowali ludzie z Google, to demo jest dość proste, bardziej zaawansowane funkcje i szybsze połączenia mogą korzystać z jednej z aplikacji obsługujących WebRTC, są łatwiejsze w użyciu. Wkrótce zrobimy również samouczek dotyczący aplikacji WebRTC.
Jak korzystać z wersji demonstracyjnej WebRTC?
Po prostu kliknij poniższy link, automatycznie generuje czat. aby połączyć ten pokój, musisz wysłać przyjaciela / dziewczynę, z którą chcesz się skontaktować.
Przyjaciel/dziewczyna i twoja, ale powinieneś używać tylko najbardziej najnowsze wersje Mozilla Firefox lub Google Chrome.

Demo WebRTC(Wprowadzenie do czatu audio - wideo)

Uwaga:
Demo nie jest zbyt stabilne, zostało stworzone wyłącznie w celach demonstracyjnych. Może być używany przez ograniczony czas, podczas którego mogą wystąpić drobne błędy połączenia.
Jeśli masz problemy z łącznością, spróbuj utworzyć inny czat.

WebRTC(Web Real-Time Communications) to technologia, która umożliwia aplikacjom internetowym i witrynom internetowym przechwytywanie i selektywne przesyłanie strumieni multimedialnych audio i/lub wideo, a także wymianę dowolnych danych między przeglądarkami, bez konieczności korzystania z pośredników. Zestaw standardów, który obejmuje technologia WebRTC, umożliwia wymianę danych i telekonferencje peer-to-peer bez konieczności instalowania przez użytkownika wtyczek lub innego oprogramowania firm trzecich.

WebRTC składa się z kilku powiązanych ze sobą interfejsów programistycznych (API) i protokołów, które ze sobą współpracują. Dokumentacja, którą znajdziesz tutaj, pomoże Ci zrozumieć podstawy WebRTC, jak skonfigurować i używać połączenia danych i multimediów i nie tylko.

Zgodność

Ponieważ implementacje WebRTC są w przygotowaniu, a każda przeglądarka ma funkcję WebRTC, przed rozpoczęciem pracy nad kodem zdecydowanie zalecamy skorzystanie z biblioteki Adapter.js polyfill od Google.

Adapter.js wykorzystuje wedges i polyfills, aby bezproblemowo niwelować różnice w implementacjach WebRTC w kontekstach, które go obsługują. Adapter.js obsługuje również przedrostki dostawców i inne różnice w nazewnictwie właściwości, ułatwiając proces tworzenia WebRTC z najbardziej spójnym rezultatem. Biblioteka jest również dostępna jako pakiet NPM.

Aby uzyskać więcej informacji na temat biblioteki Adapter.js, zobacz .

Koncepcje i wykorzystanie WebRTC

WebRTC jest wszechstronny i wraz z , zapewnia potężne możliwości multimedialne w Internecie, w tym obsługę konferencji audio i wideo, udostępnianie plików, przechwytywanie ekranu, zarządzanie tożsamością i współdziałanie ze starszymi systemami telefonicznymi, w tym obsługę wybierania tonowego DTMF. Połączenia między węzłami można tworzyć bez użycia specjalnych sterowników lub wtyczek, a często bez usług pośrednich.

Połączenie między dwoma węzłami jest reprezentowane jako obiekt interfejsu RTCPeerConnection. Po ustanowieniu i otwarciu połączenia przy użyciu obiektu RTCPeerConnection można dodać do połączenia strumienie mediów (MediaStream) i/lub kanały danych (RTCDataChannel).

Strumienie multimediów mogą składać się z dowolnej liczby ścieżek (ścieżek) informacji multimedialnych. Ścieżki te, reprezentowane przez obiekty interfejsu MediaStreamTrack, mogą zawierać jeden lub więcej typów multimediów, w tym audio, wideo, tekst (na przykład napisy lub tytuły rozdziałów). Większość strumieni składa się z co najmniej jednej ścieżki dźwiękowej (jednej ścieżki dźwiękowej) lub ścieżki wideo i można je wysyłać i odbierać jako strumienie (media czasu rzeczywistego) lub zapisywać w pliku.

Możesz także użyć połączenia między dwoma węzłami do wymiany dowolnych danych za pomocą obiektu interfejsu RTCDataChannel, który może być użyty do przesyłania informacje serwisowe, dane giełdowe, pakiety statusu gier, transfery plików lub prywatne kanały danych.

potrzebne są dodatkowe szczegóły i linki do odpowiednich przewodników i samouczków

Interfejsy WebRTC

Ponieważ WebRTC zapewnia interfejsy, które współpracują ze sobą, aby działać różne zadania podzieliliśmy je na kategorie. Widzieć indeks alfabetyczny pasek boczny do szybkiej nawigacji.

Konfiguracja i zarządzanie połączeniem

Te interfejsy służą do konfigurowania, otwierania i zarządzania połączeniami WebRTC. Reprezentują one połączenia medialne peer-to-peer, kanały danych i interfejsy używane do wymiany informacji o możliwościach każdego węzła w celu wybrania najlepszej konfiguracji podczas ustanawiania dwukierunkowego połączenia multimedialnego.

Przewodniki

WebRTC jest obecnie popularną technologią dla strumieniowe przesyłanie dźwięku i wideo w przeglądarkach. Konserwatywne technologie, takie jak HTTP Streaming i Flash, są bardziej odpowiednie do dystrybucji zarejestrowanych treści (wideo na żądanie) i znacznie ustępują WebRTC pod względem transmisji w czasie rzeczywistym i online, tj. gdzie wymagane jest minimalne opóźnienie wideo, dzięki czemu widzowie mogą zobaczyć, co dzieje się „na żywo”.

Możliwość wysokiej jakości komunikacji w czasie rzeczywistym pochodzi z samej architektury WebRTC, w której do przesyłania strumieni wideo wykorzystywany jest protokół UDP, który jest standardową podstawą przesyłania wideo z minimalnymi opóźnieniami i jest szeroko stosowany w systemach komunikacji czasu rzeczywistego.

Opóźnienie komunikacji jest ważne w systemach strumieniowania na żywo, webinarach i innych aplikacjach, w których wymagana jest interaktywna komunikacja ze źródłem wideo, użytkownikami końcowymi i rozwiązaniem.

Kolejnym dobrym powodem do wypróbowania WebRTC jest zdecydowanie trend. Każdy Android dzisiaj Przeglądarka Chrome obsługuje tę technologię, dzięki czemu miliony urządzeń są gotowe do oglądania transmisji bez konieczności instalowania dodatkowego oprogramowania i konfiguracji.

Aby przetestować technologię WebRTC w działaniu i uruchomić na niej prostą transmisję online, wykorzystaliśmy oprogramowanie serwerowe Flashphoner WebRTC Media & Broadcasting Server. Funkcje deklarują możliwość nadawania strumieni WebRTC w trybie jeden-do-wielu, a także obsługę kamer IP i systemów nadzoru wideo za pośrednictwem protokołu RTSP; w tej recenzji skupimy się na transmisjach internetowych i ich funkcjach.

Instalowanie serwera mediów i transmisji WebRTC

Ponieważ Systemy Windows nie było wersji serwerowej, a nie chciałem instalować maszyny wirtualnej jak VMWare + Linux, testować transmisje online na Strona główna Windows komputer uległ awarii. Aby zaoszczędzić czas, zdecydowaliśmy się na taką instancję na hostingu w chmurze:

Był to Centos x86_64 w wersji 6.5 bez żadnego preinstalowanego oprogramowania w centrum danych w Amsterdamie. Zatem wszystko, co mamy do dyspozycji, to serwer i dostęp do niego przez ssh. Dla osób zaznajomionych z konsolą Polecenia Linuksa, instalacja serwera WebRTC zapowiada się na prostą i bezbolesną. Więc co zrobiliśmy:

1. Pobierz archiwum:

$wget https://website/download-wcs5-server.tar.gz

2. Rozpakować:

$tar -xzf download-wcs5-server.tar.gz

3. Zainstalować:

$cd FlashphonerSerwer połączeń internetowych

Podczas instalacji wprowadź adres IP serwera: XXX.XXX.XXX.XXX

4. Aktywuj licencję:

$cd /usr/local/FlashphonerWebCallServer/bin

$./aktywacja.sh

5. Uruchom serwer WCS:

$service webcallserver start

6. Sprawdź dziennik:

$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Sprawdź, czy istnieją dwa procesy:

$ps aux | grep Flashphoner

Proces instalacji został zakończony.

Testowanie transmisji na żywo WebRTC

Testowanie transmisji okazało się prostą sprawą. Oprócz serwera istnieje klient sieciowy, który składa się z kilkunastu Javascript, HTML i pliki CSS i został przez nas wdrożony do folderu /var/www/html podczas fazy instalacji. Jedyne, co trzeba było zrobić, to wpisać adres IP serwera do konfiguracji flashphoner.xml, aby klient sieciowy mógł nawiązać połączenie z serwerem za pośrednictwem gniazd sieciowych HTML5. Opiszmy proces testowania.

1. Otwórz stronę index.html klienta testowego w przeglądarce Chrome:

2. Aby rozpocząć nadawanie, musisz kliknąć przycisk „Start” na środku ekranu.
Zanim to zrobisz, upewnij się, że kamera internetowa jest podłączona i gotowa do pracy. Nie ma specjalnych wymagań co do kamery internetowej, np. zastosowaliśmy standardową wbudowaną kamerę do laptopa o rozdzielczości 1280×800.

Przeglądarka Chrome na pewno poprosi o dostęp do kamery i mikrofonu, aby użytkownik zrozumiał, że jego film zostanie przesłany na serwer internetowy i mu na to pozwoli.

3. Interfejs reprezentuje pomyślną transmisję strumienia wideo z kamery do serwera WebRTC. W prawym górnym rogu wskaźnik wskazuje, że strumień trafia na serwer, w dolnym rogu znajduje się przycisk „Stop”, aby zatrzymać wysyłanie wideo.

Spójrz na poniższy link. Zawiera unikalny identyfikator tego strumienia, więc każdy może dołączyć do widoku. Po prostu otwórz ten link w przeglądarce. Aby skopiować go do schowka, musisz kliknąć przycisk „Kopiuj”.

W rzeczywistych aplikacjach, takich jak webinaria, wykłady, transmisje wideo online lub telewizja interaktywna, programiści będą musieli wdrożyć dystrybucję tego identyfikatora do określonych grup widzów, aby mogli połączyć się z żądanymi strumieniami, ale taka jest logika aplikacji. Serwer mediów i transmisji WebRTC nie ma to wpływu, a jedynie zajmuje się dystrybucją wideo.

5. Połączenie zostaje nawiązane, a widz widzi strumień na ekranie. Teraz może wysłać link do kogoś innego, zatrzymać odtwarzanie strumienia lub włączyć tryb pełnoekranowy za pomocą elementów sterujących w prawym dolnym rogu.

Wyniki testów serwera WebRTC dla transmisji online

Podczas testów latencja wydawała się idealna. Ping do centrum danych wynosił około 100 milisekund, a opóźnienie nie było widoczne dla oka. Stąd możemy założyć, że rzeczywiste opóźnienie jest takie samo 100 plus minus kilkadziesiąt milisekund dla czasu buforowania. W porównaniu do wideo Flash, Flash nie działa tak dobrze jak WebRTC w tych testach. Jeśli więc poruszasz ręką w podobnej sieci, ruch na ekranie widać dopiero po jednej/dwóch sekundach.

Jeśli chodzi o jakość, zauważamy, że czasami można odróżnić kostki na ruchach. Jest to zgodne z naturą kodeka VP8, a jego głównym celem jest zapewnienie komunikacji wideo w czasie rzeczywistym o akceptowalnej jakości i bez opóźnień w komunikacji.

Serwer jest dość łatwy w instalacji i konfiguracji, nie wymaga żadnych poważnych umiejętności, aby go uruchomić, poza znajomością Linuksa na poziomie zaawansowanego użytkownika, który może wykonywać polecenia z konsoli przez ssh i używać Edytor tekstu. W rezultacie udało nam się skonfigurować transmisję jeden-do-wielu online między przeglądarkami. Podłączenie dodatkowych widzów do streamu również nie sprawiało problemów.

Jakość transmisji okazała się całkiem akceptowalna w przypadku webinariów i transmisji internetowych. Jedyne, co spowodowało kilka pytań, to rozdzielczość wideo. Kamera obsługuje 1280x800, ale rozdzielczość na zdjęciu testowym jest bardzo zbliżona do 640x480. Najwyraźniej ten problem wymaga wyjaśnienia z twórcami.

Film o transmisji testowej z kamery internetowej
przez serwer WebRTC

Celem tego artykułu jest zapoznanie się z jego strukturą i zasadą działania na próbce demo czatu wideo typu peer-to-peer (czat wideo p2p). W tym celu użyjemy demo wideo czatu peer-to-peer dla wielu użytkowników webrtc.io-demo. Można go pobrać z linku: https://github.com/webRTC/webrtc.io-demo/tree/master/site .

Należy zauważyć, że GitHub jest witryną lub usługą internetową do wspólnego tworzenia projektów internetowych. Na nim programiści mogą publikować kody swoich opracowań, dyskutować o nich i komunikować się ze sobą. Ponadto niektóre duże firmy informatyczne hostują na tej stronie swoje oficjalne repozytoria. Usługa jest bezpłatna dla projektów open source. kod źródłowy. GitHub to repozytorium bibliotek open source.

Tak więc pobraną z GitHub próbkę demo czatu wideo peer-to-peer umieścimy na dysku C komputer osobisty w utworzonym katalogu dla naszej aplikacji "webrtc_demo".

Ryż. jeden

Jak wynika ze struktury (rys. 1), wideoczat peer-to-peer składa się ze skryptów client script.js i server.js zaimplementowanych w języku programowanie JavaScript. Skrypt (biblioteka) webrtc.io.js (KLIENT) - zapewnia organizację komunikacji w czasie rzeczywistym między przeglądarkami według schematu peer-to-peer: „klient-klient”, oraz webrtc.io.js (KLIENT) i webrtc .io.js (SERVER), wykorzystując protokół WebSocket, zapewniają komunikację dupleksową między przeglądarką a serwerem WWW przy użyciu architektury „klient-serwer”.

Skrypt webrtc.io.js (SERVER) jest zawarty w bibliotece webrtc.io i znajduje się w katalogu node_modules\webrtc.io\lib. Interfejs czatu wideo index.html jest zaimplementowany w HTML5 i CSS3. Zawartość plików aplikacji webrtc_demo można przeglądać za pomocą jednego z edytorów html, na przykład "Notepad++".

Sprawdzimy zasadę działania wideoczatu w system plików PC. Aby uruchomić serwer (server.js) na komputerze PC, musisz zainstalować środowisko uruchomieniowe node.js. Node.js umożliwia uruchamianie kodu JavaScript poza przeglądarką. Możesz pobrać node.js z linku: http://nodejs.org/ (wersja v0.10.13 z 15.07.13). Na głównej stronie witryny node.org kliknij przycisk pobierania i przejdź do http://nodejs.org/download/. Do użytkownicy Windows najpierw pobierz win.installer (.msi), następnie uruchom win.installer (.msi) na komputerze i zainstaluj nodejs i „npm package manager” w katalogu Program Files.

Ryż. 2

Zatem node.js składa się ze środowiska programistycznego i wykonawczego JavaScript, a także zestawu wewnętrznych modułów, które można zainstalować za pomocą menedżera pakietów npm lub menedżera pakietów.

Aby zainstalować moduły, musisz wiersz poleceń z katalogu aplikacji (na przykład "webrtc_demo") wykonaj polecenie: npm zainstaluj nazwa_modułu. Podczas instalacji modułów menedżer npm tworzy folder node_modules w katalogu, z którego wykonano instalację. Po uruchomieniu nodejs automatycznie dołącza moduły z katalogu node_modules.

Tak więc po zainstalowaniu node.js otwórz wiersz poleceń i zaktualizuj moduł express w folderze node_modules katalogu webrtc_demo za pomocą menedżera pakietów npm:

C:\webrtc_demo>npm install express

Moduł ekspresowy to platforma internetowa dla node.js lub platformy do tworzenia aplikacji internetowych. Aby mieć globalny dostęp do ekspresu, możesz zainstalować go w ten sposób: npm install -g express.

Następnie aktualizujemy moduł webrtc.io:

C:\webrtc_demo>npm zainstaluj webrtc.io

Następnie w wierszu poleceń uruchamiamy serwer: server.js:

C:\webrtc_demo>nodeserver.js

Ryż. 3

Wszystko, serwer działa pomyślnie (rysunek 3). Teraz za pomocą przeglądarki internetowej możesz skontaktować się z serwerem przez adres ip i pobrać stronę internetową index.html, z której przeglądarka internetowa wyodrębni kod skryptu klienta - script.js oraz kod skryptu webrtc.io.js, i wykonać je. Aby czat wideo peer-to-peer działał (w celu nawiązania połączenia między dwiema przeglądarkami), konieczne jest, aby dwie przeglądarki obsługujące webrtc skontaktowały się z serwerem sygnału działającym na node.js przez adres ip.

W rezultacie otworzy się interfejs części klienckiej aplikacji komunikacyjnej (czat wideo) z prośbą o zezwolenie na dostęp do kamery i mikrofonu (rys. 4).

Ryż. 4

Po kliknięciu przycisku „Zezwól” kamera i mikrofon są połączone w celu komunikacji multimedialnej. Dodatkowo za pośrednictwem interfejsu czatu wideo można komunikować się z danymi tekstowymi (rys. 5).

Ryż. 5

Należy zauważyć że . Serwer sygnalizuje i jest przeznaczony głównie do nawiązania połączenia między przeglądarkami użytkowników. Skrypt server.js, który zapewnia sygnalizację WebRTC, używa do uruchomienia Node.js.