網路、HTTP 與負載平衡

OSI 七層與 TCP/IP 四層模型 基礎

分層的目的是關注點分離：每一層只依賴下一層提供的服務、為上一層提供抽象。面試不太會要你背七層名稱，但會用「L4 vs L7 負載平衡」「這是 L3 問題還是 L7 問題」這類術語，所以要能對應。

封裝（encapsulation）過程：應用資料 → 加 TCP header（src/dst port、seq、ack、flags、window）→ 加 IP header（src/dst IP、TTL、protocol）→ 加 Ethernet header（src/dst MAC）→ 送上線路。每經過一個 router，L2 header 會換掉（下一跳的 MAC），L3 的來源/目的 IP 不變（除非經過 NAT）。

從輸入 URL 到頁面出現：完整流程 高頻

經典開放題，可以講 5 分鐘，也可以講 30 分鐘。好的回答是先給完整骨架，再依面試官興趣往某一段深入。

1. URL 解析：判斷 scheme、host、port、path；若輸入的不是 URL 就丟給搜尋引擎。檢查 HSTS 清單，若該網域要求 HTTPS，直接改用 https（避免第一次明文請求被劫持）。
2. DNS 解析：依序查瀏覽器快取 → OS 快取（/etc/hosts、systemd-resolved / nscd）→ 設定的 recursive resolver（ISP 或 8.8.8.8、1.1.1.1）。Client 對 resolver 是遞迴查詢（「請給我最終答案」）；resolver 對 root → TLD（.com）→ 權威 DNS 是迭代查詢（每一層回答「去問下一個」）。各層結果依 TTL 快取。
3. 建立 TCP 連線：三次交握，花 1 RTT。若有可重用的 keep-alive 連線則跳過。
4. TLS 交握：TLS 1.3 為 1 RTT（恢復連線可 0-RTT），TLS 1.2 為 2 RTT。協商加密套件、驗證憑證鏈、建立 session key。HTTP/2 透過 TLS 的 ALPN 擴充協商；HTTP/3 則跑在 QUIC 上，傳輸與加密交握合併。
5. 送出 HTTP 請求：method、path、headers（Host、Cookie、Accept-Encoding、User-Agent…）。
6. CDN / LB / 應用：請求先到最近的 CDN edge；未命中則回源（origin）。在 origin 端經過 L4/L7 LB → reverse proxy（Nginx）→ 應用伺服器 → 快取 / 資料庫，產生回應。
7. 回應：status code、headers（Content-Type、Cache-Control、Set-Cookie、Content-Encoding）、body（可能 gzip/br 壓縮、chunked 傳輸）。
8. 瀏覽器渲染：解析 HTML 建 DOM、CSS 建 CSSOM、合成 render tree、layout、paint、composite；遇到 <script>（非 async/defer）會阻塞解析；子資源（CSS、JS、圖片）重複上述網路流程，但可共用連線（HTTP/2 多工）。

TCP 連線管理：三次交握、四次揮手與狀態機 高頻

這是 Appier 面試實際被問過的題目。不要只畫出 SYN / SYN-ACK / ACK，要能回答「為什麼是三次」「TIME_WAIT 為什麼存在」「線上大量 CLOSE_WAIT 怎麼查」等追問。

先認識 TCP header 的關鍵欄位

Sequence number（seq）

這個 segment 第一個 byte 的序號。TCP 以 byte 為單位編號，初始序號（ISN）是隨機產生的（防止預測與舊連線混淆）。

Acknowledgment number（ack）

「我期待收到的下一個 byte 序號」，代表之前的都收到了（累積確認）。

Flags

SYN（建立連線、同步序號）、ACK、FIN（我沒有資料要送了）、RST（強制重置）、PSH、URG，以及 ECN 相關的 ECE/CWR。

Window size

接收方還能收多少 bytes（流量控制），搭配 window scale 選項可超過 64KB。

Options

MSS、Window Scale、SACK permitted、Timestamps 等，大多在 SYN 時協商。

三次交握（Three-way Handshake）

1. Client 送 SYN，帶自己的初始序號 x，以及 MSS、window scale、SACK、timestamp 等選項。
2. Server 回 SYN+ACK：確認收到 x（ack=x+1，SYN 本身佔一個序號），並帶自己的初始序號 y。
3. Client 回 ACK（ack=y+1）。此時雙方都進入 ESTABLISHED。

Server 端在 kernel 中有兩個佇列：收到 SYN 後放入 SYN queue（半連線），收到第三個 ACK 後移入 accept queue（全連線），應用呼叫 accept() 才從中取出。注意：交握是 kernel 完成的，應用程式不參與，accept() 只是拿走已完成的連線。

為什麼是三次，不是兩次？

1. 雙方都要確認「對方知道我的初始序號」：TCP 是雙向的，每個方向都有自己的序號空間。Client 的 SYN 由 server 的 ACK 確認；server 的 SYN 必須由 client 的第三個 ACK 確認。只有兩次的話，server 無法知道 client 是否收到它的 ISN，也就不確定自己送出的資料能否被正確排序。SYN 與 ACK 合併到同一個 segment，所以「四次」被壓成三次。
2. 防止過期的重複 SYN 建立錯誤連線（RFC 793 給的主要理由）：假設 client 一個舊的 SYN 在網路中滯留很久才到達 server。若兩次交握就建立連線，server 會為這個早已不存在的請求配置資源並等待資料。三次交握時，client 收到 SYN+ACK 發現 ack 號碼不對應自己目前的連線，會回 RST，錯誤連線就不會建立。
3. 確認雙向通道都可用：兩次只能證明 client→server 與 server→client 單向各通一次，但 server 不知道自己的訊息有沒有到達。

反過來說，為什麼不用四次？因為 server 的 ACK 與 SYN 可以合併送出，沒有必要分開。

四次揮手（Four-way Teardown）

為什麼要四次？因為 TCP 是全雙工，兩個方向要分別關閉（half-close）。A 送 FIN 只代表「我不再送資料」，B 可能還有資料要回傳，所以 B 先回 ACK，等自己的應用程式也送完、呼叫 close() 後才送 FIN。若 B 沒有剩餘資料，ACK 與 FIN 可以合併，實際上常看到三個 segment。

TIME_WAIT：為什麼要等 2MSL？

主動關閉的一方在送出最後一個 ACK 後進入 TIME_WAIT，等待 2 × MSL（Maximum Segment Lifetime）。Linux 的 TIME_WAIT 時間固定為 60 秒。兩個理由：

1. 確保最後的 ACK 能被對方收到：若最後一個 ACK 遺失，對方會重送 FIN；此時還在 TIME_WAIT 的一方能再回 ACK。若已經 CLOSED，只能回 RST，對方會看到錯誤。
2. 讓舊連線的延遲封包在網路中消失：避免相同四元組（src IP、src port、dst IP、dst port）的新連線收到上一個連線遲到的資料而錯亂。

大量 TIME_WAIT 或 CLOSE_WAIT 怎麼辦？

