網路層次與請求流程 (Network Layers & Request Flow)
三層核心架構
系統設計面試只需掌握三層：
| 層次 | 編號 | 核心協定 | 功能 |
|---|---|---|---|
| 網路層 | L3 | IP | 路由、定址、封包轉送（best-effort） |
| 傳輸層 | L4 | TCP, UDP, QUIC | 端到端通訊、可靠性、流量控制 |
| 應用層 | L7 | HTTP, DNS, WebSocket, WebRTC | 應用程式通訊抽象 |
為什麼只需要三層？
分層架構讓上層可以忽略下層細節。作為應用程式開發者，你只需要關心 L4 和 L7——IP 路由、實體線路電壓等都不在你的責任範圍。
完整 Web 請求流程
當瀏覽器輸入 https://www.example.com：
1. DNS 解析
域名 "example.com" → IP 位址 "32.42.52.62"
2. TCP 三次握手
Client ──SYN──────────────► Server
Client ◄──SYN-ACK─────────── Server
Client ──ACK──────────────► Server
（連線建立完成）
3. HTTP 請求
Client ──GET /page HTTP/1.1─► Server
4. 伺服器處理
Server 查詢資料庫、準備回應
（這是開發者能控制的唯一延遲！）
5. HTTP 回應
Client ◄──200 OK + HTML────── Server
6. TCP 四次揮手
Client ──FIN──────────────► Server
Client ◄──ACK───────────────── Server
Client ◄──FIN───────────────── Server
Client ──ACK──────────────► Server
三個關鍵觀察
- 應用層可以忽略底層：TCP 確保資料正確有序，DNS 負責路由定址，開發者不需要操心
- 一個「請求」背後有大量封包：每一層都增加延遲，越往上層延遲越多
- 連線是雙方狀態：除非使用 HTTP keep-alive 或 HTTP/2 多路複用，每個請求都要重新握手——代價不小
HTTP Keep-Alive vs HTTP/2 多路複用
| 機制 | 解決的問題 | 原理 |
|---|---|---|
| HTTP/1.1 keep-alive | 避免每個請求重複握手 | 同一 TCP 連線發多個請求（但序列化） |
| HTTP/2 多路複用 | 消除線頭阻塞 | 同一 TCP 連線並行多個請求 |
持久連線的設計影響
設計需要持久連線的系統（即時更新、WebSocket）時，必須考慮連線狀態的管理成本。→ 見 01-Networking/05-Realtime-Protocols、01-Networking/06-Load-Balancing
Related Notes
- 01-Networking/02-TCP-vs-UDP — L4 詳細比較
- 01-Networking/03-HTTP-and-HTTPS — L7 HTTP 深入
- 01-Networking/06-Load-Balancing — 多伺服器時的路由策略
- 01-Networking/Practice-Networking