WebSocket

WebSocket とは

通常の HTTP は「ブラウザが聞いて、サーバが答える」一方向のリクエスト駆動です。サーバから自発的に「新着が来たよ」と伝える手段がありません。

WebSocket は、最初に HTTP で接続を確立した後、その接続を双方向の通信路に昇格させます。一度つながれば、サーバからもブラウザからも、いつでもメッセージを送れます。

• 1 本の接続を開いたまま維持する（張りっぱなし）。
• どちらからでも送れる全二重（双方向）。
• テキストでもバイナリでも送れる。

HTTP ポーリングとの違い

WebSocket 以前は、HTTP で「定期的に問い合わせる」ことで擬似的なリアルタイムを実現していました。代表的な手法と比べると、無駄の差が見えてきます。

方式	仕組み	弱点
ポーリング	数秒おきに「更新ある?」と HTTP で聞き続ける	更新が無くても通信が走り、遅延も粒度任せ
ロングポーリング	更新が来るまでサーバが応答を保留する	接続のたびに HTTP の往復コストがかかる
WebSocket	接続を保ったまま双方向に送り合う	接続維持のリソース・対応インフラが必要

ポーリングは「更新が無いのに何度も聞く」空振りが避けられず、間隔を詰めるほど負荷が増え、広げるほど遅延が増えます。WebSocket はサーバ起点で即座に届くため、この板挟みから解放されます。

接続の流れ（ハンドシェイク）

WebSocket は最初だけ HTTPを使います。ブラウザが Upgrade ヘッダ付きでリクエストし、サーバが 101 Switching Protocols で応じると、以後はその接続が WebSocket になります。URL のスキームは ws://（暗号化は wss://）です。

const socket = new WebSocket("wss://example.com/chat");

socket.addEventListener("open", () => {
  socket.send(JSON.stringify({ type: "hello" }));
});

socket.addEventListener("message", (event) => {
  const data = JSON.parse(event.data);
  console.log("received", data);
});

socket.addEventListener("close", () => {
  console.log("disconnected"); // 再接続処理を入れることが多い
});

ブラウザ標準の WebSocket API はシンプルですが、実務では再接続や部屋（ルーム）管理などをライブラリ（例: Socket.IO）に任せることもよくあります。

主な用途

低遅延の双方向通信が活きる場面で使われます。

• チャット / メッセージング：相手の発言を即座に表示する。
• 通知・アラート：サーバ起点でプッシュ的に届ける。
• 同時編集 / 共同作業：他人のカーソルや変更をリアルタイム反映する。
• ライブ更新：株価・スポーツのスコア・ダッシュボードなど刻々変わる値。
• オンラインゲーム：操作と状態の高速なやり取り。

逆に、サーバ → ブラウザの一方向の通知だけで足りるなら、HTTP の延長で扱える **SSE（Server-Sent Events）**の方が手軽な選択肢になります。

観点	WebSocket	SSE
方向	双方向	サーバ → ブラウザの一方向
プロトコル	専用（ws / wss）	通常の HTTP（テキストストリーム）
自動再接続	自前で実装	標準で備わる
向く用途	チャット・同時編集・ゲーム	通知・フィード・進捗表示

注意点

接続を維持し続ける性質ゆえの留意点があります。

• スケール：多数の同時接続を扱うサーバ設計や、複数台に分散したときのメッセージ配信（Pub/Sub など）が課題になる。
• 切断と再接続：モバイル回線などでは切れる前提で、再接続とメッセージの取りこぼし対策を用意する。
• 認証：接続確立時にトークンなどで認証する。途中で権限を失効させたい場合の扱いも検討する。

土台となる HTTP の理解があると、ハンドシェイクや wss の位置づけが掴みやすくなります。