# 依狀態統計連線數
ss -tan | awk 'NR>1 {s[$1]++} END {for (k in s) print s[k], k}' | sort -rn
ss -s
# TIME_WAIT 都是連到哪裡？（找出沒用連線池的下游）
ss -tan state time-wait | awk 'NR>1 {print $4}' | sort | uniq -c | sort -rn | head
# CLOSE_WAIT 是哪個 process、對端是誰
ss -tanp state close-wait

TCP 狀態機

SYN Flood 與 SYN Cookies

SYN flood 是經典的 L4 DDoS：攻擊者大量送 SYN（通常偽造來源 IP）卻不完成交握，塞滿 server 的 SYN queue，讓正常使用者連不進來；server 還會為每個半連線重送 SYN+ACK（tcp_synack_retries，預設 5 次）。

SYN cookies（net.ipv4.tcp_syncookies=1，Linux 預設在 SYN queue 滿時啟用）：server 不在 queue 中保存半連線狀態，而是把連線資訊（時間戳、MSS 編碼、四元組的雜湊加上密鑰）編碼進 SYN+ACK 的初始序號 y。合法 client 回 ACK 時帶 ack=y+1，server 驗證這個值就能重建連線，無需事先保存狀態。代價：部分 TCP 選項（如完整的 window scale、SACK）可能無法保留（有 timestamps 時可以部分編碼）。其他防護：加大 tcp_max_syn_backlog、減少 tcp_synack_retries、前置有清洗能力的 LB / CDN / anti-DDoS 服務。

TCP 可靠傳輸、流量控制、擁塞控制與 UDP 進階

可靠傳輸的機制

• 序號 + 確認：每個 byte 有序號，接收方以累積 ACK 回報；亂序到達的資料先暫存，交給應用時保證順序。
• 重傳：逾時重傳（RTO，根據量測的 RTT 動態計算，Linux 最小值約 200ms）與快速重傳（收到 3 個重複 ACK）。
• SACK（Selective ACK）：告訴對方「哪些區段我已經收到」，只重傳真正遺失的部分。
• Checksum：偵測資料毀損。

流量控制（Flow Control）：別淹沒接收方

接收方在每個 ACK 中通告 receive window（rwnd），代表自己 buffer 還剩多少空間；傳送方在途（已送未確認）的資料量不得超過 rwnd。這就是滑動視窗（sliding window）：隨著 ACK 到達，視窗左緣右移，可以送出新資料。

• 若應用程式讀取太慢，rwnd 縮到 0（zero window），傳送方停止並定期送 window probe。用 ss -tin 或 tcpdump 看到 win 0，代表瓶頸在接收端應用。
• 原始 header 的 window 欄位只有 16 位元（最多 64KB），透過 window scale 選項可擴大到 1GB，這對高頻寬 × 高延遲（BDP 大）的連線很重要：要跑滿 1Gbps、RTT 100ms 的鏈路，在途資料需要約 12.5MB。

擁塞控制（Congestion Control）：別淹沒網路

流量控制保護「接收方」，擁塞控制保護「中間的網路」。傳送方維護 congestion window（cwnd），實際可送的量 = min(cwnd, rwnd)。傳統（Reno / NewReno）演算法的四個階段：

慢啟動（Slow Start）

新連線的 cwnd 從初始值開始（現代 Linux 為 10 個 MSS，RFC 6928），每收到一個 ACK 增加 1 MSS，效果是每個 RTT 加倍（指數成長），直到達到慢啟動門檻 ssthresh。名字叫「慢」是相對於一開始就全速傳送而言。

擁塞避免（Congestion Avoidance）

超過 ssthresh 後改為每個 RTT 加 1 MSS（線性成長，AIMD 的 Additive Increase）。

快速重傳（Fast Retransmit）

收到 3 個重複 ACK（表示後面的資料有到、只是中間某段遺失），不必等 RTO，立即重傳遺失的 segment。

快速恢復（Fast Recovery）

快速重傳後，把 ssthresh 設為目前 cwnd 的一半，cwnd 也大約減半（Multiplicative Decrease），直接進入擁塞避免，而不是退回慢啟動。只有發生逾時（RTO）這種嚴重情況，才把 cwnd 重設為很小的值並重新慢啟動。

Linux 預設演算法是 CUBIC（cwnd 依距上次丟包的時間以三次函數成長，在高 BDP 網路表現較好）。BBR（Google 提出）走不同路線：不以「丟包」當作擁塞訊號，而是持續估計瓶頸頻寬與最小 RTT，以兩者乘積控制在途資料量與發送速率（pacing），在有隨機丟包的長距離鏈路上吞吐量明顯較好、也較少塞滿中間設備的 buffer（bufferbloat）。

sysctl net.ipv4.tcp_congestion_control            # 目前演算法，通常 cubic
sysctl net.ipv4.tcp_available_congestion_control
# 啟用 BBR（kernel 4.9+；搭配 fq qdisc 做 pacing）
sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
ss -tin dst 10.0.0.5     # 每條連線的 cwnd、rtt、retrans、所用演算法

Nagle 演算法與 TCP_NODELAY

Nagle 演算法：若有已送出但尚未被確認的資料，就把後續的小 segment 累積起來，等 ACK 回來或湊滿一個 MSS 再送，目的是減少大量小封包（例如 telnet 每個按鍵一個封包）的 header 浪費。

問題在於它和接收端的 delayed ACK（接收方延遲一小段時間再送 ACK，以便合併或搭便車，Linux 最短約 40ms）互動時：傳送方在等 ACK 才送下一個小封包，接收方在等更多資料才送 ACK，造成數十毫秒的額外延遲。典型觸發情境是「write header、write body」分兩次寫的請求 / 回應協定。

對延遲敏感的 RPC、資料庫 driver、Redis client、遊戲、RTB 服務幾乎都會設定 TCP_NODELAY 關掉 Nagle（Go 的 net.TCPConn 預設就開啟 NoDelay；Nginx 在 keep-alive 連線上預設 tcp_nodelay on）。更好的做法是應用層自己把一個訊息組好再一次 write（或用 writev）。相反地，TCP_CORK 則是刻意「先塞住、湊滿再送」，適合傳送大檔。

import socket
s = socket.create_connection(("10.0.0.5", 6379))
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

TCP Keepalive vs HTTP Keep-Alive

Head-of-Line Blocking（隊頭阻塞）

HOL blocking 是「排在前面的東西卡住，後面全部跟著等」，在不同層各有一種：

• HTTP/1.1 層：一條連線同時只能處理一個請求-回應（pipelining 理論上可以連送，但回應必須依序返回，前面慢就全部卡住）。瀏覽器只好對同一網域開多條連線（通常 6 條）。
• TCP 層：TCP 保證 byte stream 有序，若一個封包遺失，後面已到達的資料也必須等它重傳後才能交給應用。HTTP/2 雖然在應用層多工，所有 stream 共用一條 TCP 連線，一個封包遺失會讓所有 stream 一起停住；在高丟包網路上 HTTP/2 甚至可能比多條 HTTP/1.1 連線還慢。
• 解法：HTTP/3 用 QUIC，每個 stream 在傳輸層各自保證順序，一個 stream 掉包不影響其他 stream。

UDP 與適用場景

