WebSocket, Server-Sent Events, server push HTTP/2, MQTT, AMQP e WebRTC risolvono tutti il problema di “avvisare il client quando succede qualcosa”. Hanno profili operativi radicalmente diversi — questa pagina è il bigliettino per scegliere quello giusto.
sgcWebSockets distribuisce nel box ogni client e server real-time Delphi mainstream — così la domanda smette di essere “posso farlo in Pascal?” e diventa “quale protocollo è giusto per questo lavoro?”
“Comunicazione real-time in Delphi” è un termine ombrello — in pratica copre sei primitive di rete fondamentalmente diverse, ciascuna con differenti proprietà di latenza, ordinamento, fan-out, NAT traversal e infrastruttura. Scegliere male costa mesi: spedisci un loop di polling REST, raggiungi soffitti di scalabilità, ci attacchi sopra un layer WebSocket, poi scopri che MQTT sarebbe stato più adatto perché il tuo traffico è fondamentalmente pub/sub. Questa pagina è la guida breve e schierata.
Scorri le righe; vince la colonna con più verde.
| Esigenza | WebSocket | SSE | Push HTTP/2 | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| Bidirezionale | Sì | No (solo server→client) | No | Sì (pub/sub) | Sì (pub/sub) | Sì (peer) |
| Broadcast a fan-out | Implementato dal server | Solo per client | Solo per stream | Nativo (topic) | Nativo (exchange) | No (1:1) |
| Supportato dai browser | Sì | Sì | Sì | Via WebSocket | Via WebSocket | Sì |
| Attraverso proxy aziendale | Via wss://443 | Sì (sembra HTTP) | Sì | Via WSS | Via WSS | Spesso (TURN) |
| Consegna garantita | Livello applicativo | Livello applicativo | Livello applicativo | QoS 1/2 | Ack | SCTP affidabile |
| Dispositivi a banda stretta | Medio | Basso | Medio | Eccellente | Medio | Medio |
| P2P / NAT traversal | No (server) | No | No | No (broker) | No (broker) | Sì (ICE) |
| Cifrato 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 |
| Server eseguibile in Delphi | Sì | Sì | Sì | Usa broker esterno | Usa broker esterno | Sì (signalling + STUN/TURN) |
Scelta predefinita. Bidirezionale, basso overhead, funziona in ogni browser. Sceglilo per dashboard live, chat, editing collaborativo, protocolli applicativi custom. Componente →
Sceglilo quando il traffico è solo server → client e vuoi il modello più semplice possibile: una response HTTP di lunga durata che fa lo streaming di testo. Integrato in ogni browser senza librerie. SSE →
Usalo per inviare in anticipo sotto-risorse (CSS, JS, JSON) insieme al documento principale — risparmia un round-trip. Non è un canale “push” generico. HTTP/2 →
Pub/sub per IoT, telemetria, presenza mobile, veicoli connessi. QoS 1/2, messaggi retained, last-will, overhead di rete minimo. Richiede un broker. MQTT →
Messaging enterprise: code durabili, exchange, routing key, gestione dead-letter, RabbitMQ / Azure Service Bus / IBM MQ. Scegli rispetto a MQTT quando serve routing ricco. AMQP →
Peer-to-peer diretto con NAT traversal — data channel per la collaborazione, eventualmente audio/video. L'unica opzione per P2P cifrato end-to-end. WebRTC →
Lo snippet Delphi minimo per connettersi con ciascun protocollo — stessa libreria, stesso pattern di componente.
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;Se ti ritrovi a chiamare Get ogni due secondi e a confrontare la response, la risposta è quasi sempre SSE (solo server→client) o WebSocket (bidirezionale). I risparmi di CPU e banda sono di norma 95 %+.
Se il tuo traffico è fondamentalmente fan-out basato su topic (device che pubblicano telemetria, dashboard che si abbonano), eseguire un protocollo JSON-su-WebSocket custom reimplementa male MQTT. Usa il broker.
Il push promise di HTTP/2 è un'ottimizzazione di sotto-risorse, non un canale push generico. Per stream server-client di lunga durata vuoi comunque SSE, WebSocket o MQTT.
Il trasporto di punta.
Pub/sub per IoT e telemetria.
HTTP multiplexato e push.
Data channel peer-to-peer.
Streaming server→client semplice.
Messaging enterprise via RabbitMQ, Service Bus, IBM MQ.
Esempio pratico SSE.
Come mettere nginx / Envoy / ALB davanti a WebSocket e HTTP/2.