WebSocket

WebSocket to protokół umożliwiający dwukierunkową komunikację w czasie rzeczywistym między klientem a serwerem.

WebSocket jako kanał komunikacji dwukierunkowej

WebSocket to protokół opisany w standardzie RFC 6455, przeznaczony do utrzymywania dwukierunkowej komunikacji między aplikacją kliencką a serwerem. W typowym modelu HTTP klient wysyła żądanie, a serwer zwraca odpowiedź. WebSocket zmienia ten sposób pracy: po ustanowieniu połączenia zarówno klient, jak i serwer mogą przesyłać dane bez konieczności rozpoczynania kolejnych niezależnych żądań HTTP. Dzięki temu serwer może przekazać informację natychmiast po wystąpieniu zdarzenia, bez ciągłego odpytywania go przez przeglądarkę.

Połączenie WebSocket zaczyna się od uzgodnienia wykonywanego za pomocą żądania HTTP. Klient wysyła nagłówki Upgrade: websocket oraz Connection: Upgrade, a serwer, jeśli obsługuje protokół i akceptuje żądanie, odpowiada kodem 101 Switching Protocols. Od tego momentu komunikacja odbywa się już za pomocą ramek WebSocket, a nie zwykłych par żądanie–odpowiedź HTTP. W adresach stosuje się schemat ws://, natomiast dla połączenia szyfrowanego TLS schemat wss://, analogiczny do relacji między HTTP i HTTPS.

Ustanawianie połączenia i znaczenie ramek

W przeglądarce połączenie można utworzyć za pomocą interfejsu JavaScript WebSocket, na przykład wskazując adres w rodzaju wss://example.com/socket. Obiekt udostępnia zdarzenia open, message, error i close, które pozwalają reagować na otwarcie kanału, odebranie danych, błąd oraz zakończenie połączenia. Dane mogą być przesyłane jako tekst albo jako dane binarne. Protokół nie narzuca jednak formatu wiadomości aplikacyjnych. JSON, tekst własnego formatu czy określony format binarny są decyzją twórców konkretnej aplikacji.

WebSocket dzieli transmisję na ramki. Ramki tekstowe przenoszą dane UTF-8, a ramki binarne mogą zawierać dowolny uzgodniony przez aplikację ciąg bajtów. Protokół definiuje również ramki sterujące: Ping służy do sprawdzania dostępności drugiej strony, Pong jest odpowiedzią kontrolną, a Close pozwala uporządkowanie zakończyć sesję. Ramka wysyłana przez klienta musi być zamaskowana zgodnie z wymaganiami RFC 6455, natomiast ramki serwera nie są maskowane. Maskowanie nie zastępuje szyfrowania, ponieważ jego celem jest inny aspekt działania protokołu, a poufność zapewnia dopiero warstwa TLS używana przez wss://.

WebSocket w aplikacjach czasu rzeczywistego

Stałe połączenie jest przydatne tam, gdzie zmiany powinny pojawiać się bez zauważalnego opóźnienia wynikającego z cyklicznego odpytywania serwera. Przykładem może być aktualizowanie statusu zadania, tablica współdzielona przez kilku użytkowników, powiadomienia w panelu aplikacji, podgląd postępu operacji albo komunikacja w narzędziu działającym w przeglądarce. Serwer może wysłać zdarzenie do konkretnego klienta lub do większej grupy klientów, jeżeli logika aplikacji przewiduje takie rozsyłanie.

WebSocket nie gwarantuje sam z siebie poprawności danych biznesowych ani ponownego dostarczenia wiadomości po zerwaniu połączenia. Jeżeli połączenie zostanie przerwane, aplikacja musi obsłużyć ponowne łączenie, ustalić, od którego zdarzenia wznowić odbiór, oraz zdecydować, czy wiadomość ma zostać ponowiona. Istotny jest również stan po stronie klienta: komunikat odebrany przed awarią przeglądarki może nie zostać zapisany w sposób pozwalający na jego odtworzenie. W praktyce stosuje się więc identyfikatory zdarzeń, numerowanie komunikatów, kontrolę kolejności oraz limity czasu bezczynności. Połączenie może też zostać zamknięte przez serwer pośredniczący, zaporę sieciową lub urządzenie sieciowe, dlatego aplikacja powinna rozróżniać zwykłe zamknięcie od błędu transportu.

Diagnostyka problemów z połączeniem WebSocket

Przy problemach z WebSocket warto najpierw sprawdzić, czy handshake zakończył się odpowiedzią 101 Switching Protocols. Odpowiedź 400, 401, 403 lub 404 wskazuje, że żądanie zostało odrzucone, wymaga uwierzytelnienia albo trafiło pod niewłaściwy adres. W narzędziach deweloperskich przeglądarki można sprawdzić adres połączenia, nagłówki, moment jego otwarcia i zamknięcia oraz listę przesłanych ramek. Należy także porównać użyty schemat z konfiguracją strony: strona działająca przez HTTPS zwykle powinna korzystać z wss://, ponieważ niezabezpieczone ws:// może zostać zablokowane jako mieszana zawartość.

Jeżeli handshake przebiega poprawnie, ale wiadomości nie docierają, przyczyną może być błąd obsługi zdarzeń, niezgodny format danych, zamykanie sesji przez serwer albo brak mechanizmu podtrzymywania połączenia. Warto zapisać kod i przyczynę zamknięcia, sprawdzić odpowiedzi na ramki Ping oraz zweryfikować, czy aplikacja nie przekracza limitu rozmiaru wiadomości. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę problemów z oprogramowaniem sieciowym, przeglądarką oraz komunikacją aplikacji korzystających z WebSocket.