NET // communication networks
LESSON 11 / 標準編

ネットワークの全体像 ─ 階層化とカプセル化

本レッスンは標準シリーズの入口です。なぜネットワークは「層」に分けて設計されているのか、TCP/IP 4層モデルと OSI 7層モデルの対応、各層が下層に対して提供するサービスインタフェース、そしてデータが層を下りるたびに包まれていくカプセル化の流れを、Kurose-Ross 流のトップダウン(アプリ層から下へ)の視点から整理します。

学習目標

本講を終えると、以下の問いに学術的な言葉で答えられるようになります。

本講は基礎の 第3回 プロトコルと TCP/IP 階層モデル(基礎) を再構成・深化したものです。基礎編で扱った「封筒のたとえ」「ヘッダの付箋」を前提とし、標準編では規格番号(IEEE 802.x)・PDU 名・サービスプリミティブといった専門語を導入します。次回(第12回)以降、アプリケーション層 → トランスポート層 → ネットワーク層 → リンク層の順で深堀りしていきます。

このレッスンの目次

01 なぜ階層化 通信システムは、電気信号の符号化からアプリケーションのセマンティクスまで、性質の大き… 02 TCP/IP と OSI 現実のインターネット実装は TCP/IP モデル(4層) に基づいています。一方、概… 03 サービスインタフェース 階層モデルを学術的に語るうえで欠かせないのが 「サービスインタフェース(servic… 04 カプセル化 送信側でデータが層を下りるとき、各層は受け取った上位層の PDU( Protocol… 05 ヘッダ・トレイラ 各層のヘッダは、その層が次の処理を行うために必要な情報の集合体です。ここでは代表的な… 06 各層の代表例 基礎編で名前を覚えたプロトコル群を、ここでは 規格番号と RFC、所属組織 とともに… 07 トップダウンの宣言 本サイトの標準レッスンは、Kurose-Ross の名著 Computer … 08 歴史を意識する インターネットの勉強を進めると、 今の感覚では「なぜわざわざこんな設計にしたのか」と… 09 まとめ 本講の重要語句を整理 10 確認問題 理解度を問題でチェック

なぜ階層化するのか ─ 設計原理としての3つの理由

通信システムは、電気信号の符号化からアプリケーションのセマンティクスまで、性質の大きく異なる多数の機能が積み重なった複雑な人工物です。これを単一のプロトコルで一括設計することは現実的ではなく、機能ごとに「層(layer)」に分割し、層と層の境界(インタフェース)だけを標準化するという方針が採られています。教科書的にはその目的は、次の3つに集約されます。
POINT 階層化の3目的:
1. 関心の分離(separation of concerns) ─ 各層は自分の役割だけを扱う
2. 置換可能性(modularity / replaceability) ─ ある層の実装を入れ替えても他層は影響を受けない
3. 複雑性の管理(complexity management) ─ 巨大なシステムを部品の階層に分解して扱える

3つの理由をもう少し

関心の分離

「何を運ぶか(意味)」「どう運ぶか(信頼性)」「どこへ運ぶか(経路)」「隣にどう信号を送るか(物理)」は、本来別の問題です。これらを別々の層に閉じ込めることで、各層を担当する技術者・規格・ツールが独立して進化できます。

置換可能性

下層を Ethernet から Wi-Fi(IEEE 802.11)に差し替えても、TCP・IP・HTTP は書き直し不要です。逆に上層の HTTP/1.1 を HTTP/2 に変えても、リンク層の規格は触らなくて済みます。これが層境界(インタフェース)を標準化したご利益です。

複雑性の管理

「全部入りの巨大仕様」を世界中の関係者が一度に合意することは事実上不可能です。階層化により、各層の RFC・IEEE 規格を独立に議論・改定でき、後方互換性も維持しやすくなります。

Q. もし「全部を1層に詰め込んだ」モノリシックなネットワーク設計だったら、どんな具体的な不都合が起きるでしょうか。3つ以上挙げてからクリック。

つながる知識: 関心の分離はソフトウェア工学全般の原理(モジュラリティ、抽象化境界の設計)と通底します。Saltzer らの古典的な End-to-End Arguments in System Design(1984)は、「ある機能はどの層に置くべきか」という、階層化のさらに一段深い設計議論への入り口です。本サイト発展編で扱います。

とはいえ現実は ─ トランスポート層は TCP / UDP、ネットワーク層は IP(IPv4 / IPv6)、データリンク層は Ethernet / Wi-Fi(IEEE 802 系) がほぼ事実上の標準として固まっており、これらを別物に「置き換える」ような動きはほとんどありません。階層化は理論上は置換可能性を約束しますが、世界中の機器・OS・ミドルボックスがこの組合せに最適化されてしまった結果、新しい層プロトコルを下から普及させるのは極めて難しい状況です。これを protocol ossification(プロトコルの硬直化) と呼びます。
最近の進化はむしろ、既存層の 上に乗せる 形(例: QUIC(発展)は UDP の上に新しいトランスポート機能を構築)や、既存層の 制御の仕方 を変える形(SDN・輻輳制御の更新など)で進んでおり、層そのものを差し替える革命は起きていない、というのが現代のインターネットの実情です。

TCP/IP 4層モデルと OSI 7層参照モデル

現実のインターネット実装は TCP/IP モデル(4層) に基づいています。一方、概念整理・教育・国際標準の文脈では OSI 参照モデル(7層, ISO/IEC 7498-1) が広く参照されます。両者は競合した歴史を持ちますが、現在は「実装は TCP/IP、用語整理は OSI」という棲み分けで併用されています。
POINT TCP/IP 4層 = アプリケーション / トランスポート / ネットワーク(インターネット) / リンク。
OSI 7層 = 上記に加え、上位を セッション / プレゼンテーション / アプリケーション に細分し、最下位を データリンク / 物理 に分割した形。

TCP/IP 4層(実装)

インターネット実装の基準モデル。RFC 1122(ホスト要件)等で採用されている、いわゆるインターネット・プロトコル・スイートです。

  1. アプリケーション層:アプリケーション固有のメッセージ意味論を担う。HTTP・SMTP・DNS など。
  2. トランスポート層:プロセス間(end-to-end)の論理通信を提供。TCP は信頼性・順序保証・フロー制御・輻輳制御を、UDP は最小機能の多重化のみを提供。
  3. ネットワーク層(インターネット層):異なるネットワーク間でホストからホストへベストエフォートでデータグラムを届ける。IP・ICMP など。
  4. リンク層:同一ネットワーク内の隣接ノード間で、フレームをやり取りする。Ethernet (IEEE 802.3)、無線 LAN (IEEE 802.11) など。物理層を内包する解釈と分離する解釈の双方があります。

OSI 7層参照

ISO による7層参照モデル。実装そのものではなく、用語と責務分担を整理するためのフレームワークとして機能します。

  1. 第7層 アプリケーション層:アプリ固有プロトコル
  2. 第6層 プレゼンテーション層:文字コード変換・暗号化・圧縮など、データ表現の変換
  3. 第5層 セッション層:対話の開始・同期点・再開の管理
  4. 第4層 トランスポート層:プロセス間 end-to-end の品質管理
  5. 第3層 ネットワーク層:経路制御(ルーティング)とパケット転送
  6. 第2層 データリンク層:隣接ノード間のフレーム転送・誤り検出
  7. 第1層 物理層:電気・光・電波などの符号化規格

両モデルを並べて比較

両モデルを縦に並べると、層の対応関係が視覚的に整理できます。

OSI 参照モデル(7層) TCP/IP モデル(4層) 7. アプリケーション 6. プレゼンテーション 5. セッション 4. トランスポート 3. ネットワーク 2. データリンク 1. 物理 アプリケーション層 (OSI 5-7 を統合) トランスポート層 ネットワーク層 リンク層 (物理層を内包する解釈もあり) ※ OSI の上位3層は、TCP/IP では1つのアプリケーション層に統合されている

図の見方:OSI のセッション・プレゼンテーション・アプリケーションは、TCP/IP では1つの「アプリケーション層」にまとめられています。これは、TCP/IP がセッション管理や表現変換を「アプリ自身の責任」と位置付けているからです。一方、リンク層は OSI のデータリンク+物理に対応し、文献によっては TCP/IP でも物理層を分離して5層と数える流儀もあります。

もっと詳しく:なぜ TCP/IP は OSI に勝ったのか

1980年代、ISO の OSI 一族と DARPA 系の TCP/IP は事実上のライバル関係にありました。TCP/IP が事実上の標準となった理由は、教科書(Tanenbaum, Kurose-Ross 等)で次のように整理されています。

とはいえ OSI の用語(「L7 ロードバランサ」「L3 スイッチ」など)は今でも実務で広く使われており、概念整理ツールとして生き残っています。

考えてみよう: あなたの普段使うアプリで、OSI の「プレゼンテーション層」に相当する処理(暗号化・圧縮・文字コード変換)はどこで行われているでしょうか。TLS は厳密には何層に位置付けられるか、標準 で再訪します。

サービスインタフェース ─ 下層は上層に何を提供するか

階層モデルを学術的に語るうえで欠かせないのが 「サービスインタフェース(service interface)」 という概念です。各層 N は、上の層 N+1 に対してサービス(できること)を提供し、上層はそのサービスをサービスプリミティブ(具体的な API 呼び出しのようなもの)を通じて利用します。隣接2層がやり取りする「窓口」を明確に決めることで、層内部の実装を自由に交換できるようになります。
POINT 上位層は、下位層が 「何を」 提供するかだけ知っていればよく、「どうやって」 実現しているかは知らなくてよい。これがプロトコル階層の抽象化境界です。

各層が下層に対して提供するサービス(代表例)

層その層が上位に提供する代表サービス上位から見えるインタフェース(イメージ)
アプリケーションアプリ固有メッセージ交換(リソース取得、メール送信など)ブラウザ・メーラ等の UI / ライブラリ API
トランスポートプロセス間の論理通信(信頼性ある byte stream / コネクションレス データグラム)ソケット API: socket / connect / send / recv
ネットワークホスト間データグラム配送(ベストエフォート)「この IP にこのデータを投げて」という単一サービス
リンク同一リンク上の隣接ノードへのフレーム転送・誤り検出「このインタフェースからフレームを送出/受信」
物理ビット列の電気/光/電波信号化と送出NIC ドライバ層、PHY チップ
OSI ではサービスプリミティブを request / indication / response / confirm の4種で形式化しています。実務でこの語彙を直接使う場面は限られますが、「下層への要求」「上層への通知」という非対称な API 設計の発想は、現代のソケット API や RPC の根幹に残っています。L3 編で再訪します。

水平方向の対話 ─ ピア・プロトコル

同じ層に属する送信側と受信側は、論理的には直接会話しているように見えます。これを ピア(peer) 同士の通信と呼びます。実際にはデータは下層に渡され、物理層を経由して相手に届くのですが、「TCP は TCP と話す」「IP は IP と話す」と捉えると整理しやすくなります。

アプリケーション トランスポート ネットワーク リンク 物理 アプリケーション トランスポート ネットワーク リンク 物理 HTTP / SMTP / DNS …(アプリ ピア) TCP / UDP(トランスポート ピア) IP(ネットワーク ピア) Ethernet / 802.11(リンク ピア) ↕ サービス ↕ サービス ↕ サービス ↕ サービス 実際のビット転送はここだけ

図の見方:横方向の点線は「同じ層同士の論理的会話(ピア・プロトコル)」を表します。実際にはデータは縦に下りて物理層に達し、相手側で縦に上がっていきますが、設計上はあたかも各層が直接話しているかのように振る舞います。縦方向の小さな矢印が「サービスインタフェース(層境界)」です。

カプセル化と非カプセル化 ─ データが層を旅する

送信側でデータが層を下りるとき、各層は受け取った上位層の PDU(Protocol Data Unit)をペイロードとして扱い、自身のヘッダ(必要ならトレイラ)を付加して下層に渡します。これを カプセル化(encapsulation) と呼びます。受信側はその逆で、各層がヘッダを剥がしながら上層へ渡していきます(非カプセル化 / decapsulation)。
POINT PDU の名前は層によって変わる:
アプリ メッセージ → トランスポート セグメント(TCP) / データグラム(UDP) → ネットワーク (IP)パケット / データグラム → リンク フレーム → 物理 ビット列。

HTTP リクエスト・レスポンスが物理回線に出るまで

具体例として、大きな HTTP メッセージ(例:画像つき HTML や動画ファイルのダウンロード)が送信される場面を、ウォークスルーで追いかけます。各ステップで「どの層が」「どんなヘッダを」加えているか、そして 大きなメッセージはどこで分割されるか に注目してください。

HTTP メッセージ(大きなファイル) アプリ層 PDU(例:大きな HTML / 画像 / 動画 ─ 点線は将来の分割位置) → MSS に合わせて複数のチャンクに分割される TCPヘッダ chunk 1 TCPヘッダ chunk 2 TCPヘッダ chunk 3 分割された各チャンクに TCP ヘッダ → 複数の TCP セグメント IPヘッダ TCPヘッダ HTTP メッセージ Ethernet ヘッダ IPヘッダ TCPヘッダ HTTP メッセージ FCS Ethernet フレーム(MAC アドレス + FCS) 物理層:ビット列に変換 10110100 11001010 01110011 … 受信側で逆順に剥がされ、HTTP メッセージとしてサーバに到着 物理 → リンク(Ethernetヘッダ / FCS検査) → ネットワーク(IPヘッダ) → トランスポート(TCPヘッダ) → アプリ 送信側 受信側
ステップ1. ブラウザ(あるいはサーバ側)がアプリケーション層のメッセージを生成します。ここでは単純な GET ではなく、大きなファイル(画像・動画・HTML+CSS+画像 で数百KB〜)を扱う場面を考えます。この時点ではまだ単なるバイト列で、ヘッダもポート番号も付いていません。点線は これから入る分割位置 を示しています。
ステップ2. トランスポート層は、まず大きな HTTP メッセージを MSS(Maximum Segment Size, 典型的に 1460 バイト) に収まるサイズの チャンクに分割 します。その上で各チャンクに TCP ヘッダを付加 し、複数の TCP セグメント を生成します。TCP ヘッダには送信元/宛先ポート番号(HTTP なら宛先 80、HTTPS なら 443)、シーケンス番号・確認応答番号、ウィンドウサイズ、フラグ(SYN/ACK/FIN 等)が入ります。シーケンス番号があるおかげで、受信側はバラバラに届いた複数のセグメントを正しい順に並べ直せます。
ステップ3. ネットワーク層が IP ヘッダ を付加し、IP パケット(データグラム)になります。ヘッダには送信元/宛先 IP アドレス、TTL、上位プロトコル番号(TCP=6, UDP=17)などが入ります。これでホスト間配送の用意ができました。
ステップ4. リンク層が Ethernet ヘッダ(送信元/宛先 MAC アドレス、EtherType)を前に、FCS(Frame Check Sequence, CRC)を後ろに付け、フレームが完成します。これだけは前後両端にビットを付ける(=トレイラを持つ)層です。
ステップ5. 物理層がフレームを ビット列に符号化し、銅線・光ファイバ・電波として送出します。受信側ではこの逆順、すなわち「ビット → フレーム検査 → IP 取り出し → TCP 取り出し → アプリへ」と剥がしていきます。
ステップ6. 受信側のサーバ アプリ(Web サーバ)に最終的に届くのは、最初にブラウザが書いた HTTP メッセージそのものです。途中の TCP・IP・Ethernet の存在は、アプリからは隠蔽されています。これが階層化の威力。
1 / 6

図の見方:層を下りるたびに、上位層 PDU(色付きの帯)は次の層のヘッダで前(と FCS のように後ろ)を包まれます。各層は自分のヘッダだけを読み、それより内側はただのバイト列(opaque payload)として扱います。

パケットがレイヤを下りるアニメーション

下の図は「アプリ層からスタートして、層ごとにヘッダが増えながら最終的にケーブルへ流れ出る」様子をアニメで示しています。再生・一時停止・最初から、で何度でも観察してみてください。

アプリ層 トランスポート層 + TCPヘッダ ネットワーク層 + IPヘッダ リンク層 + Ethernetヘッダ / FCS 物理層(ビット列) ケーブル / 光 / 電波(ビット列が流れる) HTTP TCPヘッダ HTTP IPヘッダ TCPヘッダ HTTP Ethernetヘッダ IPヘッダ TCPヘッダ HTTP FCS 1 0 1 1 0 1 0 0 1

図の見方:6秒の周期で「アプリ → トランスポート → ネットワーク → リンク → 物理(ビット列)」と PDU が成長していきます。リンク層では前後両側にヘッダ(+トレイラの FCS)が付くのがポイント。

小問:データ単位を「セグメント」と呼ぶのは、どの層の文脈ですか?
正解: B。「セグメント」は TCP のトランスポート層 PDU の呼び名です。アプリ層は「メッセージ」、ネットワーク層は「(IP)パケット / データグラム」、リンク層は「フレーム」、物理層は「ビット列」と呼び分けます。なお UDP の PDU は厳密には「(ユーザ)データグラム」と呼ばれ、混乱しがちなので注意。

各層の代表プロトコル(L2 視点での再整理)

基礎編で名前を覚えたプロトコル群を、ここでは 規格番号と RFC、所属組織 とともに再整理します。詳細は今後の各回で扱いますが、地図として手元に置いてください。
アプリケーション HTTP/1.1 / HTTP/2 / HTTP/3 SMTP / IMAP / POP3 / DNS / FTP RFC 9110-9114, 5321, 9051, 1939, 1034-1035, 959 トランスポート TCP (RFC 9293) / UDP (RFC 768) QUIC (RFC 9000) ※トランスポートに分類される新しい仲間 ネットワーク IPv4 (RFC 791) / IPv6 (RFC 8200) / ICMP (RFC 792 / RFC 4443) / IPsec (RFC 4301) 経路制御: RIP / OSPF (RFC 2328) / BGP-4 (RFC 4271) リンク Ethernet (IEEE 802.3) / 無線LAN (IEEE 802.11 a/b/g/n/ac/ax/be) / PPP (RFC 1661) ARP (RFC 826) / VLAN (IEEE 802.1Q)

図の見方:括弧内は標準化文書(RFC は IETF、IEEE 802.x は IEEE)。同じ層でも複数の規格が並列に存在し、用途・歴史的経緯で使い分けられています。QUIC(2021)はトランスポート層に新しく加わった、UDP 上に構築される現代的プロトコルです(発展編で詳しく扱います)。

Q. 「IEEE 802.11」「IEEE 802.3」「RFC 9293」、それぞれ何を規定する文書か、所属層も含めて答えてください。

本サイトの 標準編シリーズは「トップダウン」で進めます

本サイトの標準レッスンは、Kurose-Ross の名著 Computer Networking: A Top-Down Approach の構成方針を採用し、アプリケーション層から下位層へ順に学んでいきます。すなわち アプリ → トランスポート → ネットワーク → リンク の順です。
POINT アプリ層から始める3つの理由:
1. 身近・観察可能 ─ HTTP・DNS・メールは普段使うアプリそのもの。動機づけが明確。
2. サービス利用者の視点で考えられる ─ 下層は「上位に何を提供するか」で評価される。それを使う側の視点が先にあると、下層の存在意義が腑に落ちる。
3. 学習の段差が緩やか ─ ボトムアップだと電気信号・符号化など抽象度の高い物理層から始まり、ネットワーク全体像が見えるまでが遠い。

標準編シリーズの進行順序

本講の次から、次のような順序で進みます。各回はクリック可能な目次でも示されます。

アプリ層 HTTP HTTP プログラミング DNS メール ファイル転送 トランスポート層 UDP と多重化 TCP(信頼性・フロー・輻輳) ネットワーク層 IP/CIDR/サブネット NAT・DHCP ルーティング(RIP/OSPF/BGP) リンク層 Ethernet/MAC/ARP 無線LAN (VLAN/STP は発展編) 学習の進行方向(上から下へ) ※ はセキュリティ(TLS/PKI/IPsec、FW/IDS/WAF)で、層をまたぐ横断トピックとして最後に扱います

図の見方:アプリ層を起点に、回を進めるごとに「下の層」へ降りていきます。本講はそのスタート地点を確認するハブの役割を果たします。

考えてみよう: 逆向き(リンク層 → アプリ層)で学ぶ「ボトムアップ」流の教科書(例: Tanenbaum)もあります。同じ知識でも順序が違うと得意・不得意が変わります。あなたが最初に「腑に落ちた」のはどちらの順序だったでしょうか。

ネットワーク学習で意識したい「歴史」

インターネットの勉強を進めると、今の感覚では「なぜわざわざこんな設計にしたのか」と感じる仕組み に何度も出会います。HTTP がステートレス(状態を持たない)、ネットワーク内部(ルータ)はパケットを運ぶだけで中身に関与しない、SMTP は素のままだと差出人を簡単に偽れる、SSL/TLS が後付け、IPv4 アドレスが32ビットしかない…これらは個別に見ると不思議ですが、歴史的経緯を踏まえると一気に腑に落ちます。
POINT インターネットの初期(1970〜80年代)は 「とにかく動かす・つながる」 ことが最優先で、現代の感覚で当然と思える セキュリティ・認証・状態管理・なりすまし対策 はほとんど考慮されていませんでした。今ある仕組みの多くは、後から増築・拡張 されたものです。

「なぜこうなっているの?」と感じやすい例

つながる知識: 仕様に違和感を覚えたら、「いつ・誰が・何のために設計したか」 を調べると視界が開けます。多くの場合、当時の前提(性能・規模・想定ユーザ・脅威モデル)に対しては合理的でしたが、後年に状況が変わって不便な側面が露呈した、というパターンです。発展編では QUIC と HTTP/3(発展)など、「歴史的制約に対する後発の解決策」を学んでいきます。

まとめと用語チェック

SUMMARY 1. 階層化の3目的は 関心の分離 / 置換可能性 / 複雑性の管理。
2. インターネット実装は TCP/IP 4層(アプリ・トランスポート・ネットワーク・リンク)、概念整理には OSI 7層。OSI の 5-7 層は TCP/IP のアプリ層に統合されている。
3. 各層は下位のサービスインタフェースを呼び出し、同じ層のピア同士で「論理的な対話」を行う。
4. 送信時はカプセル化(ヘッダ/トレイラの付加)、受信時は非カプセル化。PDU 名は層ごとに メッセージ / セグメント / パケット / フレーム / ビット。
5. リンク層だけはヘッダに加えトレイラ(FCS)を持ち、フレーム全体の CRC で誤り検出する。
6. 本サイト L2 は アプリ層 → 下層へのトップダウン順序で進む。

用語チェック

用語1行説明
関心の分離(separation of concerns)機能を独立した責務に分けて設計する原則
サービスインタフェース下層が上層に提供する機能の公開窓口(層境界)
サービスプリミティブサービス利用の具体的操作。OSI では request/indication/response/confirm の4種で形式化
ピア(peer)送受信双方で同じ層に位置するエンティティ。論理的に直接対話する
PDU(Protocol Data Unit)各層が扱うデータ単位の総称
メッセージ / セグメント / (IP)パケット / フレーム / ビットアプリ / トランスポート / ネットワーク / リンク / 物理 各層の PDU 名
カプセル化 / 非カプセル化ヘッダ等を付加 / 剥がす操作。送信時と受信時で対をなす
ヘッダ / トレイラ制御情報。リンク層は両方持ち、他層はヘッダのみ
FCS(Frame Check Sequence)Ethernet フレーム末尾の CRC-32。ビット誤り検出に使う
EtherTypeEthernet ヘッダ内のフィールドで、上位プロトコル(IPv4/IPv6/ARP 等)を識別
IEEE 802.3 / 802.11有線 Ethernet / 無線 LAN のリンク層規格
RFC(Request for Comments)IETF が発行するインターネット標準・情報文書
ベストエフォート「最善は尽くすが保証しない」配送モデル(IP の特徴)
トップダウン教育アプリ層から下位層へ降りていく学習順序。Kurose-Ross 流
NEXT: 第12回からアプリケーション層の深掘りに入ります。最初は HTTP の詳細(persistent vs non-persistent、HTTP/2 の多重化、HTTP/3 = QUIC の概要)。本講で構築した「層の地図」を手元に持ったまま読み進めてください。

確認問題

問1. ネットワーク階層化の主目的として、最も適切ではないものを1つ選べ。

次の選択肢から最も不適切なものを選択してください。
A. 関心の分離により、各層を独立して設計・改良できる
B. 階層化することで通信の物理的な伝送速度が向上する
C. ある層の実装を入れ替えても他層に影響を与えにくい(置換可能性)
D. 巨大なシステムを部品の階層に分解して扱うことで、複雑性を管理できる
正解:B
階層化はソフトウェア設計上の利点(関心の分離・置換可能性・複雑性の管理)をもたらしますが、物理的な伝送速度を上げるわけではありません。むしろ層ごとのヘッダがオーバーヘッドとなり、絶対的な効率では「全部入りモノリス」より低下する場合すらあります。それでも階層化が選ばれているのは、設計・運用・保守上の利点が大きく上回るからです。

問2. TCP/IP モデルと OSI 参照モデルの対応関係について、正しい記述を1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. TCP/IP モデルは OSI モデルより層が多い
B. OSI のセッション層は TCP/IP ではトランスポート層に統合されている
C. OSI の上位3層(セッション・プレゼンテーション・アプリケーション)は、TCP/IP ではアプリケーション層に統合されている
D. OSI モデルは現在もインターネットの実装上の標準として使われている
正解:C
TCP/IP は4層、OSI は7層で、TCP/IP の方が層が少ない(A は誤り)。OSI のセッション・プレゼンテーション・アプリケーションの3層は、TCP/IP では 1つのアプリケーション層 にまとめられています(B は誤り、C が正)。インターネットの実装は TCP/IP であり、OSI は概念整理用の参照モデルです(D は誤り)。

問3. 「カプセル化」の動作について、最も正確な記述を1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. データを暗号化して中身を読めなくする処理である
B. パケット全体を圧縮してサイズを小さくする処理である
C. 各層が上位層のヘッダを書き換えて宛先を変更する処理である
D. 各層が上位層 PDU をペイロードとみなし、自身のヘッダ(必要ならトレイラ)を付加する処理である
正解:D
カプセル化は、上位層から渡された PDU を「中身を読まない不透明なバイト列」として扱い、自身のヘッダを付加(リンク層のみトレイラも付加)する処理です。A は暗号化、B は圧縮、C はカプセル化の定義として誤り(各層は自分のヘッダだけを加え、上位層のヘッダには触れません)。

問4. 各層の PDU 名の対応として正しい組み合わせを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. アプリ=メッセージ / トランスポート=セグメント / ネットワーク=パケット / リンク=フレーム
B. アプリ=フレーム / トランスポート=パケット / ネットワーク=セグメント / リンク=メッセージ
C. アプリ=セグメント / トランスポート=メッセージ / ネットワーク=フレーム / リンク=パケット
D. すべての層で「パケット」と呼ぶのが正式である
正解:A
上から「メッセージ → セグメント(TCP)/データグラム(UDP) → パケット → フレーム → ビット」が標準的な呼び分けです。日常会話では D の通り全部「パケット」とまとめて呼ぶことが多いですが、技術文献では層ごとに使い分けます。

問5. 「サービスインタフェース」の概念に関する記述として、最も適切なものを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. 同じ層に属する送信側と受信側が直接通信する仕組みのことである
B. アプリケーションがユーザに提供するグラフィカルな画面のことである
C. 下位層が上位層に提供するサービスの利用窓口で、層境界を成す抽象化境界である
D. 物理層のケーブルとコネクタの形状を規定するものである
正解:C
サービスインタフェースは、隣接する2つの層の境界に位置し、下層が上層に提供できるサービスを規定する「窓口」です。これがあるおかげで、上層は下層の内部実装を知らなくても機能を利用でき、下層は実装を交換できます。A は「ピア・プロトコル」(同層水平の対話)の説明、B はユーザインタフェース、D は物理層の話で、いずれも別の概念です。
← PREV
第10回 情報セキュリティの基本
NEXT →
第12回 HTTP/1.1・HTTP/2