対象試験と出題頻度
WebSocketは、応用情報技術者で出題されるテーマです。
ネットワーク応用分野のプロトコル問題として登場し、「HTTPとの違い」や「Ajaxとの使い分け」を正確に理解しているかが問われます。
詳細をクリックして確認
応用情報技術者
★★☆☆☆
ランクC（応用）余裕があれば覚える
用語の定義
情報処理試験を勉強していると、「WebSocketって結局何？HTTPと何が違うの？」と混乱しがちです。
WebSocketとは、一言で言うと
「HTTPのハンドシェイクで接続を確立した後、1本のTCPコネクション上でクライアントとサーバが自由に双方向通信できるプロトコル」
のことです。
イメージとしては、「電話回線」です。
HTTPが「手紙のやり取り（送って→返事が来て→また送って…）」だとすれば、WebSocketは「電話をかけてつながった後、お互いが好きなタイミングで話せる状態」にあたります。
一度つながれば、いちいち電話をかけ直す必要がありません。
📊 WebSocketの基本情報
| 項目 | 内容 |
|---|---|
| 技術規格 | RFC 6455（IETF策定） |
| URIスキーム | ws://（平文）、wss://（暗号化） |
| デフォルトポート | ws → 80番、wss → 443番（HTTP/HTTPSと同じ） |
| 最大の特徴 | サーバ側からもクライアントへデータをプッシュ送信できる |
解説
HTTPは「リクエスト→レスポンス」の一問一答型が基本です。クライアントが要求しない限り、サーバ側から自発的にデータを送ることはできません。
チャットや株価のリアルタイム更新のように「サーバ側に新しい情報が生まれた瞬間にクライアントへ届けたい」場面では、この仕組みが足かせになります。
従来はAjax（XMLHttpRequest）を使ってクライアント側から短い間隔で繰り返しリクエストを送る「ポーリング」で疑似的にリアルタイム通信を実現していましたが、リクエストのたびにTCPコネクションの確立とHTTPヘッダーのやり取りが発生し、オーバーヘッドが大きいという問題がありました。
WebSocketはこの課題を根本的に解決するために生まれたプロトコルです。
▶ 接続確立の流れ（クリックで展開）
WebSocketの通信は、最初にHTTPのGETメソッドを使ったハンドシェイクから始まります。クライアントは「Upgrade: websocket」「Connection: Upgrade」というHTTPヘッダーを含むGETリクエストをサーバに送信します。
サーバがWebSocket対応であれば、ステータスコード「101 Switching Protocols」を返し、通信プロトコルがHTTPからWebSocketへ切り替わります。
この切り替え以降は、同じTCPコネクションを維持したまま、クライアント・サーバの双方が任意のタイミングでテキストデータやバイナリデータを送受信できます。
HTTPのリクエスト/レスポンス形式に縛られないため、ヘッダーのオーバーヘッドが大幅に削減されます。
▶ Ajaxとの違い（クリックで展開）
ここだけは確実に押さえてください。
WebSocketとAjaxは「リアルタイム性の実現方法」がまったく異なります。
| 比較項目 | WebSocket | Ajax（ポーリング） |
|---|---|---|
| 通信方向 | 双方向（全二重） | クライアント→サーバの一方向が基本 |
| コネクション | 1本のTCP接続を維持し続ける | リクエストごとに接続を確立・切断 |
| オーバーヘッド | ハンドシェイク後は小さい | 毎回HTTPヘッダーが発生し大きい |
| サーバプッシュ | 可能 | 不可（クライアントが問い合わせる必要あり） |
| 利用場面 | チャット、株価ボード、オンラインゲーム | 検索サジェスト、部分的なページ更新 |
Ajaxはページ全体を再読込せずに一部を更新する技術としては優秀ですが、サーバから能動的にデータを届けることはできません。
WebSocketは「サーバ発信のリアルタイム通知」が求められる場面で真価を発揮します。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 WebSocketの核心を3行で
・HTTPのGETメソッドによるハンドシェイクで接続を開始し、プロトコルをWebSocketへ切り替える
・切り替え後は1本のTCPコネクション上でクライアント・サーバ双方が自由にデータを送受信できる
・Ajaxのポーリングと異なり、サーバ側からのプッシュ送信が可能でオーバーヘッドも小さい
試験ではこう出る！
WebSocketは、応用情報技術者の午前・午後の両方で出題実績があります。午前では定義や特徴を選ばせる知識問題、午後ではチャット機能の設計を題材にした読解問題として登場しています。
📊 過去問での出題実績（クリックして表示）
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H28秋 午前 問7 |
WebSocketによって実現できるものを選ぶ問題。 | ・「クライアントとサーバ間の双方向通信」が正解 ・Web Worker、映像再生、Canvas描画がひっかけ |
| AP R3春 午後 問5 |
旅行販売システムへのチャット機能追加を題材に、WebSocketの接続手順や負荷分散への影響を問う問題。 | ・HTTPのGETメソッドにUpgradeヘッダーを付与して接続を切り替える手順 ・TCPコネクションを維持し続ける特性と負荷分散装置への影響 |
| NW H30秋 午前Ⅱ 問15 |
WebSocketの説明として適切なものを選ぶ問題。 | ・「GETメソッドで通信開始」「ハンドシェイクで接続確立」が正解 ・XMLSocket、WebRTC、Ajaxの説明がひっかけ |
📝 IPA試験での出題パターン
パターン1：「WebSocketで実現できることを選べ」
Web Worker（バックグラウンド処理）、Canvas（ビットマップ描画）、映像再生といったHTML5関連技術の説明が選択肢に並ぶ。「双方向通信」を含む選択肢が正解。
パターン2：「WebSocketの特徴・接続手順を選べ」
NW H30秋のように、プロトコルの技術的特徴を問う形式。「XMLで記述」はXMLSocketの特徴、「XMLHttpRequest」はAjaxの特徴であり、これらがひっかけ。「GETメソッドで開始→ハンドシェイク→接続確立」という手順を知っていれば即答できる。
試験ではここまででOKです。フレーム構造やサブプロトコルの詳細まで問われることはないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. WebSocketプロトコルの特徴として、最も適切なものはどれでしょうか？
- A. XMLHttpRequestオブジェクトを使用し、クライアントからサーバへ非同期のHTTPリクエストを定期的に送信することで、擬似的なリアルタイム通信を実現する。
- B. 最初にHTTPのGETメソッドでハンドシェイクを行い、接続確立後は1本のTCPコネクション上でクライアントとサーバが双方向にデータを送受信できる。
- C. HTTPを拡張したプロトコルであり、サーバ上のファイルの参照、作成、削除及びバージョン管理が行える。
正解と解説を見る
正解：B
解説：
WebSocketは、HTTPのGETメソッドによるハンドシェイクでプロトコルを切り替え、その後は1本のTCPコネクション上で双方向のデータ通信を実現するプロトコルです。「GETメソッドで開始」「双方向通信」の2つが揃った選択肢Bが正解になります。
選択肢AはAjax（非同期JavaScript+XML）の説明です。XMLHttpRequestを使ったポーリングはクライアント起点の通信であり、サーバ側からの自発的なデータ送信はできません。選択肢CはWebDAV（Web-based Distributed Authoring and Versioning）の説明です。WebDAVはHTTPにファイル操作用のメソッドを追加した拡張規格であり、双方向のリアルタイム通信を目的としたものではありません。
よくある質問（FAQ）
Q. WebSocketの接続はサーバ側から開始できますか？
できません。WebSocketの接続は必ずクライアント側からHTTPのGETリクエスト（Upgradeヘッダー付き）を送信して開始します。サーバ側から接続を要求する手段はRFC 6455には定義されていません。NW H30秋 午前Ⅱ 問15でもこの点がひっかけ選択肢として出題されており、「サーバ側からも接続開始を要求できる」という記述は誤りです。
Q. WebSocketとWebRTCは何が違いますか？
WebSocketはクライアントとサーバ間の双方向通信を実現するプロトコルです。一方、WebRTC（Web Real-Time Communication）はブラウザ同士（ピアツーピア）で音声・映像・データをリアルタイムにやり取りするための技術です。WebSocketは「ブラウザ↔サーバ」、WebRTCは「ブラウザ↔ブラウザ」と通信相手の構成が異なります。ビデオ通話やオンライン会議はWebRTCの領域です。
Q. WebSocketを使うとセキュリティ上のリスクはありますか？
あります。WebSocketはTCPコネクションを長時間維持するため、クロスサイトWebSocketハイジャック（CSWSH）という攻撃手法の対象になりえます。これはCookieベースの認証を悪用して、悪意あるサイトからユーザーのWebSocket接続を乗っ取る手法です。対策としては、Originヘッダーの検証やトークンベースの認証を行うのが一般的です。また、暗号化通信のためにws://ではなくwss://（WebSocket over TLS）を使用することが推奨されます。