選 UDP 的理由：(1) 延遲比完整性重要（即時語音寧可掉一個封包也不要等重傳）；(2) 請求-回應很小，一個封包就夠，交握成本不划算（DNS）；(3) 想在 user space 自訂傳輸行為（QUIC 把可靠性、擁塞控制做在 user space，可以快速迭代，不必等作業系統 kernel 升級）；(4) 廣播 / 多播。像 StatsD 這類 metrics 送出用 UDP，是「掉一點資料可以接受、但絕不能讓業務請求被監控拖慢」的取捨。

HTTP/1.0 → HTTP/1.1 → HTTP/2 → HTTP/3 高頻

HTTP/1.0 與 HTTP/1.1

• HTTP/1.0：預設每個請求一條新 TCP 連線，回應完就關閉（可用非標準的 Connection: keep-alive 延長）。沒有強制的 Host header，一個 IP 難以服務多個網站。
• HTTP/1.1（1997 起，現行規範為 RFC 9110/9112）：
  • 持久連線（keep-alive）預設開啟，大幅減少交握成本。
  • 強制 Host header，實現 virtual hosting。
  • Pipelining：可不等回應就連續送多個請求，但回應必須依序返回 → 應用層 HOL blocking，加上中間設備相容性差，瀏覽器實務上都沒有啟用。
  • Chunked transfer encoding：Transfer-Encoding: chunked，回應長度未知時（串流、動態產生）可邊產生邊送，每塊帶自己的長度，以長度 0 的區塊結束。
  • 更完整的快取控制（Cache-Control、ETag、If-None-Match）、range request（206 Partial Content，續傳）、100 Continue。

HTTP/1.1 200 OK
Content-Type: application/x-ndjson
Transfer-Encoding: chunked

1a
{"event":"bid","price":1}
1a
{"event":"win","price":1}
0

（上例中 1a 是 16 進位的區塊長度 26 bytes：25 個字元的 JSON 加上換行。）

HTTP/2（2015）

二進位分幀（Binary framing）

訊息被切成 frame（HEADERS、DATA、SETTINGS、WINDOW_UPDATE、RST_STREAM、PING、GOAWAY…），每個 frame 標記所屬的 stream ID，解析更有效率、更不易出錯。

多工（Multiplexing）與 Stream

一條 TCP 連線上可同時有多個雙向 stream（一個請求/回應 = 一個 stream），frame 可交錯傳送，解決 HTTP/1.1 應用層的 HOL blocking，也不再需要開 6 條連線、domain sharding、圖片 sprite 等 hack。併發 stream 數由 SETTINGS_MAX_CONCURRENT_STREAMS 限制。

HPACK header 壓縮

HTTP header 大量重複（Cookie、User-Agent）。HPACK 用靜態表（常見 header 預先編號）+ 動態表（連線期間已出現的 header，之後只送索引）+ Huffman 編碼。不使用 gzip 是為了避免 CRIME 類的壓縮側通道攻擊。

Stream 優先權與流量控制

每個 stream 與整條連線都有自己的 flow control window。原本的優先權樹設計過於複雜，RFC 9113 已將其淡化，改由較簡單的 Extensible Priorities（RFC 9218）取代。

Server Push

伺服器主動推送 client 尚未請求的資源。實務效果不佳（常推送已在快取中的東西），Chrome 已移除支援，改用 103 Early Hints。

GOAWAY

伺服器通知「不再接受新 stream」，搭配 graceful shutdown / 連線輪替。

瀏覽器上 HTTP/2 實務上只在 TLS 上使用（透過 ALPN 協商 h2）；服務對服務的明文 HTTP/2 稱為 h2c，gRPC 就是建立在 HTTP/2 上。

HTTP/3 與 QUIC（2022 標準化）

• QUIC 跑在 UDP 上，在 user space 實作可靠傳輸、擁塞控制與多工。選 UDP 是因為中間設備（防火牆、NAT）只認得 TCP/UDP，新的傳輸協定無法部署；而 TCP 實作在 kernel 與中間設備中，難以演進。
• 解決 TCP 層 HOL blocking：每個 stream 獨立有序，一個封包遺失只影響它所屬的 stream。
• 內建 TLS 1.3：傳輸與加密交握合併，新連線 1 RTT（TCP + TLS 1.3 需要 2 RTT），恢復連線可 0-RTT（第一個封包就帶應用資料；但 0-RTT 資料可能被重放，只適合冪等請求）。
• Connection migration：連線以 Connection ID 識別而非四元組，手機從 Wi-Fi 切到 4G、IP 改變時連線不中斷。
• QPACK：HPACK 的變形，避免 header 壓縮本身又造成 HOL blocking。
• 代價：UDP 在部分企業網路被封鎖（需 fallback 到 HTTP/2）、user space 處理封包的 CPU 成本較高、對 LB 而言需要能依 Connection ID 路由。伺服器透過 Alt-Svc: h3=":443" header 或 DNS HTTPS record 告知 client 支援 HTTP/3。

HTTP 語意：Methods、Status Codes 與 Headers 高頻

Methods：safe 與 idempotent

Safe（安全）

語意上不改變伺服器狀態（唯讀）。GET、HEAD、OPTIONS、TRACE。

Idempotent（冪等）

執行一次與執行多次，對伺服器狀態的效果相同（回應可以不同）。safe 方法都是冪等的，另外 PUT、DELETE 也是。冪等性決定了「網路逾時後可不可以安全重試」—— LB、client library、proxy 的自動重試只應用在冪等請求上。

讓 POST 也能安全重試的做法是 idempotency key：client 產生唯一 key 放在 header（例如 Idempotency-Key），伺服器記錄 key 與結果，重複請求直接回傳先前結果。支付、下單、發送訊息（例如 LINE 推播）都需要。詳見 第 7 章。

Status Codes 重點表

快取相關 headers：Cache-Control 與 ETag

Cache-Control: max-age=3600

回應在 3600 秒內是新鮮的，可直接用快取。s-maxage 只對共享快取（CDN、proxy）生效。

no-cache

可以存，但每次使用前都要向伺服器驗證（revalidate）。常被誤以為是「不快取」。

no-store

完全不可儲存（敏感資料）。

private / public

private 只能存在瀏覽器（含個人化內容），不能被 CDN 快取。

stale-while-revalidate=60

過期後 60 秒內可先回舊資料，同時背景更新，降低尾端延遲。

ETag / If-None-Match

伺服器給資源一個版本指紋；client 下次帶 If-None-Match: "abc"，未變則回 304 Not Modified，省頻寬。Last-Modified / If-Modified-Since 是以時間為準的版本。If-Match 則用於寫入時的樂觀鎖（不符回 412）。

Vary: Accept-Encoding

告訴快取：不同的 Accept-Encoding 要分開存（gzip 與未壓縮版本）。Vary 設太多（如 Vary: Cookie）會讓 CDN 命中率崩潰。

靜態資源最佳實務：檔名加 hash（app.3f9a1c.js）+ Cache-Control: public, max-age=31536000, immutable；HTML 則用 no-cache 確保拿到新版本的引用。

CORS（跨來源資源共享）

