WebSocket, Server-Sent Events, HTTP/2 server push, MQTT, AMQP i WebRTC wszystkie rozwiązują „pchnij klienta, gdy coś się stanie”. Mają radykalnie różne profile operacyjne — ta strona to ściągawka do wyboru właściwego.
sgcWebSockets dostarcza każdego głównego klienta i serwer czasu rzeczywistego Delphi w pakiecie — więc pytanie przestaje być „czy mogę to zrobić w Pascalu?” i staje się „który protokół pasuje do zadania?”
„Komunikacja w czasie rzeczywistym w Delphi” to termin parasolowy — w praktyce pokrywa sześć fundamentalnie różnych prymitywów sieciowych, każdy z innymi właściwościami latencji, kolejności, fan-outu, traversal NAT i infrastruktury. Wybranie źle kosztuje miesiące: dostarczasz pętlę polling REST, trafiasz na sufity skalowalności, retrofituje warstwę WebSocket, potem odkrywasz, że MQTT byłby lepszym dopasowaniem, bo Twój ruch jest fundamentalnie pub/sub. Ta strona to krótki, opiniotwórczy przewodnik.
Skanuj wiersze; kolumna z najwięcej zieleni wygrywa.
| Potrzeba | WebSocket | SSE | HTTP/2 push | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| Dwukierunkowy | Tak | Nie (tylko serwer→klient) | Nie | Tak (pub/sub) | Tak (pub/sub) | Tak (peer) |
| Rozgłaszanie fan-out | Implementowane przez serwer | Tylko per-klient | Tylko per-strumień | Natywne (topics) | Natywne (exchanges) | Nie (1:1) |
| Wspierany przez przeglądarkę | Tak | Tak | Tak | Przez WebSocket | Przez WebSocket | Tak |
| Przez firmowe proxy | Przez wss://443 | Tak (wygląda jak HTTP) | Tak | Przez WSS | Przez WSS | Często (TURN) |
| Gwarantowane dostarczenie | Poziom aplikacji | Poziom aplikacji | Poziom aplikacji | QoS 1/2 | Ack’d | SCTP niezawodne |
| Urządzenia o niskiej przepustowości | Średnie | Niska | Średnia | Doskonałe | Średnie | Średnie |
| P2P / traversal NAT | Nie (serwer) | Nie | Nie | Nie (broker) | Nie (broker) | Tak (ICE) |
| Szyfrowanie end-to-end | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | DTLS-SRTP E2E |
| Serwer może działać w Delphi | Tak | Tak | Tak | Użyj zewnętrznego brokera | Użyj zewnętrznego brokera | Tak (sygnalizacja + STUN/TURN) |
Domyślny wybór. Dwukierunkowy, niski narzut, działa w każdej przeglądarce. Wybierz dla pulpitów na żywo, czatu, kolaboracyjnej edycji, niestandardowych protokołów aplikacji. Komponent →
Wybierz, gdy ruch jest tylko serwer → klient i chcesz najprostszego możliwego modelu: długotrwała odpowiedź HTTP strumieniująca tekst. Wbudowane w każdą przeglądarkę bez biblioteki. SSE →
Użyj, by prewencyjnie wysłać subzasoby (CSS, JS, JSON) obok głównego dokumentu — tnie round-trip. Nie ogólny kanał „push”. HTTP/2 →
Pub/sub dla IoT, telemetrii, obecności mobilnej, pojazdów połączonych. QoS 1/2, retained messages, last-will, mały narzut wire. Potrzebuje brokera. MQTT →
Komunikaty przedsiębiorstwa: trwałe kolejki, exchanges, klucze routingu, obsługa dead-letter, RabbitMQ / Azure Service Bus / IBM MQ. Wybierz zamiast MQTT, gdy potrzebujesz bogatego routingu. AMQP →
Bezpośrednie peer-to-peer z traversal NAT — kanały danych dla kolaboracji, ewentualnie audio/video. Jedyna opcja dla E2E-szyfrowanego P2P. WebRTC →
Minimalny opłacalny fragment Delphi do połączenia z każdym protokołem — ta sama biblioteka, ten sam wzorzec komponentu.
WS := TsgcWebSocketClient.Create(nil);
WS.URL := 'wss://echo.websocket.events';
WS.OnMessage := DoMessage;
WS.Active := True;
WS.WriteData('hello');SSE := TsgcWSPClient_SSE.Create(nil);
SSE.URL := 'https://stream.example.com/events';
SSE.OnEvent := DoEvent;
SSE.Active := True;MQTT := TsgcWSPClient_MQTT.Create(nil);
MQTT.Client := WSClient;
MQTT.OnMQTTPublish := DoMqttPublish;
WSClient.Active := True;
MQTT.Subscribe('sensors/+/temperature', mtqsAtLeastOnce);AMQP := TsgcWSPClient_AMQP.Create(nil);
AMQP.Client := WSClient;
AMQP.OnAMQPMessage := DoAmqpMessage;
WSClient.Active := True;
AMQP.Consume('orders');H2 := TsgcHTTP2Client.Create(nil);
H2.Host := 'api.example.com';
H2.Port := 443;
H2.TLS := True;
H2.OnResponse := DoResponse;
H2.Connect;
for i := 1 to 10 do H2.Get(Format('/items/%d', [i]));RTC := TsgcWSPClient_WebRTC.Create(nil);
RTC.Client := WSSignal;
RTC.IceServers.Add.URL := 'stun:stun.l.google.com:19302';
RTC.OnDataChannelMessage := DoP2PMessage;
WSSignal.Active := True;
RTC.CreateDataChannel('chat', True, True);
RTC.CreateOffer;Jeśli przyłapiesz się na wywoływaniu Get co dwie sekundy i diff odpowiedzi, odpowiedzią prawie zawsze jest SSE (tylko serwer→klient) lub WebSocket (dwukierunkowy). Oszczędności CPU i pasma to rutynowo 95 %+.
Jeśli Twój ruch jest fundamentalnie fan-out oparty na tematach (urządzenia publikujące telemetrię, pulpity subskrybujące), uruchamianie niestandardowego protokołu JSON-over-WebSocket implementuje MQTT źle. Użyj brokera.
HTTP/2 push promise to optymalizacja subzasobu, nie ogólny kanał push. Dla długotrwałych strumieni serwer-do-klienta nadal chcesz SSE, WebSocket lub MQTT.
Flagowy transport.
Pub/sub IoT i telemetrii.
Multipleksowane HTTP i push.
Kanały danych peer-to-peer.
Proste strumieniowanie serwer→klient.
Komunikaty przedsiębiorstwa przez RabbitMQ, Service Bus, IBM MQ.
Praktyczny przykład SSE.
Jak postawić nginx / Envoy / ALB przed WebSocket i HTTP/2.