單元 02 分層、封裝與效能
學習目標
本章以單元 01 的端點與路徑為基礎。讀完後，你應能說明分層介面的用途，區分傳送、傳播、處理及排隊延遲，計算多跳 store-and-forward 路徑的理想延遲，並用頻寬延遲乘積分析視窗限制。
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 四種延遲
| 類型 | 模型 | 直覺與限制 |
|---|---|---|
| 傳送延遲 | L / R | 把 L bits 推上速率 R bit/s 的鏈路需要時間 |
| 傳播延遲 | d / v | 訊號沿距離 d 以速率 v 傳播 |
| 處理延遲 | 依裝置與工作而定 | 檢查、轉送、排程或協定處理 |
| 排隊延遲 | 依到達、服務與排程而定 | 封包等待可用出口資源 |
頻寬提高可以降低傳送延遲，但不能直接消除遠距離的傳播延遲。排隊延遲會隨時間改變，因此同一路徑的測量不會總是相同。RTT 是往返時間，不保證正反方向的單向延遲各佔一半。
單位換算要先做：1 byte = 8 bits；本教材網路速率用十進位，例如 100 Mb/s = 100,000,000 bit/s。MiB 等二進位容量另行標示，避免把 MB 與 MiB 混用。
2.4 完整例題：封包穿過三段鏈路
一個 1500-byte 封包穿過三段各 100 Mb/s 的鏈路。每段傳播延遲是 2 ms，各中間節點使用 store-and-forward，忽略處理及排隊。問題是第一個 bit 出發到最後一個 bit 到達的總時間。
封包長度 L = 1500 × 8 = 12,000 bits。每段傳送延遲：
L/R = 12,000 / 100,000,000 s = 0.00012 s = 0.12 ms。
三段 store-and-forward 各要等完整封包到齊後才開始下一段傳送，所以總時間：
3 × (0.12 + 2) ms = 6.36 ms。
這是單一封包的理想模型。兩個相同封包連續送出時，第二個只多一個傳送間隔 0.12 ms，理想總時間為 6.48 ms。連續多個封包可以在不同鏈路同時前進，形成流水線；不能把每個封包的單一延遲相加，當作整個檔案傳輸的時間。裝置採 cut-through、鏈路速率不同或有排隊時，也要重新建模。
2.5 瓶頸、流水線與檔案傳輸
若三段鏈路的速率分別為 100、20、100 Mb/s，理想的穩態資料率受到 20 Mb/s 的瓶頸限制。這是忽略協定開銷、競爭、流量控制及壅塞的上界。實際應用吞吐量可能更低。
檔案時間可以粗略估計為「連線及請求的啟動時間 + 內容大小／穩態 goodput」。這個近似在大檔案時較有用；小型資源可能主要花在名稱解析、連線建立、驗證及請求往返。改善吞吐量與改善頁面啟動延遲，可能需要不同方法。
2.6 頻寬延遲乘積與在途資料
若可用速率為 R，往返時間為 RTT，BDP = R × RTT。它描述為了持續利用這個速率，需要維持的在途資料量尺度。其單位取決於 R：若 R 是 bit/s，乘積是 bits。
例：100 Mb/s、RTT 40 ms，BDP = 100,000,000 × 0.04 = 4,000,000 bits = 500,000 bytes。
64 KiB 是本題假設值，不是未縮放 TCP 視窗欄位的 65,535-byte 上限；TCP 視窗縮放見 RFC 7323。假設傳送端最多允許 64 KiB 在途，且沒有其他限制，視窗模型的上界約為：
W / RTT = 65,536 / 0.04 = 1,638,400 byte/s = 13.11 Mb/s。
即使鏈路能傳 100 Mb/s，這個視窗模型仍只允許約 13.11 Mb/s。後續 TCP 章會再區分接收視窗、壅塞視窗、實際 in-flight bytes、RTT 變動及應用供給。本章的公式是分析工具，不是對所有 TCP 連線的精確預測。
2.7 排隊、遺失與 bufferbloat
一個出口的服務速率有限。若短時間到達的封包超過服務能力，緩衝區會累積資料；緩衝區滿時，裝置可能丟棄封包或採用其他管理策略。平均利用率相同，也可以有很不同的尖峰與延遲分布。
增大緩衝區可以吸收短暫尖峰，卻也可能讓封包等待很久。大量上傳時互動程式突然變慢，可能與排隊有關。要測試這個假設，可以比較負載前後的 RTT 分布與排隊行為；僅看下載速率不足以定位原因。
M/M/1 等排隊模型需要特定的到達及服務假設。除非這些假設適用，不應把其公式直接當作真實家庭網路的精確延遲。延伸閱讀可以討論利用率、服務變異及不同排程的影響。
2.8 可重現的量測
報告至少記錄工作負載、資料大小、連線數、觀察層、計時起迄、暖身、重複次數、硬體與版本。同時檢視中位數、尾端分位數與異常值，而不是只交一個平均。
分清楚三種資料：實際量測、依模型計算、人工示例。L02 會提供模型計算與參數對照；L01 的本機時間則是實測，但包含應用與排程等開銷，不能直接當作單向鏈路傳播延遲。
習題
- 1200-byte 封包在 10 Mb/s 鏈路上的傳送延遲是多少？
- 兩段 10 Mb/s 鏈路，各傳播延遲 1 ms；依 store-and-forward 模型求上一題封包的總時間。
- 20 Mb/s、RTT 100 ms 的 BDP 是多少 bytes？
- 為什麼一次 recv 不必對應一個應用訊息？
- 如何分辨大檔案吞吐量瓶頸與小請求啟動延遲問題？
- 一段路徑利用率是 80%，為什麼不能僅憑此數字推算其排隊延遲？
章末檢核與來源
你應能在計算前寫出資料單位、量測位置與模型假設，並說明什麼現象不在模型內。延伸來源：RFC 9293（TCP）、RFC 5681（壅塞控制）、RFC 9000／9002（QUIC 與遺失／壅塞處理）。例題、延遲模型與教學圖為本教材自行設計。