瀏覽器的同源政策（scheme + host + port 相同）預設禁止 JS 讀取跨來源回應。CORS 是伺服器用 header 告訴瀏覽器「哪些來源可以讀」。注意：CORS 是瀏覽器的保護機制，curl 或後端呼叫不受影響，它也不是伺服器端的存取控制。

• 簡單請求（GET/HEAD/POST，且 Content-Type 僅限 text/plain、application/x-www-form-urlencoded、multipart/form-data、無自訂 header）：直接送出，瀏覽器檢查回應的 Access-Control-Allow-Origin。
• Preflight：其他情況（如 Content-Type: application/json、Authorization header、PUT/DELETE），瀏覽器先送 OPTIONS 帶 Access-Control-Request-Method / -Headers，伺服器回應允許後才送真正請求。用 Access-Control-Max-Age 快取 preflight 結果，減少一個 RTT。
• 帶 cookie 的跨來源請求需 Access-Control-Allow-Credentials: true，且此時 Allow-Origin 不能是 *，必須是明確的來源（並加 Vary: Origin）。

OPTIONS /v1/events HTTP/1.1
Origin: https://dashboard.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://dashboard.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: content-type, authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 600
Vary: Origin

Cookies 與 SameSite

Set-Cookie: sid=abc123; Path=/; Domain=example.com; Max-Age=86400; Secure; HttpOnly; SameSite=Lax

Secure

只透過 HTTPS 傳送。

HttpOnly

JS（document.cookie）讀不到，降低 XSS 偷 session 的風險。

SameSite=Strict

任何跨站請求都不帶 cookie（從外部連結點進來也不帶，體驗較差）。

SameSite=Lax

跨站的「頂層導覽 GET」（點連結）會帶，跨站的 POST、iframe、fetch 不帶。主流瀏覽器在未指定時預設以 Lax 處理，是防 CSRF 的第一道防線。

SameSite=None

跨站也帶，必須同時設 Secure。第三方情境（嵌入式 widget、廣告追蹤）需要。

HTTPS 與 TLS、即時通訊協定 進階

TLS 提供什麼

• 機密性：對稱加密（AES-GCM、ChaCha20-Poly1305）保護資料。
• 完整性：AEAD 演算法同時提供驗證，資料被竄改會被發現。
• 身分驗證：透過憑證確認「我連到的真的是 example.com」，防止中間人攻擊（MITM）。

核心思路：用非對稱密碼學（ECDHE 金鑰交換 + RSA/ECDSA 簽章）在不安全的通道上安全地協商出一把對稱的 session key，之後的資料都用對稱加密（快很多）。

TLS 1.2 與 TLS 1.3 的交握

前向保密（Forward Secrecy）：每次連線用臨時的 DH 金鑰產生 session key，即使伺服器私鑰日後外洩，過去錄下來的流量也無法解密。RSA 金鑰交換是用伺服器公鑰直接加密 pre-master secret，私鑰一旦外洩所有歷史流量都能解開，因此 TLS 1.3 移除了它。

憑證鏈（Certificate Chain）

1. 伺服器送出 leaf 憑證 + 中繼憑證（伺服器必須送完整的中繼鏈；只送 leaf 是常見設定錯誤，部分 client 會驗證失敗）。
2. Client 逐層驗證簽章，直到找到自己信任庫中的 root CA。
3. 檢查有效期限、網域是否符合（Subject Alternative Name，含 wildcard *.example.com）、是否被撤銷（OCSP / CRL；OCSP stapling 讓伺服器代為附上撤銷狀態）。
4. 驗證伺服器擁有對應私鑰（TLS 1.3 中透過 CertificateVerify 簽章）。

SNI（Server Name Indication）：ClientHello 中帶上要連的網域名稱，讓同一個 IP 上的伺服器 / LB 選擇正確的憑證。SNI 在 ClientHello 中是明文（ECH 正在推動加密它）。

# 檢查憑證鏈、有效期限、協商的協定版本
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null
echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
curl -sv --tlsv1.3 https://api.example.com -o /dev/null 2>&1 | grep -E 'SSL connection|ALPN|expire'

mTLS（雙向 TLS）

一般 TLS 只有 client 驗證 server；mTLS 中 server 也要求 client 出示憑證（CertificateRequest），雙方互相驗證。用途：

• 服務對服務的零信任通訊：Service mesh（Istio、Linkerd）由 sidecar 自動發放短效憑證並做 mTLS，應用程式不用改。
• B2B API：合作夥伴以 client 憑證認證（某些 ad exchange、金融 API 會要求）。
• 挑戰：憑證發放、輪替、撤銷的管理成本；短效憑證 + 自動化（cert-manager、SPIFFE/SPIRE）是主流做法。

server {
    listen 443 ssl;
    http2 on;                       # Nginx 1.25.1+ 寫法；舊版為 listen 443 ssl http2;
    server_name api.example.com;
    ssl_certificate     /etc/nginx/tls/fullchain.pem;   # leaf + intermediate
    ssl_certificate_key /etc/nginx/tls/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache shared:SSL:50m;    # session 恢復，降低重複交握成本
    ssl_session_timeout 1h;

    # mTLS：要求並驗證 client 憑證
    ssl_client_certificate /etc/nginx/tls/partner-ca.pem;
    ssl_verify_client on;
    location / {
        proxy_set_header X-Client-DN $ssl_client_s_dn;
        proxy_pass http://app;
    }
}

延伸：即時通訊 WebSocket、SSE 與 Long Polling

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# FastAPI 的 SSE：每秒推送一次即時競價統計
import asyncio, json
from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()

async def stats_stream():
    i = 0
    while True:
        i += 1
        payload = json.dumps({"seq": i, "qps": 12000 + i})
        yield f"id: {i}\nevent: stats\ndata: {payload}\n\n"   # SSE 格式：空行分隔事件
        await asyncio.sleep(1)

@app.get("/stats/stream")
async def stream():
    return StreamingResponse(stats_stream(), media_type="text/event-stream",
                             headers={"Cache-Control": "no-cache", "X-Accel-Buffering": "no"})

DNS 細節與 CDN 原理 進階

常見 DNS record types

DNS 主要走 UDP 53；回應過大（超過 EDNS0 協商的大小時會被截斷，設定 TC 位元）或 zone transfer 時改用 TCP。隱私需求可用 DoH（DNS over HTTPS）/ DoT（DNS over TLS）。

TTL 的取捨

• TTL 短（30～60 秒）：切換快（故障轉移、藍綠部署），但查詢量大、解析延遲出現頻率高。
• TTL 長（數小時）：快取命中高、對 DNS 服務依賴低，但改 IP 時要等很久才全面生效。
• 實務：計畫遷移前先把 TTL 調短、等舊 TTL 過期，再切換，之後調回。
• 陷阱：有些 client 不遵守 TTL（舊版 JVM 預設在有 security manager 時永久快取、某些 HTTP client 連線池長期持有舊 IP 的連線）。後端 IP 改變後，長連線並不會因 DNS 改變而自動斷開，需要連線有最大存活時間。
• 負向快取：NXDOMAIN 也會依 SOA 的設定被快取，網域剛建好前就被查過的話可能要等一段時間。

DNS-based Load Balancing 與 GeoDNS

