Realtime
wpisy (8)
- Realtime w przeglądarce: od pollingu do WebTransport7/7
Polling, Streaming, SSE, WebSocket czy WebTransport?
Wybór wynika z modelu ruchu: świeżości danych, kierunku, częstotliwości, kolejności i niezawodności. Najprostszy poprawny mechanizm zwykle wygrywa.
- Realtime w przeglądarce: od pollingu do WebTransport6/7
WebTransport: streams i datagramy dla realtime nad HTTP/3
HTTP/3 i QUIC dają jednej sesji wiele niezależnych streamów oraz datagramy. Nie każde dane muszą dotrzeć niezawodnie i w kolejności.
- Realtime w przeglądarce: od pollingu do WebTransport5/7
WebSockets: trwały kanał komunikacji w obu kierunkach
Po handshake nie ma już requestów i odpowiedzi, tylko frames. Trwałe połączenie jest stanem, który dotyka load balancera, deployu i fan-outu między instancjami.
- Realtime w przeglądarce: od pollingu do WebTransport4/7
Server-Sent Events: protokół zdarzeń nad HTTP streamingiem
Standardowy format zdarzeń i reconnect nad strumieniem HTTP. Last-Event-ID daje wznowienie, ale trwałości eventów w systemie już nie załatwia.
- Realtime w przeglądarce: od pollingu do WebTransport3/7
HTTP Streaming: jedna odpowiedź, wiele fragmentów danych
Odpowiedź może powstawać w czasie. Chunk transportowy nie jest wiadomością, więc framing i backpressure stają się sprawą aplikacji.
- Realtime w przeglądarce: od pollingu do WebTransport2/7
Long Polling: kiedy serwer opóźnia odpowiedź
Serwer nie odpowiada, dopóki nie ma czego wysłać. Powstaje ciąg długich requestów, w którym timeout i kursor są częścią protokołu.
- Realtime w przeglądarce: od pollingu do WebTransport1/7
Polling: realtime przez powtarzanie requestu
Opóźnienie jest funkcją interwału, a koszt istnieje nawet wtedy, gdy nic się nie zmienia. W zamian każdy request jest niezależny i cała infrastruktura działa…
- seria · 7 części
Realtime w przeglądarce: od pollingu do WebTransport
Realtime to wymaganie dotyczące maksymalnego opóźnienia informacji, nie nazwa protokołu. Mechanizmy od pollingu po WebTransport, każdy z ograniczenia…