PlayInfoBox

ホーム /ネットワーク /WebSocket(ウェブソケット)とは?基礎知識を整理

WebSocket(ウェブソケット)とは?基礎知識を整理

リアルタイムチャットや価格のライブ更新は、ページを再読み込みせずにどうやって即座に更新されているのでしょうか。

WebSocketとは

通常のHTTP通信は、クライアントがリクエストを送って初めてサーバーが応答する「リクエスト・レスポンス」型の仕組みのため、サーバー側から自発的にクライアントへ新しい情報を知らせることはできません。WebSocketはこの制約を超え、接続が維持されている間はサーバーとクライアントのどちらからでも好きなタイミングでメッセージを送れる、真の双方向リアルタイム通信を実現します。

WebSocket以前の方式:ポーリング

WebSocket登場以前は、クライアントが数秒おきに「何か新しい情報はある?」とサーバーへ繰り返し問い合わせるポーリングという手法でリアルタイム風の動作を再現していました。短いポーリング(short polling)は一定間隔でリクエストを送り続けサーバーとネットワークに不要な負荷をかけ、ロングポーリング(long polling)はサーバーが新しい情報が生じるまで応答を遅らせることである程度改善しましたが、それでもリクエストごとにHTTPヘッダーのオーバーヘッドが発生し、完全な双方向通信でもありませんでした。WebSocketは1本の持続的な接続によって、こうした繰り返しリクエストなしにこの問題を解決します。

ハンドシェイクとプロトコルのアップグレード

WebSocket接続は、通常のHTTPリクエストとして始まります。クライアントが「Upgrade: websocket」ヘッダーを含むHTTPリクエストを送り、サーバーがこれを受け入れるとHTTPステータスコード101(Switching Protocols)で応答します。この瞬間から、同じTCP接続はもはやHTTPのリクエスト・レスポンス方式ではなく、どちらの側からでもいつでもフレームを送受信できるWebSocket接続に切り替わります。

「ws://」と「wss://」の違い

ws://は暗号化されていないWebSocket接続を、wss://はTLSで暗号化されたWebSocket接続を意味し、HTTPとHTTPSの関係と同じです。通常のウェブサイトでHTTPSを使うのと同じように、機密性のあるデータをやり取りする場合は必ずwss://を使い、途中で盗聴や改ざんされないようにする必要があります。ほとんどのブラウザは、HTTPSで読み込まれたページから暗号化されていないws://接続を試みることを、セキュリティ上の理由でブロックします。

実際の活用事例

WebSocket(またはそれに類するリアルタイム技術)は、チャットアプリで相手のメッセージが再読み込みなしに即座に表示される仕組み、株や仮想通貨のチャートがリアルタイムで動き続ける仕組み、オンラインゲームでの状態のリアルタイム同期、複数人が同じ文書を同時編集する際に互いのカーソルや変更点がリアルタイムに表示される仕組みなど、幅広く使われています。

WebSocketと代替技術の比較

サーバーからクライアントへ一方向にデータを送るだけでよい場合、Server-Sent Events(SSE)というよりシンプルな代替技術があります。通常のHTTPの上に構築されているため実装が簡単で、既存のHTTPインフラとも相性がよいのが特徴です。一方、チャットやゲームのようにクライアント側も頻繁にメッセージを送る必要がある場合は、真の双方向通信が可能なWebSocketのほうが適しています。

WebSocketはHTTPとどう関係しているか

WebSocketをHTTPを置き換えるものだと考えがちですが、実際にはHTTPリクエストとして始まり、ハンドシェイクが成功して初めて(ステータスコード101で)プロトコルが切り替わります。つまりWebSocketサーバーは最初のHTTPリクエストを正しく処理する必要があり、通常のHTTPしか理解しない一部の古いプロキシや厳格なファイアウォールなどのインフラが、このアップグレードを妨げることがあります。

実運用のWebSocketアプリに追加の仕組みが必要な理由

スマートフォンがWi-Fiからモバイル回線へ切り替わったり、パソコンがスリープ状態になったりすると、基本的なWebSocket接続はどちらの側も気づかないまま静かに切断されることがあります。そのため実際のアプリケーションでは、接続の生死を検知するための定期的なping/pongハートビートフレームや、自動的に回復する再接続処理を組み込むのが一般的です。また、各WebSocket接続はステートレスなHTTPリクエストとは異なり、長時間状態を保持し続けるものであるため、WebSocketサービスを複数のサーバーへスケールさせるには、スティッキーセッションや共有メッセージブローカーなどを用いて、クライアントが常に自分の接続状態を保持しているサーバーへたどり着けるようにする追加の工夫が必要になります。

よくある質問

ファイアウォールでWebSocket接続がブロックされることはありますか?

はい。一部の厳格な社内ネットワークや公共Wi-Fiのファイアウォールは、標準のHTTP・HTTPSポート(80・443)以外への接続やプロトコルアップグレードのリクエストをブロックすることがあります。ただし、ほとんどのWebSocketサービスは通常HTTPSが使う443番ポートをそのまま利用することで、こうした問題を最小限に抑えています。

WebSocketはモバイル環境でも安定して動作しますか?

モバイル回線の切り替え(Wi-Fi⇔セルラー)や、画面が消えてアプリがバックグラウンドに移行したタイミングで接続が切れることがあるため、実務では接続が切れた際に自動的に再接続を試みる処理を合わせて実装するのが一般的です。