WebSocket, Server-Sent Events, server push HTTP/2, MQTT, AMQP et WebRTC résolvent tous « pousser le client quand quelque chose arrive ». Ils ont des profils opérationnels radicalement différents — cette page est l'antisèche pour choisir le bon.
sgcWebSockets livre chaque client et serveur temps réel Delphi principal dans la boîte — donc la question n'est plus « puis-je faire cela en Pascal ? » mais « quel protocole convient au job ? »
« Communication temps réel en Delphi » est un terme parapluie — en pratique il couvre six primitives réseau fondamentalement différentes, chacune avec des propriétés différentes de latence, ordonnancement, fan-out, traversée NAT et infrastructure. Choisir incorrectement coûte des mois : vous livrez une boucle de polling REST, atteignez des plafonds de scalabilité, rétrofittez une couche WebSocket, puis découvrez que MQTT aurait été un meilleur choix parce que votre trafic est fondamentalement pub/sub. Cette page est le guide court et opinionné.
Scannez les lignes ; la colonne avec le plus de vert gagne.
| Besoin | WebSocket | SSE | HTTP/2 push | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| Bi-directionnel | Oui | Non (serveur→client seulement) | Non | Oui (pub/sub) | Oui (pub/sub) | Oui (pair) |
| Diffusion fan-out | Implémenté côté serveur | Par client seulement | Par flux seulement | Natif (topics) | Natif (exchanges) | Non (1:1) |
| Supporté par navigateur | Oui | Oui | Oui | Via WebSocket | Via WebSocket | Oui |
| À travers proxy d'entreprise | Via wss://443 | Oui (ressemble à HTTP) | Oui | Via WSS | Via WSS | Souvent (TURN) |
| Livraison garantie | Niveau app | Niveau app | Niveau app | QoS 1/2 | Acquitté | SCTP fiable |
| Appareils à faible bande passante | Moyen | Faible | Moyen | Excellent | Moyen | Moyen |
| P2P / traversée NAT | Non (serveur) | Non | Non | Non (broker) | Non (broker) | Oui (ICE) |
| Chiffré de bout en bout | TLS saut par saut | TLS saut par saut | TLS saut par saut | TLS saut par saut | TLS saut par saut | DTLS-SRTP E2E |
| Le serveur peut tourner en Delphi | Oui | Oui | Oui | Utiliser un broker externe | Utiliser un broker externe | Oui (signalisation + STUN/TURN) |
Choix par défaut. Bi-directionnel, faible surcharge, fonctionne dans chaque navigateur. Choisissez-le pour les tableaux de bord live, chat, édition collaborative, protocoles applicatifs personnalisés. Composant →
Choisissez quand le trafic est serveur → client uniquement et que vous voulez le modèle le plus simple possible : une réponse HTTP longue durée qui streame du texte. Intégré dans chaque navigateur sans bibliothèque. SSE →
Utilisez pour envoyer préventivement des sous-ressources (CSS, JS, JSON) à côté du document principal — économise un aller-retour. Pas un canal « push » polyvalent. HTTP/2 →
Pub/sub pour IoT, télémétrie, présence mobile, véhicules connectés. QoS 1/2, messages retained, last-will, surcharge wire minuscule. Nécessite un broker. MQTT →
Messagerie d'entreprise : files durables, exchanges, routing keys, gestion de dead-letter, RabbitMQ / Azure Service Bus / IBM MQ. Choisissez plutôt que MQTT quand vous avez besoin d'un routage riche. AMQP →
Peer-to-peer direct avec traversée NAT — data channels pour la collaboration, éventuellement audio/vidéo. La seule option pour P2P chiffré de bout en bout. WebRTC →
Le snippet Delphi minimal viable pour se connecter avec chaque protocole — même bibliothèque, même pattern de composant.
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 vous vous retrouvez à appeler Get toutes les deux secondes et à diff la réponse, la réponse est presque toujours SSE (serveur→client uniquement) ou WebSocket (bi-directionnel). Les économies de CPU et de bande passante sont régulièrement de 95 %+.
Si votre trafic est fondamentalement fan-out basé sur topics (appareils publiant de la télémétrie, tableaux de bord s'abonnant), faire tourner un protocole JSON-sur-WebSocket personnalisé ré-implémente MQTT mal. Utilisez le broker.
Le push promise HTTP/2 est une optimisation de sous-ressources, pas un canal push polyvalent. Pour les flux longue durée serveur-vers-client vous voulez toujours SSE, WebSocket ou MQTT.
Le transport phare.
Pub/sub IoT et télémétrie.
HTTP multiplexé et push.
Data channels peer-to-peer.
Streaming serveur→client simple.
Messagerie d'entreprise via RabbitMQ, Service Bus, IBM MQ.
Exemple SSE pratique.
Comment mettre nginx / Envoy / ALB devant WebSocket et HTTP/2.