WebSocket

WebSocket – jest protokołem komunikacyjnym, zapewniającym dwukierunkowy kanał wymiany danych poprzez pojedyncze połączenie TCP. Protokół WebSockets został ustandaryzowany przez IETF jako RFC 6455 w 2011 roku, a jego przeglądarkowe API podlega standaryzacji w W3C.

WebSocket

Platforma sprzętowa	wieloplatformowy
Rodzaj	Protokół komunikacyjny
Licencja	2-klauzulowa licencja BSD
Strona internetowa

WebSockets różni się od protokołu HTTP. Oba protokoły są zlokalizowane na 7 warstwie w modelu OSI i zależą od TCP na warstwie 4. Pomimo faktu, że są one różne, standard RFC 6455 mówi, że WebSocket został zaprojektowany do działania na portach 80 i 443 przypisanych do HTTP, a także ma wspierać funkcje proxy i pośredników (intermediaries). Aby osiągnąć kompatybilność z HTTP, handshake WebSocket’u wykorzystuje nagłówek HTTP Upgrade, aby przełączyć komunikację z protokołu HTTP na WebSockets.

Protokół WebSocket umożliwia interakcję między przeglądarką internetową (lub inną aplikacją kliencką), a serwerem sieciowym przy niższym obciążeniu niż alternatywne rozwiązania półdupleksowe, takie jak np. odpytywanie HTTP (polling), ułatwiając przy tym znacznie przesyłanie danych w czasie rzeczywistym do i z serwera. Jest to możliwe dzięki zapewnieniu znormalizowanego sposobu wysyłania przez serwer treści do klienta bez uprzedniego żądania klienta i umożliwienia przesyłania komunikatów tam i z powrotem przy zachowaniu aktywnego połączenia. W ten sposób między klientem, a serwerem może odbywać się dwukierunkowa wymiana danych. Komunikacja odbywa się zwykle przez port TCP o numerze 443 (lub 80 w przypadku połączeń niezabezpieczonych), co jest korzystne w środowiskach, które blokują połączenia dla aplikacji innych niż przeglądarki internetowe (np. klienty Torrent, IRC). Przed pojawieniem się WebSocket’ów podobną dwukierunkową komunikację przeglądarka-serwer osiągano w niestandardowy sposób, wykorzystując technologie takie jak Comet czy Adobe Flash Player.

Większość współczesnych przeglądarek obsługuje WebSocket’y, w tym m.in.: Google Chrome, Firefox, Microsoft Edge, Internet Explorer, Safari i Opera.

W przeciwieństwie do protokołu HTTP, WebSocket zapewnia komunikację w pełnym dupleksie. Dodatkowo WebSocket umożliwia przesyłanie wiadomości na wierzchu protokołu TCP. Sam protokół TCP obsługuje strumienie bajtów bez wbudowanej koncepcji wiadomości. Przed WebSocket komunikacja na porcie 80 w pełnym dupleksie była osiągalna przy użyciu kanałów Comet, jednak implementacja Comet nie jest trywialna, a ze względu na uzgadnianie TCP i obciążenie nagłówka HTTP jest nieefektywna w przypadku małych wiadomości. Protokół WebSocket ma na celu rozwiązanie tych problemów bez naruszania założeń bezpieczeństwa sieci.

