この記事でわかること

• アプリケーション層が担う役割と、下の3層との違い
• クライアントとサーバーのリクエスト/レスポンスという基本パターン
• データが各層のヘッダで包まれていくカプセル化の仕組み
• 代表的なアプリケーション層プロトコルの一覧と用途
• URLを入力してから画面に表示されるまでの、全層を使った総まとめ

はじめに

第16回でTCP/IPモデルの4層構造を学んで以来、この連載は下の層から順に積み上げてきました。

アプリケーション層      ← 今回、ついにここへ
─────────────────
トランスポート層        第27〜30回
─────────────────
インターネット層        第18〜26回
─────────────────
ネットワークインターフェース層  第17回

MACアドレス、スイッチ、IPアドレス、ルーティング、ARP、NAT、ポート番号、TCP、3ウェイハンドシェイク——それぞれの層で学んだものすべてが土台となって、今回のアプリケーション層に到達します。

アプリケーション層はユーザーに最も近い層です。ブラウザでウェブを見るとき、メールを送るとき、ドメイン名でサーバーを見つけるとき——私たちが「インターネットを使っている」と感じるほぼすべての瞬間は、アプリケーション層のプロトコルが動いています。

アプリケーション層の役割——「何を」届けるか

これまでの3つの層が担ってきたことを振り返ります。

下の3層が「どうやって届けるか」を担うのに対し、アプリケーション層が担うのは「何を届けるか」です。

「ウェブページのデータをください」「このメールを送ってください」「このドメイン名はどのIPアドレスですか」——アプリが実際にやりとりしたい内容の書式・意味・手順を定めるのがアプリケーション層の役割です。

郵便に例えるなら、下の3層は「手紙を届けるための仕組み（トラック・道路・配達員）」です。アプリケーション層は「手紙の中身の書き方」——ビジネス文書なら縦書きで敬語、フォームなら決まった欄に記入する、といった「書式と文法」に相当します。同じ配送インフラを使いながら、手紙の書き方（プロトコル）は用途ごとに異なります。

クライアントとサーバー

アプリケーション層の通信は、ほとんどの場合「クライアントとサーバー」という役割分担で成り立っています。

• Client（クライアント）：もとは「依頼人」「顧客」という意味。サービスを要求する側
• Server（サーバー）：Serve（サービスを提供する）+ -er（〜するもの）→「サービスを提供するもの」

ブラウザはクライアントとして「このページをください」と要求を送り、ウェブサーバーはその要求に答えてHTMLデータを返します。

• Request（リクエスト）：「要求」「依頼」という意味
• Response（レスポンス）：「返答」「応答」という意味

クライアント（ブラウザ）          サーバー（ウェブサーバー）
       │                                │
       │ ── リクエスト ───────────────► │  「このページをください」
       │                                │
       │ ◄─────────────── レスポンス ── │  「はい、どうぞ（HTMLデータ）」
       │                                │

このリクエスト→レスポンスのパターンは、HTTP・DNS・SMTP・DHCPなど、ほぼすべてのアプリケーション層プロトコルに共通する基本形です。

「クライアント」と「サーバー」はソフトウェアの役割であって、機器の名前ではありません。同じパソコンが、ウェブを見るときはクライアントとして動き、ファイルを共有するときはサーバーとして動くことも珍しくありません。

データの包み方——カプセル化

アプリケーション層で作られたデータは、送信される前に下の層から順番に「包み紙」をかぶせられていきます。これを**カプセル化（Encapsulation）**と呼びます。

• Encapsulation（エンカプスレーション）：Capsule（カプセル）→「カプセルに包む」という意味。各層が自分の管理情報（ヘッダ）を付け加えながらデータを包んでいく操作

HTTPリクエストが各層でどのように包まれていくかを見てみましょう。

【アプリケーション層】
┌──────────────────────────────────┐
│         HTTP リクエストデータ       │
└──────────────────────────────────┘

【トランスポート層】TCPヘッダを追加
┌──────────┬───────────────────────┐
│ TCPヘッダ │   HTTP リクエストデータ  │
└──────────┴───────────────────────┘

【インターネット層】IPヘッダを追加
┌─────────┬──────────┬─────────────┐
│ IPヘッダ │ TCPヘッダ │ HTTP データ  │
└─────────┴──────────┴─────────────┘

【ネットワークインターフェース層】Ethernetヘッダ＋フッタを追加
┌──────────┬─────────┬──────────┬────────┬──────┐
│Ethernetヘッダ│ IPヘッダ │ TCPヘッダ │HTTPデータ│フッタ│
└──────────┴─────────┴──────────┴────────┴──────┘

各層が自分の担当情報（宛先MACアドレス、宛先IPアドレス、宛先ポート番号など）をヘッダとして前に追加します。

• Header（ヘッダー）：「頭部」「先頭部分」という意味。宛先・送信元・通信管理に必要な情報が書かれた部分
• Payload（ペイロード）：もとは「積み荷の費用」という意味。転じてパケットの「本当に届けたい中身のデータ」を指します

受信側では逆の順番で包みを開いていきます（デカプセル化）。Ethernetヘッダを外してIPヘッダを外してTCPヘッダを外し、中のHTTPデータを取り出してブラウザに渡します。

この「包んで送り、受け取って開く」という仕組みがあるおかげで、各層は他の層の中身を知らなくても自分の役割だけに集中できます。HTTPが「下でTCPが動いているか、それともUDPか」を気にしなくていいのはこのためです。

