プレーンな HTTP の代わりに WebSocket、SSE、long-polling をいつ使いますか？

Question

IT Interview Practice · Accepted Answer

プレーンな HTTP は **request/response** です：クライアントが尋ね、サーバーが答え、終わり。これは、*サーバー*が新しいものを持ったときにいつでもデータを push する必要がある**リアルタイム**機能（チャット、ライブダッシュボード、通知、共同編集）には不向きです。選択肢は、HTTP のクライアント起点モデルを回避する方法であり、複雑さのスペクトル上に並びます：

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** はどこでも動くフォールバックです：クライアントは通常のリクエストを送り、サーバーはデータが得られるまでそれを開いたまま保持し、その後クライアントが即座に再リクエストします。プレーンな HTTP 上で push を近似しますが、メッセージごとに 1 リクエストサイクルを浪費し latency を加えます。

**SSE（Server-Sent Events）**は、単一の長命な HTTP レスポンス上の、軽量で標準化された**一方向**ストリーム（server → client）です。サーバーだけが push する場合に理想的です — ライブフィード、通知、進捗、LLM トークンのストリーミング。シンプルで、通常の HTTP/2 上で動き（特別なインフラ不要）、自動再接続します。制限：一方向でテキストのみです。

**WebSocket** は、単一の HTTP コネクションを、両側が最小のメッセージごとオーバーヘッドでいつでも送れる、永続的な **full-duplex** の TCP チャネルにアップグレードします。真に双方向で低 latency な対話に使います：チャット、マルチプレイヤーゲーム、共同エディタ、取引。代償は運用面です — proxy、load balancer、autoscaler が設定を要する状態を持つコネクションであり、再接続、heartbeat、backpressure を自前で作らねばなりません。

**経験則：**既定ではプレーンな HTTP を使う；server→client のストリーミングには **SSE** を使う；本当に双方向のリアルタイムが必要なときだけ **WebSocket** に手を伸ばす；普遍的なフォールバックとして **long-polling** を残す。

## なぜ重要なのか

リアルタイムのトランスポートを選ぶことは、古典的な senior の設計判断であり、素朴な答え（「何でも WebSocket を使えばいい」）はたいてい間違いです。面接官は、あなたが道具を*通信パターン* — 一方向対双方向、latency の要求、メッセージ量 — に合わせられること、そして状態を持つ長命なコネクションの**運用コスト** — sticky session、スケーリング、proxy タイムアウト、再接続ロジック — を天秤にかけられることを見たがっています。SSE がしばしば「サーバーが更新を push する」を WebSocket より単純にカバーすること、long-polling が依然として堅牢なフォールバックであることを認識できれば、最も派手な選択肢に飛びつくのではなく、本物の production 経験を持つことを示せます。

なぜ重要なのか

関連する質問