WebSocketの仕組みは？HTTP・SSEとの違いと再接続の注意

ひよこ

WebSocketは何ができるの？

ペンギン先生

接続が成立した後、クライアントとサーバーの両方からメッセージを送れる通信方式だよ。普通のHTTPのように、毎回リクエストと応答を一組にする必要がない。チャットや共同編集など、頻繁に双方向へ更新を送る用途で使われるね。

ひよこ

HTTPではサーバーから送れないの？

ペンギン先生

短い応答を毎回完結させる使い方では、新しい要求を待つことになる。でもSSEならHTTPの応答を開いたままサーバーから継続して送れるよ。ポーリングも含め、更新頻度と送信方向で選ぶんだ。

ひよこ

最初の接続はどうする？

ペンギン先生

HTTP/1.1の例ではUpgradeを要求し、サーバーが101応答で切り替えを受け入れるよ。以後はWebSocketのフレームで通信する。HTTP/2ではExtended CONNECTを使う方式があり、手順が同じではない点も押さえよう。

ひよこ

フレームは軽いの？

ペンギン先生

小さな基本ヘッダーを使い、HTTPヘッダーをメッセージごとに繰り返す必要はないよ。ただし長いペイロードでは追加の長さ情報が必要だし、クライアントからのフレームにはマスクがある。このマスクは暗号化ではなく、通信の暗号化にはwssのTLSを使うんだ。

ひよこ

Socket.IOも同じ？

ペンギン先生

WebSocketそのものではなく、独自のプロトコルとライブラリだよ。ロングポーリングやWebSocketなどを使い、再接続などの機能を提供する。通常のWebSocketクライアントとSocket.IOサーバーを、そのまま接続できるわけではないんだ。

ひよこ

切れたら自動で戻る？

ペンギン先生

標準のWebSocket APIには自動再接続はないので、アプリで設計するよ。再接続できても、切れている間のメッセージが自動で全部復元されるわけではない。ID、処理済み位置、履歴の再取得、重複処理の防止などが必要になるね。

ひよこ

つながっていれば認証は終わり？

ペンギン先生

いいえ。接続時の認証に加えて、操作ごとの認可や入力検証が必要だよ。Cookieを使うならOriginも検証し、ログアウトやセッション期限切れ後の接続をどう閉じるかを決める。暗号化だけで権限の問題は解決しないんだ。

ひよこ

SSEとどちらがよい？

ペンギン先生

サーバーからの通知中心ならSSEと通常のHTTP送信の組み合わせでもよいね。双方向の頻繁なメッセージが必要ならWebSocketを検討する。接続数、プロキシのタイムアウト、送受信の詰まり、再接続時の負荷まで含めて選ぼう。

通信方式の比較

SSEのEventSourceには再接続の仕組みがありますが、過去イベントを再送するかどうかはサーバーの実装も必要です。通信路の復旧と、業務データの復旧は分けて考えます。

本番運用で確認すること

• 接続：プロキシやロードバランサーのアイドル時間、同時接続数。
• 再接続：待ち時間を徐々に増やし、一斉再接続の集中を避ける。
• データ：欠落・重複の扱い、受信量やメッセージサイズの上限。
• 認証：Origin、セッションの失効、操作ごとの権限、ログへの秘密情報混入。

プロトコルにはPing/Pongがありますが、ブラウザのJavaScript APIから直接操作できません。必要ならアプリのメッセージによる確認を設計します。WebSocketを採用しても、「必ず即時に一度だけ届く」という保証は得られません。

参考資料

確認日：2026年9月27日。製品の仕様・料金・対応環境は導入時にも確認してください。

• RFC 6455: WebSocket：HTTP/1.1の確立、フレーム、マスクとTLS。
• WHATWG: WebSockets：ブラウザAPIとPing/Pong。
• OWASP: WebSocket Security：Origin・認証・メッセージ認可と上限。
• Socket.IO: How it works：独自プロトコルと通信方式。
• WHATWG: Server-sent events：EventSourceの再接続とイベントID。
• RFC 8441：HTTP/2でのExtended CONNECT。