DNS round robin

同一網域回傳多個 A 記錄，client 通常取第一個（順序輪替）。簡單但沒有健康檢查，且受快取影響，分配不均、故障節點無法即時摘除。

GeoDNS / Latency-based routing

權威 DNS 依查詢來源（resolver 的 IP，或 EDNS Client Subnet 帶來的 client 子網段）回傳最近 / 延遲最低區域的 IP。例如 Route 53 的 geolocation / latency routing。

Health-checked failover

DNS 服務自己做健康檢查，故障區域的記錄自動撤下（仍受 TTL 影響）。

Anycast

同一個 IP 由多個地點透過 BGP 宣告，網路自然把封包送到「路由上最近」的節點。DNS 根伺服器、1.1.1.1、各大 CDN 都用 anycast。與 GeoDNS 不同，它在網路層運作，切換不受 DNS TTL 影響。

CDN 原理

1. 導流：透過 CNAME 到 CDN 網域 + GeoDNS，或 anycast IP，把使用者導到最近的 PoP（Point of Presence）。
2. 快取：依 Cache-Control / s-maxage、cache key（預設 host + path + query，可自訂忽略某些 query 參數或加入 header）決定是否命中。
3. 回源：未命中時向 origin 取得；多層架構（origin shield）讓同一物件只有一個節點回源，避免 origin 被大量 miss 打爆（也可合併同時的相同請求，request collapsing）。
4. 失效：等 TTL 過期，或主動 purge / invalidate；最可靠的是檔名帶版本 hash，不需 purge。
5. 額外功能：TLS 終止（離使用者近，交握 RTT 短）、HTTP/2/3、壓縮、DDoS 吸收、WAF、edge computing（Cloudflare Workers、Lambda@Edge）。

負載平衡：L4 vs L7、演算法、健康檢查與 Draining 高頻 深入

L4 與 L7 負載平衡

大型系統常見的組合是兩層：最前面 anycast / DNS → L4 LB（扛流量、高可用）→ 一群 L7 proxy（Nginx / Envoy，做路由與 TLS）→ 應用服務。L4 LB 的 DSR（Direct Server Return） 模式讓回應直接從後端回 client，不經過 LB，適合回應遠大於請求的流量。

負載平衡演算法

Round Robin / Weighted Round Robin

依序輪流；有權重時依比例分配（Nginx 用 smooth weighted RR，避免連續打同一台）。假設每個請求成本相同、後端效能相同，請求成本差異大時會不平衡。

Least Connections

選目前進行中連線（或請求）數最少的後端，自動適應「慢請求」與「慢機器」。適合請求處理時間差異大的服務。

Random / Power of Two Choices（P2C）

隨機挑兩個後端，選負載較小的那個。理論上已能把最大負載從 O(log n / log log n) 降到 O(log log n)，而且不需要全域精確狀態，避免「所有 LB 同時把流量丟給同一台最閒的機器」的羊群效應（herd behavior）。Envoy、gRPC、Finagle 都採用。

EWMA（Peak EWMA）

對每個後端的回應延遲做指數加權移動平均（常再乘上進行中請求數），選分數最低的。對延遲敏感的服務很有效，能自動避開 GC 中或負載高的節點。Linkerd、Finagle 使用；常與 P2C 結合（P2C + EWMA）。

IP Hash / Hash by key

依 client IP、user ID、URL 雜湊選後端，同一 key 固定到同一台（session 黏著、快取區域性）。但一般的 hash % N 在 N 改變時幾乎所有 key 都會重新分配。

Consistent Hashing

把後端與 key 都雜湊到一個環上，key 順時針找到第一個節點。增減一個節點時只影響約 1/N 的 key。用虛擬節點（每台機器在環上放多個點）改善分佈不均。變形：Ketama（Nginx hash ... consistent）、Maglev hashing（查表快、分佈均勻，Google L4 LB）、Rendezvous（HRW）hashing、有界負載一致性雜湊（consistent hashing with bounded loads，避免熱點 key 打爆單台）。適用：快取叢集、有狀態服務、依 user 分片。

import bisect
import hashlib

class ConsistentHashRing:
    """含虛擬節點的一致性雜湊環。"""

    def __init__(self, nodes: list[str] | None = None, vnodes: int = 160) -> None:
        self.vnodes = vnodes
        self._keys: list[int] = []          # 排序後的環上位置
        self._ring: dict[int, str] = {}     # 位置 -> 實體節點
        for n in nodes or []:
            self.add(n)

    @staticmethod
    def _hash(s: str) -> int:
        return int.from_bytes(hashlib.md5(s.encode()).digest()[:8], "big")

    def add(self, node: str) -> None:
        for i in range(self.vnodes):
            h = self._hash(f"{node}#{i}")
            self._ring[h] = node
            bisect.insort(self._keys, h)

    def remove(self, node: str) -> None:
        for i in range(self.vnodes):
            h = self._hash(f"{node}#{i}")
            del self._ring[h]
            self._keys.remove(h)            # O(n)，節點變動不頻繁時可接受

    def get(self, key: str) -> str:
        if not self._keys:
            raise LookupError("empty ring")
        idx = bisect.bisect_right(self._keys, self._hash(key)) % len(self._keys)
        return self._ring[self._keys[idx]]

ring = ConsistentHashRing(["cache-a", "cache-b", "cache-c"])
before = {f"user:{i}": ring.get(f"user:{i}") for i in range(10_000)}
ring.add("cache-d")
moved = sum(before[k] != ring.get(k) for k in before)
print(f"moved {moved / len(before):.1%}")   # 約 25%（理想值 1/4），而非 hash % N 的約 75%

import random

class P2CBalancer:
    """Power of Two Choices + 延遲 EWMA 的簡化版。"""

    def __init__(self, backends: list[str], alpha: float = 0.3) -> None:
        self.alpha = alpha
        self.ewma = {b: 0.0 for b in backends}       # 平均延遲（ms）
        self.inflight = {b: 0 for b in backends}

    def _score(self, b: str) -> float:
        return (self.ewma[b] or 1.0) * (self.inflight[b] + 1)

    def pick(self) -> str:
        a, b = random.sample(list(self.ewma), 2)
        chosen = a if self._score(a) <= self._score(b) else b
        self.inflight[chosen] += 1
        return chosen

    def done(self, backend: str, latency_ms: float) -> None:
        self.inflight[backend] -= 1
        self.ewma[backend] = self.alpha * latency_ms + (1 - self.alpha) * self.ewma[backend]

健康檢查（Health Check）

• Liveness vs Readiness：liveness 回答「程式是否卡死，需要重啟嗎」，readiness 回答「現在能接流量嗎」（暖機中、依賴的 DB 斷線、正在 draining 時回 not ready）。不要把下游依賴檢查放進 liveness，否則 DB 一抖動全部 Pod 被重啟，引發雪崩。
• 健康檢查端點要便宜且有意義：太淺（只回 200）偵測不到真正問題；太深（每次查 DB）會在高頻探測下自己變成負載。
• Slow start：剛恢復或新加入的節點快取是冷的，逐步提升權重（HAProxy slowstart、Nginx Plus slow_start）。
• 所有後端都被判定不健康時，有些 LB 會進入 fail-open / panic mode（全部照樣送），以免健康檢查本身的錯誤造成全面停擺。

