Delphi でのリアルタイム通信 — プロトコルを選ぶ
WebSocket、Server-Sent Events、HTTP/2 サーバープッシュ、MQTT、AMQP、WebRTC はすべて「何かが起きたらクライアントにプッシュする」を解決します。運用プロファイルが根本的に異なります — このページは正しいものを選ぶためのチートシートです。
WebSocket、Server-Sent Events、HTTP/2 サーバープッシュ、MQTT、AMQP、WebRTC はすべて「何かが起きたらクライアントにプッシュする」を解決します。運用プロファイルが根本的に異なります — このページは正しいものを選ぶためのチートシートです。
sgcWebSockets はすべての主流 Delphi リアルタイムクライアントとサーバーを箱に同梱します — だから問いは「これは Pascal で可能か？」ではなく「どのプロトコルが仕事に合うか？」になります。
「Delphi でのリアルタイム通信」は包括的な用語です — 実用上 6 つの根本的に異なるネットワークプリミティブをカバーし、それぞれがレイテンシ、順序付け、ファンアウト、NAT 越え、インフラストラクチャの特性が異なります。誤った選択は数か月を浪費します: ポーリング REST ループを出荷し、スケーラビリティ上限に達し、WebSocket 層を後付けし、その後トラフィックが本質的に pub/sub であるため MQTT の方が適合したと発見する。このページは短く意見ある案内です。
行をスキャン; 最も多くの「あり」を持つ列が勝ち。
| 必要なもの | WebSocket | SSE | HTTP/2 push | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| 双方向 | あり | なし（サーバー→クライアントのみ） | なし | あり（pub/sub） | あり（pub/sub） | あり（ピア） |
| ファンアウトブロードキャスト | サーバー実装 | クライアントごとのみ | ストリームごとのみ | ネイティブ（トピック） | ネイティブ（エクスチェンジ） | なし（1:1） |
| ブラウザサポート | あり | あり | あり | WebSocket 経由 | WebSocket 経由 | あり |
| 企業プロキシ越し | wss://443 経由 | あり（HTTP に見える） | あり | WSS 経由 | WSS 経由 | 多く（TURN） |
| 保証された配信 | アプリレベル | アプリレベル | アプリレベル | QoS 1/2 | Ack 付き | SCTP 信頼性 |
| 低帯域デバイス | 中 | 低 | 中 | 優秀 | 中 | 中 |
| P2P / NAT 越え | なし（サーバー） | なし | なし | なし（ブローカー） | なし（ブローカー） | あり（ICE） |
| エンド・ツー・エンド暗号化 | TLS ホップごと | TLS ホップごと | TLS ホップごと | TLS ホップごと | TLS ホップごと | DTLS-SRTP E2E |
| サーバーを Delphi で実行可 | あり | あり | あり | 外部ブローカー使用 | 外部ブローカー使用 | あり（シグナリング + STUN/TURN） |
デフォルトの選択。双方向、低オーバーヘッド、すべてのブラウザで動作。ライブダッシュボード、チャット、共同編集、カスタムアプリケーションプロトコルに選んでください。コンポーネント →
トラフィックがサーバー → クライアントのみで、最も単純なモデルが欲しいときに選んでください: テキストをストリームする長寿命の HTTP レスポンス。ライブラリなしですべてのブラウザに組み込まれています。SSE →
サブリソース（CSS、JS、JSON）をメインドキュメントと並行して先取り送信するために使用 — ラウンドトリップをカット。汎用的な「プッシュ」チャネルではありません。HTTP/2 →
IoT、テレメトリ、モバイルプレゼンス、コネクテッドビークルの pub/sub。QoS 1/2、retained メッセージ、last-will、小さなワイヤーオーバーヘッド。ブローカーが必要。MQTT →
エンタープライズメッセージング: 永続キュー、エクスチェンジ、ルーティングキー、dead-letter ハンドリング、RabbitMQ / Azure Service Bus / IBM MQ。リッチなルーティングが必要なら MQTT より優先。AMQP →
NAT 越え付きの直接ピア・ツー・ピア — 共同作業のためのデータチャネル、最終的にはオーディオ／ビデオ。E2E 暗号化 P2P の唯一の選択肢。WebRTC →
各プロトコルに接続する最小限の Delphi スニペット — 同じライブラリ、同じコンポーネントパターン。
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;2 秒ごとに Get を呼び出してレスポンスを diff している自分に気づいたら、答えはほぼ常に SSE（サーバー→クライアントのみ）または WebSocket（双方向）です。CPU と帯域の節約は通常 95 % 以上です。
トラフィックが本質的にトピックベースのファンアウト（デバイスがテレメトリを発行、ダッシュボードが購読）なら、カスタム JSON-over-WebSocket プロトコルを実行することは MQTT を不適切に再実装することです。ブローカーを使用してください。
HTTP/2 のpush promise はサブリソース最適化で、汎用プッシュチャネルではありません。長寿命のサーバー・ツー・クライアントストリームには SSE、WebSocket、MQTT が欲しいままです。
フラッグシップトランスポート。
IoT とテレメトリの pub/sub。
多重化 HTTP とプッシュ。
ピア・ツー・ピアデータチャネル。
シンプルなサーバー→クライアントストリーミング。
RabbitMQ、Service Bus、IBM MQ 経由のエンタープライズメッセージング。
実用的な SSE の例。
nginx / Envoy / ALB を WebSocket と HTTP/2 の前に置く方法。