封包交換透過將資料切割為獨立定址的資料單元進行統計多工傳輸，與電路交換相比大幅提高了通訊線路的利用率與容錯能力。 理解現代電腦網路的運作方式，必須先釐清封包在網路線路上的傳遞本質，以及通訊協定為何採用分層抽象。
本文接續全站架構，並作為電腦網路主題的起點；後續可銜接IP 位址、子網路遮罩與 CIDR與TCP 基礎：連線生命週期與流量控制。
電路交換與封包交換
在傳統電話網路中，通訊採用電路交換（Circuit Switching）。 通話雙方在發起通訊前，必須先建立一條端到端的專屬實體或邏輯通話迴路；在通話結束前，這條線路的頻寬完全被預留並獨占。 即使雙方中途沉默不語，其他人都無法使用這條線路的容量；若中間節點或實體線路損壞，整通通話立即中斷。
現代網際網路則建立在封包交換（Packet Switching）基礎上：
- 資料切塊與定址：傳送端將欲傳送的原始訊息切割為多個較小的「封包（Packet）」，每個封包都附帶來源位址與目的位址等控制標頭。
- 統計多工（Statistical Multiplexing）：中間路由器或交換器不會為特定連線預留專用通道，而是讓所有節點的封包共享同一條實體傳輸線路。
- 儲存後轉送（Store-and-Forward）：中繼交換節點完整接收一個封包、驗證資料完整性無訛後，檢查目的地標頭，並根據當前線路排程轉送到下一個節點。
| 比較維度 | 電路交換（Circuit Switching） | 封包交換（Packet Switching） |
|---|---|---|
| 資源配置 | 事先建立專用通道並獨占資源 | 動態共享鏈路頻寬（統計多工） |
| 閒置容量 | 通話沉默時頻寬依然被占用造成浪費 | 無傳輸時立即讓給其他封包使用 |
| 突發流量 | 容量固定，超過直接拒絕連線 | 透過暫存佇列排隊處理突發流量 |
| 單點故障 | 專用線路中斷時整場通話即刻終止 | 封包可動態繞道走替代路徑 |
| 延遲特性 | 建立通道後傳輸延遲極度穩定 | 包含排隊延遲（Queueing Delay）與潛在抖動 |
因為網際網路流量具有強烈的「突發性（Burstiness）」，電腦在發送請求後往往有漫長的閱讀或處理間隔，封包交換以極高的整體資源利用率與彈性，成為電腦網路的根本技術。
為什麼需要分層協定模型
網路通訊涉及極為複雜的軟硬體協作：包括網線電壓與光訊號的調變、網卡間的訊框校驗、跨路由器尋路、端點間的遺失重傳，以及應用程式的格式解析。 如果將所有功能寫在單一龐大的程式中，任何底層硬體的改動（例如從乙太網路換成 Wi-Fi）都會迫使所有應用程式全面重寫。
分層模型（Layered Model）運用電腦科學的核心方法——關注點分離與介面抽象：
- 每一層只專注解決特定的通訊問題。
- 每一層只透過明確定義的介面為上一層提供服務，並使用下一層的能力。
- 各層內部實作可獨立演進：無論底層走光纖、雙絞線還是 5G 行動通訊，IP 層看到的都是統一的網路介面；無論上層是 HTTP 還是 SSH，TCP 層處理的都是位元組串流。
OSI 七層模型與 TCP/IP 四層架構
在網路技術的演進中，有兩個最著名的模型：國際標準化組織（ISO）提出的理論性 OSI 七層模型，以及網際網路工程任務組（IETF）實際落地的 TCP/IP 體系結構（定義於 RFC 1122）。
| OSI 七層模型 | TCP/IP 四層架構 | 主要職責與典型協定／單位 |
|---|---|---|
| 7. 應用層（Application） 6. 表示層（Presentation） 5. 會議層（Session） | 應用層（Application） | 負責應用程式間的高階資料交換與業務語意。 協定：HTTP、DNS、SSH、SMTP 資料單位：訊息（Message） |
| 4. 傳輸層（Transport） | 傳輸層（Transport） | 負責處理兩台主機上「特定行程（Process）」之間的端對端通訊與可靠性機制。 協定：TCP、UDP 資料單位：區段（Segment / Datagram） |
| 3. 網路層（Network） | 網際網路層（Internet） | 負責跨多個異質網路的邏輯定址與路徑尋址（Routing）。 協定：IPv4、IPv6、ICMP 資料單位：封包（Packet / Datagram） |
| 2. 資料鏈結層（Data Link） 1. 實體層（Physical） | 網路介面層（Network Interface / Link） | 負責在同一個區域廣播網域或實體介質相鄰節點間傳遞訊框與位元訊號。 協定：Ethernet（802.3）、Wi-Fi（802.11）、ARP 資料單位：訊框（Frame）與位元（Bits） |
OSI 模型中的表示層（資料編碼、加密）與會議層（會話建立與同步）在實務上大多直接融入應用程式自身（例如由 TLS 程式庫或應用框架處理），因此現代網際網路均以簡潔的 TCP/IP 架構為實作基礎。
封裝與解封裝過程
當一個應用程式（如瀏覽器）發送資料給伺服器時，資料由上至下經過各層協定，經歷封裝（Encapsulation）；抵達接收端主機後，再由下至上經歷解封裝（Decapsulation）：
應用層 (HTTP Request) [ HTTP 負載 ]
↓ 加上 TCP 標頭 (來源/目的連接埠、序號)
傳輸層 (TCP Segment) [ TCP 標頭 | HTTP 負載 ]
↓ 加上 IP 標頭 (來源/目的 IP、TTL)
網路層 (IP Packet) [ IP 標頭 | TCP 標頭 | HTTP 負載 ]
↓ 加上 乙太網路標頭與尾部 (來源/目的 MAC、FCS)
鏈結層 (Ethernet Frame) [ MAC 標頭 | IP 標頭 | TCP 標頭 | HTTP 負載 | FCS 校驗尾 ]
- 封裝（發送端）：每下一層將上一層傳遞來的整份資料視為不可分割的「資料有效負載（Payload）」，並在其前端附加上本層運作所需的「控制標頭（Header）」，鏈結層通常還會在尾端附上訊框檢查碼（FCS）。
- 解封裝（接收端）：接收端網卡收取訊框並檢驗 FCS 無誤後，剝除乙太網路標頭，交給作業系統核心的 IP 模組；IP 模組檢查目的 IP 與校驗和無誤後，剝除 IP 標頭交給 TCP 模組；TCP 模組確認序號無缺並重組串流後，剝除 TCP 標頭將純淨的 HTTP 資料推送給目標行程。
MTU 與封包大小邊界
每一條實體傳輸鏈路都有其所能承載的最大訊框負載上限，稱為 MTU（Maximum Transmission Unit，最大傳輸單元）。 在標準乙太網路中，標準 MTU 通常為 1500 位元組（Bytes）。 當 IP 封包的大小超過鏈路 MTU 時，若不啟用分段（Fragmentation），封包將被直接丟棄並回報 ICMP 錯誤。 現代網路強烈傾向使用「路徑 MTU 探索（PMTUD）」並讓傳輸層（如 TCP MSS 調校）在來源端直接限制區段大小，避免 IP 層分段帶來嚴重的效能耗損與遺失放大問題。
常見誤解與邊界
- 分層不代表必須在實體硬體中一層一層分開：在現代作業系統中，傳輸層與網路層的邏輯通常皆位於同一份作業系統核心（Kernel Network Stack）中運作，共用同一塊記憶體緩衝區（如 Linux 的
sk_buff），透過指標移動避免反覆複製記憶體。 - 高階協定不一定「凌駕」於低階協定：協定是可以嵌套的（Tunneling）。例如在 VPN（如 IPsec、WireGuard）或 VXLAN 覆蓋網路中，一個完整的 IP 封包可以被封裝在 UDP 負載中，跨越底層網際網路傳輸，抵達終點後再解開封裝還原為原始 IP 封包。
- 路由器只檢查與修改網路層及鏈結層：標準的 L3 路由器在轉送封包時，僅讀取並修改鏈結層標頭（MAC 位址變更）與網路層標頭（TTL 減 1、重新計算校驗和），不會也不應擅自改動 TCP 標頭或應用層內容。
相關主題與參考來源
- IP 位址、子網路遮罩與 CIDR：理解網路層如何定義跨主機的邏輯定址空間。
- TCP 基礎：連線生命週期與流量控制：深入傳輸層如何將不可靠的封包轉換為可靠串流。
- Linux 網路基礎：從作業系統指令與介面角度觀察分層運作。
- RFC 1122 - Requirements for Internet Hosts -- Communication Layers：IETF 定義之網際網路主機通訊協定分層規範。