API・メッセージング

WebSocket うぇぶそけっと

リアルタイム通信双方向通信HTTPTCPプッシュ通知ロングポーリング
WebSocketについて教えて

簡単に言うとこんな感じ!

WebSocketは、サーバーとブラウザが「常につながったまま」でおしゃべりできる仕組みだよ!普通のWebは「質問→返答→切断」の繰り返しだけど、WebSocketは電話みたいに繋ぎっぱなしで、サーバー側からもいつでも話しかけられるんだ!


WebSocketとは

WebSocketは、Webブラウザとサーバーの間で双方向かつリアルタイムの通信を実現するプロトコル(通信規約)です。従来のHTTP通信が「リクエスト→レスポンス→切断」という一問一答型なのに対し、WebSocketは一度接続を確立すると、その接続を維持したままどちら側からでも自由にデータを送り合えます。

身近な例で言うと、チャットアプリ・株価のリアルタイム表示・オンラインゲーム・共同編集ツールなどがWebSocketの恩恵を受けています。ページを更新しなくても新しいメッセージが届いたり、他のユーザーの操作が即座に反映されたりするのは、WebSocketがあるからこそです。

2011年にIETFによってRFC 6455として標準化され、現在はすべての主要ブラウザでサポートされています。接続の開始はHTTPで行われますが、その後「アップグレード」と呼ばれる手続きを経てWebSocketプロトコルに切り替わります。


WebSocketの仕組みと特徴

接続の流れ(ハンドシェイク)

WebSocketの接続確立は「ハンドシェイク(握手)」と呼ばれます。まず普通のHTTPリクエストとして始まり、途中でWebSocket用の接続に切り替わります。

クライアント → サーバー
  GET /chat HTTP/1.1
  Upgrade: websocket          ← 「WebSocketに切り替えたい!」
  Connection: Upgrade
  Sec-WebSocket-Key: dGhlIHNhbXBsZQ==

サーバー → クライアント
  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket          ← 「OK!切り替えるよ!」
  Connection: Upgrade
  Sec-WebSocket-Accept: s3pPL...

  ↓ ここからWebSocket通信スタート(切断するまで継続)

HTTP通信との比較

項目HTTP(従来)WebSocket
通信方向一方向(クライアント→サーバー)双方向
接続の持続リクエストごとに切断接続を維持
サーバーからの送信基本的に不可いつでも可能
オーバーヘッドリクエストごとにHTTPヘッダーが発生初回のみ
向いている用途Webページ取得・REST APIリアルタイム通信
URLスキームhttp:// / https://ws:// / wss://

覚え方のコツ

「WebSocket = 電話、HTTP = 手紙」 手紙(HTTP)は送るたびに封筒(ヘッダー)が必要で、返事も別の手紙。 電話(WebSocket)は一度つながれば、お互いいつでも話しかけられる!


歴史と背景

  • 2008年以前 — リアルタイムWebを実現するには「ポーリング」(一定間隔でサーバーに問い合わせ)や「ロングポーリング」(レスポンスを意図的に遅らせて疑似プッシュを実現)しか手段がなく、非効率だった
  • 2008年 — Ian Hickson(Google)らによってWebSocketの概念がHTML5仕様の一部として提案される
  • 2010年 — Google ChromeがWebSocketを初めて実装。リアルタイムWebの可能性が広がる
  • 2011年12月 — IETFが RFC 6455 としてWebSocketプロトコルを正式標準化
  • 2012年 — W3CがWebSocket APIを勧告(ブラウザのJavaScriptからWebSocketを使うためのインターフェース仕様)
  • 2013年頃〜Node.jsの普及とともにWebSocketサーバーの実装が容易になり、チャット・通知・ゲームなどに急速に普及
  • 現在 — 全モダンブラウザ・主要言語・クラウドサービスでサポートされ、リアルタイム通信のデファクトスタンダードに

HTTP通信 vs WebSocket:接続モデルの違い

従来のHTTPとWebSocketでは、接続の考え方が根本的に異なります。

HTTP vs WebSocket 通信モデル HTTP(従来の通信) クライアント サーバー ① リクエスト ② レスポンス ── 切断 ── ③ リクエスト ④ レスポンス ── 切断 ── ⚠ 課題 毎回ヘッダーを送るため無駄が多い サーバーから能動的に送れない WebSocket(リアルタイム通信) クライアント サーバー ① ハンドシェイク ② 接続確立(101) 接続を維持 送信 プッシュ 送信 プッシュ (切断まで継続) ✓ メリット ヘッダーオーバーヘッドが最小限 サーバーからいつでもプッシュ可能

WebSocketの主なユースケース

カテゴリ具体例
チャット・メッセージングSlack、LINEのWeb版、カスタマーサポートチャット
リアルタイムデータ表示株価・為替レート、スポーツスコア、IoTセンサー値
コラボレーションツールGoogle Docs的な共同編集、Figmaのリアルタイム共有
オンラインゲームマルチプレイヤーゲームの操作同期
通知・アラート管理画面のリアルタイムアラート、注文通知

WebSocketとServer-Sent Events(SSE)の違い

WebSocketに似た技術としてSSE(Server-Sent Events)があります。

項目WebSocketSSE
通信方向双方向サーバー→クライアントのみ
プロトコルws:// / wss://HTTP
複雑さやや複雑シンプル
向いている用途チャット・ゲームニュースフィード・通知

関連する規格・RFC

規格・RFC番号内容
RFC 6455WebSocketプロトコルの本体仕様(2011年)。ハンドシェイク・フレーム形式・クローズ処理を定義
RFC 7936WebSocketに関する補足要件の明確化
RFC 8441HTTP/2上でのWebSocket実行(Bootstrapping WebSockets with HTTP/2)

関連用語

  • HTTP — WebSocket接続の起点となるプロトコル。WebSocketはHTTPのUpgradeヘッダーで切り替わる
  • TCP — WebSocketが下位層で使用するトランスポートプロトコル
  • REST API — HTTPベースの一問一答型API。WebSocketとよく対比される
  • SSE(Server-Sent Events) — サーバーからクライアントへの一方向プッシュ通信。WebSocketより軽量
  • ロングポーリング — WebSocket登場前のリアルタイム通信の代替手法
  • TLS/SSLwss:// による暗号化WebSocket通信を実現するセキュリティ層
  • プッシュ通知 — サーバーから能動的にクライアントへ情報を届ける仕組み全般
  • Socket.IO — WebSocketを扱いやすくしたJavaScriptライブラリ。フォールバック機能付き