主なアプリケーション層プロトコル

アプリケーション層には、用途ごとに多くのプロトコルが存在します。

それぞれのプロトコルは「この種類のやりとりはこのフォーマットで、この順序で行う」というルールを細かく定めています。

HTTPであれば GET /index.html HTTP/1.1 という書式でリクエストし、200 OK や 404 Not Found という形式でレスポンスが返ります。DNSであれば「このドメイン名のAレコード（IPアドレス）を教えてください」という形式で問い合わせます。プロトコルはその「文法」です。

このシリーズでは今後、DNS・DHCP・HTTP を個別の記事で深掘りしていきます。

URLを入力してから表示されるまで——全層の総まとめ

ここで、アドレスバーに https://www.google.com と入力してエンターキーを押したときに何が起きるかを、この連載で学んだすべての層の仕組みを使って追いかけてみます。

① DNSで名前をIPアドレスに変換する（アプリケーション層）

ブラウザは www.google.com というドメイン名を知っていますが、通信に必要なIPアドレスは知りません。まず設定されたDNSサーバーに「このドメイン名のIPアドレスは何ですか？」と問い合わせます（第25回のデフォルトゲートウェイ設定でDHCPが自動配布していたDNSサーバーです）。

DNSサーバーから 142.250.185.46 のようなIPアドレスが返ってきます。

② デフォルトゲートウェイかどうか判断する（インターネット層）

IPアドレスがわかりました。自分のサブネットマスクと照らし合わせると、142.250.185.46 は自分とは別のネットワークです（第21・25回）。パケットはデフォルトゲートウェイ（自宅ルーター）に転送されます。

③ ARPでゲートウェイのMACアドレスを調べる（ネットワークインターフェース層）

ルーターのMACアドレスをARPで問い合わせます（第26回）。Ethernetフレームの宛先にルーターのMACアドレスを書いてパケットを送り出します。

④ TCPの3ウェイハンドシェイクで接続確立（トランスポート層）

ルーターとNATを経由したパケットが（第23回）、複数のルーターをホップして（第24回）Googleのサーバーに届き、TCPの3ウェイハンドシェイクが行われます（第30回）。宛先ポートはHTTPSの443番です。

⑤ TLSハンドシェイクで暗号化を確立

TCPの接続が確立した後、TLSというプロトコルでハンドシェイクが行われ、以降の通信が暗号化されます。これもアプリケーション層寄りの仕組みです。

⑥ HTTPリクエストを送信（アプリケーション層）

接続が確立したら、ブラウザがHTTPリクエストを送ります。

GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 ...
Accept: text/html, ...

「/（トップページ）をHTTP/1.1の書式でください」という要求です。このリクエストがカプセル化されて、TCPヘッダ→IPヘッダ→Ethernetヘッダと包まれて送信されます。

⑦ HTTPレスポンスが返ってくる（アプリケーション層）

Googleのサーバーがレスポンスを返します。

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<!doctype html>...（HTMLデータ）

200 OK は「正常に返せました」を意味するステータスコードです。

⑧ ブラウザがHTMLを解釈して画面に表示

レスポンスの中のHTMLデータをブラウザが解釈し、CSS・JavaScript・画像を追加取得しながらページを構築して表示します。

ブラウザのアドレスバーにURLを入力してエンターを押す——その0.数秒の間に、これだけの処理が連鎖しています。第16回から第31回まで積み上げてきた知識が、この一連の流れの中にすべて詰まっています。

アプリケーション層のデータをコマンドで覗いてみよう

アプリケーション層のHTTPリクエスト・レスポンスは、curl コマンドで直接確認できます。

curl -v https://www.google.com 2>&1 | head -50

-v（verbose = 詳細表示）オプションをつけると、TCPの接続・TLSのハンドシェイク・HTTPのリクエストとレスポンスヘッダが順番に出力されます。

* Connected to www.google.com (142.250.185.46) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
> GET / HTTP/2
> Host: www.google.com
> User-Agent: curl/8.1.2
>
< HTTP/2 200
< content-type: text/html; charset=UTF-8
< date: Sat, 07 Jun 2026 12:34:56 GMT

> で始まる行がブラウザから送ったリクエスト、< で始まる行がサーバーから返ってきたレスポンスです。

レスポンスのヘッダだけを見たいときは -I オプションを使います。

curl -I https://www.google.com

ステータスコード（200・301・404など）・コンテンツの種類・キャッシュの設定などが確認できます。アプリケーション層のプロトコルが実際にどんなメッセージを交わしているか、目で見ることができます。

まとめ

• アプリケーション層はTCP/IPモデルの最上位の層。下の3層が「どうやって届けるか」を担うのに対し、アプリケーション層は「何を届けるか（メッセージの内容・書式・意味）」を定義する
• アプリケーション層の通信はクライアント（要求する側）とサーバー（応答する側）のリクエスト→レスポンスというパターンが基本
• データは送信時に下の層から順にヘッダで包まれていく（カプセル化）。受信時は逆順に開かれる（デカプセル化）。この仕組みにより各層は独立して動ける
• 代表的なプロトコルはHTTP・HTTPS・DNS・SMTP・POP3・IMAP・FTP・SSH・DHCP・SNMPなど
• URLを入力してからページが表示されるまでの流れの中に、この連載で学んだすべての層（DNS・ARP・NAT・ルーティング・TCP・HTTP）が順番に登場する
• curl -v コマンドでHTTPのリクエスト・レスポンスの中身をリアルタイムで確認できる