WebRTC zatrzęsie Internetem

Wyobraźmy sobie świat, w którym komputer, telefon czy telewizor komunikują się ze sobą, korzystając ze wspólnej, powszechnie używanej platformy. Świat, w którym wyposażenie aplikacji webowej w funkcje współdzielenia plików czy komunikacji wideo nie jest niczym trudnym. To wkrótce może być rzeczywistość, za którą stoi WebRTC.

Jeszcze kilka lat temu koncepcja używania przeglądarki do komunikacji wideo była bardzo atrakcyjną, ale tylko wizją. Dzisiaj, za sprawą WebRTC, staje się to realne. Interfejs API WebRTC jest już wbudowany w najnowsze wersje przeglądarek Firefox, Chrome i Opera (w wersjach na komputery stacjonarne i Androida). W rozwój tego projektu są zaangażowani najwięksi potentaci w branży IT, żeby wymienić kilku: Google, Oracle czy Cisco. Jest ponad 300 dostawców, którzy wykorzystują WebRTC w różnych fazach rozwoju, a część z nich już nawet zarabia na tej technologii. Gdy zostaną ukończone prace nad standaryzacją WebRTC, co być może nastąpi jeszcze w 2014 r. i rozpocznie się wdrażanie tej technologii, wywrze ona wpływ na większość dostawców w branży IT, także takich Gigantów, jak Apple, Cisco, Google and Microsoft.

WebRTC oferuje szereg możliwości, z których najszerzej znaną jest prowadzenie rozmów audio i wideo z wykorzystaniem przeglądarki internetowej. Zagraża to zamkniętym platformom, jak Skype czy FaceTime, ale także otwiera potencjał do tworzenia całkiem nowej generacji narzędzi do współpracy, które będą działać w przeglądarkach internetowych. Z tego powodu wiele firm technologicznych, zaniepokojonych sytuacją, wyraża negatywne opinie o WebRTC. Zdecydowanymi zwolennikami są Google i Mozilla. Cisco jest umiarkowanie przychylne, a Microsoft nie zajął dotychczas konkretnego stanowiska (Internet Explorer na razie nie obsługuje WebRTC). Głosu w debacie praktycznie nie zabiera Apple.

WebRTC w pigułce

Akronim w nazwie oznacza Real Time Communication. WebRTC jest bezpłatny. Ten interfejs programistyczny (API) został udostępniony wraz z otwartym kodem źródłowym (open source) przez Google w 2011 r. Celem twórców popularnej wyszukiwarki było dostarczenie silnika do transmisji mediów w czasie rzeczywistym, bazującego na standardach, bezpłatnego i wbudowanego we wszystkie obecne na rynku przeglądarki WWW.

Technologia ułatwi firmom komunikację z klientami – nawiązanie rozmowy wideo będzie równie łatwe, jak obecnie korzystanie z tekstowego chatu. WebRTC znajdzie też wiele innych zastosowań. Firmy mogą użyć tej technologii do rozbudowywania swoich systemów konferencyjnych, dając dostęp do nich większej liczbie pracowników, jak również partnerom, klientom czy innym podmiotom zewnętrznym. Zamiast kupować kosztowne, dedykowane terminale wideo, wystarczy komputer, notebook czy inne urządzenia wyposażone w przeglądarkę internetową. Entuzjaści WebRTC bardzo dużo obiecują sobie po tej technologii i puszczają wodze fantazji. Do komunikacji wideo ma w przyszłości posłużyć dowolna powierzchnia, z którą mamy na co dzień do czynienia: lustro w łazience czy stół w kuchni.

Korzyści w dużym stężeniu

WebRTC przynosi korzyści, które znamy z obecnie stosowanych platform do komunikacji i pracy grupowej. Jednak w WebRTC występują one w takim natężeniu, że pchają systemy wideo i VoIP na kolejny etap ewolucji. Największą wartością tej technologii jest obietnica interoperacyjności z istniejącymi systemami komunikacji głosowej i wideo. Ewentualne ograniczenia w interoperacyjności będą natomiast wynikały z konieczności aktualizacji oprogramowania w istniejących urządzeniach. Alternatywnie, można stosować bramki sieciowe, które rozwiążą problemy z interoperacyjnością. Tego typu produkty są już na rynku. Jeśli urządzenia korzysta ze standardowych protokołów komunikacji audio i wideo, z dużym prawdopodobieństwem będzie mogło komunikować się z urządzeniami korzystającymi z WebRTC. Jak ostatecznie będzie wyglądała kwestia interoperacyjności będzie można powiedzieć, gdy zakończą się pracę standaryzacyjne, np. zostanie wybrany kodek wideo.

