網路基礎練習題 (Practice - Networking)

• L3 網路層：IP — 路由、定址、封包轉送（best-effort）
• L4 傳輸層：TCP, UDP, QUIC — 端到端通訊、可靠性
• L7 應用層：HTTP, DNS, WebSocket, WebRTC — 應用程式通訊抽象

1. DNS 解析：域名 → IP 位址
2. TCP 三次握手：SYN → SYN-ACK → ACK
3. HTTP 請求：客戶端發送 GET 請求
4. 伺服器處理：查詢資料、準備回應（開發者唯一能控制的延遲）
5. HTTP 回應：伺服器回傳內容
6. TCP 四次揮手：FIN → ACK → FIN → ACK

沒有 keep-alive，每個 HTTP 請求都需要重新三次握手，帶來顯著延遲。

• HTTP/1.1 keep-alive：同一 TCP 連線發多個請求（序列化，有線頭阻塞）
• HTTP/2 多路複用：同一 TCP 連線並行多個請求，消除線頭阻塞

在設計需要持久連線的系統（SSE、WebSocket）時，連線狀態管理成本也需要特別考量。

TCP：面向連線、保證交付、維護順序、流量控制、壅塞控制，標頭 20–60 bytes
UDP：無連線、盡力而為、不保證順序、無流量控制，標頭 8 bytes
TCP 額外開銷大但可靠；UDP 輕量但可能丟包。

• (A) TCP：銀行交易不能丟包，必須可靠交付
• (B) UDP：遊戲要低延遲，偶爾丟一幀位置更新可以接受
• (C) UDP：影片串流可容忍少量丟包（卡頓比延遲更不可接受）
• (D) TCP：檔案下載必須完整無缺，丟包需要重傳

瀏覽器只能透過 WebRTC 使用 UDP，無法直接使用原生 UDP。

支援瀏覽器的設計方案：

• 原生 App 用戶 → 使用真正的 UDP 串流
• 瀏覽器用戶 → 降級到批次 HTTP 串流（如 SSE 或 polling）

冪等：(A) GET、(C) PUT、(D) DELETE
非冪等：(B) POST、(E) PATCH

冪等 = 多次呼叫結果和一次相同。GET 讀取不改狀態；PUT 覆寫結果相同；DELETE 刪了就是刪了。

• 401 Unauthorized：「你是誰？」— 尚未驗證身份，需要提供憑證
• 403 Forbidden：「我知道你是誰，但你沒有權限」— 已驗證但沒有存取此資源的授權

HTTPS 只加密傳輸通道，不保證請求內容是合法客戶端產生的。

❌ 錯誤：從 request body 讀取 user_id 做資料庫查詢
→ 攻擊者自行構造請求並修改 body 中的 user_id，可讀取任意用戶資料

✅ 正確：永遠從驗證過的 session/token（如 JWT 簽名、Cookie）取得用戶身份

• REST：外部 API 的預設選擇，簡單、靈活、易快取
• GraphQL：前端需靈活查詢且資料結構複雜時（避免 over/under-fetching）
• gRPC：內部微服務間通訊，二進位序列化（Protocol Buffers），吞吐量約 JSON 的 10 倍

策略：內部 gRPC + 外部 REST

• /updateUser?id=5 → PUT /users/5 或 PATCH /users/5
• /createOrder → POST /orders
• /deleteComment?id=10 → DELETE /comments/10

REST 原則：資源（名詞）+ HTTP 動詞，URL 裡不放動詞。

GraphQL 更合適：

• 首頁需要多種資料類型（用戶、貼文、推薦），REST 需要多個 API 呼叫（under-fetching）
• 各個 client（手機/網頁）需要的欄位不同，GraphQL 讓各自請求精確需要的資料
• 前端團隊可以快速迭代頁面佈局而無需後端配合

但如果是面試中固定需求的題目，先說 REST 再提 GraphQL 作為選項也是好做法。

• (A) SSE：伺服器單向推送出價更新即可，不需要雙向
• (B) WebSocket：遊戲需要高頻雙向通訊（玩家操作 + 伺服器狀態）
• (C) WebRTC：音視訊 P2P 通話，低延遲 UDP
• (D) SSE：股票報價是伺服器推送，客戶端只需接收

WebSocket 的隱藏成本很高：

1. 基礎設施成本：客戶端到伺服器之間的每個元件（防火牆、代理、LB）都必須支援 WebSocket
2. 有狀態連線：規模下需要大量設計配合（Session Affinity、橫向擴展複雜）
3. HTTP Upgrade 後難以降級

正確做法：先考慮 SSE（夠嗎？），只有需要真正雙向高頻通訊時才用 WebSocket。

• L4 LB（傳輸層）：根據 IP/Port 路由，維護持久 TCP 連線，速度快，不理解 HTTP 內容 → 適合 WebSocket
• L7 LB（應用層）：理解 HTTP，可根據 URL/header/cookie 路由，功能強但 CPU 消耗高 → 適合 HTTP 流量（預設）

• LB 類型：L4 LB — WebSocket 需要持久 TCP 連線，L7 LB 會終止並重建連線破壞 WebSocket
• 演算法：Least Connections（最少連線）— WebSocket 是長連線，Round Robin 會讓舊伺服器積累所有連線，新加入的伺服器無法分到已建立的連線

CDN：

• 靜態內容（圖片、影片、JS/CSS）全球分發
• 可快取性高、不需要個人化的資料
• 透過邊緣節點降低全球延遲

區域分片：

• 資料有地理性（使用者的資料只跟同區域用戶相關）
• 典型例子：Uber 叫車（台北用戶不需要紐約的司機資料）
• 讓計算和資料共址，大幅降低查詢延遲

沒有抖動 → 大量客戶端在同一時間同步重試 → thundering herd（驚群效應）：瞬間流量尖峰反而讓已經不健康的服務更不堪負荷。

加入隨機抖動讓重試時間錯開，分散請求，給伺服器恢復的時間。
面試關鍵字：「retry with exponential backoff and jitter」

使用冪等鍵（Idempotency Key）：

POST /payments
headers: { "Idempotency-Key": "user_123_2026-04-20_order_456" }
body: { "amount": 100 }

伺服器：

• 收到請求 → 檢查是否已處理此 key
• 已處理 → 回傳相同結果，不重複扣款
• 未處理 → 處理並記錄 key

Key 組成：user_id + date + operation_type（識別同一「意圖」的重試）

三個狀態：

1. Closed（正常）：監控失敗次數，正常通過
2. Open（跳閘）：失敗超閾值後，立即拒絕所有請求，不嘗試呼叫
3. Half-Open（測試）：逾時後放一個測試請求，成功則復原，失敗則回到 Open

解決的問題：級聯故障（cascading failure）
下游服務崩潰時，持續重試只會讓問題更嚴重（驚群效應）

vs 簡單重試的優勢：

• 快速失敗：立即拒絕，不等逾時（用戶體驗更好）
• 減少下游壓力：不用更多請求壓垮已掙扎的服務
• 自動恢復：無需人工介入
• 防止整個系統崩潰，而不只是保護一個服務