本章談跨資料中心的流量分配，下一章談資料中心內部的負載平衡。
為什麼不能依賴單一強大機器#
即使存在「能處理所有請求的超級電腦」也不可行：光速與光纖的物理上限決定資料傳輸的下限；單點故障必然是災難配方。
「最佳」分配取決於：
- 階層（全球 vs. 區域內）
- 技術層級（硬體 vs. 軟體）
- 流量性質
兩種典型對照：
- 搜尋請求：低延遲是王道 → 送往 RTT 最短的可用資料中心
- 影片上傳：吞吐量是王道 → 走目前較空閒的路徑（即使延遲較高）
在資料中心內部：通常假設所有機器離使用者等距，重點轉為最佳資源利用 + 防止單台機器過載。
DNS 負載平衡#
最簡單的做法：回多個 A / AAAA 紀錄、client 自選。但有諸多限制：
- 對 client 行為控制力極低——隨機選一個
- SRV 紀錄理論上能設權重，但 HTTP 並未採用
- Client 無法判斷哪個位址最近（需要 anycast 或地理映射）
- DNS 中介問題：使用者通常透過 recursive resolver，不直連 authoritative nameserver
DNS 中介帶來的三大影響#
- 遞迴解析的 IP 是 resolver 的，不是 user 的——可用 EDNS0 擴充把 client subnet 帶過去（OpenDNS、Google Public DNS 已支援）
- 回應路徑不確定：一台 ISP nameserver 可能服務跨城市的使用者，最佳路徑不存在
- 快取：低 TTL 也擋不了某些 resolver 不遵守 TTL，更新傳播下限因此被綁住
Google 的做法#
- 持續分析流量，更新「resolver → 估計使用者規模」清單以量化影響
- 估計每個 resolver 背後使用者的地理分布
- 將 authoritative DNS server 與全球流量、容量、基建狀態系統整合
- DNS 回應需控制在 RFC 1035 規定的 512 bytes 內，可放入的位址數有限
DNS 是「在 TCP 連線建立前」最簡單有效的負載平衡層——但不夠。後面還需要 VIP 層。
在虛擬 IP（VIP）做負載平衡#
VIP 不綁在特定 NIC 上，多個裝置共享。對 user 而言它是一個普通 IP；對運維者而言它隱藏了背後有多少機器、便於維護。
關鍵元件是 網路負載平衡器（network load balancer）：收 packet → 轉給後端機器。
該選哪一台後端？#
- 負載最少：直觀但對 stateful 協定行不通——必須記住所有連線
- 以連線 ID 做 hash：
id(packet) mod N- 不需狀態
- 但 N 變化（後端壞了）就會大量重新映射，幾乎所有連線被打斷
一致性雜湊（Consistent Hashing）#
1997 年提出的演算法：後端清單變動時，只少量現有對應被打亂——平常用簡單連線追蹤，壓力下回退到一致性雜湊（如 DDoS 防禦）。
該怎麼把封包轉到後端？#
選項一：NAT——必須維護每個連線的紀錄表，阻擋了「無狀態回退」。
選項二：Direct Server Response（DSR）——修改 L2 destination MAC，上層資訊不變，後端直接回應原始 sender。
- 對「請求小、回應大」（多數 HTTP）極省頻寬
- 但所有機器必須在同一 broadcast domain → Google 規模下早就不可行
選項三（Google 現役）：封包封裝（GRE encapsulation）
- 把原 packet 包進另一個 IP packet（GRE），目的設為後端
- 後端剝去外層，當作直接送達自己 NIC
- LB 與後端不需同 broadcast domain，可跨大陸
代價：
- 封裝增加 24 bytes（IPv4 + GRE）
- 可能超過 MTU 需要分片
- 內網可用較大 MTU 解決，但需網路支援大 PDU
規模化的負載平衡看似簡單（「早一點、常一點」），但細節決定成敗——前端跨資料中心、後端進入資料中心後，都各有挑戰。