インターネットの通信は、単純に「送る→返ってくる」の繰り返しではありません。HTTPというプロトコルは、時代とともに進化し、より効率的で多機能な通信を可能にしてきました。例えば、HTTP/1.1の「パイプライン処理」では、リクエストを連続して送ることで待ち時間を減らす工夫がありました。しかし、これには限界があり、後継のHTTP/2では「ストリーム」という概念や「HPACK」によるヘッダ圧縮、さらにはサーバ側からデータを先回りして送る「サーバプッシュ」などが登場します。
また、HTTPはWebページの表示だけでなく、ファイル管理を可能にするWebDAVや、常時接続を実現するWebSocketなど、多様な拡張も持っています。さらに、HTTP通信の基本である「ヘッダ」と「ボディ」の役割、レスポンスの状態を示す「ステータスコード」も理解しておく必要があります。
この記事では、これらの技術を体系的に整理しながら、試験で問われやすい違いや仕組みを、図解・表・身近な例を交えてわかりやすく解説します。特に「パイプライン処理とHTTP/2の違い」「ストリームの概念」「HPACKの仕組み」「サーバプッシュの動き」「WebSocketとの違い」を重点的に押さえ、実務や試験対策の両面で役立つ知識を得られる内容にします。
目次
パイプライン処理とHTTP/2の違い│試験に出る並列化・多重化の仕組み
HTTPは、クライアント（ブラウザなど）とサーバの間でリクエストとレスポンスをやり取りするプロトコルです。通信効率を高めるため、HTTP/1.1では「パイプライン処理」という手法が導入されました。これは、1つのTCP接続で複数のリクエストを立て続けに送信し、サーバからのレスポンスを順番に受け取る方式です。
パイプライン処理の仕組み
- 特徴：リクエストを連続送信できる
- 制約：レスポンスは必ず送信順に返ってくる（FIFO）
- 課題：1つのレスポンスが遅れると後続が待たされる「Head-of-line blocking（HOLブロッキング）」が発生
| 項目 | パイプライン処理（HTTP/1.1） | HTTP/2 |
|---|---|---|
| リクエスト送信 | 連続送信可能 | 並列・多重送信可能 |
| レスポンス順序 | 必ず送信順 | 順序自由（ストリームIDで管理） |
| HOLブロッキング | 発生する | 発生しにくい（TCPレベルのHOLを除く） |
| ヘッダ圧縮 | なし（ヘッダ繰り返し多い） | HPACKで圧縮 |
| サーバプッシュ | なし | あり |
HTTP/2の進化ポイント
HTTP/2では「多重化（Multiplexing）」が可能になり、複数のリクエストとレスポンスを同時に並列処理できます。これにより、1つのレスポンスが遅れても他のレスポンスに影響を与えにくくなりました。さらに、ヘッダ圧縮（HPACK）やサーバプッシュといった新機能も加わっています。
身近な例え
- パイプライン処理：1本のレーンしかないレジで、客が順番に清算。前の人がもたつくと全員が待つ。
- HTTP/2の多重化：複数レーンのセルフレジ。1人が時間をかけても他のレーンは進む。
簡易図解（通信の流れ）
HTTP/1.1 パイプライン処理：
Request1 → Request2 → Request3
↓
Response1 → Response2 → Response3
HTTP/2 多重化：
Request1 ↔ Response1
Request2 ↔ Response2
Request3 ↔ Response3
（同時進行）
HTTP/2のストリームとHPACK圧縮│効率化の核心技術
HTTP/2では、通信の単位としてストリーム（Stream）という概念が導入されました。ストリームは、1つのTCP接続の中で独立してやり取りできる仮想的な通信チャネルです。これにより、複数のリクエストとレスポンスを同時並行で処理でき、HTTP/1.1のパイプライン処理で起きていたHOLブロッキング問題を緩和します。
ストリームの特徴
- ストリームID：各ストリームには番号（ID）が割り振られる
- 優先度制御：重要なリソースを優先的に送信できる
- 片方向・双方向の両方に対応
HPACKによるヘッダ圧縮
HTTP/1.1では、同じホスト名やCookieなどのHTTPヘッダ情報が毎回繰り返し送られ、通信量が増大していました。HTTP/2はHPACK（Header Compression for HTTP/2）という方式でこれを解決します。
| 項目 | HTTP/1.1 | HTTP/2（HPACK） |
|---|---|---|
| ヘッダ圧縮 | なし | あり（静的テーブル＋動的テーブル） |
| 繰り返しヘッダ | 毎回送信 | 1回送信後はインデックス参照 |
| 文字列表現 | そのまま送信 | ハフマン符号化で圧縮 |
| 効果 | 通信量増加 | 通信量を大幅削減 |
HPACKの仕組み（簡易イメージ）
- 静的テーブル：共通ヘッダ（例：
:method: GET）は事前登録済み - 動的テーブル：通信中に送られた新しいヘッダを登録し、以降は番号で参照
- ハフマン符号化：文字列自体を圧縮
身近な例え
- HTTP/1.1のヘッダ送信：毎回住所・氏名・電話番号を全部書いた宅配伝票を渡す
- HPACK圧縮：最初にフル情報を渡し、次からは「顧客番号」で伝える
ストリーム＋HPACKの組み合わせ効果
- ページ内の画像、CSS、JSなどを同時取得可能
- ヘッダの重複送信を防ぎ、モバイル回線でも高速化
HTTP/2サーバプッシュの仕組みと注意点│先回り配信で高速化
HTTP/2では、クライアントがリクエストを送る前に、サーバ側が必要になりそうなリソースを先回りして送信するサーバプッシュ（Server Push）機能が追加されました。これにより、ページ表示に必要なファイルを事前配信し、表示速度を向上させられます。
サーバプッシュの動作イメージ
- ブラウザがHTMLファイルをリクエスト
- サーバはHTMLを返すと同時に、そのHTML内で参照されているCSSやJavaScript、画像ファイルなども自動で送信
- ブラウザは受け取ったリソースをすぐ利用できるため、表示が速くなる
身近な例え
- 普通のHTTP通信：お客さんが料理を頼んだら、その料理だけ出す
- サーバプッシュ：料理を頼まれたら、必要になりそうな箸・スープ・漬物も一緒に出す
メリット
- リクエスト回数を減らせる
- 表示の初動を高速化できる
注意点
- 不要なリソースを送ると帯域の無駄になる
- ブラウザがすでにキャッシュしている場合は逆効果
- HTTP/3（QUIC）ではサーバプッシュの利用が減少傾向
サーバプッシュの簡易図解
通常通信：
Client → HTMLください
Server → HTMLどうぞ
Client → CSSください
Server → CSSどうぞ
サーバプッシュ：
Client → HTMLください
Server → HTML＋CSS＋JSどうぞ（一括）
WebSocketとの違いと使い分け│HTTPとの境界線を理解する
HTTPとWebSocketはどちらもWeb通信で使われますが、目的や特性が大きく異なります。HTTPはリクエストとレスポンスのペアによる一方向型通信が基本ですが、WebSocketは双方向・常時接続を前提としています。
HTTPの特徴
- 通信はリクエスト→レスポンスの1往復単位
- 接続は必要に応じて都度確立（Keep-Aliveで維持可能）
- ページ取得やAPI呼び出しに適する
WebSocketの特徴
- 1回接続したら維持し続け、双方向にデータを送受信
- サーバからの即時通知が可能
- チャットやオンラインゲーム、株価更新などリアルタイム性が必要なサービスに適する
比較表
| 項目 | HTTP | WebSocket |
|---|---|---|
| 通信方向 | 基本は一方向（クライアント発→サーバ応答） | 双方向 |
| 接続維持 | 必要に応じて確立 | 常時接続 |
| 用途 | ページ取得、API通信 | リアルタイムチャット、通知、ゲーム |
身近な例え
- HTTP：店に行くたびに注文して受け取るスタイル
- WebSocket：カウンター席に座り、必要な時にすぐ注文・提供してもらえるスタイル
使い分けの指針
- 更新頻度が低く、必要な時だけ情報を取得する場合はHTTP
- 常に最新情報をやり取りしたい場合はWebSocket
WebDAVの特徴と利用例│HTTPを使ったリモートファイル操作
WebDAV（Web-based Distributed Authoring and Versioning）は、HTTPを拡張してファイルのアップロードや編集、削除などを可能にするプロトコルです。通常のHTTPが「読み取り中心」なのに対し、WebDAVはサーバ上のファイルをリモートで編集・管理できる点が大きな特徴です。
WebDAVの基本機能
- ファイルのアップロード・ダウンロード
- ディレクトリの作成・削除
- ファイルの移動やコピー
- ロック機能による同時編集防止
HTTPとの関係
WebDAVはHTTPの拡張として設計されており、追加メソッド（PROPFIND、MKCOL、LOCK、UNLOCK など）を利用します。そのため、HTTPで利用するポート番号80や443をそのまま使えます。
身近な例え
- 通常のHTTP：美術館で作品を観るだけ（閲覧専用）
- WebDAV：アトリエに入って作品を描き直したり追加したりできる（編集可能）
利用例
- クラウドストレージ（例：ownCloud、Nextcloud）
- 企業内の文書共有システム
- Webサーバ上での共同編集
メリットと注意点
| メリット | 注意点 |
|---|---|
| HTTP互換で既存のインフラを利用可能 | セキュリティ設定を強化しないと外部からの不正アクセスリスクあり |
| ファイル管理をGUIクライアントやOS標準機能で行える | 大量ファイルや大容量データには不向き |
HTTPヘッダとボディの役割│通信内容を整理する2つの領域
HTTPメッセージは大きくヘッダ（Header）とボディ（Body）の2つの部分に分かれます。ヘッダは通信の「説明書」、ボディは「実際の中身」と考えると分かりやすいです。
HTTPメッセージ構造
リクエスト（例）
GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
（ボディは通常なし）
レスポンス（例）
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
...
ヘッダの役割
- リクエストやレスポンスの追加情報を伝える
- 例：
Content-Type（データ形式）、Content-Length（データサイズ）、Set-Cookie（クッキー設定） - HTTP/2以降はヘッダ圧縮（HPACK）によって送信効率が向上
ボディの役割
- 実際のデータ（HTML、画像、JSONなど）を格納
- POSTやPUTリクエストではフォーム入力内容やファイルが含まれる
身近な例え
- ヘッダ：宅配便の送り状（宛先・サイズ・発送日など）
- ボディ：荷物の中身そのもの
試験で問われやすいポイント
- ヘッダとボディは空行（CRLF）で区切られる
- GETリクエストは通常ボディを持たない
- HTTP/2でも概念は同じだが、実装レベルではフレーム分割される
HTTPステータスコード一覧と試験頻出ポイント│意味と使いどころを理解する
HTTPステータスコードは、サーバがクライアントからのリクエストに対して返す応答の状態を示す3桁の数字です。最初の1桁で分類され、続く2桁で詳細を表します。Webの動作確認やトラブルシューティングだけでなく、試験でもよく問われる分野です。
ステータスコードの分類
| 分類 | 範囲 | 意味 |
|---|---|---|
| 1xx | 100〜199 | 情報（リクエストを受け、処理を継続） |
| 2xx | 200〜299 | 成功（リクエストが正常に処理された） |
| 3xx | 300〜399 | リダイレクト（別の場所へ誘導） |
| 4xx | 400〜499 | クライアントエラー（リクエストに問題） |
| 5xx | 500〜599 | サーバエラー（サーバ側で処理失敗） |
代表的なステータスコード
| コード | 意味 | 試験ポイント |
|---|---|---|
| 200 OK | リクエスト成功 | 最も基本的な成功レスポンス |
| 301 Moved Permanently | 恒久的なリダイレクト | SEOやURL変更時に使用 |
| 302 Found | 一時的なリダイレクト | 一時移転時に利用 |
| 304 Not Modified | 前回から変更なし | キャッシュ利用時に重要 |
| 400 Bad Request | クライアントのリクエストが不正 | URLの形式エラーなど |
| 401 Unauthorized | 認証が必要 | Basic認証やBearerトークンなど |
| 403 Forbidden | アクセス禁止 | 認証は通ったが権限なし |
| 404 Not Found | 対象リソースが存在しない | 最頻出エラー |
| 500 Internal Server Error | サーバ内部エラー | アプリケーションの不具合など |
| 503 Service Unavailable | サービス一時停止中 | メンテナンスや高負荷時 |
身近な例え
- 200 OK：注文通りに料理が提供された
- 404 Not Found：注文した料理がメニューにない
- 503 Service Unavailable：厨房がメンテナンス中で料理できない
試験で問われやすいポイント
- 分類の番号と意味を押さえる
- 301と302、401と403などの違いを理解する
- 304 Not Modifiedはキャッシュ活用の要
まとめ│HTTPの進化と関連技術を体系的に理解する
HTTPはWebの基盤となる通信プロトコルであり、その進化はパフォーマンスや機能性の向上に直結します。HTTP/1.1のパイプライン処理は効率化の一歩でしたが、HTTP/2ではストリームによる多重化やHPACK圧縮、サーバプッシュなど、より高度な最適化が可能になりました。
さらに、リアルタイム通信を可能にするWebSocket、ファイル管理を実現するWebDAV、通信の構造を決めるヘッダとボディ、レスポンスの意味を示すステータスコードも、試験や実務での重要ポイントです。
これらを体系的に理解しておくことで、ネットワークやWeb開発の現場だけでなく、情報処理試験でも確実な得点源になります。