ネットワーク

Webの初期段階では、ブラウザはシンプルなドキュメントビューアに過ぎませんでした。ページをリクエストすると、サーバーがそれをレンダリングし、接続が閉じられていました。この「リクエスト・レスポンス」のサイクルが HTTP (Hypertext Transfer Protocol) の核心です。 しかし、Webアプリケーションがリアルタイムチャット、ライブの株価表示、共同編集、マルチプレイヤーゲームなどのリッチでインタラクティブな体験へと進化するにつれて、従来のHTTPモデルの限界が浮き彫りになりました。 リアルタイムの更新情報を取得するために、開発者は当初、以下のような回避策に頼っていました。 ショートポーリング (Short Polling): ブラウザが数秒おきにHTTPリクエストを繰り返し送信し、新しいデータがあるかサーバーに問い合わせます。これは大量のヘッダーオーバーヘッドを生み出し、サーバーリソースを浪費します。 ロングポーリング (Long Polling / Comet): ブラウザがリクエストを送信し、サーバーは新しいデータが利用可能になるまで接続を保持します。データが送信されると接続が閉じられ、ブラウザは即座に新しいリクエストを開きます。これは管理が複雑で、接続確立時のオーバーヘッドも依然として発生します。 **WebSocket（ウェブソケット）**は、単一のTCP接続上で永続的、双方向、かつ全二重（フルデュプレックス）の通信を行うための標準化されたプロトコルを導入することで、これらの制限を解決しました。 WebSocketとは何か？ WebSocket（RFC 6455で定義）はHTTPと並行して動作します。HTTPがクライアントからしかリクエストを開始できないステートレスなプロトコルであるのに対し、WebSocket接続は一度確立されると無期限に開いたままになり、クライアントとサーバーの両方がいつでも最小限の遅延でデータを送信し合うことができます。 WebSocketの根本的なルールは以下の通りです。 一度接続が確立されると、どちらの側からでも、新しい接続リクエストを開始することなく、いつでもメッセージを送信できます。 ステップバイステップ・ウォークスルー：接続のライフサイクル WebSocket接続は、ハンドシェイク、データ転送、切断という3つの明確なフェーズを経ます。 1. HTTPハンドシェイク（プロトコルのアップグレード） ファイアウォールやルーターは、ポート80（HTTP）および443（HTTPS）の標準的なウェブトラフィックを許可するように設定されているため、WebSocketは標準のHTTP/1.1リクエストとして開始されます。これはアップグレードハンドシェイクと呼ばれます。 クライアントからのリクエスト クライアントは、プロトコルの切り替えを要求する特定のヘッダーを含むHTTP GETリクエストを送信します。 GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 Origin: https://example.com Upgrade: websocket と Connection: Upgrade: プロトコルの切り替えを希望していることをサーバーに伝えます。 Sec-WebSocket-Key: Base64でエンコードされたランダムな16バイトの値。サーバーがハンドシェイクを受信し、WebSocketプロトコルを理解していることを証明するために使用されます。 Sec-WebSocket-Version: WebSocketプロトコルのバージョンを指定します（通常は13）。 Origin: サーバーが接続を許可するかどうかを判断するために使用されます（不正なサイトからのクロスサイト接続を防ぐセキュリティチェック）。 サーバーからのレスポンス サーバーがWebSocketをサポートしている場合、リクエストを検証し、HTTPステータスコード 101 Switching Protocols（プロトコル切り替え）で応答します。