WebSocket ─ ブラウザの双方向通信

学習目標

本講を終えると、以下を達成できるようになります。

• HTTP リクエスト/レスポンスでは実現しにくい サーバプッシュ・低遅延双方向 の用途を挙げ、WebSocket がその解になる理由を述べられる
• HTTP Upgrade ハンドシェイク(Upgrade: websocket、Sec-WebSocket-Key、101 Switching Protocols)の流れを説明できる
• WebSocket フレーム構造(FIN・RSV・opcode・MASK・payload length・masking key・payload)を図示できる
• Text/Binary・フラグメンテーション・制御フレーム(Ping/Pong/Close)・wss:// の役割を区別できる
• Python の websockets ライブラリと JavaScript の WebSocket API で 最小双方向チャット を書ける
• Server-Sent Events / Long Polling / WebRTC / socket.io との使い分けを場面別に語れる

このレッスンの目次

なぜ WebSocket か ─ HTTP の限界とリアルタイム化

「HTTP だけで頑張る」古い手法と比べると

図の見方:① の短周期ポーリングは「とりあえず何回も訊く」方式。HTTP ヘッダのオーバーヘッドが毎回発生し、無駄が多い。② Long Polling はサーバが応答を保留することで頻度を下げるが、本質はリクエスト型のまま。③ WebSocket は最初だけ HTTP で「ハンドシェイク」し、以降は 1本の TCP の上で自由に双方向メッセージ を流せる。

つながる知識: HTTP/2 にも Server Push がありますが、これはあくまで「応答に付随してファイルを先送りする」用途であって、長時間の双方向対話には設計されていません(2022 年の Chrome では既定で無効化された)。HTTP/3 でも同様。「ブラウザとサーバの双方向対話」を素直に表現できるのは依然として WebSocket、または UDP ベースの WebTransport(2024 年現在まだ標準化途中)です。

ハンドシェイク ─ HTTP Upgrade で「昇格」する

実際のリクエスト/レスポンス例

# クライアント → サーバ
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://example.com

# サーバ → クライアント
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# ↓ ここから先は WebSocket フレームでの双方向通信

Sec-WebSocket-Accept の計算

「キャッシュされた古い HTTP 応答を WebSocket 開始と勘違いしないため」 の検証手順です。サーバはクライアントの Key にマジックストリングを足してハッシュを取り、Accept として返します。クライアントは同じ計算をして突き合わせ、一致しなければ接続を破棄します。

# Python で確認
import hashlib, base64
key = "dGhlIHNhbXBsZSBub25jZQ=="
magic = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
accept = base64.b64encode(hashlib.sha1((key + magic).encode()).digest()).decode()
print(accept)  # → s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

考えてみよう: なぜ HTTP/1.1 GET から始まるのでしょうか?TCP を直接立てて独自プロトコルを話せば、Upgrade のような遠回りは不要なはずです。理由は 「インターネット中のプロキシ・ファイアウォール・LB が HTTP しか通さない」 という現実への適応です。HTTP リクエストとして見えれば、80/443 を経由してまず通り、その後で素性を変えられる。レガシーインフラに優しい新プロトコルの設計テクニック として知られています。

フレーム構造 ─ 最短 2 バイトのコンパクトなヘッダ

フレームのレイアウト(RFC 6455 §5.2)

図の見方:最小構成は FIN+opcode+MASK+payload len = 2 バイト。ペイロードが 125 バイト以下なら 7 ビットの payload len 欄に収まり、追加ヘッダなし。126 バイト以上なら 16 ビット拡張、64 KB 以上なら 64 ビット拡張が登場します。HTTP のように Content-Type: 等を毎回送らないので、短いメッセージほど効率的です。

opcode の種類

Text と Binary、フラグメンテーション

使い分けの目安

フラグメンテーション ─ 1 メッセージを複数フレームに割れる

大きいメッセージは FIN=0 のフレームを複数連ねて、最後に FIN=1 で送るルール。これによりストリーミング的に流せます。例:1 GB のファイル送信を 1 フレームではなく、64 KB ずつのフラグメントに分割。

# 例:大きい binary を 3 フラグメントに分割
[FIN=0, opcode=0x2, payload=...]   ← 最初のフラグメント(binary 開始)
[FIN=0, opcode=0x0, payload=...]   ← 続き(continuation)
[FIN=1, opcode=0x0, payload=...]   ← 最後の続き(完結)

