APIやリアルタイム通信の設計をするとき、HTTP・WebSocket・SSEなど選択肢が多くて迷うことがあります。それぞれの通信方向・接続維持の仕方・向いている用途を整理しました。
通信方式比較表
ここに挙げているのは、実際にバイト列をどう運ぶかを定義している「通信方式」です。gRPCはHTTP/2の上に構築されていますが、独自のバイナリ形式・ストリーミングモデルを持つ実体のあるプロトコルなので、他の方式と同列に並べています。
| 通信方式 | 通信方向 | 接続維持 | 主な用途 | 備考 |
|---|---|---|---|---|
| HTTP | → | ❌ 都度接続 | 一般的なAPI通信 | 最も基本的 |
| Long Polling | ←（疑似） | ⚠️ 疑似的に維持 | WebSocketが使えない環境の代替 | 古い環境・Proxy越しでも動作 |
| WebSocket | ⇄ | ✅ 常時接続 | チャット・ゲーム | 高速・双方向 |
| SSE | ← | ✅ 常時接続 | 通知・監視 | 軽量・片方向 |
| gRPC | ⇄ | ✅ 常時接続 | サーバー間通信 | 高速・型安全（HTTP/2ベース） |
（参考）GraphQLは比較表とは別軸
GraphQLはこの表には含めていません。GraphQLは通信方式（プロトコル）ではなく、APIのクエリ言語・設計スタイルだからです。GraphQL自身は独自の接続方式やフレーム形式を持たず、実際の通信は上記のいずれかに乗せて行われます。
| GraphQLの操作 | 実際に使われる通信方式 |
|---|---|
| Query / Mutation | 通常のHTTP（多くはPOST /graphql） |
| Subscription | WebSocketやSSEなど、別途リアルタイム通信を組み合わせる |
つまり「HTTP vs WebSocket vs GraphQL」を同列に並べると、「データの運び方」と「データの問い合わせ方」という別レイヤーの話を混ぜてしまうことになります。gRPCのように独自の通信モデルを持つプロトコルとは、この点で扱いが異なります。
1. HTTP（リクエスト／レスポンス型）
① Client → Server にリクエスト送信
② Server → Client にレスポンスを返す
③ 通信はここで終了（接続が切れる）
④ 必要に応じて次のリクエストを再度送信
概要
クライアントがリクエストを送り、サーバーがレスポンスを返す最も基本的な通信方式です。通信は1回で完結します。
特徴
- リクエストはクライアント起点（クライアント → サーバー）
- 都度接続（常時接続ではない）
- ステートレス（サーバー側はリクエスト間の状態を保持しない）
- REST APIやFetch/Axios通信の基本
用途
- Webページ取得
- 一般的なAPI通信
- フォーム送信
2. Long Polling（ロングポーリング）
① Client → Server にリクエスト送信
② Server はすぐに返さず「新しいデータが来るまで待機」
③ 新しいデータが来たらレスポンスを返す
④ Client はまたすぐ新しいリクエストを送る
→ これをずっと繰り返す
概要
通常のHTTPリクエスト/レスポンスを使って、リアルタイム通信に近い体験を作る手法です。WebSocketが使えない環境での代替として使われます。
仕組み
- クライアントがリクエストを送信する
- サーバーは新しいデータが来るまでレスポンスを保留する
- データが来たらレスポンスを返す
- クライアントはレスポンスを受け取ったらすぐに次のリクエストを送る
これを繰り返すことで、疑似的なリアルタイム通信を実現します。
特徴
- リクエスト自体はクライアント起点だが、実質的にはサーバー起点でデータが届く（疑似的な片方向配信）
- 「接続維持」ではなく、リクエストの即時再送で維持しているように見せている
- 普通のHTTPなので、古い環境やWebSocketをブロックするProxy越しでも動作しやすい
用途
- WebSocketがブロックされる企業ネットワーク
- シンプルな通知機能
3. WebSocket（ウェブソケット）
① Client → Server に1回だけ接続要求
② 接続確立（socket open）
③ あとはサーバーもクライアントも自由に送受信可能
概要
HTTPのUpgrade機構でプロトコルを切り替え、常時接続の双方向通信を行う方式です。
仕組み
- 最初はHTTPで接続する
-
Upgrade: websocketヘッダーで切り替えを要求する - サーバーが
101 Switching Protocolsを返して承認する - 以降は
ws://（またはwss://）の常時接続に切り替わり、軽量な双方向通信ができる
特徴
- 双方向通信（クライアント ⇄ サーバー）
- 常時接続でリアルタイム性が高い
- ハンドシェイク以降はHTTPヘッダーを繰り返さないため軽量
- 接続を維持する分、サーバー側はコネクション数の管理・スケーリング設計が必要になる
用途
- チャット
- 通知・コメント機能
- ゲーム同期
- IoT機器通信
4. Server-Sent Events（SSE）
[Client] ←←← （サーバーからデータが流れてくる） ←←← [Server]
概要
WebSocketのようなプロトコル切り替えは行わず、通常のHTTPレスポンスをContent-Type: text/event-streamとして流し続ける仕組みです。サーバーからクライアントへの一方向ストリーミング通信に使います。
仕組み
- クライアントが
/eventsのようなエンドポイントに1回接続する - サーバーが新しいデータをリアルタイムに送り続ける
- 接続が切れた場合、
EventSource側で自動的に再接続を試みる
実装例（JavaScript）
const eventSource = new EventSource("/events");
eventSource.onmessage = (e) => console.log(e.data);
特徴
- 一方向通信（サーバー → クライアント）
- 接続維持あり、自動再接続にも対応
- 通常のHTTPの上に乗るため実装・運用がシンプルで、WebSocketを塞ぎがちな厳しいProxy環境でも通りやすい
- テキストデータ専用（バイナリは送れない）
- HTTP/1.1ではブラウザの同時接続数制限（1オリジンあたり6本程度）の影響を受けやすい。HTTP/2を使う構成であれば緩和できる
用途
- 通知やライブフィード
- 監視ダッシュボード
- ストリーミングログ表示
5. gRPC（ジーアールピーシー）
概要
Googleが開発した通信プロトコルです。HTTP/2をベースにしていますが、バイナリ形式（Protocol Buffers）のシリアライズと独自のストリーミングモデルを自身で定義している、実体のあるプロトコルです。
特徴
- 高速かつ型安全（
.protoファイルでスキーマを定義する） - Unary（単発）に加えて、サーバー/クライアント/双方向ストリーミングに対応
- JSONより軽量でシリアライズ/デシリアライズが速い
- Webサーバー間通信・マイクロサービス間通信で多用される
- ブラウザから直接は呼べないため、Webから使う場合は
gRPC-Webとプロキシ（Envoyなど）を挟む必要がある
用途
- マイクロサービス間通信
- IoT・機械学習サーバー連携
- 高速なバックエンド間通信
定義ファイル例（Protocol Buffers）
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
}
6.（参考）GraphQL（グラフキューエル） — 通信方式ではなくAPIの設計スタイル
ここまでの5つは「データをどう運ぶか」を定義する通信方式でしたが、GraphQLはレイヤーが異なります。通信方式ではなく、API設計・クエリ言語の仕組みです。クライアントが「必要なデータだけ」を指定して取得できます。
特徴
- 通信はHTTP（Query/Mutation）またはWebSocket（Subscription）の上で行われる。GraphQL自身は独自の接続方式やフレーム形式を持たない
- RESTのようにエンドポイントを分けず、単一エンドポイントに対してクエリで問い合わせる
- 必要なデータだけ取得できるためオーバーフェッチ/アンダーフェッチを避けやすい
- 一方で、ネストしたクエリの書き方次第ではN+1問題が起きやすく、リゾルバ側での対策が必要になる
- RESTのようなURL単位のキャッシュが効きにくく、キャッシュ戦略は別途検討が必要
用途
- 大規模API（GitHub、Shopify、Metaなど）
- ネスト構造のデータを一括取得したい場合
例（GraphQLクエリ）
query {
user(id: 1) {
name
email
}
}
まとめ
- 単発のリクエスト/レスポンスで十分ならHTTP
- WebSocketが使えない環境でリアルタイムっぽさが欲しいならLong Polling
- 双方向かつ高頻度なやり取りが必要ならWebSocket
- サーバーからの一方向配信だけで十分ならSSE
- サーバー間の高速・型安全な通信が必要ならgRPC
用途に対してオーバースペックな方式を選ぶと、実装・運用コストだけが増えることが多いです。まずは「双方向が必要か」「サーバー起点の配信が必要か」を基準に絞り込むと選びやすくなります。
GraphQLは、この5つのどれを選ぶかとは別軸の話です。「エンドポイントをどう設計するか・クライアントにどこまで柔軟な問い合わせを許すか」で迷ったときに検討します。