WebSocket, Server-Sent Events, server push HTTP/2, MQTT, AMQP y WebRTC resuelven todos “empuja al cliente cuando ocurra algo”. Tienen perfiles operativos radicalmente diferentes — esta página es la chuleta para escoger el adecuado.
sgcWebSockets incluye en la caja todos los clientes y servidores en tiempo real mainstream de Delphi — así la pregunta deja de ser “¿puedo hacer esto en Pascal?” y pasa a ser “¿qué protocolo encaja con el trabajo?”.
“Comunicación en tiempo real en Delphi” es un término paraguas — en la práctica cubre seis primitivas de red fundamentalmente distintas, cada una con propiedades distintas de latencia, ordenación, fan-out, traversal de NAT e infraestructura. Elegir mal cuesta meses: lanzas un bucle de polling REST, te topas con techos de escalabilidad, retrofitas una capa WebSocket y entonces descubres que MQTT habría encajado mejor porque tu tráfico es fundamentalmente pub/sub. Esta página es la guía corta y opinada.
Repasa las filas; la columna con más verde gana.
| Necesidad | WebSocket | SSE | Push HTTP/2 | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| Bidireccional | Sí | No (sólo servidor→cliente) | No | Sí (pub/sub) | Sí (pub/sub) | Sí (peer) |
| Broadcast fan-out | Implementado en servidor | Sólo por cliente | Sólo por stream | Nativo (topics) | Nativo (exchanges) | No (1:1) |
| Soportado en navegador | Sí | Sí | Sí | Vía WebSocket | Vía WebSocket | Sí |
| A través de proxy corporativo | Vía wss://443 | Sí (parece HTTP) | Sí | Vía WSS | Vía WSS | A menudo (TURN) |
| Entrega garantizada | A nivel app | A nivel app | A nivel app | QoS 1/2 | Con ack | SCTP fiable |
| Dispositivos de bajo ancho de banda | Medio | Bajo | Medio | Excelente | Medio | Medio |
| P2P / traversal de NAT | No (servidor) | No | No | No (broker) | No (broker) | Sí (ICE) |
| Cifrado de extremo a extremo | TLS por salto | TLS por salto | TLS por salto | TLS por salto | TLS por salto | DTLS-SRTP E2E |
| El servidor puede correr en Delphi | Sí | Sí | Sí | Usa broker externo | Usa broker externo | Sí (señalización + STUN/TURN) |
Elección por defecto. Bidireccional, bajo sobrecoste, funciona en cualquier navegador. Elígelo para dashboards en vivo, chat, edición colaborativa, protocolos de aplicación personalizados. Componente →
Elígelo cuando el tráfico es sólo servidor → cliente y quieres el modelo más simple posible: una respuesta HTTP de larga vida que hace streaming de texto. Integrado en cada navegador sin librería. SSE →
Úsalo para enviar preventivamente sub-recursos (CSS, JS, JSON) junto con el documento principal — ahorra un round-trip. No es un canal “push” de propósito general. HTTP/2 →
Pub/sub para IoT, telemetría, presencia móvil, vehículos conectados. QoS 1/2, mensajes retained, last-will, sobrecoste de wire mínimo. Necesita un broker. MQTT →
Mensajería empresarial: colas duraderas, exchanges, routing keys, dead-letter, RabbitMQ / Azure Service Bus / IBM MQ. Elígelo sobre MQTT cuando necesites enrutamiento rico. AMQP →
Peer-to-peer directo con traversal de NAT — data channels para colaboración, eventualmente audio/vídeo. La única opción para P2P cifrado E2E. WebRTC →
El snippet Delphi mínimo viable para conectarse con cada protocolo — misma librería, mismo patrón de 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;Si te ves llamando a Get cada dos segundos y comparando la respuesta, la solución es casi siempre SSE (sólo servidor→cliente) o WebSocket (bidireccional). Los ahorros de CPU y ancho de banda son rutinariamente del 95 %+.
Si tu tráfico es fundamentalmente fan-out basado en topics (dispositivos publicando telemetría, dashboards suscribiendo), correr un protocolo JSON-sobre-WebSocket personalizado reimplementa MQTT mal. Usa el broker.
Push promise HTTP/2 es una optimización de sub-recursos, no un canal push de propósito general. Para streams server-to-client de larga vida sigues queriendo SSE, WebSocket o MQTT.
El transporte estrella.
Pub/sub para IoT y telemetría.
HTTP multiplexado y push.
Data channels peer-to-peer.
Streaming sencillo servidor→cliente.
Mensajería empresarial vía RabbitMQ, Service Bus, IBM MQ.
Ejemplo SSE práctico.
Cómo poner nginx / Envoy / ALB delante de WebSocket y HTTP/2.