1. ホーム
2. web
3. WebSocketによるリアルタイムアプリケーション完全ガイド

リアルタイム機能はモダンなWebアプリケーションの基本要件となっています。WebSocketは単一のTCP接続上で全二重通信チャネルを提供し、クライアントとサーバー間の低レイテンシなデータ交換を可能にします。本ガイドでは、WebSocketプロトコル、実装パターン、スケーリング戦略、プロダクショングレードのリアルタイムアプリケーション構築の実践的考慮事項を解説します。

WebSocketプロトコル概要

WebSocketはHTTPアップグレードハンドシェイクから始まります。クライアントがUpgrade: websocketヘッダーを含むHTTPリクエストを送信し、サーバーが101 Switching Protocolsで応答して接続を確立します。確立後は同じTCPソケット上でHTTPからWebSocketプロトコルに移行します。

Client → Server: GET /ws HTTP/1.1
                  Upgrade: websocket
                  Connection: Upgrade
                  Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
                  Sec-WebSocket-Version: 13

Server → Client: HTTP/1.1 101 Switching Protocols
                  Upgrade: websocket
                  Connection: Upgrade
                  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

フレームがWebSocket通信の基本単位です。テキストフレームはUTF-8エンコードされたメッセージ、バイナリフレームはArrayBufferやBlobなどの生バイナリデータ、制御フレームはPing、Pong、Closeによる接続ライフサイクル管理を担当します。

接続ライフサイクル

WebSocket接続の管理には6つの状態があります。サーバー側バリデーション付きの接続確立、双方向通信のためのオープン状態、メッセージの送受信処理、Ping/Pongによるハートビート、適切なクローズコードを使用したグレースフルクローズ、ネットワークエラーやプロトコル違反のエラー処理です。

const ws = new WebSocket("wss://api.example.com/ws");
ws.onopen = () => console.log("Connected");
ws.onmessage = (event) => handleMessage(event.data);
ws.onclose = (event) => handleDisconnect(event.code, event.reason);
ws.onerror = (error) => console.error("WebSocket error:", error);

クローズコードは終了理由を示します。1000は通常終了、1001はエンドポイントの停止、1002はプロトコルエラー、1011は予期しないサーバー状態です。適切なクローズコードを選択することで、クライアントが再接続を適切に処理できます。

再接続戦略

ネットワーク中断は避けられません。堅牢な再接続戦略には、指数バックオフとジッターによるサンダリングハード問題の防止が重要です。

class ReconnectingWebSocket {
  constructor(url, options = {}) {
    this.url = url;
    this.maxRetries = options.maxRetries || Infinity;
    this.baseDelay = options.baseDelay || 1000;
    this.maxDelay = options.maxDelay || 30000;
    this.retryCount = 0;
    this.connect();
  }
  connect() {
    this.ws = new WebSocket(this.url);
    this.ws.onclose = () => this.scheduleReconnect();
  }
  scheduleReconnect() {
    const delay = Math.min(
      this.baseDelay * Math.pow(2, this.retryCount),
      this.maxDelay
    ) + Math.random() * 1000;
    setTimeout(() => this.connect(), delay);
    this.retryCount++;
  }
}

ベストプラクティスとして、最大リトライ回数の制限、接続状態の追跡（接続中、再接続中、切断）、再接続中に送信されたメッセージのバッファリング、持続接続確立後のリトライカウントリセットも重要です。

バイナリメッセージと圧縮

高性能アプリケーションでは、JSONテキストフレームよりもバイナリメッセージの方がオーバーヘッドを削減できます。ArrayBufferとDataViewを使用することで、構造化データの効率的なエンコードとデコードが可能です。

const buffer = new ArrayBuffer(4);
const view = new DataView(buffer);
view.setUint32(0, 12345);
ws.send(buffer);

ws.binaryType = "arraybuffer";
ws.onmessage = (event) => {
  const view = new DataView(event.data);
  const value = view.getUint32(0);
};

Per-Message Deflate（PMCE）圧縮により、テキストメッセージの帯域幅を60〜80%削減できます。ただし、CPUオーバーヘッドが追加され、小さなペイロードではレイテンシが増加する可能性があります。画像や動画など既に圧縮済みのデータには効果がありません。

Redis Pub/Subによるスケーリング

単一サーバーのWebSocketデプロイメントは水平スケーリングできません。Redis pub/subは、複数のアプリケーションサーバー間でメッセージをブロードキャストすることでこの問題を解決します。

Client A → Server 1 → Redis (publish message)
                           ↓
Client B ← Server 2 ← Redis (subscribe, broadcast)

各サーバーがRedisチャネルにサブスクライブします。サーバーがクライアントからメッセージを受信するとRedisにパブリッシュし、他の全サーバーが購読を介して受信し、各クライアントにブロードキャストします。このパターンはルームベースの選択的配信をサポートし、Socket.IOやwsとioredisの組み合わせで実装できます。

SSEおよびロングポーリングとの比較

サーバーからクライアントへの一方向ストリーミングのみが必要な場合（株価ティッカーや通知など）はSSEを選択します。チャット、共同編集、リアルタイムゲームなど双方向通信が必要な場合はWebSocketを選択します。

セキュリティの考慮事項

本番環境ではwss://（TLS上のWebSocket）を排他的に使用します。オリジンヘッダーを検証してクロスサイトWebSocketハイジャックを防止し、接続URLまたは初期ハンドシェイクメッセージで認証トークンを実装し、すべてのメッセージコンテンツをサーバー側でサニタイズし、接続タイムアウトとメッセージサイズ制限を設定し、IPアドレスごとに新規接続をレート制限します。サブプロトコルネゴシエーションはWebSocket APIのバージョン管理メカニズムを提供します。

結論

WebSocketはリアルタイムWeb通信のゴールドスタンダードであり続けています。本番環境での成功には、完全な接続ライフサイクルへの注意、指数バックオフを用いた堅牢な再接続ロジック、Redis pub-subによるスマートなスケーリング、慎重なセキュリティ対策が必要です。SSEやロングポーリングにはそれぞれのニッチがありますが、WebSocketの双方向・低レイテンシな性質は、要求の厳しいリアルタイムアプリケーションに適切な選択肢です。