Session Affinity（Sticky Session）

讓同一使用者的請求固定送到同一後端，方式有：LB 插入 cookie（HAProxy cookie SRV insert、ALB stickiness）、依 source IP hash、依應用 cookie / header hash。

• 優點：伺服器本機的 session / 快取可以重用；WebSocket 等有狀態連線需要。
• 缺點：負載不均（熱門使用者黏在同一台）、節點故障時 session 遺失、擴縮容時無法立即平衡；source IP hash 在大量使用者藏在同一個 NAT / proxy 後面時會嚴重偏斜。
• 首選設計是讓服務無狀態，把 session 放到 Redis 等共享存放處，或使用簽章的 token（JWT），黏著只作為快取最佳化。

Connection Draining（連線排空）

下線一台後端（部署、縮容、維護）時：LB 停止送新連線 / 請求給它，但讓進行中的請求在一段時間內完成，時間到才強制關閉。AWS ALB/NLB 稱為 deregistration delay（預設 300 秒），HAProxy 可將 server 設為 drain 狀態，K8s 則透過 Pod 進入 Terminating、從 Endpoints 移除，加上應用自身的 graceful shutdown（見 第 3 章 signal 小節）。對 HTTP keep-alive 連線，後端在 draining 時應回 Connection: close（HTTP/2 送 GOAWAY），讓 client 換到其他後端。

Reverse Proxy、Forward Proxy 與 API Gateway

Nginx 與 HAProxy 實戰設定 高頻

Nginx：反向代理、upstream keepalive、限流、gzip、timeouts

user  nginx;
worker_processes  auto;              # 每個 CPU core 一個 worker
worker_rlimit_nofile 200000;         # 每個 worker 的 fd 上限

events {
    worker_connections  65535;       # 每個 worker 最多連線數（含對上游的連線）
    use epoll;
    multi_accept on;
}

http {
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
                    '$request_time $upstream_response_time $upstream_addr';
    access_log /var/log/nginx/access.log main buffer=64k flush=5s;

    sendfile    on;
    tcp_nopush  on;                  # 搭配 sendfile，填滿封包再送
    tcp_nodelay on;

    # ---- client 端 timeouts ----
    keepalive_timeout        65s;    # client keep-alive 閒置逾時
    keepalive_requests       1000;
    client_header_timeout    10s;    # 防 slowloris：header 要在時限內送完
    client_body_timeout      10s;
    send_timeout             10s;
    client_max_body_size     5m;

    # ---- gzip ----
    gzip            on;
    gzip_comp_level 5;               # 1-9，越高越耗 CPU，5 左右是常見平衡點
    gzip_min_length 1024;            # 太小的回應壓縮不划算
    gzip_types      application/json application/javascript text/css text/plain image/svg+xml;
    gzip_vary       on;              # 加上 Vary: Accept-Encoding
    gzip_proxied    any;

    # ---- 限流：以 client IP 為 key，每秒 50 個請求 ----
    limit_req_zone  $binary_remote_addr zone=per_ip:20m rate=50r/s;
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
    limit_req_status 429;

    # ---- upstream 與連線池 ----
    upstream bidder_backend {
        least_conn;
        server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
        server 10.0.1.12:8080 max_fails=3 fail_timeout=10s;
        server 10.0.1.13:8080 max_fails=3 fail_timeout=10s;
        server 10.0.1.14:8080 backup;           # 其他都掛掉才使用
        keepalive 128;               # 每個 worker 保留的閒置上游連線數
        keepalive_requests 10000;
        keepalive_timeout 60s;       # 需「小於」上游服務的 idle timeout，避免 502
    }

    upstream cache_tier {
        hash $arg_user_id consistent;   # 一致性雜湊：同 user 到同一台，快取命中高
        server 10.0.2.21:8080;
        server 10.0.2.22:8080;
        keepalive 64;
    }

    server {
        listen 80 backlog=65535 reuseport;
        server_name api.example.com;

        location /healthz {
            access_log off;
            return 200 "ok\n";
        }

        location /bid {
            limit_req  zone=per_ip burst=100 nodelay;  # 允許短暫突發 100 個，超過回 429
            limit_conn conn_per_ip 200;

            proxy_pass http://bidder_backend;
            proxy_http_version 1.1;              # 上游 keep-alive 必須用 HTTP/1.1
            proxy_set_header Connection "";     # 清掉 Connection: close，才能重用連線
            proxy_set_header Host              $host;
            proxy_set_header X-Real-IP         $remote_addr;
            proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Request-ID      $request_id;   # 方便追蹤

            # RTB 等低延遲服務：timeout 要短且小於整體延遲預算
            proxy_connect_timeout 50ms;
            proxy_send_timeout    100ms;
            proxy_read_timeout    80ms;

            # 失敗時換下一台；預設不會重試非冪等方法（POST），除非加上 non_idempotent
            proxy_next_upstream error timeout http_502 http_503;
            proxy_next_upstream_tries 2;
            proxy_next_upstream_timeout 90ms;

            proxy_buffering on;
        }

        location /ws/ {
            proxy_pass http://bidder_backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade    $http_upgrade;   # WebSocket
            proxy_set_header Connection "upgrade";
            proxy_read_timeout 1h;
        }
    }
}

limit_req 的語意

以 leaky bucket 實作：rate=50r/s 代表每 20ms 放行一個；burst=100 允許最多 100 個超額請求排隊；加上 nodelay 則 burst 內的請求立即處理而不排隊延遲，但仍佔用 burst 額度。不加 nodelay 時超額請求會被延遲到符合速率，對低延遲服務通常不適合。

$binary_remote_addr

以二進位存放 IP（IPv4 4 bytes），比字串的 $remote_addr 省記憶體。若 Nginx 前面還有 LB，要用 real_ip 模組（set_real_ip_from + real_ip_header X-Forwarded-For）取得真實 client IP，否則所有人都被當成 LB 的 IP 一起限流。

Upstream keepalive 的三件套

keepalive N + proxy_http_version 1.1 + proxy_set_header Connection ""，缺一不可。漏掉的話 Nginx 對上游每個請求都新建 TCP 連線，造成大量 TIME_WAIT 與額外延遲。

nginx -t                       # 檢查設定語法
nginx -s reload                # 平滑重載：master 用新設定起新 worker，舊 worker 處理完現有連線後退出
nginx -T | less                # 印出完整生效設定（含 include）

HAProxy：frontend / backend、健康檢查、stick table

global
    maxconn 200000
    log /dev/log local0
    stats socket /run/haproxy/admin.sock mode 600 level admin   # runtime API
    nbthread 8

defaults
    mode http
    log global
    option httplog
    option http-keep-alive
    option forwardfor                       # 加上 X-Forwarded-For
    timeout connect 1s
    timeout client  30s
    timeout server  5s
    timeout http-request 10s                # 防 slowloris
    timeout http-keep-alive 10s
    retries 2
    option redispatch                       # 重試時允許換到其他 server