WebRTC jest niezależne od platformy i urządzeń, na których działa. Każda przeglądarka internetowa z wbudowaną obsługą tej technologii może zainicjować połączenie z innym urządzeniem WebRTC bądź media-serwerem WebRTC. Dzieje się to niezależnie od tego, jaki system operacyjny oraz aplikację webową posiada użytkownik. Jest to możliwe za sprawą zastosowania standardowego API zaakceptowanego przez W3C oraz protokołów będących standardami IETF. Programiści mogą tworzyć kod HTML 5, który będzie działać na zarówno urządzeniach stacjonarnych i mobilnych.

Komunikacja przez WebRTC, przynajmniej w założeniach, jest bezpieczna – głos i obraz są szyfrowane. Protokół SRTP (Secure Real-time Transport Protocol) służy do szyfrowania i uwierzytelniania komunikacji audio i wideo. Jest to szczególnie przydatne dla użytkowników sieci Wi-Fi, ponieważ chroni przed przechwytywaniem i nagrywaniem rozmów.

Wysoką jakość dźwięku zapewnia kodek, który powstał na bazie technologii Skype SILK. Natomiast do kodowania wideo służy prawdopodobnie jeden z dwóch kodeków VP8 lub H.264. Efektem takiego doboru kodeków jest interoperacyjność i brak konieczności pobierania dodatkowych oprogramowania, które może zawierać niebezpieczny kod.

WebRTC obsługuje nawiązywanie niezawodnych połączeń. Jest to możliwe również w przypadku sieci z NAT, który to mechanizmu często utrudnia lub nawet blokuje inne protokoły komunikacyjne i pracy grupowej. Niezawodność sesji pozwalaja uniknąć stosowania pośredniczących serwerów mediów, co przekłada się na mniejsze opóźnienia i wyższą jakość transmisji. Poza tym zmniejsza obciążenie serwerów.

WebRTC jest rozwiązaniem adaptacyjnym, które dostosowuje się do zmiennych warunków sieciowych. Dopasowuje jakość komunikacji, reaguje na dostępną przepustowość, wykrywa przeciążenia i zapobiega ich powstawaniu. Takie możliwości osiągnięto, stosując zwielokrotnienie protokołu RTP Control Protocol (RTCP) oraz Secure Audio Video Profile with Feedback (SAVPF). Przeglądarka odbiorcy wysyła do nadawcy informacje zwrotne o warunkach panujących w sieci. Otrzymane dane są analizowane, aby móc zareagować, gdy jest to konieczne.

WebRTC potrafi w procesie nawiązywania połączenia negocjować komunikację z wykorzystaniem różnych rodzajów mediów oraz urządzeń końcowych. Służy to efektywnemu wykorzystywaniu dostępnej przepustowości sieci, aby otrzymać jak najlepsze parametry dźwięku i obrazu. Rozmiar i jakość mogą być negocjowane indywidualnie dla każdego punktu końcowego.

Natomiast deweloperów ucieszy fakt, że proces programowania z wykorzystaniem WebRTC przebiega bardzo sprawnie. Nie jest też wymagana szczegółowa wiedza, ponieważ używa się ustandaryzowanego API.

Kwestie do rozwiązania

WebRTC ma duże szanse wejść do powszechnego użytku, ale przed nami jeszcze co najmniej kilka lat, zanim uda się rozwiązać wszystkie wyzwania. Jako główne problemy wymienia się: brak standardowych kodeków stosowanych w różnych przeglądarkach WWW oraz brak wsparcia ze strony firmy Apple. Istotnym wyzwaniem jest również bezpieczeństwo. Korzystanie z WebRTC nie powinno otwierać przed hakerami nowych płaszczyzn ataku umożliwiających włamania. Poważnym problem jest również spodziewana ogromna skala popularności tego rozwiązania, ponieważ dla tego ruchu trzeba będzie zapewnić odpowiedną przepustowość.

Batalia o kodek

