同一個觀念，兩張地圖
在前一篇導覽裡，你認識了整個主題中最強大的一個觀念：分層。每一層只解決問題的一小塊、依靠（比較笨的）下一層，並對（比較聰明的）上一層提供乾淨的服務。所謂模型，不過就是把那些層加上名字後排成的一張清單——一套共同的詞彙，好讓兩位工程師能指著同一個位置、說的是同一件事。網路界有兩個著名的模型，而關鍵在於認清：它們其實是兩個不同的委員會，替同一片疆域畫出來的兩張地圖。
第一個是 OSI 模型（開放系統互連），這是 1970 年代末構思出來的一套七層參考模型，立意是要成為一個宏大、不偏袒任何廠商的標準。第二個是 TCP/IP 模型，這是從真正的 ARPANET 長出來、由四層（有時算五層）組成的協定堆疊，並在真實世界裡勝出。誠實的重點是：OSI 模型是一個教學用的參考模型——它乾淨俐落的七層階梯非常適合用來解釋觀念——而你此刻正在使用的真正網際網路，跑的是 TCP/IP 模型。當人們在工作中說「第三層」或「第七層」時，他們借用的是 OSI 的編號，但實際在運行的卻是 TCP/IP 的協定。
OSI 的七層，由上而下
讓我們沿著 OSI 階梯往下走，從你會碰到的應用程式走到你看不見的那條線。第七層，應用層，是你的程式所在之處——網頁用 HTTP、電子郵件用 SMTP。第六層，表現層，處理資料在線路上如何被編碼（想想字元集、壓縮，以及歷史上的加密）。第五層，會議層，管理一段漫長對話的開始、檢查點與結束。第四層，傳輸層，把主機對主機的傳遞變成程式對程式的傳遞，並且（若你選了 TCP）讓它變得可靠。第三層，網路層，讓一個封包跨越多跳、穿過不同網路。第二層，資料連結層，讓一個訊框跨越單一一跳。第一層，實體層，就是化為電壓、光或無線電的真實位元。
由下往上有個小口訣：「Please Do Not Throw Sausage Pizza Away」——Physical（實體）、Data link（資料連結）、Network（網路）、Transport（傳輸）、Session（會議）、Presentation（表現）、Application（應用）。請注意：底下三層（1–3）關心的是把位元送到正確的機器，最上面三層（5–7）關心的是兩個程式彼此說些什麼。第四層，傳輸層，是中間的那個樞紐——傳輸層正是「送到這台電腦」變成「送到這台電腦上的這個程式」的那個位置。
把七層摺成四層
現在把 TCP/IP 模型疊到 OSI 階梯之上，看著它們扣合在一起。TCP/IP 保留四層，並悄悄地把其餘的合併掉。它的應用層把 OSI 的第 5、6、7 層一口吞下——你的程式自己處理會議與編碼，所以 HTTP、DNS 與 SMTP 全都只是住在「最頂端」。它的傳輸層正好就是 OSI 的第四層：這裡是 TCP 與 UDP 的家。它的網際網路層就是 OSI 的第三層，而它只有一位明星協定——網際網路協定，也就是 IP。它的連結層把 OSI 的第一、二層捲在一起：框架化加上實體位元，在區域網路上通常就是乙太網路或 Wi-Fi。
OSI (7 layers) TCP/IP (4 layers) example protocol -------------------- ----------------- ---------------- 7 Application \ 6 Presentation > Application HTTP, DNS, SMTP 5 Session / 4 Transport Transport TCP, UDP 3 Network Internet IP 2 Data link \ Link Ethernet, Wi-Fi 1 Physical /
這個形狀有個著名的別名叫「沙漏」。上半部很寬——應用層協定多到數不清。下半部也很寬——乙太網路、Wi-Fi、光纖、5G、衛星。但腰身很窄：幾乎所有東西都跑在 IP 之上。正是這一層薄薄的東西，讓一個全新的應用能跑在一種全新的無線電之上，而兩者都不必知道對方存在，因為它們都只需要對中間的 IP 說話。那張表裡的每一個方框，都由一個 通訊協定來描述——對訊息格式、訊息順序、以及該採取的動作所達成的精確約定——而其中公開的那些，會被寫成任何人都能讀的編號標準。
封裝：一次點擊背後一層層相套的信封
分層是觀念；封裝則是讓它運作起來的機制。當你的資料沿著堆疊往下走時，每一層都把從上面收到的東西裝進自己的信封——它加上一個標頭（有時還有一個尾標），並把裡面的一切當成不可窺探的不透明酬載。經典的比喻是：分層就是一層層相套的信封。你的信放進一個信封，那個信封又放進一個更大的信封，而讀著最外層地址的郵差，永遠不會打開裡面那幾層。
- 在應用層，你的瀏覽器產生一個 HTTP 請求，像是「GET /index.html」——只是一段文字，是它想送出的訊息。
- 傳輸層把它包進一個 TCP 區段，在前面加上一個標頭，內含來源與目的的連接埠號以及一個序號；現在這份資料有了程式對程式的定址。
- 網際網路層把那個區段包進一個 IP 封包，加上來源與目的 IP 位址，好讓它能被路由穿過許多網路。
- 連結層把那個 IP 封包包進一個訊框（比方說一個乙太網路訊框），帶上這一跳的 MAC 位址，接著實體層把這些位元化為訊號送上線路或送進空氣中。
- 在接收端，整個過程反向進行：每一層讀取並剝掉自己的標頭、把酬載往上交，最後瀏覽器看見的就是原本的「GET /index.html」——一個一個地拆開信封。
有兩個誠實的但書，能讓這一切不致淪為童話。第一，這些層並非完美密封：NAT 裝置會改寫 IP 與連接埠標頭，而防火牆也樂於檢視第四層的標頭，所以「永不窺探內部」這條規則，是一個帶有真實世界例外的乾淨理想。第二，封裝是要花位元組的——每個標頭都是額外負擔，這正是為什麼極小的訊息可能很沒效率，也是為什麼傳輸層會操心它究竟能塞進多少真正的酬載，也就是我們在本層稍早遇過的「有效傳輸量對上吞吐量」的權衡。
你真正該隨身帶著的，是哪一個模型？
兩個都帶著，用在不同的工作上。當你要講解、教學或採購設備時，伸手去拿 OSI 的七層與它的編號——「這是第三層的問題」、「那是一台第七層負載平衡器」。當你真正動手打造、除錯或追蹤某樣東西時，伸手去拿 TCP/IP 的四層堆疊，因為那四個方框就是線路上的協定。這兩者並非對手；OSI 是你用來量測的那把尺，TCP/IP 則是你所量測的對象。一個很棒的早期習慣是：每當有什麼壞掉，就問「是哪一層？」根本連 IP 都連不到？懷疑第 1 到 3 層。連上了但程式行為不對勁？去看第四層以上。
在你往上爬之前，有兩個值得戳破的迷思。第一，別假設模型暗示了任何關於安全的事：TCP 給你一條可靠的位元組串流，但它本身並不安全、也不加密任何東西——隱私是另外一層、是疊在上頭的 TLS。第二，UDP 不是壞掉的或次等的 TCP；它是一個刻意的選擇，用拋棄可靠性來換取速度，而這正是一通即時語音通話或一場遊戲所想要的。模型告訴你的是每個協定坐在哪裡，而不是它對你的工作而言是否正確——那種判斷，正是這整座階梯接下來要教你的。