HTTP では足りないとき

リアルタイムアプリに別の接続が必要な理由

⏱ 想定 ~7 分

01 · 読む

ここまでで、リクエストに応答するサーバーを作ってきました。ブラウザがページを要求すれば、サーバーは返す。フォームを送信すれば、サーバーが処理する。このリクエストとレスポンスのサイクルが、 web のほとんどを動かしています。

でも、もしサーバーの方から、こちらが頼みもしないうちにあなたに話しかけたいとしたら？

チェスの相手が一手指した。チャットのメッセージが届いた。株価が変わった。通常の HTTP では、サーバーは自分から動けません —— こちらが聞くまで待つしかないのです。リアルタイムなものを作ろうとすると、ここが問題になります。

💡 想像してみてくださいHTTP は手紙のやり取りに似ています。書いて、送って、返事を待つ。動きはしますが、毎回どうしてもタイムラグがある。一方、 WebSocket は電話のようなものです —— 接続がつながっている間、どちらからでも自由に話せます。手紙の返事を待つ必要はありません。

ポイントまとめ

WebSocket が登場する前、エンジニアは polling という手法でリアルタイム機能を無理やり実現していました。ブラウザが 1 〜 2 秒おきに server へ「更新ありますか？」と聞きにいき、あれば送り、なければ空のレスポンスを返す、という方式です。

技術的には動きます。でも無駄が多い。 30 秒おきにピザ屋へ電話して「私の注文できましたか？」と聞く様子を想像してみてください。たいていの場合答えは「まだ」で、お互いの時間を消耗するだけです。

WebSocket はこのハックを本物の解決策に置き換えます：常時開かれた接続を保ち、どちらからでもいつでもメッセージを送れる仕組みです。問い合わせは要りません。

ポイントまとめ

次は、 WebSocket 接続がどう確立されるかを見ていきます —— 通常の HTTP リクエストから始まり、そこからアップグレードされます。

ブラウザは普通の HTTP リクエストを server へ送りますが、特別なヘッダー「Upgrade: websocket」を含めます。これで server に「HTTP から WebSocket に切り替えたい」と伝えます。

Server が WebSocket に対応していれば、ステータスコード 101（Switching Protocols）で応答します。これで HTTP 接続が WebSocket 接続にアップグレードされます。

ここからは、両者がいつでもメッセージを送れます。 Server は client に聞かれなくてもデータをプッシュできるし、 client もレスポンスを待たずに server へ送れます。

どちらの側も「frame」と呼ばれる小さなデータパケットを送ります。リクエストとレスポンスのパターンはなく、必要に応じてメッセージが行き来するだけ。チェスの一手が相手の画面にすぐ反映されるのも、これが理由です。

どちらの側からでもいつでも接続を閉じられます。ブラウザは画面を離れたときに閉じ、 server はログアウト時に閉じる。それまでは開いたままです。

それぞれの機能を分類してみましょう：これは HTTP？それとも WebSocket？

（このセクションはインタラクティブです — JavaScript を有効にしてください。）

マルチプレイヤーゲームで WebSocket が HTTP より優れている最大の点は？

HTTP のリクエスト・レスポンスのサイクルとは違い、 WebSocket は _____ な接続を確立し、両者がいつでもメッセージを送れます。

⚠ 全機能のインタラクティブ体験には JavaScript が必要です。JavaScript を有効にして再読み込みしてください。

※ このサイトは独立した教育プロジェクトで、Anthropic の公式製品ではありません。Claude™ は Anthropic, PBC の商標です。