つながる知識: 制御フレーム(Ping/Pong/Close)は フラグメント化できません。これは「制御メッセージは即座に確実に届く必要がある」ためで、データフラグメントの最中でも割り込んで送られます。これは TCP / IP の世界における「制御プレーンとデータプレーンの分離」発想を、アプリ層プロトコルの設計に持ち込んだ例として読めます。

制御フレーム ─ Ping / Pong / Close

Ping/Pong による接続維持

WebSocket 接続は長時間維持されます。途中の NAT・LB・プロキシ がアイドル状態の TCP を勝手に切るのを防ぐには、定期的な Ping/Pong が有効です。多くのライブラリではデフォルト 20〜60 秒間隔で送信します。

図の見方:Ping/Pong は アプリのデータとは別レーン で流れる小さな存在確認メッセージ。これがあるおかげで、何時間も発言のないチャットルームでも切断されません。

Close ステータスコード

wss:// と TLS over WebSocket

典型的な wss 構成

図の見方:外向きは TLS で暗号化、内側のアプリサーバとのやり取りは平文 ws のまま、というのが運用上ほぼ標準。アプリサーバは TLS 処理から解放され、nginx 側で証明書管理・HTTP/2/3 終端・WebSocket 中継が一元化できる。

location /chat {
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;     # ← 必須
    proxy_set_header Connection "upgrade";          # ← 必須
    proxy_set_header Host       $host;
    proxy_read_timeout 86400;                       # 長寿命化
}

ハンズオン ─ Python と JS で双方向チャット

サーバ:Python

まずは依存をインストール。

python3 -m pip install websockets

# server.py — 全クライアントにメッセージをブロードキャスト
import asyncio, websockets

CLIENTS = set()

async def handler(ws):
    CLIENTS.add(ws)
    try:
        async for msg in ws:                        # 受信ループ
            print("recv:", msg)
            await asyncio.gather(
                *[c.send(f"<> {msg}") for c in CLIENTS if c is not ws]
            )
    finally:
        CLIENTS.remove(ws)

async def main():
    async with websockets.serve(handler, "localhost", 8765):
        print("listening on ws://localhost:8765/")
        await asyncio.Future()                      # 永久に待機

asyncio.run(main())

クライアント:HTML + JavaScript

<!doctype html>
<input id="msg" placeholder="message" />
<button id="send">send</button>
<ul id="log"></ul>

<script>
  const ws = new WebSocket("ws://localhost:8765/");

  ws.addEventListener("open",    () => console.log("connected"));
  ws.addEventListener("message", e  => {
    const li = document.createElement("li");
    li.textContent = e.data;
    document.getElementById("log").appendChild(li);
  });
  ws.addEventListener("close",   e  => console.log("closed", e.code));

  document.getElementById("send").addEventListener("click", () => {
    const v = document.getElementById("msg").value;
    ws.send(v);
  });
</script>

動作確認

1) python3 server.py でサーバ起動 → 2) HTML をブラウザで複数タブ開く → 3) どれかのタブで送信すると 他のタブ全てに表示される。これだけで「双方向チャットの背骨」が完成します。本番運用するには認証・room 機能・永続化を足していくだけ。

つながる知識: 上のサーバ実装は async / await を多用しています。これは 1 プロセスで多数の長寿命コネクションを捌く ための現代的な設計。WebSocket のように接続が長時間生きる用途では、スレッドあたり 1 接続のモデルではメモリが足りなくなります。発展編 第29回 HTTP プログラミング の aiohttp 章とも考え方が共通しています。

関連技術との比較 ─ SSE / Long Polling / WebRTC / socket.io

4 つの技術を要件で比較

判断フロー

考えてみよう: Slack や Discord のチャットは何で動いているでしょうか?Web 版の DevTools を開くと、WebSocket(wss://) の長寿命コネクションがちゃんと見えます。一方、X(Twitter)のタイムライン更新は SSE、Zoom や Google Meet の音声・ビデオは WebRTC ─ それぞれ「双方向の頻度」と「レイテンシ要件」と「データ量」のトレードオフで設計が分かれています。

まとめと用語チェック

用語チェック

確認問題