WebSocket, Server-Sent Events, HTTP/2-Server-Push, MQTT, AMQP und WebRTC lösen alle dieselbe Aufgabe: „Den Client benachrichtigen, wenn etwas passiert.“ Sie haben grundverschiedene Betriebsprofile — diese Seite ist der Spickzettel, um das richtige zu wählen.
sgcWebSockets liefert jeden Mainstream-Delphi-Echtzeit-Client und -Server out of the box mit — die Frage ist nicht mehr „Kann ich das in Pascal?“, sondern „Welches Protokoll passt zur Aufgabe?“
„Echtzeitkommunikation in Delphi“ ist ein Sammelbegriff — in der Praxis umfasst er sechs fundamental unterschiedliche Netzwerkprimitive, jedes mit eigenen Eigenschaften bei Latenz, Reihenfolge, Fan-Out, NAT-Traversal und Infrastruktur. Die falsche Wahl kostet Monate: Du fährst eine Polling-REST-Schleife, läufst gegen Skalierungsgrenzen, rüstest eine WebSocket-Schicht nach und merkst dann, dass MQTT besser gepasst hätte, weil dein Traffic fundamental Pub/Sub ist. Diese Seite ist der kurze, klare Leitfaden.
Scanne die Zeilen; die Spalte mit den meisten Grüns gewinnt.
| Anforderung | WebSocket | SSE | HTTP/2-Push | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| Bidirektional | Ja | Nein (nur Server→Client) | Nein | Ja (Pub/Sub) | Ja (Pub/Sub) | Ja (Peer) |
| Fan-Out-Broadcast | Serverseitig implementiert | Nur pro Client | Nur pro Stream | Nativ (Topics) | Nativ (Exchanges) | Nein (1:1) |
| Browser-Unterstützung | Ja | Ja | Ja | Über WebSocket | Über WebSocket | Ja |
| Durch Firmen-Proxy | Über wss://443 | Ja (wirkt wie HTTP) | Ja | Über WSS | Über WSS | Oft (TURN) |
| Garantierte Auslieferung | App-seitig | App-seitig | App-seitig | QoS 1/2 | Ack-basiert | SCTP zuverlässig |
| Schmalbandige Geräte | Mittel | Niedrig | Mittel | Hervorragend | Mittel | Mittel |
| P2P / NAT-Traversal | Nein (Server) | Nein | Nein | Nein (Broker) | Nein (Broker) | Ja (ICE) |
| Ende-zu-Ende-verschlüsselt | TLS Hop-by-Hop | TLS Hop-by-Hop | TLS Hop-by-Hop | TLS Hop-by-Hop | TLS Hop-by-Hop | DTLS-SRTP E2E |
| Server kann in Delphi laufen | Ja | Ja | Ja | Externen Broker nutzen | Externen Broker nutzen | Ja (Signalling + STUN/TURN) |
Standardwahl. Bidirektional, geringer Overhead, läuft in jedem Browser. Wähle es für Live-Dashboards, Chats, kollaboratives Editieren, eigene Anwendungsprotokolle. Komponente →
Wähle es, wenn der Verkehr nur Server → Client läuft und du das einfachste Modell willst: eine langlebige HTTP-Antwort, die Text streamt. In jedem Browser ohne Bibliothek eingebaut. SSE →
Nutze es, um Sub-Ressourcen (CSS, JS, JSON) präventiv mit dem Hauptdokument zu senden — spart einen Round-Trip. Kein allgemeiner „Push“-Kanal. HTTP/2 →
Pub/Sub für IoT, Telemetrie, Mobile-Presence, vernetzte Fahrzeuge. QoS 1/2, Retained Messages, Last Will, winziger Wire-Overhead. Benötigt einen Broker. MQTT →
Enterprise-Messaging: dauerhafte Queues, Exchanges, Routing-Keys, Dead-Letter-Handling, RabbitMQ / Azure Service Bus / IBM MQ. Wähle es statt MQTT, wenn du reichhaltiges Routing brauchst. AMQP →
Direkter Peer-to-Peer mit NAT-Traversal — Data Channels für Kollaboration, später Audio/Video. Die einzige Option für E2E-verschlüsseltes P2P. WebRTC →
Das minimal nötige Delphi-Snippet zum Verbinden mit jedem Protokoll — dieselbe Bibliothek, dasselbe Komponenten-Muster.
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;Wenn du dich beim Aufruf von Get alle zwei Sekunden wiederfindest und die Antwort diffst, ist die Antwort fast immer SSE (nur Server→Client) oder WebSocket (bidirektional). Die CPU- und Bandbreitenersparnis liegt routinemäßig bei 95 %+.
Wenn dein Verkehr fundamental topic-basiertes Fan-Out ist (Geräte publishen Telemetrie, Dashboards subscriben), reimplementiert ein eigenes JSON-über-WebSocket-Protokoll MQTT schlecht. Nutze den Broker.
Der HTTP/2-Push-Promise ist eine Sub-Ressourcen-Optimierung, kein allgemeiner Push-Kanal. Für langlebige Server-zu-Client-Streams willst du weiterhin SSE, WebSocket oder MQTT.
Der Flaggschiff-Transport.
Pub/Sub für IoT und Telemetrie.
Multiplexed HTTP und Push.
Peer-to-Peer-Data-Channels.
Einfaches Server→Client-Streaming.
Enterprise-Messaging über RabbitMQ, Service Bus, IBM MQ.
Praxis-SSE-Beispiel.
Wie man nginx / Envoy / ALB vor WebSocket und HTTP/2 setzt.