「WebSocketは、HTTPと同じポート（80番や443番）を使えるから便利だ」と、IT資格試験や技術解説記事でよく言われます。確かにその通りですが、なぜ新しいプロトコルなのに既存のHTTPポートを使えるのか、その「中継機能」の仕組みまで深く理解できていますか？
本記事では、このWebSocketが持つ、HTTP通信を“トンネル化”して双方向通信へアップグレード（Upgrade）させる仕組みに焦点を当てて解説します。この仕組みこそが、ファイアウォールやルータの設定をほとんど変えずにリアルタイム通信を実現できる本質です。
応用情報技術者試験（令和3年春 午後問）でも問われた、WebSocketの核心となる技術要素を、図解と具体例とともに完全理解していきましょう。
目次
- 1 1. WebSocketとは — HTTP通信を拡張したリアルタイム技術を応用情報対策として解説
- 2 2. WebSocketの“中継機能”とは何か？ — HTTPのコネクションを再利用する仕組みを図解で解説
- 3 3. なぜ他のポート番号を使わず通信できるのか — ファイアウォール通過性との関係
- 4 4. WebSocketの中継と通常の“プロキシ中継”との違いを応用情報レベルで比較
- 5 5. 「同じポートで済む」とはどういう意味か — 中継機能の本質とファイアウォール通過の根拠
- 6 6. 中継機能の応用例 — HTTPをトンネル化し非HTTP通信を通すテクニック
- 7 7. まとめ — WebSocketが“同じポートで済む”理由と応用情報技術者試験の攻略
1. WebSocketとは — HTTP通信を拡張したリアルタイム技術を応用情報対策として解説
WebSocket は、クライアント（ブラウザなど）とサーバ間で双方向かつリアルタイムにデータをやり取りするために開発されたプロトコルです。
従来の HTTP (HyperText Transfer Protocol) は、クライアントがリクエストを送り、サーバがレスポンスを返すという単方向の通信モデル（半二重通信）でした。サーバ側から「何かあったから通知する」というプッシュ通知を行うには、ポーリング（短い間隔でリクエストを送り続ける）など非効率な手法を用いる必要がありました。
WebSocket の最大の特徴は、一度接続が確立されると、そのコネクションを維持したまま、クライアントとサーバのどちらからも自由にデータを送受信できる点です（全二重通信）。これにより、以下のようなリアルタイム性が求められるアプリケーションの実装が容易になりました。
- チャットアプリケーション
- 株価や為替レートなどのリアルタイム表示
- オンラインゲームの通信
- IoTデバイスからのデータ収集
【WebSocket通信が始まるまでの流れ（A to Z スタイル）】
- **ハンドシェイク（握手）**：まず、クライアントは通常の HTTP 通信として、サーバに対して特別なリクエストを送ります。
- **Upgradeリクエスト**：このリクエストには、特定のヘッダ（
Connection: Upgrade、Upgrade: websocketなど）が含まれており、「WebSocketプロトコルに切り替えたい」という意思を伝えます。 - **プロトコル切り替え（101 Switching Protocols）**：サーバがこれを受け入れると、HTTP レスポンスとしてステータスコード
101 Switching Protocolsを返します。 - **WebSocketセッション開始**：この応答をもって、TCP コネクションは切断されずに**プロトコルだけが HTTP から WebSocket へと切り替わり**、以降は双方向通信が可能になります。
この「HTTPから始まるが、途中でプロトコルを切り替える」という動作こそが、後の「中継機能」の解説で非常に重要になってきます。
2. WebSocketの“中継機能”とは何か？ — HTTPのコネクションを再利用する仕組みを図解で解説
WebSocket の中継機能（またはトンネリング機能）とは、**既存の HTTP コネクションを再利用し、新しいポートを開かずに双方向通信を実現する**仕組みです。これは、私たちが普段利用している「トンネル」に非常に似ています。
身近な例え：トンネルを「双方向」で使う
通常、HTTP 通信は、車でいうと「片道通行の道路」のようなものです。クライアント（車）がサーバー（目的地）へ一方的にリクエストを送ります。
一方、WebSocket は、最初こそ HTTP という道路を通りますが、途中で **「ここは双方向通信が可能な専用トンネルに切り替えます」** という手続き（Upgrade）を行うことで、**同じ道路の出口**から、今度はサーバー側からもクライアントに向けて自由にデータ（車）を送れるようになります。
ここで重要なのは、**「新しい道路（ポート）を作っていない」** という点です。
「中継」の核心：101 Switching Protocols とコネクションの維持
なぜ、WebSocket が HTTP と同じポート（80番や443番）で通信できるのか。その理由は、セクション1で触れた「プロトコル切り替え」にあります。
| ステップ | アクション | HTTPステータスコード | 備考 |
|---|---|---|---|
| 1. | クライアント → サーバー | HTTPリクエスト | Connection: Upgrade を含む |
| 2. | サーバー → クライアント | **101 Switching Protocols** | 「切り替えOK」の合図 |
| 3. | **以降** | **TCPコネクションはそのまま**、通信プロトコルだけWebSocketに移行 |
この一連の動作において、**TCPコネクションそのものは切断されず、ポート番号も変わりません。**単に、そのコネクション上で流れるデータのルール（プロトコル）だけが変わるのです。
ファイアウォールやルータは、最初に確立された「HTTP（80番/443番）の通信である」という認識を保ったまま、その後の WebSocket のデータも素通しさせます。これが、WebSocketが「HTTPを**中継**（トンネル）している」と言われる所以であり、「設定変更が少なく済む」というメリットの根拠となります。
3. なぜ他のポート番号を使わず通信できるのか — ファイアウォール通過性との関係
WebSocket が HTTP と同じポート（標準で 80 番、HTTPS で 443 番）を利用することの最大のメリットは、**「ファイアウォール（FW）やネットワーク機器の設定変更が不要になる」**点にあります。この点が、応用情報技術者試験などの問題で頻繁に問われる核心です。
ネットワーク境界における「ポートの壁」
企業ネットワークや多くの公共 Wi-Fi ネットワークでは、セキュリティ確保のため、**HTTP（80番）と HTTPS（443番）以外のポート番号への通信を厳しく制限・ブロック**しています。これは、不正な通信やマルウェアが勝手に外部と通信するのを防ぐためです。
もし WebSocket が別の専用ポート（例：9000番）を使用する必要があったとしたら、システム管理者はルータやファイアウォールに「9000番ポートも許可する」という例外ルールを**必ず追加**しなければなりません。この作業はコストと手間がかかり、セキュリティリスクも増大させます。
許可された「トンネル」を流用する
WebSocket は、以下のロジックでこの「ポートの壁」を回避します。
- **通信の開始**：Web ブラウザ（クライアント）が、ファイアウォールがすでに許可している 80番（または 443番）宛てに HTTP リクエストを送ります。
- **FW の認識**：ファイアウォールは、この通信を「通常の HTTP / HTTPS 通信である」と認識し、ブロックせずに通過させます。
- **プロトコル切り替え**：通過後、サーバーとの間で「プロトコルを WebSocket に切り替える（Upgradeする）」手続きを行います。**この切り替えはネットワーク内部（サーバーとクライアント間）で行われる**ため、中間にあるファイアウォールはその後の通信が WebSocket に変わったことを気にしません（または検知できません）。
- **継続通信**：WebSocket データは、許可された 80/443 ポートの**既存の TCP コネクション**に乗り続けているため、ファイアウォールは引き続き素通しさせます。
この「許可されているポートを利用して通信を開始し、その中でプロトコルを切り替える」という動作こそが、**「追加設定不要」**の直接的な理由です。
4. WebSocketの中継と通常の“プロキシ中継”との違いを応用情報レベルで比較
WebSocket が行う「中継（トンネリング）」は、通信経路の途中に介在する**プロキシサーバー**が行う一般的な「中継」とは、動作の本質が異なります。この違いを理解することが、応用情報技術者試験におけるプロキシ問題への対策にも繋がります。
通常のプロキシサーバーによる中継
通常の**フォワードプロキシ**（クライアントと外部サーバーの間に入る）や**リバースプロキシ**（Webサーバーの前に入る）は、クライアントからのリクエストを受け取り、それを**サーバーへ中継し直す**のが役割です。
- **セッションの切断と再接続:** プロキシは、クライアントとの TCP セッションを**一旦終了**させ、サーバーと**新たに** TCP セッションを確立し直す（あるいは接続プールから再利用する）ことが一般的です。つまり、通信セッションが途中で「バトンタッチ」されます。
- **ポートの変更可能性:** プロキシによっては、リクエストを受け取るポート（例: 80番）と、サーバーに接続し直すポート（例: 8080番）が異なる場合があります。
WebSocket の中継（トンネリング）との決定的な違い
WebSocket の中継は、TCP コネクションを再確立せず、プロトコルを切り替えるだけです。
| 比較項目 | WebSocket の中継（トンネリング） | 通常のプロキシによる中継 |
|---|---|---|
| **通信層** | L7 (HTTP上) | L7 (別セッションとして処理) |
| **TCP コネクション** | **切断・再確立しない** (Upgradeで継続利用) | **多くの場合、切断・再確立される** (セッションが分かれる) |
| **ポートの扱い** | 同じポート番号を**使い続ける** (80/443) | ポートが変わる可能性がある (例: 80 → 8080) |
| **通信方向** | 双方向（全二重） | 主に単方向のリクエスト/レスポンス |
| **適用範囲** | Webアプリのリアルタイム通信 | 負荷分散、キャッシュ、アクセス制御 |
結論： プロキシが通信セッションを**管理・中継**するのに対し、WebSocket は**既存のセッション自体を双方向に変質**させて「トンネル」として利用する、という点が決定的な違いです。
5. 「同じポートで済む」とはどういう意味か — 中継機能の本質とファイアウォール通過の根拠
これまでのセクションで学んだ内容を、試験対策の観点から「WebSocketの中継機能の本質」として再定義し、知識を定着させます。
本質の再確認：ポートではなく「接続」を再利用
WebSocket の特徴を問う試験問題で「同じポートを利用するから」という選択肢が出てきた際、単に「80番と443番を使う」と理解しているだけでは不十分です。本質は、**確立済みの TCP 接続（コネクション）を、プロトコル変更後も切り替えずに使い続ける**点にあります。
- **新しいプロトコルの定義が不要:** WebSocket は TCP/IP の上で動作する新しいプロトコルではありますが、通信の初期段階を HTTP として振る舞うため、既存の通信ルール（ポート80/443は許可）を破りません。
- **プロトコル変更のみ:** HTTP Upgrade は、**確立済みの通信路**の「中身の言語」を変える手続きであり、「新しい通信路（新しいポート）を作る」手続きではありません。
ファイアウォール通過性の根拠を整理
この中継機能の本質があるからこそ、ファイアウォールを通過できます。
| 要素 | 動作 | 結論 |
|---|---|---|
| **ファイアウォール (FW)** | TCP 接続の開始（ハンドシェイク）を監視し、ポート80/443が許可されているか判断する。 | HTTP 通信として開始されるため、FW は許可する。 |
| **Upgrade の実行** | FW の内側にあるクライアントとサーバーの間で行われる。 | FW は、内部でプロトコルが切り替わったことを検知できない（または、セッション単位では気にしない）。 |
| **FW の役割** | **通信開始時**にポート番号を見て許可/ブロックを決定する。 | 一度許可された後のセッションの**途中のプロトコル変更**は、基本的には関知しない。 |
つまり、WebSocket の中継機能とは、「ポートを流用してファイアウォールを騙す」技術ではなく、「TCPコネクションという**物理的な接続は変えず**、その上での**論理的な通信プロトコルだけを切り替える**ことで、設定変更という手間を回避する」**合理的**な技術なのです。
6. 中継機能の応用例 — HTTPをトンネル化し非HTTP通信を通すテクニック
WebSocket の「既存の HTTP ポートを利用して、異なるプロトコルのデータを双方向に流す」という中継（トンネル）機能は、リアルタイムWebアプリ以外にも応用されています。この応用技術は「トンネリング」として知られ、特定の通信をネットワーク制限から回避させたい場合に有効です。
非Webプロトコルを「HTTPの中身」として流す
WebSocket は本来、Webブラウザとサーバー間の通信のために設計されましたが、そのトンネルとしての能力を使えば、**Webとは無関係のプロトコル**を HTTP の通路に乗せて運ぶことができます。
- **SSH over WebSocket (例: wetty):**
セキュアなリモート接続プロトコルである SSH（Secure Shell）は、通常 22番ポートを使用します。しかし、この 22番ポートがファイアウォールでブロックされている環境は少なくありません。
これを回避するため、SSH のデータを WebSocket のペイロード（中身）としてカプセル化し、許可されている 80番や 443番ポートを通じてサーバーに送信します。サーバー側では、WebSocket のトンネルから SSH データを取り出し、SSH サーバーへ渡すという処理を行います。これにより、**WebブラウザだけでSSH接続**が実現します。 - **VNC over WebSocket (例: noVNC):**
リモートデスクトップ接続に使われる VNC (Virtual Network Computing) も、同様に専用のポートを使用します。これも WebSocket のトンネルに乗せることで、ファイアウォールの制限を気にせず、Webブラウザ経由でリモートデスクトップを利用可能にします。
応用情報・セキュリティ対策としての視点
このトンネリング技術は、利便性を高める一方で、セキュリティ上の課題も生じさせます。ファイアウォールは「80番/443番は Web 通信」と判断して許可していますが、実際にはその中で SSH や VNC といった**危険な可能性を持つ通信**が行われているかもしれないからです。
今日のファイアウォールやプロキシ製品には、パケットの中身を詳細に検査する**ディープパケットインスペクション (DPI)** 機能が搭載されつつあります。これにより、HTTP Upgrade 後に流れるデータが「純粋な WebSocket フレームなのか、それともトンネル化された非 Web プロトコルなのか」を分析し、不正な通信をブロックしようとする対策も進んでいます。
7. まとめ — WebSocketが“同じポートで済む”理由と応用情報技術者試験の攻略
本記事で解説したWebSocketの「中継機能」について、その本質を改めて整理します。応用情報技術者試験の対策キーワードと結びつけて理解を深めましょう。
中継機能（トンネリング）の本質
WebSocket が**「同じポートで通信できる」**というのは、以下の技術要素が組み合わさって実現されています。
- **接続の開始:** 通常の HTTP（80番/443番）として TCP コネクションを確立する。
- **プロトコルの切り替え:** HTTP ヘッダ内の
Connection: Upgradeリクエストに対し、サーバーが101 Switching Protocolsレスポンスを返し、**通信路はそのままに**プロトコルを WebSocket へと昇格させる（**HTTP Upgrade**）。 - **ファイアウォール通過性:** 接続開始時に許可されたポート（80/443）のコネクションを維持するため、ルータやファイアウォールは、その後の WebSocket による双方向リアルタイム通信をブロックせず、**設定変更なしで通過**させる。
これが、WebSocket が新しいポートを開くことなく、HTTP の通路を「双方向トンネル」として再利用する**中継機能**の核心です。
応用情報技術者試験 対策キーワード
このテーマを確実に得点源にするために、以下のキーワードとその意味を正確に結びつけましょう。
| キーワード | 意味合いと重要性 |
|---|---|
| **HTTP Upgrade** | プロトコルを HTTP から WebSocket に切り替える命令。中継機能の技術的なスタート地点。 |
| **101 Switching Protocols** | サーバが Upgrade 要請を受理したことを示す HTTP ステータスコード。 |
| **全二重通信** | 確立後の WebSocket 通信の性質。双方向リアルタイムを可能にする。 |
| **ファイアウォール通過性** | 同じポート（80/443）を利用することで、設定変更なしでネットワーク境界を越えられる性質。 |
| **トンネリング** | 既存のプロトコル（HTTP）の中に、別のプロトコル（WebSocketやSSHなど）のデータを包み込んで運ぶ技術。 |
WebSocketの仕組みは、Web開発の利便性だけでなく、ネットワークセキュリティやプロトコル技術の理解度を測る上で重要です。本記事で得た知識を、ぜひ試験対策や実務に活かしてください。