動作の仕組み
HTTPハンドシェイクで接続を確立後、プロトコルをWebSocketに切り替えて双方向の持続的接続を維持します。
クライアント・サーバー双方から任意のタイミングでメッセージを送信でき、最小限のフレームヘッダーで低遅延通信を実現します。

特徴

• 方式: 双方向の持続的接続
• 実装難易度: ★★★☆☆
• リアルタイム性: ★★★★★

実装例

// クライアント側
const ws = new WebSocket('wss://example.com/ws');

ws.onopen = () => console.log('接続確立');
ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  handleRealtimeUpdate(data);
};

// 双方向通信
ws.send(JSON.stringify({ type: 'chat', message: 'Hello!' }));

// サーバー側 (Node.js + ws)
const wss = new WebSocketServer({ port: 8080 });
wss.on('connection', (ws) => {
  ws.on('message', (data) => {
    // 全クライアントにブロードキャスト
    wss.clients.forEach(client => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(data);
      }
    });
  });
});

最適な使用場面:

• 低遅延の双方向通信
• チャット、ゲーム、協調編集
• 高頻度のデータ交換

制限事項:

• 実装とデバッグの複雑さ
• 接続状態の管理
• スケーリングの課題

スケーラビリティの考え方
同時接続数は技術選択の最も重要な指標の一つです。
ポーリングは接続数が増えるとサーバー負荷が急激に上昇し、WebSocketは持続的接続により効率的に多数のクライアントを扱えます。

同時接続数による技術選択:
- < 100接続: どの技術でも問題なし
- 100-1,000: ポーリング避ける、SSE/WebSocket推奨
- 1,000-10,000: WebSocket + 負荷分散
- 10,000+: WebSocket + マイクロサービス + クラスタリング

要件:

• 即座のメッセージ配信
• 数千人の同時接続
• モバイル対応

技術選択: WebSocket

// 理由:
// 1. 双方向リアルタイム通信が必須
// 2. 高い同時接続数に対応
// 3. モバイルでのバッテリー効率

機能要件

• リアルタイム性の要求レベル
• 通信方向 (一方向/双方向)
• データタイプ (テキスト/バイナリ)
• 同時接続数の想定
• ブラウザ対応範囲

非機能要件

• パフォーマンス要求値
• スケーラビリティ計画
• セキュリティ要件
• 運用保守体制
• 予算とスケジュール

技術制約

• 既存システムとの連携
• インフラ制約
• チームのスキル
• ライブラリ・フレームワーク
• 長期保守性

1. 低遅延の双方向通信が必要
2. 高頻度のデータ交換がある
3. スケーラビリティが重要
4. 効率的なリソース使用を求める