Skip to content
Published on

[コンピュータネットワーク] 05. アプリケーション層：HTTPとWeb

🇰🇷KO🇺🇸EN🇯🇵JA
Split View
Authors

本記事は James Kurose, Keith Ross 著 Computer Networking: A Top-Down Approach (6th Edition) の教科書を基にまとめた内容です。

1. ネットワークアプリケーション構造

1.1 クライアント-サーバー構造（Client-Server Architecture）

常時稼働サーバー（固定IP）
       ↑↓
┌──────┴──────┐
│ クライアント1 │
│ クライアント2 │  （間欠的接続、動的IP可能）
│ クライアント3 │
└─────────────┘

特徴：

  • サーバーが常時稼働し固定IPアドレスを持つ
  • クライアント同士は直接通信しない
  • スケーリングのために**データセンター（data center）**を活用

1.2 P2P構造（Peer-to-Peer Architecture）

ピア1 ←────→ ピア2
  ↕            ↕
ピア3 ←────→ ピア4

すべてのピアがクライアントでありサーバーでもある

特徴：

  • 常時稼働サーバーがないか最小限のみ存在
  • 自己拡張性（self-scalability）：ピアが増えるほどサービス容量も増加
  • 例：BitTorrent、Skype、ビットコイン

1.3 プロセス通信

ネットワークアプリケーションは、異なるエンドシステムで実行されるプロセス間の通信で構成される。

  • クライアントプロセス：通信を開始するプロセス
  • サーバープロセス：接続を待つプロセス
  • プロセスは**ソケット（socket）**を通じてネットワークにアクセス
┌──────────────┐                    ┌──────────────┐
│ アプリケーション│                    │ アプリケーション│
│  プロセス      │                    │  プロセス      │
│      │        │                    │      │        │
│  ソケット(ドア)│                    │  ソケット(ドア)│
├──────┼────────┤                    ├──────┼────────┤
│ トランスポート層│                    │ トランスポート層│
│      │        │  ← インターネット → │      │        │
│   ...         │                    │   ...         │
└──────────────┘                    └──────────────┘
  クライアント                         サーバー

2. HTTPの概要

2.1 HTTPとは

**HTTP（HyperText Transfer Protocol）**はWebのアプリケーション層プロトコルである。

  • クライアント-サーバーモデルに従う
  • クライアント：Webブラウザ（Webオブジェクトを要求し表示）
  • サーバー：Webサーバー（要求に応じてオブジェクトを送信）

2.2 WebページとWebオブジェクト

Webページの構成：
  ├── ベースHTMLファイル（base HTML file）
  ├── JPEG画像（referenced object）
  ├── JavaScriptファイル
  ├── CSSスタイルシート
  └── 動画ファイル

各オブジェクトは1つのURLで識別される。

URLの構造：

http://www.example.com/path/page.html
 ──┬──  ──────┬──────  ─────┬───────
プロトコル  ホスト名       パス名

2.3 HTTPの特徴

  • TCPを使用：信頼性のある転送を保証
  • ステートレス（stateless）プロトコル：サーバーはクライアントの以前の要求情報を保持しない
HTTP通信プロセス：
  1. クライアントがサーバーのポート80（または443）へTCP接続を開始
  2. TCP接続確立（3ウェイハンドシェイク）
  3. HTTPメッセージ交換
  4. TCP接続終了

3. 非持続接続 vs 持続接続

3.1 非持続HTTP（Non-Persistent HTTP）

各リクエスト/レスポンスのペアが別々のTCP接続を通じて送信される。

ベースHTML + 10個の画像を含むページの要求：

1. TCP設定 → ベースHTML要求/応答 → TCP終了
2. TCP設定 → 画像1要求/応答 → TCP終了
3. TCP設定 → 画像2要求/応答 → TCP終了
...
11. TCP設定 → 画像10要求/応答 → TCP終了

→ 合計11回のTCP接続が必要！

応答時間の分析

RTT（Round-Trip Time）：パケットがクライアントからサーバーへ行き
                         戻ってくるのにかかる時間

