單元 02 分層、封裝與一次連線的依賴

學習目標與問題

本章以單元 01 的角色、識別資訊與下一跳為基礎。讀完後，你應能說明分層介面的用途，計算標頭造成的開銷，把一次網站存取拆成可驗證的步驟並標出各步驟所屬的層，再用證據逐步排錯。本章不需要子網計算；例子會直接說明哪些位址在同一網段。問題是：瀏覽器顯示頁面之前，哪些步驟必須先成功？

2.2 末段的吞吐量與 goodput 定義，會在單元 03 用來分析延遲與視窗。

2.1 分層是把責任和介面說清楚

HTTP 描述應用如何請求及回覆資源；TCP 提供可靠、有序的位元組串流；IP 提供跨網路的封包交付；鏈路層將資料送到相鄰節點。每一層利用下層的服務，並向上層提供介面。分層讓應用不必處理每一種網線的電氣細節，也讓鏈路技術可以替換。

OSI 七層是理解責任的參考模型，Internet 常以應用、傳輸、網路、鏈路等層次討論。模型中的層數不比實際責任重要。TLS、VPN、代理與多重封裝尤其需要畫出完整堆疊，而不能僅用一個層號下結論。

在一個例子中，應用資料成為 TLS 記錄的內容，再由 TCP 傳送；TCP 段放入 IP 封包；IP 封包放入鏈路訊框。資料單位可能被分段、合併或拆成多個記錄，所以一個 HTTP 訊息不等於一個 TCP 段，也不等於一次 Socket 讀取。Socket 是程式使用作業系統通訊服務的介面；recv 讀取目前可交付、且不超過指定上限的 bytes，不保證對齊應用訊息。

2.2 標頭、有效資料與開銷

假設每個 IP 封包有 20 bytes IPv4 標頭和 20 bytes TCP 標頭，沒有 options；其中承載 1000 bytes 應用資料，暫不計 TLS 與鏈路開銷。應用資料在 IP 層的比例為：

1000 / (1000 + 20 + 20) = 0.9615，約 96.15%。

這個比例不是整條網路的實際效率。ACK、重傳、TLS、鏈路標頭及媒介時間都會影響實際佔用。若計入更多層，需要明確指定量測位置，不能把 IP bytes 與實體線速混在同一個分母。

吞吐量描述某個觀察位置每秒傳過多少資料；goodput（有效吞吐量）常用來描述應用得到的有效資料率。報告量測時應寫清楚：計入哪一層、方向、時間區間、有效內容及重傳是否算入。

2.3 一次網站存取的依賴關係

採用下列明確假設：筆電已有 IPv4 位址 192.168.10.23/24；預設閘道及 DNS 轉送器是 192.168.10.1，已知與筆電在同一網段；目標名稱與鄰居位址尚未快取；使用 HTTP/1.1、TCP 與 TLS；沒有應用代理；僅走 IPv4，瀏覽器使用系統解析器，不啟用 DoH／DoT；閘道執行 NAPT。目標的示例位址為 203.0.113.80。

應用層（DNS）：瀏覽器或作業系統需要把名稱解析成可用位址。
鏈路層（ARP）：DNS 查詢要送到 192.168.10.1。因它在同一網段，而筆電還不知道其 MAC，會先需要 ARP 鄰居解析。
網路層（IP 路由）：得到名稱解析結果後，筆電查路由表。遠端位址不在本地 /24，資料交給預設閘道；步驟 2 已取得其 MAC，快取有效時不再做第二次 ARP。若 DNS 位於遠端網段，送 DNS 查詢時的 ARP 對象也通常是本地閘道。
傳輸層（TCP）：TCP 與遠端建立連線。承載 TCP 段的 IP 封包先放進訊框交給閘道；閘道取出封包後，由後續路由器逐跳轉送，每一跳都重新作鏈路封裝。
TLS（HTTP 與 TCP 之間）：TLS 協商與驗證建立受保護的通訊；客戶端驗證伺服器憑證及名稱。
應用層（HTTP）：瀏覽器送出 HTTP 請求，接收狀態、標頭及內容。

這是一個受假設約束的流程，不是所有網站存取的固定時間表。DNS 快取可以略去網路查詢；IPv6 使用不同的鄰居解析；HTTP/3 使用 QUIC 而不是 TCP。ARP 是鏈路送出訊框時的依賴，可能由 DNS 流量先觸發，不能一律排在 DNS 解析之後。

若筆電連網時連位址都沒有，還要先處理鏈路接入與位址設定，可能包含 Wi-Fi 關聯及 DHCP。後續章節會逐項建立這些模型。

2.4 用證據逐步排錯

先描述症狀：是所有名稱失敗、只有一個服務失敗，還是內容讀取很慢？再提出最小假設：例如「名稱解析失敗」，然後選擇能支持或反駁該假設的觀察。

能 ping 一個位址只表示有某種 ICMP 回應，不保證 TCP 服務存在。ping 沒回應也不一定代表主機不可達，因為防火牆或裝置政策可能不回覆。HTTP 狀態碼表示已與某個 HTTP 端點交換訊息，但仍需檢查內容及是否由中間服務回覆。

這門課反覆採用同一個方法：先畫路徑，寫下假設，取得證據，確認證據的範圍，再修正模型。

常見誤解

「連上 Wi-Fi 就能取得網站內容」：接入只是完整流程的一個環節。

實驗與習題

完成 L01。本機實驗會觀察 TCP 端點、HTTP 請求與內容；它不經過家庭閘道、外部 DNS、NAT 或 TLS。

基本：為什麼一次 recv 不必對應一個應用訊息？
基本：沿用 2.2 的 IPv4 與 TCP 標頭假設，但 1000 bytes 應用資料先放進一個 TLS 1.3 記錄，記錄另加 22 bytes（標頭 5、內部 content type 1、tag 16，不計 padding），整個記錄恰好由一個 TCP 段承載；IP 封包放進鏈路訊框時，再加 18 bytes 的訊框標頭與尾端。分別求應用資料佔 IP 封包與佔訊框的比例，並說明兩個分母各在哪個位置觀察。
基本：在 2.3 的示例中，第一個 ARP 可能由哪個應用流程觸發？
分析：HTTP 200、ping 成功、Wi-Fi 已連線，各能支持什麼結論？

章末檢核

不用背流程清單，試著逐項回答：每一層向上提供什麼服務？名稱如何解析？每個步驟依賴哪一層？每種觀察最多能支持什麼結論？

來源

RFC 826（ARP）、RFC 791（IPv4）、RFC 9293（TCP）、RFC 9110／9112（HTTP）、RFC 1034／1035（DNS）、RFC 9846（TLS 1.3）、RFC 5737（文件位址）。規範連結及版本註記見 references/source-notes.md。圖與例題為本教材自行建立的教學模型。