WebSocket, Server-Sent Events, server push HTTP/2, MQTT, AMQP e WebRTC todos resolvem “empurrar para o cliente quando algo acontece”. Eles têm perfis operacionais radicalmente diferentes — esta página é o cheat sheet para escolher o certo.
O sgcWebSockets entrega na caixa cada cliente e servidor de tempo real mainstream para Delphi — então a pergunta deixa de ser “dá pra fazer em Pascal?” e vira “qual protocolo encaixa no trabalho?”
“Comunicação em tempo real em Delphi” é um termo guarda-chuva — na prática cobre seis primitivas de rede fundamentalmente diferentes, cada uma com propriedades distintas de latência, ordenação, fan-out, NAT traversal e infraestrutura. Escolher errado custa meses: você sobe um loop de polling REST, bate em tetos de escalabilidade, retrofita uma camada WebSocket, e descobre que MQTT teria sido um encaixe melhor porque seu tráfego é fundamentalmente pub/sub. Esta página é o guia curto e opinativo.
Olhe as linhas; a coluna com mais “Sim” vence.
| Necessidade | WebSocket | SSE | HTTP/2 push | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| Bidirecional | Sim | Não (só servidor→cliente) | Não | Sim (pub/sub) | Sim (pub/sub) | Sim (peer) |
| Broadcast com fan-out | Implementado no servidor | Só por cliente | Só por stream | Nativo (topics) | Nativo (exchanges) | Não (1:1) |
| Suportado no navegador | Sim | Sim | Sim | Via WebSocket | Via WebSocket | Sim |
| Por proxy corporativo | Via wss://443 | Sim (parece HTTP) | Sim | Via WSS | Via WSS | Frequentemente (TURN) |
| Entrega garantida | Em nível de app | Em nível de app | Em nível de app | QoS 1/2 | Com ack | SCTP confiável |
| Dispositivos de baixa banda | Médio | Baixo | Médio | Excelente | Médio | Médio |
| P2P / NAT traversal | Não (servidor) | Não | Não | Não (broker) | Não (broker) | Sim (ICE) |
| Criptografia ponta a ponta | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | DTLS-SRTP E2E |
| Servidor pode rodar em Delphi | Sim | Sim | Sim | Use broker externo | Use broker externo | Sim (signalling + STUN/TURN) |
Escolha padrão. Bidirecional, baixo overhead, funciona em todo navegador. Escolha para dashboards ao vivo, chat, edição colaborativa, protocolos de aplicação customizados. Componente →
Escolha quando o tráfego é só servidor → cliente e você quer o modelo mais simples possível: uma resposta HTTP de longa duração que faz stream de texto. Embutido em todo navegador, sem biblioteca. SSE →
Use para enviar preventivamente sub-recursos (CSS, JS, JSON) junto com o documento principal — corta um round-trip. Não é um canal “push” de propósito geral. HTTP/2 →
Pub/sub para IoT, telemetria, presença móvel, veículos conectados. QoS 1/2, mensagens retidas, last-will, overhead minúsculo no fio. Precisa de broker. MQTT →
Mensageria corporativa: filas duráveis, exchanges, routing keys, dead-letter, RabbitMQ / Azure Service Bus / IBM MQ. Escolha em vez de MQTT quando precisa de roteamento rico. AMQP →
Peer-to-peer direto com NAT traversal — data channels para colaboração, eventualmente áudio/vídeo. A única opção para P2P criptografado ponta a ponta. WebRTC →
O snippet Delphi viável mínimo para conectar com cada protocolo — mesma biblioteca, mesmo padrão 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;Se você se pega chamando Get a cada dois segundos e fazendo diff da resposta, a resposta quase sempre é SSE (só servidor→cliente) ou WebSocket (bidirecional). A economia de CPU e banda é rotineiramente 95 %+.
Se seu tráfego é fundamentalmente fan-out baseado em tópicos (dispositivos publicando telemetria, dashboards assinando), rodar um protocolo customizado JSON-sobre-WebSocket reimplementa MQTT de jeito ruim. Use o broker.
O push promise do HTTP/2 é uma otimização de sub-recurso, não um canal de push geral. Para streams servidor-para-cliente de longa duração você ainda quer SSE, WebSocket ou MQTT.
O transporte principal.
Pub/sub para IoT e telemetria.
HTTP multiplexado e push.
Data channels peer-to-peer.
Streaming simples servidor→cliente.
Mensageria corporativa via RabbitMQ, Service Bus, IBM MQ.
Exemplo prático de SSE.
Como colocar nginx / Envoy / ALB na frente de WebSocket e HTTP/2.