1つのオブジェクト要求にかかる時間：

  クライアント       サーバー
     |── SYN ──────>|
     |<─ SYN+ACK ──|   ← 1 RTT（TCP接続設定）
     |── GET ──────>|
     |<─ ファイル転送 ─|   ← 1 RTT + ファイル転送時間
     |              |

  総時間 = 2 RTT + ファイル転送時間

3.2 持続HTTP（Persistent HTTP）

サーバーがレスポンスを送信した後もTCP接続を維持する。

持続接続：

1. TCP接続設定                      ← 1 RTT
2. ベースHTML要求/応答               ← 1 RTT
3. 画像1要求/応答（同じ接続）        ← 1 RTT
4. 画像2要求/応答（同じ接続）        ← 1 RTT
...

→ TCP接続を再利用するためオーバーヘッド削減

パイプライニング（Pipelining）

持続接続で応答を待たずに連続してリクエストを送る技法である。

パイプラインなし：           パイプライン使用：
  リクエスト1 ──>            リクエスト1 ──>
  <── レスポンス1            リクエスト2 ──>
  リクエスト2 ──>            リクエスト3 ──>
  <── レスポンス2            <── レスポンス1
  リクエスト3 ──>            <── レスポンス2
  <── レスポンス3            <── レスポンス3

  合計 3 RTT                 合計 約1 RTT

HTTP/1.1では持続接続がデフォルトである。

4. HTTPメッセージ形式

4.1 HTTPリクエストメッセージ

GET /somedir/page.html HTTP/1.1
Host: www.example.com
Connection: close
User-Agent: Mozilla/5.0
Accept-Language: ko-KR

リクエストメッセージの構造

┌────────────────────────────────────────┐
│ リクエスト行（request line）             │
│   メソッド SP URL SP バージョン CR LF    │
├────────────────────────────────────────┤
│ ヘッダ行（header lines）                │
│   ヘッダフィールド: 値 CR LF             │
│   ヘッダフィールド: 値 CR LF             │
│   ...                                  │
│   CR LF（空行 = ヘッダ終了）             │
├────────────────────────────────────────┤
│ エンティティボディ（entity body）        │
│   POSTメソッドの場合に使用               │
└────────────────────────────────────────┘

主要なHTTPメソッド

メソッド用途ボディの有無
GETオブジェクトの要求なし
POSTフォームデータの送信あり
HEADGETと同じだがヘッダのみ応答なし
PUT特定URLにオブジェクトをアップロードあり
DELETE特定URLのオブジェクトを削除なし

4.2 HTTPレスポンスメッセージ

HTTP/1.1 200 OK
Connection: close
Date: Thu, 19 Mar 2026 12:00:00 GMT
Server: Apache/2.4
Content-Length: 6821
Content-Type: text/html

(データ...)

主要なステータスコード

コード意味説明
200OKリクエスト成功
301Moved Permanentlyオブジェクトが恒久的に移動
304Not Modifiedキャッシュ版使用可能
400Bad Requestリクエスト形式エラー
404Not Found要求オブジェクトなし
505HTTP Version Not Supported非対応HTTPバージョン

5. クッキー（Cookies）

HTTPはステートレスプロトコルだが、Webサイトはユーザーを識別する必要がある。そのためにクッキーを使用する。

5.1 クッキーの4つの構成要素

1. HTTPレスポンスメッセージのSet-Cookieヘッダ
2. HTTPリクエストメッセージのCookieヘッダ
3. クライアント（ブラウザ）に保存されるクッキーファイル
4. Webサイトのバックエンドデータベース

5.2 クッキーの動作プロセス

初回訪問：
  クライアント                  サーバー
     |── GET /index.html ──>|
     |                       | クッキーID 1678を生成
     |<── Set-Cookie: 1678 ──|
     |                       | DBに1678の記録を保存
     |  ブラウザがクッキー保存 |

再訪問：
     |── GET /cart           |
     |   Cookie: 1678 ────>  |
     |                       | DBで1678を検索
     |<── カスタム応答 ──────── |

6. Webキャッシュ（Web Caching）

6.1 プロキシサーバー

Webキャッシュ（またはプロキシサーバー）は、オリジンサーバーに代わってHTTPリクエストに応答するネットワークエンティティである。

クライアント ──> プロキシサーバー ──> オリジンサーバー
                    │
                キャッシュストレージ

6.2 動作プロセス