Specyfikacja protokołu WebSocket definiuje ws (WebSocket) i wss (WebSocket Secure) jako dwa nowe schematy jednolitego identyfikatora zasobów (URI), które są używane odpowiednio do połączeń nieszyfrowanych i szyfrowanych. Oprócz nazwy schematu i fragmentu (tj. # nie jest obsługiwany), pozostałe komponenty URI są zdefiniowane tak, aby używały ogólnej składni URI.

Wykorzystując narzędzia developera w przeglądarce, twórcy stron mogą sprawdzić zarówno handshake WebSocket’u, jak i poszczególne paczki (frames).

Historia

WebSocket’y zostały po raz pierwszy wymienione jako TCPConnection w bazowej specyfikacji HTML5, jako symbol zastępczy dla interfejsu (API) gniazda, opartego o protokół TCP. W czerwcu 2008 roku Michael Carter przeprowadził serię dyskusji w wyniku których powstała pierwsza wersja protokołu znanego obecnie jako WebSocket.

Nazwa „WebSocket” została ukuta przez Iana Hicksona i Michaela Cartera podczas współpracy na kanale IRC #whatwg, a następnie włączona do specyfikacji HTML5 przez samego Hicksona. W grudniu 2009 r. Google Chrome 4 została pierwszą przeglądarką z pełną obsługą nowego standardu, z domyślnie włączonym API WebSocket. Rozwój protokołu WebSocket został następnie przeniesiony z grup W3C i WHATWG do IETF w lutym 2010.

Po zakończeniu prac nad protokołem i jego domyślnym włączeniu w większości przeglądarek, standard RFC 6455 został sfinalizowany przez Iana Fettera w grudniu 2011 roku.

RFC 7692 wprowadził rozszerzenie kompresji wiadomości do WebSocket przy użyciu algorytmu DEFLATE.

Przeglądarki wspierające WebSocket

WebSocket został zaimplementowany w przeglądarkach: Firefox 4, Google Chrome 4, Opera 11, Internet Explorer 10 oraz Safari 5 (również w mobilnym Safari dla iOS 4.2). Z powodu luk w zabezpieczeniach WebSocket został domyślnie wyłączony w Firefoksie 4 i Operze 11 do czasu ich naprawienia. Aktualnie wszystkie najpopularniejsze przeglądarki wspierają tę technologię.

Implementacja WebSocket w przeglądarkach internetowych

Protokół, wersja	Data konspektu	Internet Explorer	Firefox (PC)	Firefox (Android)	Chrome (PC, iOS, Android)	Safari (Mac, iOS)	Opera (PC, Android, iOS)	Android Browser
hixie-75	4 Luty, 2010				4	5.0.0
hixie-76 hybi-00	6 Maj, 2010 23 Maj, 2010		4.0 (wyłączono)		6	5.0.1	11.00 (wyłączono)
hybi-07	22 kwietnia 2011		6
hybi-10	11 lipca 2011		7	7	14
RFC 6455	Grudzień 2011	10	11	11	16	6	12.10	4.4

Przykładowy klient w języku javaScript

// stworzenie nowego obiektu typu WebSocket
const socket = new WebSocket('ws://game.example.com:12010/updates');

// metoda wywoływana w momencie stworzenia socketu
socket.onopen = function () {
  setInterval(function() {
    if (socket.bufferedAmount == 0)
      socket.send(getUpdateData());
  }, 50);
};

// metoda wywoływana w momencie otrzymania wiadomości
socket.onmessage = function(event) {
  handleUpdateData(event.data);
};

// metoda wywoływana w momencie zamknięcia gniazda
socket.onclose = function(event) {
  onSocketClose(event);
};

// metoda wywoływana w momencie, gdy socket został zamknięty z powodu błędu
socket.onerror = function(event) {
  onSocketError(event);
};

Handshake protokołu

Aby ustanowić połączenie typu WebSocket, klient musi najpierw wysłać żądanie typu handshake, dla którego serwer zwraca odpowiednią odpowiedź, jak pokazane jest to w przykładzie poniżej.

Zarówno w żądaniu klienta, jak i odpowiedzi serwera każda linia wiadomości kończy się znakiem nowej linii (\r\n) – identycznie jak ma to miejsce w przypadku protokołu HTTP. Dodatkowo na samym końcu żądania/odpowiedzi musi znajdować się pusta linia.

Żądanie klienta:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

Odpowiedź serwera:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

Handshake rozpoczyna się od żądania/odpowiedzi HTTP, dzięki czemu dany serwer może obsługiwać połączenia HTTP, a także WebSocket na tym samym porcie. Po nawiązaniu połączenia komunikacja przełącza się na dwukierunkowy protokół binarny, który nie jest już zgodny z protokołem HTTP.

Oprócz nagłówka Upgrade klient wysyła również nagłówek Sec-WebSocket-Key zawierający losowe bajty zakodowane w standardzie base64, na co serwer odpowiada, podając hash tego klucza w nagłówku Sec-WebSocket-Accept. Ma to na celu zapobieganie sytuacji, gdzie np. serwer/proxy buforujący wyśle ponownie całą zapisaną konwersację innemu klientowi, podczas gdy ten nie miał de facto styczności z właściwym serwerem. Proces polega na tym, że funkcja szyfrująca dodaje stały ciąg znaków 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 do wartości podanej w nagłówku Sec-WebSocket-Key klienta (nie jest on dekodowany z base64), a następnie stosuje algorytm szyfrujący SHA-1, by na samym końcu zakodować uzyskaną wartość używając base64.

Gdy połączenie jest już ustanowione, klient i serwer mogą wysyłać sobie dane w formie binarnej lub tekstowej w postaci tzw. ramek w trybie pełnego dupleksu. Sama ramka ma niewielki narzut, dodając jedynie mały nagłówek, po którym znajdują się docelowe dane. Transmisje WebSocket są opisywane jako „wiadomości”, w których pojedyncza wiadomość może być opcjonalnie podzielona na kilka ramek. Pozwala to na wysyłanie wiadomości, w których dostępne są dane początkowe, ale nie jest znana pełna długość wiadomości (wysyłane są jedna ramka danych za drugą, aż do osiągnięcia końca i zakończenia bitem FIN). Dzięki rozszerzeniom protokołu można to również wykorzystać do multipleksowania kilku strumieni jednocześnie (na przykład w celu uniknięcia monopolizowania użycia gniazda dla pojedynczego dużego ładunku).

Zobacz też

• XMLHttpRequest
• HTTP