WebSocketとは？仕組みをわかりやすく図解で解説【初心者向け】

「WebSocketって聞いたことはあるけど、HTTPと何が違うんだろう？」
「チャットアプリやリアルタイム通信で使われているらしいけど、具体的にどんな仕組みなの？」

このような疑問をお持ちではありませんか?

近年、Webアプリケーションにはリアルタイム性がますます求められています。チャット機能、株価のライブ表示、オンラインゲームなど、ユーザーが「今この瞬間」の情報を求める場面が増えているからです。

この記事では、リアルタイム通信を実現する技術「WebSocket」について、初心者の方にもわかりやすく図解を交えて解説します。従来のHTTP通信との違いから、具体的な仕組み、メリット・デメリット、実装の基礎まで、実務で判断に迷わない知識が身につく内容です。

技術的な背景を理解することで、あなたのプロジェクトに最適な通信方式を選択できるようになります。ぜひ最後までお読みください。

WebSocketとは？基本を理解しよう

WebSocketの定義と特徴

WebSocketとは、Webブラウザとサーバー間で双方向通信を実現するための通信プロトコルです。2011年にRFC 6455として標準化されました。

従来のHTTP通信が「クライアントからのリクエストに対してサーバーが応答する」という一方向的な仕組みだったのに対し、WebSocketでは一度接続を確立すれば、サーバー側からも自由にデータを送信できるのが最大の特徴です。

接続の確立時にはHTTPを使用しますが、その後は独自のプロトコルに切り替わり、軽量で高速な通信が可能になります。URLはws://（暗号化する場合はwss://）で始まります。

WebSocketが必要になった背景

Webアプリケーションの進化とともに、リアルタイム性への要求が高まったことが、WebSocket誕生の背景にあります。

かつてのWebサイトは静的なものでしたが、Ajaxの登場により動的になり、次に求められたのがサーバー側で発生した変更を即座にクライアントに反映する仕組みでした。

例えば以下のような場面を考えてみてください：

• チャットアプリで相手のメッセージがリアルタイムで表示される
• 株価や為替レートが刻一刻と更新される
• オンラインゲームで他のプレイヤーの動きが同期される
• 複数人で同時編集できるドキュメントツール

これらを従来のHTTP通信だけで実現しようとすると、クライアントが頻繁にサーバーに問い合わせ続ける必要があり、通信コストやサーバー負荷が大きな課題となっていました。WebSocketは、この課題を解決するために生まれた技術なのです。

身近な活用例

WebSocketは、私たちが日常的に使っているさまざまなサービスで活用されています：

• チャット・メッセージングアプリ：SlackやChatwork、LINEのWeb版など
• 金融・株価情報サービス：証券会社の取引画面や暗号資産取引所
• オンラインゲーム：ブラウザで動作するマルチプレイヤーゲーム
• コラボレーションツール：Google DocsやNotionなど複数人で同時編集できるツール
• IoT・監視システム：センサーデータの監視やサーバー稼働状況のダッシュボード

HTTPとWebSocketの違い

WebSocketの価値を理解するには、従来のHTTP通信との違いを知ることが不可欠です。

HTTPの基本的な仕組み

HTTPは「リクエスト・レスポンス型」のプロトコルです。基本的な流れは以下の通りです：

1. クライアント（ブラウザ）がサーバーにリクエストを送信
2. サーバーがそのリクエストを処理
3. サーバーがレスポンスを返す
4. 通信が終了し、接続が切断される

この一連の流れは、必ずクライアント側から始まるという特徴があります。サーバー側から自発的にデータを送ることはできません。

この仕組みは静的なWebページの表示には効率的ですが、リアルタイム性が求められる用途では課題となります。

HTTPでリアルタイム通信を実現する場合の課題

HTTPでリアルタイム通信を実現しようとすると、以下のような回避策が必要になります。

ポーリング（Polling）

最もシンプルな方法が、クライアントが定期的にサーバーに問い合わせるポーリングです。

課題：

• 無駄な通信が多い：更新がなくても定期的にリクエストを送り続ける
• リアルタイム性が低い：ポーリング間隔によっては、情報の反映に遅延が生じる
• サーバー負荷が高い：多数のクライアントが同時にポーリングすると大きな負担

ロングポーリング（Long Polling）

リクエストを送った後、サーバー側で更新があるまで接続を保持する手法です。

課題：

• 接続の再確立が頻繁に発生：レスポンスごとに接続が切れるため、オーバーヘッドが大きい
• 双方向通信ではない：あくまでクライアントからのリクエストが起点
• サーバーリソースの占有：多数の接続を長時間保持する必要がある

HTTPヘッダーのオーバーヘッド

