WebSocket: Web上でのリアルタイム通信

WebSocket: Web上でのリアルタイム通信

従来のWebはリクエスト・レスポンスモデルで動作します。ブラウザが何かを要求し、サーバーが応答します。しかし、サーバーが要求なしにブラウザにデータを送信する必要がある場合はどうでしょうか？そこでWebSocketの出番です。WebSocketはブラウザとサーバーの間に永続的な双方向接続を提供し、リアルタイム通信を可能にします。

WebSocketの違い

通常のHTTPでは、ブラウザは新しいデータがないかサーバーに問い合わせ続ける必要があります。これはポーリングと呼ばれる手法です。ほとんどのポーリングは何も返さないため、帯域幅とサーバーリソースを浪費する非効率的な方法です。WebSocketはこのモデルを逆転させます。接続は開いたままになり、どちらの側もいつでもデータを送信できます。サーバーはクライアントの要求を待たずに、即座に更新をプッシュできます。

WebSocket接続は通常のHTTPリクエストとして開始され、その後WebSocketプロトコルにアップグレードされます。アップグレードされると、どちらかが閉じるまで接続は開いたままになります。データは双方向に同時に流れることができ、メッセージあたりのオーバーヘッドはわずか数バイトのフレーミングと非常に低くなります。

一般的なユースケース

WebSocketはリアルタイム更新が必要なあらゆるアプリケーションに最適です。チャットアプリケーションはメッセージを即座に配信するために使用します。ライブダッシュボードは株価、サーバーメトリクス、スポーツスコアを変化に応じて更新します。Google Docsのような共同編集ツールは、複数のユーザー間で変更を同期するためにWebSocketを使用します。マルチプレイヤーゲームはリアルタイムのゲーム状態更新に使用します。

WebSocketを使った構築

クライアント側では、WebSocket APIは最新のブラウザに組み込まれています。URLを指定してWebSocketオブジェクトを作成し、open、message、closeなどのイベントをリッスンします。データの送信はsocket.send()を呼び出すだけです。サーバー側では、ほとんどのフレームワークにWebSocketサポートが組み込まれているか、アドオンとして利用可能です。

より複雑なアプリケーションでは、Socket.IOのようなライブラリが生のWebSocketの上に便利な機能を追加します。接続が切れた場合の自動再接続、WebSocketが利用できない場合のHTTPロングポーリングへのフォールバック、ルームや名前空間のような高レベルの抽象化などです。

WebSocketのスケーリング

WebSocketはユーザーごとに開かれた接続を維持するため、通常のHTTPリクエストよりもサーバー上のメモリを多く使用します。数千、数百万の同時接続がある場合、スケーリングについて考える必要があります。一般的なアプローチは、Redisのようなpub/subシステムを使用して、複数のサーバーインスタンス間でメッセージをブロードキャストすることです。ロードバランサーはスティッキーセッションまたはWebSocketアップグレードプロトコルをサポートする必要があります。

Server-Sent Events (SSE) のような代替アプローチは、サーバーからクライアントへの一方向通信にはよりシンプルです。また、非常に高いスループットが必要なシナリオでは、WebRTCデータチャネルの方が効率的な場合があります。