1. クライアントがプロキシサーバーにリクエスト
2. プロキシがキャッシュにオブジェクトを保有？
   ├── YES → キャッシュされたオブジェクトをクライアントに返送
   └── NO  → オリジンサーバーにリクエスト → 応答をキャッシュ → クライアントに返送

6.3 Webキャッシュの利点

例：機関ネットワーク → インターネット接続リンク(15 Mbps) → インターネット

リクエスト率：毎秒15件、平均オブジェクトサイズ：1 Mbit
総リクエストトラフィック：15 Mbps

接続リンク利用率 = 15/15 = 100% → キューイング遅延爆発！

解決策1：接続リンクのアップグレード（100 Mbps）→ コスト高
解決策2：Webキャッシュの設置（ヒット率40%と仮定）
  → 接続リンクトラフィック = 15 * 0.6 = 9 Mbps
  → 利用率 = 9/15 = 60% → 遅延削減！
方策接続リンク利用率コスト
リンクアップグレード（100Mbps）15%非常に高い
Webキャッシュ設置（40%ヒット率）60%低い

7. 条件付きGET（Conditional GET）

キャッシュされたオブジェクトが最新かどうかを確認するメカニズムである。

7.1 動作プロセス

初回リクエスト：
  プロキシ ── GET /fruit.gif ──────────> サーバー
  プロキシ <── 200 OK                ──  サーバー
                Last-Modified: Wed, 9 Mar 2026

キャッシュ有効性確認（条件付きGET）：
  プロキシ ── GET /fruit.gif ──────────> サーバー
               If-Modified-Since:
               Wed, 9 Mar 2026

  ケース1：変更なし
  プロキシ <── 304 Not Modified ──────── サーバー
                （オブジェクト本文なし！帯域幅節約）

  ケース2：変更あり
  プロキシ <── 200 OK ───────────────── サーバー
                （新しいオブジェクト本文を含む）

304レスポンスはオブジェクト本文を含まないため、帯域幅を節約する。

8. HTTPバージョンの発展

HTTP/1.0 (1996):
  - 非持続接続
  - GET, POST, HEAD

HTTP/1.1 (1997):
  - 持続接続（デフォルト）
  - パイプライニング
  - Hostヘッダ必須
  - PUT, DELETE追加

HTTP/2 (2015):
  - バイナリフレーミング
  - マルチプレキシング（1つの接続で複数リクエスト/レスポンスを並列処理）
  - ヘッダ圧縮
  - サーバープッシュ

HTTP/3 (2022):
  - QUICプロトコルベース（UDP）
  - HOLブロッキングの解決
  - より高速な接続設定

9. まとめ

HTTPの核心要約：
  ├── TCPベース、ステートレスプロトコル
  ├── リクエスト-レスポンスモデル
  ├── 非持続/持続接続（HTTP/1.1から持続がデフォルト）
  ├── クッキーで状態管理
  ├── Webキャッシュ（プロキシ）で遅延削減と帯域幅節約
  └── 条件付きGETでキャッシュの有効性検証

10. 確認問題

Q1. 非持続HTTPで10個のオブジェクトを含むWebページを要求するとTCP接続は何回必要か？

11回である。ベースHTMLファイル用の1回 + 10個の参照オブジェクト用の10回 = 合計11回のTCP接続が必要である。各TCP接続ごとに2 RTT（接続設定1 RTT + リクエスト/レスポンス1 RTT）が必要なため、合計22 RTTが必要となる。

Q2. HTTPはステートレスプロトコルなのに、どのようにユーザーを識別するのか？

**クッキー（Cookie）**を使用する。サーバーが Set-Cookie ヘッダで一意の識別番号を送り、ブラウザがこれを保存して以降のリクエスト時に Cookie ヘッダに含める。サーバーはこのクッキー値でバックエンドデータベースを検索してユーザーを識別する。

Q3. 条件付きGETの目的は何か？

キャッシュに保存されたオブジェクトが最新かどうかを確認するために使用する。If-Modified-Since ヘッダを含めてリクエストすると、サーバーはオブジェクトが変更されていない場合 304 Not Modified をオブジェクト本文なしで応答する。これにより不要なデータ転送を削減し帯域幅を節約する。

Discuss on Twitter • View on GitHub