HTTPでは、リクエストとレスポンスのたびに数百バイトから数キロバイトのヘッダー情報を送信する必要があります。小さなデータを頻繁にやり取りする場合、ヘッダーのサイズがデータ本体を上回ることもあります。

WebSocketの優位性

WebSocketは、これらの課題を根本的に解決します。

一度の接続確立で双方向通信が可能

最初に一度だけ接続を確立すれば、その後は接続を維持したまま双方向に自由にデータをやり取りできます。サーバー側で変更が発生したら、即座にクライアントにデータを送信できます。

軽量なフレーム通信

接続確立後のデータ送信では、最小2バイトのフレームヘッダーだけで済みます。これにより、小さなメッセージを頻繁にやり取りする場合でも、通信コストを大幅に削減できます。

通信コストの比較

項目	HTTP（ポーリング）	WebSocket
初回接続	毎回必要	1回のみ
ヘッダーサイズ	500〜2000バイト/回	2〜14バイト/回
通信方向	一方向	双方向
レイテンシ	ポーリング間隔に依存	ほぼゼロ

例えば、1秒間に10回のデータ更新がある場合、HTTPでは10回の接続確立・切断と10回のヘッダー送信が必要ですが、WebSocketは接続を維持したまま10回の軽量なフレーム送信のみで済みます。

WebSocketの仕組み

接続確立の流れ（ハンドシェイク）

WebSocketの接続は、HTTPから始まり、WebSocketプロトコルにアップグレードするという特徴的な流れで確立されます。

全体の流れ

1. クライアントがHTTPリクエストを送信（アップグレード要求）
2. サーバーがアップグレードに同意（HTTPレスポンス）
3. プロトコルがWebSocketに切り替わる
4. 双方向通信が可能になる

この仕組みにより、WebSocketは既存のWebインフラ（HTTPサーバー、ファイアウォール、プロキシなど）と互換性を保ちながら、新しい通信方式を実現しています。

クライアントからのアップグレードリクエスト

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

重要なヘッダー：

• Upgrade: websocket：WebSocketプロトコルへのアップグレードを要求
• Sec-WebSocket-Key：クライアントが生成したランダムな値（セキュリティ用）
• Sec-WebSocket-Version：WebSocketのバージョン（現在は13が標準）

サーバーからのアップグレード承認

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

ステータスコード101が返された時点で、HTTPプロトコルからWebSocketプロトコルに切り替わり、以降は双方向通信が可能になります。

データのやり取り（フレーム通信）

ハンドシェイクが完了すると、データは「フレーム」という単位でやり取りされます。

フレームの特徴

• 最小2バイトのヘッダー：データが小さい場合、非常に軽量
• フレームの種類：テキスト、バイナリ、制御フレーム（接続維持や切断用）
• マスキング：クライアントからサーバーへのデータは暗号化が必須

データ送受信の流れ

1. 送信側がデータをフレームに格納
2. フレームを送信（接続は維持されたまま）
3. 受信側がフレームを解析
4. アプリケーションにデータを渡す

この一連の流れは、ブラウザやライブラリが自動的に処理してくれるため、開発者はデータの送受信だけに集中できます。

接続の切断方法

WebSocketの接続は、クライアントとサーバーのどちらからでも切断できます。

正常な切断の流れ

1. 切断開始側が「Closeフレーム」を送信
2. 相手側がCloseフレームを受信し、Closeフレームを返信
3. TCP接続を切断

切断理由コード

• 1000：正常終了
• 1001：サーバーがダウンまたはブラウザがページから離脱
• 1006：異常終了（予期しない切断）

異常切断への対応

ネットワークの問題などで予期せず接続が切断されることもあります。対策として：

• ハートビート（Ping/Pong）：定期的にPingフレームを送信して接続を確認
• 自動再接続：切断を検知したら、自動的に再接続を試みる
• 接続状態の監視：readyStateプロパティで状態を確認

WebSocketのメリットとデメリット

メリット

1. 真のリアルタイム性

サーバー側で変更が発生した瞬間に、クライアントにデータを送信できます。遅延がほぼゼロで、ユーザー体験が大幅に向上します。

2. 通信コストの削減

接続を維持したまま軽量なフレームでやり取りするため、HTTPに比べて通信量を大幅に削減できます。特に頻繁な更新が必要な場合に効果的です。

3. サーバー負荷の軽減

ポーリングのように無駄なリクエストを送り続ける必要がないため、サーバー負荷を抑えられます。

4. 双方向通信

クライアントとサーバーが対等にメッセージを送り合えるため、柔軟なアプリケーション設計が可能です。

デメリット・注意点

1. 接続維持のコスト

接続を維持し続ける必要があるため、多数の同時接続を扱う場合、サーバー側のリソース管理が重要になります。

2. 実装の複雑さ

HTTPに比べて、再接続処理やエラーハンドリングなど、考慮すべき点が増えます。

