HTTP jest ulicą jednokierunkową
Aby przesłać dane przez Sieć, klient inicjuje połączenie TCP (Transmission Control Protocol) z serwerem. TCP sprzęga adresy IP i porty punktów końcowych oraz zapewnia bezbłędne przesyłanie danych pomiędzy nimi. Ponieważ jednak informacje wymagają nie tylko przesłania, ale też zrozumienia, ponad warstwą TCP działa protokół aplikacji, przez który komunikują się klient i serwer: w przypadku stron WWW jest to najczęściej HTTP (Hypertext Transfer Protocol). Chociaż TCP, jako ślepa warstwa transportowa, oferuje dwukierunkowe wysyłanie danych, HTTP nie wykorzystuje tych możliwości. Protokół ten nie pozwala również na przesyłanie potrzebnych w nowoczesnych aplikacjach sieciowych wiadomości typu push od serwera do klienta. HTTP działa według prostego wzorca: klient pyta, serwer odpowiada. To powolne i pracochłonne.
Aby użytkownicy nie musieli bez przerwy naciskać przycisku aktualizacji, programiści otrzymują do dyspozycji prowizorki, które naśladują dwustronną komunikację w czasie rzeczywistym przez HTTP. Najprostszą metodą jest tzw. polling. Skrypt w przeglądarce w ustalonych interwałach zapytuje serwer o nowe wydarzenia. Polling przy każdym zapytaniu buduje nowe połączenie, kończone przez serwer po odpowiedzi – nawet jeśli ten nie ma do zakomunikowania żadnych zmian. To zabiera czas, zwiększa ruch internetowy i obciążenie sieci przez częste budowanie nowego połączenia TCP. Technologia long polling idzie o krok dalej, podtrzymując połączenie, aż serwer będzie miał zdarzenia do zameldowania.
Najlepszą prowizoryczną metodą jest streaming HTTP: połączenie pozostaje otwarte przez dłuższy czas, w którym serwer może przesyłać dane. Wadą rozwiązania okazuje się pracochłonna implementacja obiektu JavaScriptXMLHttpRequest, która nie w każdej przeglądarce jest taka sama. Oprócz tego dwukierunkowa komunikacja w czasie rzeczywistym wymaga utrzymywania przez cały czas dwóch otwartych połączeń HTTP.
Technologia WebSocket jest wydajna i szybka
WebSocket rozwiązuje opisane wcześniej problemy, tworząc w przeglądarce tzw. socket, który przez adres IP i port utrzymuje obustronny kanał do serwera. Dzięki temu oba punkty końcowe mogą równocześnie przesyłać dane przez to samo połączenie.
WebSocket wykorzystuje do budowy połączenia prawie zapomnianą funkcję w nawiązywaniu łączności HTTP: zmianę protokołu przez jego aktualizację. Opcja ta pierwotnie służyła do kodowania niezaszyfrowanych połączeń portu 80 przez upgrade protokołu TLS, ale nigdy nie została zastosowana w praktyce. WebSocket przywraca tę zapomnianą możliwość i wykorzystuje ją do tego, aby przez nawiązanie łączności HTTP stary protokół zastąpić nowym, czyli właśnie WebSocketem. Implementacja WebSocket API w przeglądarce odbywa się przez obiekt JavaScript. Aktywne połączenia WebSocket rozpoznaje się na pasku adresu po innej ikonie.
Aby komunikowały się ze sobą tylko dopuszczalne punkty końcowe WebSocketu, programiści wstawili do nagłówka HTTP kilka mechanizmów zabezpieczających: klient generuje w swoim zapytaniu klucz zabezpieczający kodowany za pomocą algorytmu base64. Jego wynik serwer uzupełnia o dodatkowy ciąg znaków, tworzy z niego wartość zahaszowaną (hash SHA-1), rozkodowuje ją i odsyła do klienta. W ten sposób oba punkty końcowe zapewniają się, że używają protokołu WebSocket. Dane o pochodzeniu w zapytaniu chronią serwer WebSocket przed ingerencjami z obcych źródeł, dzięki czemu tylko znane mu i obsługiwane przez niego zdalne aplikacje są w stanie utworzyć z nim kanał komunikacyjny.
Ostatni mechanizm zabezpieczający wkracza do akcji po nawiązaniu połączenia HTTP: klient WebSocket musi zakodować każdy pakiet danych za pomocą prostej maski bitowej XOR, aby włączony jako pośrednik serwer proxy błędnie nie wziął ruchu WebSocket za zapytania HTTP. Bez szyfrowania pakietów danych złośliwe skrypty mogłyby sterować serwerami proxy i wykorzystywać je do atakowania innych użytkowników. Jednak ponieważ serwery proxy nie potrafi ą odczytywać zaszyfrowanych danych, bezproblemowo przekazują je do podanego punktu końcowego.
Jak nie wszystkie przeglądarki obsługują protokół WebSocket. Ma się to zmienić w najbliższych miesiącach, bo technologia ta oferuje same korzyści: aplikacje internetowe stają się bliższe użytkownikowi, bardziej wszechstronne i działa ją szybciej.
Te przeglądarki obsługują WebSocket
Obecnie jedynie przeglądarki Firefox oraz Chrome standardowo obsługują aktualną, zgodną ze standardem W3C wersję protokołu sieciowego Web- Socket. Opera i Safari ciągle jeszcze stawiają na starszą implementację.
Jedno połączenie, dwa kierunki
Za pomocą protokołu WebSocket, w przeciwieństwie do HTTP, można wysyłać dane w dwóch kierunkach równocześnie przez jedno połączenie TCP. W efekcie zmniejszają się opóźnienia i obciążenie Sieci. WebSocket bazuje na HTTP, lecz po nawiązaniu połączenia zastępuje ten protokół. Połączenia WebSocket, podobnie jak w HTTP, wykorzystują standardowe porty: 80, gdy nie są szyfrowane, i 443 w przeciwnym wypadku. Dlatego, inaczej niż w przypadku socketów Javy i Flash, nowego protokołu można używać bez wtyczki przeglądarki, także w środowisku chronionym firewallem. WebSocket ma schemat analogiczny do HTTP: ws (Web Servieces) dla połączeń nieszyfrowanych i wss (Web Secure Servieces) dla połączeń szyfrowanych.
ZALETY WEBSOCKET:
- komunikacja dwukierunkowa
- wiadomości w czasie rzeczywistym
- niewielkie obciążenie Sieci