WebRTC ma być uniwersalnym rozwiązaniem, zapewniającym interoperacyjność. Aby osiągnąć ten cel, musi bazować na powszechnie obowiązujących standard. Jednym z kluczowych zadań jest wybór kodeka wideo. Wokół tej kwestii toczy się zawzięta rywalizacja miedzy Google, który jest orędownikiem własnego, otwartego kodeka VP8, a Cisco, które promuje kodek H.264. Najistotniejsza różnica między nimi polega na tym, że H.264 pojawił się wcześniej i jest zgodny z większą liczbą urządzeń, szczególnie tych starszych. VP8 jest nowocześniejszy, ale obecny w mniejszej liczbie urządzeń. Google miało jeszcze silny argument – VP8 jest bezpłatny. Jednak Cisco w październiku 2013 r. zdecydowało się udostępnić kod źródłowy swojej implementacji kodeka H.264 i wziąć na siebie koszty opłat licencyjnych na rzecz MPEG LA.

Nie jest to spór o pietruszkę – wybór kodeka będzie miał istotne implikacje dla dużych firm technologicznych. Cisco oficjalnie deklaruje swoje wsparcie dla WebRTC, jednak w tle chodzi o włączenie H.264 do tego standardu. Producent oraz jego klienci zainwestowali bowiem znaczne środki w produkty wykorzystujące ten kodek. Jeśli zostanie on włączony do standardu, ruch ten zapewni zgodność istniejących rozwiązań Cisco z WebRTC. Istotne jest również to, że trwają pracę nad H.265, nowszą wersją H.264. Zwycięstwo kodeka VP8, który Google udostępnia bezpłatnie sprawi, że rozwój H.265 może stracić sens.

Na początku listopada 2013 r. grupa robocza IETF pracującą nad WebRTC miała wybrać kodek, który otrzymałby status Mandatory to Implement (MTI), czyli elementu obowiązkowego do umieszczenia w implementacji WebRTC. Nie wypracowano jednak wspólnego stanowiska. Debata toczyła się wokół kodeków VP8 oraz H.264. Komisja zasugerowała kilka kompromisowych rozwiązań: uznanie obu kodeków jako MTI, tymczasowy wybór H.261 jako MTI lub uznanie obu kodeków jako sugerowanych, ale nie obowiązkowych. Żadne z tych rozwiązań nie zyskało wyraźnego poparcia, co opóźnia perspektywę zakończenia prac nad standardem. Wydaje się, że ostatecznie zwycięsko wyjdzie ze starcia H.264. Po pierwsze, Microsoft i Apple raczej nie zgodzą się na wsparcie dla VP8 w swoich rozwiązaniach z uwagi na silną konkurencję z Google. Ponadto Nokia procesuje się sądownie z Google co do praw własności do kodeka VP8. Jeśli wygra sprawę, użytkownicy VP8 również będą zmuszeni do ponoszenia opłat licencyjnych.

Jednakże kodek wideo to tylko początek tego, jak WebRTC będzie oddziaływać na branżę IT, zagrażając wielu dobrze prosperującym przedsięwzięciom, jak Skype. Przykładowo, Microsoft, który jest właścicielem Skype, do tej pory nie zadeklarował, kiedy zaimplementuje WebRTC w Internet Explorerze. Natomiast Google i Mozilla już to uczynili. Historia z kodekiem wideo jest zapewne początkiem fascynującej batalii, jaka będzie rozgrywać się wokół tego ważnego standard internetowego.

Komunikacja nie tylko między przeglądarkami

Często błędnie powtarza się, że WebRTC to rozwiązania do komunikacji w czasie rzeczywistym dla przeglądarek. Owszem, pierwszym miejscem, w którym WebRTC jest implementowany, są właśnie przeglądarki. Nie ma jednak ograniczeń, z powodu których nie można by stosować tego rozwiązania w innych miejscach czy różnych urządzeniach. Standard został opracowany, aby oferować dwie podstawowe funkcje: zestaw standardowych interfejsów API, których serwer może używać do zarządzania zachowaniem punktów końcowych oraz zestaw protokołów, które umożliwiają komunikację peer-to-peer. Nie postawiono jednak wymagania, że stronami komunikacji P2P muszą być przeglądarki internetowe. Punkt końcowy musi jedynie spełniać bardzo podstawowy zestaw wymagań narzucanych przez protokół RTP i interfejsy API.