3. プロキシ・ファイアウォールの問題

一部の古いプロキシやファイアウォールでは、WebSocket接続がブロックされる可能性があります。

4. ステートフルな通信

接続を維持するため、サーバー側でクライアントの状態を管理する必要があり、スケーリングに工夫が必要です。

使い分けの判断基準

WebSocketが向いている場面

• チャット・メッセージング機能
• リアルタイムダッシュボード
• 協働編集ツール
• オンラインゲーム
• IoTデバイスからのデータ収集
• 株価・為替などの金融情報表示

従来のHTTPで十分な場面

• 静的なコンテンツの表示
• 一般的なフォーム送信
• ファイルのダウンロード
• ユーザーの操作に応じたデータ取得

判断のポイント

1. データはリアルタイムで更新される必要があるか？
2. クライアントからサーバーへも頻繁に送信するか？
3. 同時接続数はどの程度か？
4. 既存システムとの統合は容易か？

実装の基礎知識

対応環境

ブラウザ対応状況

現在使われているほぼすべてのブラウザでWebSocketは利用可能です：

• Chrome、Firefox、Safari、Edge、Opera：すべて対応済み
• スマートフォンブラウザ：iOS Safari、Android Chromeも対応

サーバー側の対応

主要な言語・フレームワークでWebSocketをサポートしています：

• Node.js：ws、Socket.io
• Python：websockets、Django Channels
• Java：Spring WebSocket
• Ruby：Action Cable（Rails）
• Go：gorilla/websocket

主要なライブラリ

Socket.io（Node.js）

最も人気のあるWebSocketライブラリの一つです。

特徴：

• WebSocketに対応していない環境では自動的にポーリングにフォールバック
• 再接続機能が標準装備
• ルーム機能でグループ分けが簡単

ws（Node.js）

シンプルで軽量なWebSocketライブラリです。

特徴：

• WebSocket仕様に忠実な実装
• 余計な機能がなく、軽量
• パフォーマンスが高い

簡単な実装例

クライアント側（JavaScript）

// WebSocket接続を開始
const socket = new WebSocket('wss://example.com/socket');

// 接続が確立されたとき
socket.addEventListener('open', (event) => {
  console.log('接続しました');
  socket.send('こんにちは、サーバー！');
});

// メッセージを受信したとき
socket.addEventListener('message', (event) => {
  console.log('受信:', event.data);
});

// 接続が切断されたとき
socket.addEventListener('close', (event) => {
  console.log('切断されました');
});

サーバー側（Node.js + ws）

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  console.log('クライアントが接続しました');

  ws.on('message', (message) => {
    console.log('受信:', message);
    ws.send(`サーバーより: ${message}`);
  });
});

セキュリティ対策

1. wss://（暗号化通信）を使う

本番環境では、必ずwss://を使いましょう。暗号化されていない通信では、盗聴や改ざんのリスクがあります。

2. 認証・認可を実装する

接続時にトークンやAPIキーで認証を行います：

const token = localStorage.getItem('authToken');
const socket = new WebSocket(`wss://example.com/socket?token=${token}`);

3. 入力値のバリデーション

クライアントから送られてくるデータは必ず検証しましょう：

• データ型のチェック
• 文字数制限
• XSS攻撃の防止（HTMLエスケープ）

4. レート制限（Rate Limiting）

大量のメッセージ送信による攻撃を防ぐため、送信頻度に制限を設けます。

5. オリジン検証

意図しないドメインからの接続を防ぐため、オリジンを検証します。

6. 接続数の制限

サーバーのリソースを保護するため、同時接続数に上限を設けます。

まとめ

WebSocketの本質

WebSocketは、双方向・リアルタイム通信を実現する技術です。

• 一度の接続確立で双方向通信が可能
• サーバーからクライアントへ即座にデータを送信できる
• 軽量なフレーム通信で通信コストを削減
• 既存のWebインフラと互換性がある

適切な技術選定のために

WebSocketは強力な技術ですが、すべてをWebSocketにする必要はありません。

判断のポイント

1. データはリアルタイムで更新される必要があるか？
2. 双方向通信が必要か？
3. 同時接続数や通信量の要件は？
4. 既存システムとの統合は容易か？

段階的なアプローチ

最初から完璧を目指すのではなく、小さく始めて徐々に拡大する方法も有効です：

1. 既存のHTTPで最小限の機能を実装
2. 特に必要な部分だけWebSocketを導入
3. 効果を検証しながら、範囲を拡大

目的に応じた選択を

WebSocketは手段であり、目的ではありません。ビジネス要件に基づいて冷静に判断し、自社にとって「ちょうどいい」技術選定を行いましょう。

リアルタイム通信の実現に向けて、この記事が判断材料となれば幸いです。