🌐

WebSocket 超入門

に公開
WebSocket
tech

0. このガイドの読み方

  • 対象: 「聞いたことはあるけどピンと来ていない方」「HTTP は知ってるけど“常時接続”って何？」というレベルのエンジニア・企画職・学生…誰でも OK。

  • ゴール: 読み終わる頃には「自分でもチャットアプリを動かせそう」と思えるだけの 概念理解＋最低限の実装力 を身につけます。

  • スタイル:

    1. できるだけ 平易な言葉 を使用。
    2. カタカナ語には必ず（かっこ）で日本語 or 具体例を付けていきます。
    3. 「なぜ？」→「どうする？」→「気をつける点」という三段構成で進行。

1. まず “リアルタイム通信” とは？

1-1. イメージで理解

  • 従来の HTTP = “手紙”

    • 手紙を書いてポスト（サーバー）に出し、返事を待つ。
    • 一往復ごとに封をして配達するので時間と労力がかかる。

  • WebSocket = “電話”

    • いったん受話器を取ったら、切るまで しゃべり放題＆聞き放題。
    • 追加の手続き不要で相手の声（データ）がすぐ届く。

リアルタイム通信 ＝ “電話” のように 待ち時間ほぼゼロで情報をやり取り できるしくみ。

1-2. どんな場面で役立つ？

例 どう便利？
チャット 入力した瞬間、相手の画面に表示。
株価・仮想通貨 銘柄の値動きを秒単位で反映。
オンラインゲーム プレイヤーの位置や攻撃をリアルタイム同期。
IoT センサー 温度・湿度などの最新値を常時監視。

2. WebSocket のしくみを 5 分で

2-1. “ハンドシェイク” ――まずは名刺交換

  1. ブラウザが「WebSocket を始めたい！」と HTTP でリクエスト。

  2. サーバーが「OK、これからは WebSocket で話そう」と返事。

    • ここで Upgrade: websocket ヘッダーをやり取り。

  3. お互い合意したら 電話回線（ソケット）を開通。この時点からは HTTP ではなく WebSocket 規格に従って通信。

2-2. “データフレーム” ――小包みたいなデータの箱

  • 通信は フレーム（ヘッダー＋本体）単位で行う。
  • ヘッダーが最小 2〜14 バイト程度と超軽量 → レイテンシ（遅延）減少。
  • テキストだけでなく バイナリ（画像・音声など）の箱も送れる。

2-3. 接続の維持と終了

  • 片方が close フレームを送る or ネットワークが切れるまで 常時つながったまま。
  • 長時間つなぎっぱなしなので 心臓の鼓動のように「Ping↔Pong」で生存確認を行う。

3. 実装してみよう（最小構成）

3-1. クライアント（ブラウザ側）

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

ws.addEventListener("open", () => {
  console.log("接続 OK");
  ws.send("こんにちはサーバー!");
});

ws.addEventListener("message", (e) => {
  console.log("受信:", e.data);
});

ws.addEventListener("close", () => console.log("接続終了"));
ws.addEventListener("error", (err) => console.error(err));
</script>

3-2. サーバー（Node.js + ws ライブラリ）

# 事前インストール
npm install ws

import { WebSocketServer } from 'ws';

const wss = new WebSocketServer({ port: 8080 });
wss.on('connection', (socket) => {
  console.log('クライアント接続');

  socket.on('message', (msg) => {
    console.log('受信:', msg.toString());
    socket.send('こちらサーバーです!');
  });

  socket.on('close', () => console.log('切断'));
});

3 分で動くデモ: 上記サーバーを起動 → 任意の HTML ファイルにクライアントスクリプトを貼り付け → ブラウザを開く。

4. メリット・デメリットを正直に

4-1. メリット

  1. 爆速: 一度つながればヘッダーが小さく遅延ほぼゼロ。
  2. 双方向: サーバー → クライアントにも即時プッシュ。
  3. 経済的: Polling のように “無駄なリクエスト連打” が不要。
  4. バイナリ OK: 画像や音声も送れる。

4-2. デメリット

課題 対策のヒント
コードが複雑 ライブラリ（Socket.IO など）で抽象化。
常時接続ゆえの DoS 攻撃 コネクション数制限・レートリミット。
プロキシ・ファイアウォールが遮断する場合あり wss://（TLS）を使う、ポート 443 利用。

5. 他方式との比較

方式 通信方向 接続維持 主な用途
Polling クライアント → サーバー いいえ 小規模でも実装がラク
Long Polling 同上（レスポンス長持ち） 条件付き 古いチャット、通知
SSE (Server‑Sent Events) サーバー → クライアント のみ はい 株価ティッカーなど
WebSocket 双方向 はい ゲーム、チャット、IoT

結論: 双方向 かつ 高頻度 のやり取りなら WebSocket 一択。片方向だけ or 更新頻度が低いなら SSE / Polling で十分。

6. 本番運用でハマらないためのチェックリスト

  1. TLS (wss://) を必ず使用。平文 (ws://) は盗聴・改ざんリスク大。
  2. Origin チェック: 予期しないサイトからの接続を拒否。
  3. 認証トークン をハンドシェイク時 or 接続後すぐ検証。
  4. バックプレッシャー: 受信量が多すぎるとアプリが落ちる。
  5. スケーリング: 複数サーバー間でメッセージを中継する場合、Redis などの Pub/Sub を利用。
  6. モニタリング: 接続数・エラー率・Ping 遅延をダッシュボードで可視化。

7. よくある質問 (FAQ)

Q A
スマホでも動く？ もちろん。iOS/Android のブラウザやネイティブアプリ用ライブラリあり。
何人まで同時接続できる？ 設計次第。1 台で数万コネクション、負荷分散で数十万も可能。
HTTP/2 や HTTP/3 とどっちが速い？ HTTP/2,3 も多重化で高速化するが、“常時双方向” では WebSocket が依然有利。
動画ストリーミングにも使える？ 可能。ただし大容量は HLS/DASH の方が一般的。

8. まとめ 〜“手紙”から“電話”へ〜

  • WebSocket は 常時双方向 の “専用電話回線”。
  • チャット・ゲーム・IoT など リアルタイム性が命 のアプリに最適。
  • 本番では TLS・認証・モニタリング を忘れずに。

これであなたも「WebSocket？ ああ、あの電話みたいな通信でしょ」と自信を持って語れます。さっそくローカルで動かし、リアルタイムの世界を体験してみてください。

学びは“動かしてナンボ”。この記事があなたの一歩を後押しできれば幸いです。

Discussion