Od samego początku rozwoju WebRTC przyjęto kierunek, który nie wykluczał punktów końcowych innych niż przeglądarki. Jest to związane z koniecznością działania takich mechanizmów, jak tworzenie mostków konferencyjnych czy scentralizowane nagrywanie. W ten sposób w komunikacji P2P może brać dowolny punkt końcowy z obsługą WebRTC. Jednakże nie ma innych standardów, niż W3C API, które definiowałby sposoby kontrolowania punktów końcowych.

Przykładowo, możliwy jest scenariusz, w którym w komunikacji pośredniczy centralny serwer. W tego typu konferencji każdy strumień wideo ma dwa identyczne zakończenia: na jednym końcu jest to przeglądarka WWW działająca w urządzeniu końcowym, a na drugim serwerów mediów. Jeśli kilka punktów końcowych komunikuje się ze sobą jednocześnie, używając WebRTC, serwer mediów musi zarządzać wieloma strumieniami wideo, stosując mikser typu MCU (Multipoint Control Unit) lub poprzez routing i przełączanie transmisji wideo. W obu przypadkach serwer mediów działa jako równorzędny peer w stosunku do pozostałych punktów końcowych, odbierając i odsyłając strumienie wideo, ograniczając wykorzystanie pasma sieciowego i wpływ zbyt wielu strumieni wideo na wydajność. Są już na rynku rozwiązania, w których zaimplemetowano taką architecturę, a WebRTC zastosowano, aby umożliwić użytkownikowi przeglądarki WWW komunikację z systemem wideokonferencyjnym.

Innym przykładem jest wykorzystanie przez firmę Vonage niskopoziomowego stosu WebRTC (tzw. Google Media Engine) do implementacji tego standard bezpośrednio w urządzeniach mobilnych. W ten sposób, stosując powszechnie używane kodeki, urządzenie mobilne może łatwo komunikować się z systemami zaplecza tej firmy. To pozwala na używanie WebRTC w komunikacji z niektórymi urządzeniami, a innych interfejsów API w innych częściach systemu. Google Media Engine jest podstawą implementacji WebRTC i zapewne będziemy obserwować, jak kolejne firmy telekomunikacyjne będę sięgały po ten silnik do budowania innowacyjnych rozwiązań WebRTC, które nie będą bazowały na przeglądarkach internetowych.

Pomysłów na wykorzystanie WebRTC w innych miejscach, niż przeglądarka internetowa, jest więcej. Przykładowo, kamera może mieć wbudowane API, protokoły i kodeki WebRTC, co umożliwi sterowanie nią za pomocą serwera WebRTC i prostych skryptów JavaScript. Łatwo będzie stworzyć stronę WWW, która posłuży do odbierania obrazu z takiej kamery. Może się to przydać, np. do monitoringu. O ile przeglądarka internetowa musi być zgodna z HTML 5, kamerę wystarczy wyposażyć w podstawowe API do kontrolowania strumienia multimedialnego oraz połączenia P2P. Podobnie, inne urządzenie będące tylko sensorem mogą być kontrolowane za pośrednictwem WebRTC i przesyłać strumień danych.

Kreatywne zastosowania

WebRTC to nie tylko transmisja obrazu i dźwięku, ale również danych. Ten aspekt jest mocno niedoceniany i najczęściej przypisuje mu się tylko jedno zastosowanie – jako tekstowy czat. Jednak transmisja danych typu P2P daje bardzo szerokie możliwości. Przyjrzyjmy się kilku przykładom. Pierwszy jest wręcz oczywisty – udostępnianie plików między dwoma przeglądarkami.

Żeby transmisja mogła zadziałać, po obu stronach muszą być uruchomione przeglądarki, co wyklucza asynchroniczne działanie. Ma też swoje zalety - redukcję przepustowości wymaganej do transmisji oraz ochronę prywatności, ponieważ można precyzyjnie określić, komu udostępnia się pliki.

