Porównanie SSE, WebSockets i pollingu

WebSockets ustanawia trwałe połączenie TCP między klientem a serwerem. Obie strony mogą wysyłać wiadomości w dowolnym momencie, dlatego WebSockets doskonale nadają się do prawdziwie interaktywnej komunikacji w czasie rzeczywistym: aplikacji czatowych, wspólnej edycji dokumentów, gier wieloosobowych i kursorów na żywo. Połączenie pozostaje otwarte do momentu jawnego zamknięcia go przez jedną ze stron.

SSE (Server-Sent Events) korzysta ze zwykłego połączenia HTTP, za pośrednictwem którego serwer przesyła dane do klienta w postaci serii zdarzeń. Połączenie jest jednokierunkowe: dane wysyła wyłącznie serwer. Klient nie może odsyłać wiadomości przez połączenie SSE — w tym celu wykonuje osobne żądania HTTP. SSE jest implementowane za pomocą przeglądarkowego API EventSource.

Short polling oznacza, że klient wysyła żądanie HTTP w stałych odstępach, na przykład co 5 sekund: „Czy są jakieś aktualizacje?”. Serwer natychmiast odpowiada bieżącymi danymi. Jest to najprostsza implementacja, ale także najbardziej nieefektywna — klient wykonuje wiele żądań, gdy nie pojawiło się nic nowego. Rozwiązanie nadaje się wyłącznie do danych zmieniających się bardzo powoli.

Long polling jest udoskonaleniem short polling: klient wysyła żądanie, a serwer utrzymuje połączenie otwarte do momentu udostępnienia nowych danych. Gdy pojawią się nowe dane, serwer odpowiada, a klient natychmiast wysyła kolejne żądanie. Ogranicza to liczbę niepotrzebnych odpowiedzi, ale nadal powoduje większy narzut niż SSE, ponieważ każda odpowiedź wymaga ponownego ustanowienia połączenia TCP.

SSE ma kilka praktycznych przewag nad WebSockets w przypadku przesyłania danych z serwera do klienta: działa przez zwykłe HTTP, bez aktualizacji protokołu, dzięki czemu przechodzi przez firmowe serwery proxy i load balancery bez specjalnej konfiguracji. EventSource ma wbudowaną funkcję automatycznego ponownego łączenia. Protokół tekstowy jest łatwy do debugowania w karcie sieciowej przeglądarki.

SSE ma istotne ograniczenia: obsługuje wyłącznie tekst, więc dane binarne muszą być kodowane w base64; jest jednokierunkowe, więc klient nie może odsyłać danych; ponadto HTTP/1.1 ogranicza liczbę jednoczesnych połączeń EventSource na domenę do 6 (HTTP/2 multipleksuje je w ramach jednego połączenia, eliminując ten limit). W przypadku komunikacji dwukierunkowej SSE wymaga uzupełnienia o wywołania REST.

SSE doskonale nadaje się do: pulpitów nawigacyjnych wyświetlających dane w czasie rzeczywistym, kanałów powiadomień przesyłających nowe alerty, pasków postępu dla długo działających procesów serwera, kanałów mediów społecznościowych aktualizowanych na żywo, tickerów z cenami akcji oraz interfejsów czatowych, w których wiadomości płyną wyłącznie z serwera do klienta (wiadomości są przesyłane osobno za pomocą POST). We wszystkich tych scenariuszach aktualizacje inicjuje serwer.

WebSockets są niezbędne, gdy potrzebna jest dwukierunkowa komunikacja o małych opóźnieniach: czat w czasie rzeczywistym, w którym wiadomości płyną w obu kierunkach przez jedno połączenie, wspólna edycja w stylu Google Docs, gry wieloosobowe, w których działania klienta i aktualizacje serwera zachodzą szybko, aukcje na żywo oraz platformy handlowe. Dwukierunkowość uzasadnia dodatkową złożoność.

HTTP/2 znacząco zwiększa praktyczność SSE. Multipleksowanie połączeń sprawia, że wszystkie strumienie SSE z danej domeny współdzielą jedno połączenie TCP, eliminując limit liczby połączeń na domenę. Jeśli serwer obsługuje HTTP/2, SSE staje się jeszcze praktyczniejszym rozwiązaniem w przypadku pulpitów nawigacyjnych z wieloma jednoczesnymi strumieniami danych.

Kryteria wyboru: jeśli potrzebują Państwo dwukierunkowej komunikacji o małych opóźnieniach → WebSockets. Jeśli serwer przesyła aktualizacje, a klient tylko je odczytuje → SSE. Jeśli potrzebują Państwo sporadycznych aktualizacji i ważna jest prostota → polling. Jeśli interfejs API serwera już istnieje i nie można dodać SSE → polling. Należy zacząć od najprostszego rozwiązania, które spełnia wymagania dotyczące opóźnień.

Ramkowanie WebSocket dodaje od 2 do 14 bajtów do każdej wiadomości po początkowym uzgadnianiu połączenia. SSE przesyła nagłówki HTTP raz na połączenie, a następnie tekst rozdzielany znakami nowej linii. Short polling zawiera pełne nagłówki żądania i odpowiedzi HTTP przy każdym odpytywaniu. W przypadku danych o wysokiej częstotliwości WebSockets mają mniejszy narzut. Przy rzadkich aktualizacjach przesyłanych przez serwer SSE jest prostsze i zapewnia akceptowalny narzut.

Jaka jest najważniejsza różnica w kierunku komunikacji między SSE a WebSockets?

WebSockets: dwukierunkowe, trwałe połączenie TCP (czat, gry, wspólna edycja). SSE: jednokierunkowe przesyłanie danych z serwera do klienta przez HTTP za pomocą API EventSource (powiadomienia, pulpity nawigacyjne, kanały). Short polling: żądania w stałych odstępach (najprostsze, ale najbardziej nieefektywne rozwiązanie). Long polling: serwer wstrzymuje odpowiedź do czasu udostępnienia danych (mniej żądań, większe opóźnienia). Zalety SSE: działanie przez serwery proxy i automatyczne ponowne łączenie. Ograniczenia SSE: tylko tekst, komunikacja jednokierunkowa i limity liczby połączeń w HTTP/1.1.