Na czym polega i czym różni się od HTTP Request?
Połączenie szybsze i dwukierunkowe
Czy zastanawiałeś się kiedyś, jak działają różnego rodzaje aplikacje do śledzenia lokalizacji? Jak taki program do wyświetlania pozycji danego obiektu (niezależenie od tego czy chodzi o kuriera z pizzą czy o kontenerowiec) albo chat jest w stanie wyświetlać dane w czasie rzeczywistym w ciągu kilku sekund? Dzięki websocketom, które pozwalają nam, poprzez ustanowienie dwukierunkowego połączenia między klientem a serwerem, na budowanie funkcji działających w czasie rzeczywistym.
Średnio pojedyncze żądanie websocket (przy użyciu Socket.io) zajmuje około 83 milisekund w porównaniu do 107 milisekund w przypadku żądania HTTP. Może nie wydawać się to znaczącą różnicą, ale gdy uświadomimy sobie ile tych żądań jest i zaczniemy zliczać czas potrzebny na wiele równoległych żądań, różnica czasu staje się uderzająca.
Najpierw przyjrzyjmy się, jak działa tradycyjne połączenie HTTP, a następnie przyjrzyjmy się, czym różni się od niego połączenie z wykorzystaniem websocketu.
HTTP Request i próba jego podrasowania
Najpierw przyjrzyjmy się, jak działa tradycyjne połączenie HTTP, a następnie przyjrzyjmy się, czym różni się od niego połączenie z wykorzystaniem websocketu.
Połączenie HTTP jest tworzone, gdy klient wysyła żądanie do serwera. Tworzy to połączenie TCP/IP między serwerem a klientem. Następnie serwer odsyła klientowi odpowiedź, po czym połączenie zostaje zakończone. Oznacza to, że za każdym razem, gdy klient wysyła nowe żądanie, należy nawiązać nowe połączenie. Na początku istnienia sieci WWW ten rodzaj modelu odpowiedzi na żądanie miał sens, ale wraz z rozwojem potrzeba aktualizacji w czasie rzeczywistym stała się bardziej widoczna i HTTP request przestawał wystarczać. Wtedy zaczęły pojawiać się różne sposoby manipulacji żądaniami HTTP.
Te manipulacje są często nazywane jako Comet techniques, a tzw. długie odpytywanie http (HTTP long polling) jest najlepszym ich przykładem. Przepływ połączenia jest tu taki sam, jak w przypadku tradycyjnego żądania HTTP, z tą różnicą, że serwer próbuje utrzymać połączenie klienta tak długo, jak to tylko możliwe. Odbywa się to poprzez odesłanie odpowiedzi tylko wtedy, gdy serwer ma nowe dane do wysłania do klienta (lub gdy upłynie limit czasu). Stwarza to złudzenie, że dane są aktualizowane w czasie rzeczywistym. Długie odpytywanie jest używane na przykład przez Facebooka i Google.
Sprawdź oferty pracy na TeamQuest
Jak działają websockety?
Połączenie WebSocket rozpoczyna się od wysłania przez klienta żądania do serwera. Jednak żądanie wygląda trochę inaczej. Zamiast żądania zaczynającego się od http://, mamy żądanie zaczynające się od ws://. Jeśli serwer wyrazi zgodę na połączenie, odeśle odpowiedź zawierającą kod stanu 101, który potwierdza, że przełącznik w protokole został zaakceptowany.
W tym momencie zainicjowano uzgadnianie między klientem a serwerem, co oznacza, że połączenie TCP/IP zostało nawiązane i jest pozostawione otwarte. Umożliwia to dwukierunkowy przepływ komunikatów między serwerem a klientem z dużą szybkością. To połączenie pozostanie otwarte, dopóki klient lub serwer nie zdecyduje się je zakończyć. Z technicznego punktu widzenia połączenie WebSocket używa protokołu HTTP aż do początkowego uzgadniania połączenia (handshake). Następnie po prostu konwertuje połączenie HTTP na połączenie WebSocket.
Ten typ połączenia jest często nazywany połączeniem Full-Duplex (to taki termin bardziej telekomunikacyjny, opisujący sposób działania linii naziemnej). Chodzi o to, że podczas rozmowy telefonicznej obie strony mogą rozmawiać i być słyszane jednocześnie. Ten termin pasuje więc do sposobu w jaki działa połączenie WebSocket.
Jeśli szukać właściwego rozwiązania dla siebie, najbardziej aktywnie obecnie używane biblioteki Websocket (open-source) to Socket.io, WS, Sockjs, SocketCluster.io, Feathera czy Faye-web socket-node. Z WebSocket korzysta na przykład Visual Studo Codebase – powiedziałbyś?