Kolejnym zastosowaniem jest rozszerzenie sieci typu CDN o funkcjonalność P2P i ograniczenie w ten sposób obciążenia w sytuacjach, gdy większa liczba użytkowników próbuje uzyskać dostęp do tego samego zasobu. Można użyć do tego celu kanał danych i pozwolić na przesyłanie fragmentów poszukiwanego zasobu bezpośrednio między użytkownikami. Jest to dokładnie ta koncepcja, którą opracowała firma PeerCDN (została przejęta przez Yahoo). To rozwiązanie określa się również terminami peer assisted delivery oraz P2P CDN. W tym obszarze działa jeszcze kilku producentów, którzy mają własne koncepcje, różniące się szczegółami.

Jeśli scalić ze sobą dwa poprzednie pomysły, mamy gotową receptę na BitTorrent działający w przeglądarce internetowej. Można udostępniać pliki z jednego źródła każdemu, a jednocześnie wymuszać na osobach uzyskujących do nich dostęp, ażeby również między sobą współdzieliły pobierane zasoby. Teoretycznie, można nawet włączyć przeglądarkę WWW do prawdziwych sesji BitTorrent.

Po nawiązaniu połączenia komunikacja odbywa się już bezpośrednio między punktami końcowymi, więc można użyć kanału danych do stworzenia sieci charakteryzującej się niskimi opóźnieniami. Dane w takiej sieci są dostępne bezpośrednio bez przesyłania ich przez dodatkowe węzły, np. serwer pośredniczący. Najczęściej wskazuje się, że jest to rozwiązanie odpowiednie dla gier typu multiplayer.

Ciekawą koncepcją jest też stworzenie “bezserwerowej” sieci. Można użyć kanału danych do uruchomienia serwera WWW wewnątrz przeglądarki internetowej. To z kolei może przełożyć się na mniejsze zapotrzebowanie na “prawdziwe” serwery WWW używane do uruchamiania usług. W tym scenariuszu urządzenia końcowe WebRTC służą jako punkty dostępowe w dynamicznej sieci, która może być tworzona ad-hoc. Nie jest to czysto teoretyczna koncepcja – przeprowadzono już kilka testów jej realizacji.

WebRTC nadaje się również jako alternatywa dla sieci TOR i to znacznie bezpieczniejsza. Problemem są serwery pracujące na styku klasycznego Internetu i sieci TOR. Wprawdzie anonimizują one ruch, ale stanowią jednocześnie pojedynczy punkt dostępu do sieci oraz pojedynczy punkt zagrożenia dla bezpieczeństwa. Administrator serwera może bowiem przechwytywać i odczytywać przechodzącą przez niego transmisję. Zdarza się, że serwery Tora zostają zhakowane, np. przez agendy rządowe. Jeśli do anonimizacji zaprzęgnie się WebRTC, kontrolowanie ruchu przy ogromnej liczbie użytkowników przeglądarek internetowych staje się znacznie trudniejsze.

W złej wierze

WebRTC jest technologią, a nie usługą, i jako taka może posłużyć do dobrych bądź złych celów. Możemy być pewni, że w tym roku będzie ona mocno testowana w celu wykrycia luk w bezpieczeństwie. W tym kontekście warto przyjrzeć się dwóm aspektom. Po pierwsze, kanałowi do transmisji danych. Zdaniem części ekspertów to właśnie ten element WebRTC odegra większą rolę niż możliwość nawiązywania połączeń wideo z wykorzystaniem przeglądarki internetowej. Kanał danych WebRTC można bowiem wykorzystać m.in. do ustalenia adresów IP urządzeń pracujących w sieci w lokalnej. Można zdobyć te adresy, posługując się prostą stroną HTML wykorzystującą technologię WebRTC, co zostało już potwierdzone w testach. Jest to tym bardziej niepokojące, ponieważ WebRTC przedstawia się jako najbardziej bezpieczne rozwiązanie VoIP.

Po drugie dlatego, że WebRTC jest nowością i potrzeba jeszcze wiele czasu, żeby dopracować tę technologię. Jeśli do powszechnego użytku wprowadza się nowe API, można być pewnym, że zostanie ono użyte również w sposób, jaki nie był intencją jego twórców. Jednym ze sztandarowych przykładowych potwierdzających tę tezę jest Outlook. W ten popularny program pocztowy wbudowano mechanizm automatyzujący wykonywanie najczęstszych czynności. Został on wykorzystany przez twórców wirusa Melissa do automatycznego rozsyłania złośliwego kodu do 50 pierwszych osób z listy kontaktów.


TOP 200