- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択今ここ
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理
- DB保存
第2期はここから始まります。ネットワークの個々の仕組みに入る前に、まず「層に分けて考える」という見方そのものを扱います。この見方は、以降の第15週から第26週まですべての土台になります。
まず結論
通信は「宛先を書いた紙を、宛先を書いた封筒に入れ、それをまた別の宛先を書いた袋に入れる」という入れ子の構造を持っています。層とは、この入れ子の一段一段のことです。
ただし、層は完全に独立した部品ではありません。「層に分ければ中身を自由に差し替えられる」という説明は言い過ぎで、規格そのものに層をまたぐ結びつきが組み込まれています。
「層に分かれているので、上の層は下の層が何であるかを一切知らなくてよい」——TCP/IPの規格について、この説明は正しいでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
層とは、入れ子の一段のこと
第2期はここから始まります。個々の仕組みに入る前に、「層に分けて考える」という見方そのものを扱います。
ネットワークの説明には必ず「層」が出てきます。いきなり層の名前を覚えようとすると丸暗記になるので、先に構造だけを押さえます。層とは、入れ子の一段一段のことです。
伝えたい中身があるとします。その中身に宛名を付けて包む。包んだものをさらに別の宛名を付けて包む。これを繰り返すと、外側から内側へ向かって何段もの宛名が並んだ荷物ができます。各段の宛名は、その段を担当する人だけが読みます。
なぜこの形になるのでしょうか。配達に関わる人が、それぞれ違う範囲しか知らないからです。 隣の机まで運ぶ人は建物の外のことを知りません。街をまたいで運ぶ人は、最終的に誰の手に渡るかを知りません。それぞれが「自分が知っている範囲の宛名」だけを見て次に渡せば、全体として届きます。
- ・受け取る側は、外側から順に開けていく
- ・途中の配達人は、自分の段の宛名だけを見ればよい
この「包む」操作をカプセル化と呼びます。上の段から受け取ったものを、中身が何であるかを問わずそのまま包み、自分の宛名を付けて下へ渡すだけです。
RFC 1122 が実際に何を書いているか
では実際の規格は、層をどう書いているでしょうか。インターネットの実装が従う基本文書のひとつ、RFC 1122 の §1.1.3 を見ます。
層名 担当する範囲の目安Application アプリケーションどうしのやりとりTransport 端点どうしの会話の面倒を見るInternet 網をまたいで宛先ホストへ届けるLink Layer 目の前の線・隣の機器へ渡す
ここで、この教材の主題に直結する注意が2つあります。
1つ目。RFC 1122 は「4層である」とは書いていません。 導入文は「インターネットアーキテクチャで使われるプロトコル層は次のとおり」と述べているだけで、結果として4つ挙がります。列挙されているのは事実なので「4層モデル」と呼ぶこと自体は通じますが、「RFC 1122 が4層と定義した」と書くと、原文が言っていないことを出典に帰属させることになります。
2つ目。最下層の名は Link Layer です。 「ネットワークインタフェース層」という呼び名は教科書に広く見られますが、RFC 1122 の語ではありません。どの呼び名を使うかは自由でも、RFCを出典として示すなら、RFCの語を使う必要があります。
入れ子の構造において、途中の配達人(ルータ)は、いちばん内側の中身を読む必要がありますか。
OSIの7層と、RFCの層は、何が違うのか
層の話をすると必ず「OSIの7層」が出てきます。ここが混乱の多い場所なので、はっきりさせておきます。
2つは目的が違う文書です。 OSI参照モデル(ISO/IEC 7498-1)は、標準化の議論を整理するための参照モデルとして作られました。一方 RFC 1122 が列挙する層は、実際に実装され動いているプロトコルスイートの記述です。設計図と、建った建物の説明書ほどの違いがあります。
そしてもう一点。実務では「L7ロードバランサ」「L4で分散する」のようにOSIの層番号を略語として使います。会話としては広く通じるので、使うこと自体は構いません。ただしこれらはベンダが広めた慣用表現で、RFCやIANAレジストリに定義がある用語ではありません。 「L7はOSIの第7層だからRFCで定義されている」という連想は成り立たない、と知っておくだけで十分です。
郵便 — 封筒の入れ子
社内の同僚あての手紙を、別の会社の担当者経由で送る場面です。外側の封筒には相手企業の住所、内側の封筒には社内の部署と氏名が書かれています。郵便局は外側の住所しか見ず、内側の封筒を開けません。相手企業の受付は外側を開けて内側の宛名を読み、部署へ回します。
段 宛名として書かれているもの 読む人外側の封筒 相手企業の住所 郵便局内側の封筒 部署名・氏名 相手企業の受付中身 伝えたい文章 本人だけ
関数呼び出しのスタック(第1期)
第1期で見たように、関数を呼ぶとスタックに積まれます。呼び出し元は、呼んだ関数が内部で何をしているかを知りません。呼ばれた関数も、誰に呼ばれたかを知らず、戻り先のアドレスに従って帰るだけです。各段が自分の1段ぶんの約束だけを守っています。
main() ← 一番外側。中の事情を知らないhandleRequest() ← main が何者かを知らないparseHeader() ← さらに内側。呼び出し元を知らない
郵便の封筒の入れ子と、関数呼び出しのスタック。見た目はまったく違うこの2つに共通する構造は何でしょうか。そしてその構造は、何を可能にしているでしょうか。
「途中にいる人(段)は、何を見ていて、何を見ていないか」に注目して比べてください。
「TCP/IPは層に分かれているので、IP層を別のものに差し替えてもTCPは一切変更せずに動く」という説明は妥当ですか。
ここが本題 — 層は完全には独立していない
ここまでの説明で、「層に分かれているのだから、どの層も他の層と無関係に差し替えられる」と受け取ったかもしれません。その理解は行き過ぎです。 そしてこの行き過ぎは、AIの説明にも解説記事にもよく現れます。
TCPとIPの規格そのものに、層をまたぐ結び付きが3つ組み込まれています。
結合 出典TCPのチェックサムがIPの疑似ヘッダ RFC 9293 §3.1(送信元IP・宛先IP)を含むTCPのMSSがIP層のMTU由来の値から決まる RFC 9293 §3.7.1ISN生成関数がローカル/リモートの RFC 9293 §3.4.1IPアドレスを入力に取る
いちばん分かりやすいのが1つ目です。TCPは「自分のデータが壊れていないか」を調べるチェックサムを計算しますが、その計算範囲にIPアドレスが入っています。 上の層の検査に、下の層の値が混ざっているわけです。
これは抽象的な話ではなく、実務に直接跳ね返ります。NATがIPアドレスを書き換えると、TCPのチェックサムを計算し直さなければなりません。 IPだけを書き換えて済むなら再計算は不要なはずですが、TCPの計算範囲にIPアドレスが含まれている以上、辻褄が合わなくなるのです。第20週でNATを扱うとき、この結合がそのまま効いてきます。
次に何を学ぶか
層という枠組みが手に入ったので、第2期の残りは下から順に一段ずつ登っていきます。
- ・前の週で定義していない語は使わない順序になっている
- ・第18週(ルーティング表)だけは先に読める。宛先IPだけを見る段の話
語彙の暗記やヘッダのフィールド一覧は、本コースでは扱いません。既存のTCP/IP系クイズ群に譲ります。本コースが扱うのは一貫して「なぜその仕組みが必要になったのか」だけです。
この章のまとめ
- 層とは入れ子の一段一段。各段は自分の宛名だけを見て次に渡し、中身には踏み込まない。
- この構造は郵便の封筒の入れ子とも、関数呼び出しのスタックとも同型。共通するのは変更の影響を1段の内側に閉じ込めること。
- RFC 1122 §1.1.3 は Application / Transport / Internet / Link Layer を列挙している。ただし「4層である」と数を明言してはいない。最下層の名は Link Layer。
- OSI参照モデルとRFCの層は目的が違う文書。層番号の1対1対応表はRFC 1122 §1.1.3 に書かれておらず、同節がOSIに触れているのは「アプリケーション層がOSIの上位2層の機能を統合している」と「IPがOSIのコネクションレス型ネットワークプロトコルの手本だった」の2文だけ。
- 「L7ロードバランサ」等の層番号による言い方は業界慣用であって、RFC/IANAに定義がある用語ではない。
- 層は完全に独立ではない。 TCPのチェックサムはIPの疑似ヘッダを含み、MSSはMTU由来、ISN生成はIPアドレスを入力に取る。正しくは「影響範囲を局所化する仕組み」。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「RFC 1122 はインターネットの通信を4層と定義している」という説明の、最も正確な評価はどれですか。
用語集(7語)
- 層 (layer)
- 通信の機能を段に分けて、各段が自分の担当する宛名と手続きだけを扱うようにした区分。上の段のデータをそのまま中身として受け取り、自分の宛名を付けて下へ渡す、という入れ子の関係で積み上がる。
- カプセル化 (encapsulation)
- 上の層から受け取ったデータ全体を「中身」として扱い、自分の層のヘッダを付けて包むこと。封筒に入れた手紙を、さらに別の袋に入れる操作にあたる。受け取る側は逆に、外側から順に開けていく。
- RFC 1122 が列挙する層
- 上から Application / Transport / Internet / Link Layer。§1.1.3 が列挙している。ただし同文書は「4層である」と数を明言してはいない。最下層の正式な呼称は Link Layer で、「ネットワークインタフェース層」はRFCの語ではない。
- OSI参照モデル
- ISO/IEC 7498-1 が定める、通信機能を層に分けて整理するための参照モデル。標準化の議論の枠組みとして作られたもので、実装されているプロトコルスイートの記述であるRFC 1122 とは目的が異なる。
- MTU (Maximum Transmission Unit)
- 1つのフレームで運べる「中身」の最大長。Ethernetでは1500オクテットで、これはペイロードの上限であってフレーム全体の長さではない(ヘッダを含みFCSを除くと1514、FCSを足すと1518)。第15週で詳しく扱う。
- MSS (Maximum Segment Size)
- TCPが1セグメントで送れるデータの最大長。下の層のMTUから、IPヘッダとTCPヘッダの分を引いて決まる。一般的なイーサネットでは約1460オクテット。上の層の値が下の層の都合で決まる、層をまたぐ結合の代表例。
- 疑似ヘッダ (pseudo header)
- TCPのチェックサム計算のために組み立てる、送信元IPアドレス・宛先IPアドレスなどを含む仮想的なヘッダ。RFC 9293 §3.1 が規定している。実際に送られるわけではないが、計算には含まれる。層をまたぐ結合の代表例。