frontend fe_https
    bind :443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
    # ---- stick table：以來源 IP 追蹤 10 秒內的請求速率 ----
    stick-table type ip size 1m expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    http-request deny deny_status 429 if { sc_http_req_rate(0) gt 1000 }
    http-request deny deny_status 429 if { sc_conn_cur(0) gt 200 }

    acl is_bid   path_beg /bid
    acl is_admin path_beg /admin
    acl office   src 10.10.0.0/16
    http-request deny if is_admin !office
    http-request set-header X-Request-ID %[uuid()]
    use_backend be_bidder if is_bid
    default_backend be_web

backend be_bidder
    balance leastconn
    option httpchk
    http-check send meth GET uri /healthz
    http-check expect status 200
    default-server inter 2s fall 3 rise 2 slowstart 30s maxconn 2000
    server bid1 10.0.1.11:8080 check
    server bid2 10.0.1.12:8080 check
    server bid3 10.0.1.13:8080 check

backend be_web
    balance roundrobin
    cookie SRV insert indirect nocache      # sticky session：LB 插入 cookie
    server web1 10.0.3.31:8080 check cookie w1
    server web2 10.0.3.32:8080 check cookie w2

listen stats
    bind :8404
    stats enable
    stats uri /stats
    stats refresh 5s

# 透過 runtime API 做 connection draining：不再給新連線，既有連線繼續完成
echo "set server be_bidder/bid1 state drain" | socat stdio /run/haproxy/admin.sock
echo "show servers state be_bidder"          | socat stdio /run/haproxy/admin.sock
echo "show table fe_https"                   | socat stdio /run/haproxy/admin.sock   # 看 stick table 內容
echo "set server be_bidder/bid1 state ready" | socat stdio /run/haproxy/admin.sock
haproxy -c -f /etc/haproxy/haproxy.cfg       # 驗證設定

RTB 低延遲情境：Keep-alive、連線池與 HTTP/2 深入

Real-time bidding 中，ad exchange 對 DSP 發出 bid request，DSP 必須在約 100ms（含網路往返）內回應出價，否則視同放棄。扣掉跨區網路的 RTT，留給 bidder 內部的時間常只有數十毫秒，其中還要查使用者特徵、跑模型、計算出價。此時「建立連線」本身就可能吃掉大半預算。

延遲預算的帳

若 exchange 與 bidder 之間 RTT 為 20ms，新建 TLS 1.2 連線光交握就要約 60ms（TCP 1 RTT + TLS 2 RTT），已用掉一大半的 100ms 預算。所以：

1. 對外（exchange → bidder）：支援並鼓勵 HTTP keep-alive / HTTP/2，keep-alive timeout 與 max requests 設寬鬆，避免頻繁重建；在靠近 exchange 的區域部署 bidder（降低 RTT）。
2. 對內（bidder → 下游）：所有下游都用連線池（Redis、DB、HTTP client），池大小依「QPS × 平均下游延遲」（Little's Law）估算並設上限；預先暖機建立連線，避免冷啟動時大量同時建連。
3. HTTP/2 / gRPC 多工：少量連線即可承載大量併發請求，降低 fd 與交握成本；但注意 L4 LB 無法分散單一連線的請求，需要 client-side LB 或 L7 proxy。
4. 嚴格 timeout 與 deadline 傳遞：每個下游呼叫的 timeout 必須小於剩餘預算，逾時就用預設值或放棄出價（no-bid 回 204），而不是讓整個請求超時。避免在時間已用完時還重試。
5. TCP 層：TCP_NODELAY、適當的 backlog 與 somaxconn、監控 ListenOverflows 與重傳。
6. 非同步旁路：bid log、metrics 用非同步 / 批次送出，不放在請求的關鍵路徑上。

# Python：共用 httpx.AsyncClient 連線池，並設定總逾時預算
import asyncio
import httpx

limits = httpx.Limits(max_connections=200, max_keepalive_connections=100, keepalive_expiry=60)
timeout = httpx.Timeout(0.03, connect=0.01)        # 讀取 30ms、建立連線 10ms
client = httpx.AsyncClient(limits=limits, timeout=timeout, http2=True)   # http2 需安裝 httpx[http2]

async def score(features: dict) -> float | None:
    try:
        r = await client.post("https://model.internal/score", json=features)
        r.raise_for_status()
        return r.json()["ctr"]
    except (httpx.TimeoutException, httpx.HTTPError):
        return None                                  # 降級：不出價或使用預設值

async def handle_bid(req: dict) -> dict | None:
    try:
        async with asyncio.timeout(0.06):            # Python 3.11+：整體 60ms 預算
            ctr = await score(req["features"])
    except TimeoutError:
        return None
    if ctr is None:
        return None
    return {"price": round(ctr * 1000 * 0.8, 4)}
# 錯誤示範：在每個請求裡 `async with httpx.AsyncClient() as c:`
# —— 每次都建立新連線池 = 每次都重新做 TCP + TLS 交握

// Go：自訂 Transport，預設 MaxIdleConnsPerHost 只有 2，高併發打同一個 host 時會大量建新連線
var client = &http.Client{
    Timeout: 50 * time.Millisecond,
    Transport: &http.Transport{
        MaxIdleConns:        1000,
        MaxIdleConnsPerHost: 200,
        IdleConnTimeout:     90 * time.Second,
        DialContext: (&net.Dialer{
            Timeout:   20 * time.Millisecond,
            KeepAlive: 30 * time.Second,
        }).DialContext,
        ForceAttemptHTTP2: true,
    },
}
// 使用後務必讀完並關閉 body，連線才能回到池中重用：
// defer resp.Body.Close(); io.Copy(io.Discard, resp.Body)

Socket 程式設計 進階

理解 socket API 能把前面所有概念串起來：listen() 的 backlog 就是 accept queue、connect() 觸發三次交握、close() 送出 FIN、ephemeral port 在 connect() 時分配。

一個多執行緒的 TCP server（含訊息分幀）

TCP 是 byte stream，沒有訊息邊界：一次 send(100 bytes) 對方可能分兩次 recv 才收齊，兩次 send 也可能在一次 recv 中一起到（俗稱「黏包」）。所以應用層協定一定要定義分幀方式：固定長度前綴（length-prefixed）、分隔符號（例如 HTTP header 以 \r\n\r\n 結束、Redis RESP 以 \r\n）、或固定長度訊息。

import socket
import struct
import threading
from concurrent.futures import ThreadPoolExecutor

HEADER = struct.Struct("!I")        # 4 bytes 網路位元組序（big-endian）的長度前綴
MAX_MSG = 1 << 20                   # 1MB 上限，避免惡意長度造成記憶體爆炸

def recv_exact(conn: socket.socket, n: int) -> bytes:
    """recv 可能只回傳一部分，必須迴圈直到收滿 n bytes。"""
    buf = bytearray()
    while len(buf) < n:
        chunk = conn.recv(n - len(buf))
        if not chunk:
            raise ConnectionError("peer closed")
        buf += chunk
    return bytes(buf)

def recv_msg(conn: socket.socket) -> bytes:
    (length,) = HEADER.unpack(recv_exact(conn, HEADER.size))
    if length > MAX_MSG:
        raise ValueError("message too large")
    return recv_exact(conn, length)

def send_msg(conn: socket.socket, payload: bytes) -> None:
    conn.sendall(HEADER.pack(len(payload)) + payload)   # sendall 會處理部分寫入

def handle(conn: socket.socket, addr) -> None:
    conn.settimeout(30)                                 # 閒置連線 30 秒後關閉
    with conn:
        try:
            while True:
                msg = recv_msg(conn)
                send_msg(conn, msg.upper())
        except (ConnectionError, socket.timeout, ValueError):
            pass                                        # 對端關閉 / 逾時 / 格式錯誤

def serve(host: str = "0.0.0.0", port: int = 9000) -> None:
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as srv:
        # 允許重啟時立即重新 bind（即使舊連線還在 TIME_WAIT）
        srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        srv.bind((host, port))
        srv.listen(1024)        # backlog：accept queue 長度，實際上限為 min(1024, somaxconn)
        # 用 thread pool 限制併發，避免「一連線一 thread」無上限地建立 thread
        with ThreadPoolExecutor(max_workers=256) as pool:
            while True:         # accept loop
                conn, addr = srv.accept()
                conn.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
                pool.submit(handle, conn, addr)

if __name__ == "__main__":
    threading.Thread(target=serve, daemon=True).start()
    import time; time.sleep(0.2)
    with socket.create_connection(("127.0.0.1", 9000), timeout=2) as c:
        send_msg(c, b"hello appier")
        print(recv_msg(c))      # b'HELLO APPIER'

重要的 socket 選項與細節

backlog

listen() 的參數，accept queue 長度上限，實際值受 net.core.somaxconn 截斷。accept 太慢導致佇列滿時，新連線的 ACK 會被丟棄（或回 RST，依 tcp_abort_on_overflow），client 端表現為連線延遲或失敗。

SO_REUSEADDR

允許 bind 到仍有 TIME_WAIT 連線的位址，server 重啟必設，否則會遇到 Address already in use。

SO_REUSEPORT

允許多個 socket（多個 process / thread）bind 同一個 port，由 kernel 以雜湊把新連線分散給它們，減少單一 accept queue 的競爭與驚群。Nginx listen ... reuseport。

TCP_NODELAY

關閉 Nagle，低延遲 RPC 必設。

SO_KEEPALIVE + TCP_KEEPIDLE/TCP_KEEPINTVL/TCP_KEEPCNT

偵測半開連線。

SO_LINGER

設 linger 為 0 時 close() 直接送 RST 而非 FIN，不會進入 TIME_WAIT。可以避免 TIME_WAIT，但會丟棄未送出的資料，一般不建議。

SO_RCVBUF / SO_SNDBUF

手動設定 buffer 會關閉 kernel 的自動調整，除非確定需要，否則交給 auto-tuning。

網路排查工具箱與常見攻擊 高頻

curl -w：把延遲拆開

cat > curl-format.txt <<'EOF'
    dns_lookup:  %{time_namelookup}s\n
   tcp_connect:  %{time_connect}s\n
 tls_handshake:  %{time_appconnect}s\n
  pre_transfer:  %{time_pretransfer}s\n
          ttfb:  %{time_starttransfer}s\n
         total:  %{time_total}s\n
     http_code:  %{http_code}\n
  http_version:  %{http_version}\n
   remote_addr:  %{remote_ip}:%{remote_port}\n
EOF
curl -s -o /dev/null -w @curl-format.txt https://api.example.com/v1/health

這些時間都是從請求開始累計的，所以要相減才是各階段耗時：

curl -v https://api.example.com/ 2>&1 | less      # 完整的交握與 header 過程
curl -I https://www.example.com/                    # 只看 response header（HEAD）
curl --http2 -sI https://www.example.com/ | head -1  # 確認 HTTP/2
curl --resolve api.example.com:443:10.0.1.11 https://api.example.com/healthz   # 繞過 DNS 打指定後端
curl -H 'Host: api.example.com' http://10.0.1.11/healthz                       # 以 Host header 測 virtual host
for i in $(seq 1 20); do curl -s -o /dev/null -w '%{time_total}\n' https://api.example.com/; done | sort -n

dig：DNS 排查

dig api.example.com                    # 完整回應：ANSWER、TTL、查詢時間、使用的 server
dig +short api.example.com A
dig api.example.com @1.1.1.1           # 指定 resolver，比較不同 resolver 的結果
dig +trace api.example.com             # 從 root 開始逐層迭代，找出哪一層出錯
dig example.com NS                     # 查其他類型：NS、MX、TXT、CAA…
dig example.com TXT +short
dig -x 203.0.113.10                    # 反解
cat /etc/resolv.conf                   # 確認 nameserver、search、options ndots

tcpdump：看封包說話

# 觀察三次交握與揮手
tcpdump -i any -nn 'host 10.0.1.11 and port 8080 and (tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0)'
# 找出 RST（連線被拒絕或被重置）
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'
# 錄下來用 Wireshark 分析（限制大小與數量，避免塞爆磁碟）
tcpdump -i eth0 -nn -s 0 -C 100 -W 5 -w /tmp/cap.pcap port 443
# DNS 查詢
tcpdump -i any -nn port 53

常見判讀：只有 SYN 沒有 SYN-ACK → 對方沒收到或被防火牆擋 / accept queue 滿；立刻收到 RST → port 沒在 listen 或被主動拒絕；大量重傳 → 網路丟包或對端過載；win 0 → 接收方應用讀太慢。

mtr、ss -s 與其他

mtr -rwzc 100 api.example.com    # traceroute + ping 的結合，報表模式跑 100 次，看每一跳的丟包與延遲
# 注意：中間某一跳顯示丟包但後面各跳正常，通常只是該路由器限制 ICMP 回應，不是真的丟包
ss -s                             # 連線總覽：estab、timewait、orphaned 數量
ss -tin state established dst 10.0.1.11   # 每條連線的 rtt、cwnd、retrans
ip -s link show eth0              # 網卡 RX/TX errors、dropped
ethtool -S eth0 | grep -i -E 'drop|err|miss'
nc -zv 10.0.1.11 8080             # 快速測 port 是否可連
ping -c 5 10.0.1.11               # 基本連通與 RTT（ICMP 可能被擋）

排查流程：「API 變慢 / 間歇失敗」

1. 界定範圍：所有 client 還是特定區域？所有後端還是特定節點？何時開始？是否有部署或設定變更？
2. 拆延遲：用 curl -w 或 APM 的 trace 把時間拆成 DNS / connect / TLS / server / transfer。
3. 網路層：mtr 看路徑丟包；ss -tin 看重傳與 RTT；nstat 看 ListenOverflows、TCP 重傳率。
4. 連線層：ss -s 看 TIME_WAIT / CLOSE_WAIT 是否異常；連線池是否耗盡（應用端等待取得連線的時間）。
5. Proxy 層：Nginx log 的 $request_time vs $upstream_response_time（兩者差距大 = client 慢或 Nginx 本身排隊）；502/504/499 比例。
6. 應用與下游：profiling、慢查詢、下游延遲。

常見網路攻擊與防護

面試自測題