Windows 平台第 7 層 (應用層) 軟體負載平衡經驗分析：Http.sys、HttpWebRequest、可靠性架構

在 Windows 平台實作 Layer 7 (HTTP/URL 型) 軟體負載平衡器，核心基於 Http.sys (核心模式 HTTP 協定堆疊) 與 HttpWebRequest。本文分析效能瓶頸與可靠性架構選型。

效能分析

1. 外部連線管理與協定解析：Http.sys (HttpApi.dll/HttpListener) 於核心層級處理，效能有保證。
2. 內部 RealServer 連線管理：HttpWebRequest 預設每請求建立/銷毀連線，受限於 65535 埠上限。對策：啟用 RealServer Keep-Alive 重用連線。
3. 封包重組開銷：HttpListener 解析物件需重新序列化為 HttpWebRequest (複製 URI/Header/Cookie/Body)，記憶體複製成本高，難以避免。
4. 回應資料轉發：常規 Web 應用 Request 小/Response 大，Proxy 需轉發大量回應資料，再次記憶體複製；無法實作 LVS 型 Direct Routing (需修改 MAC/IP 隧道)，受限於使用者模式。
5. HTTP 協定同步阻塞：Request/Response 必須成對，管線化 限制多 (POST 不支援、首請求不可管線、斷線多請求失敗)，天然同步等待影響併發。
6. HttpListener APM 非同步模型：Begin/End 模式頻繁建構/銷毀 IAsyncResult 增加 GC 壓力，無自訂物件池介面。期待 Event-based Async (XXXAsync) 改善。
7. 核心/使用者模式切換：HttpListener 為 .NET 包裝類跑在使用者模式，請求/回應各經歷一次模式切換。Linux LVS/KTCPVS 可在核心模式直接 7 層轉發；Windows 需 TDI/NDIS 開發，複雜度極高。

可靠性架構方案比較

1. 方案 A：前置 L4 負載 + 多台 L7 Proxy 共享雜湊策略 (推薦)
   L4 設備 (支援 Keep-Alive 健康檢查) 按 Session 隨機分發 → 所有 L7 節點均可正確處理任一請求 (共享 Session/雜湊) → 單節點故障 L4 偵測剔除，餘節點持續服務。
2. 方案 B：L7 雙機熱備 + ARP 欺騙漂移 IP (次選)
   主機處理流量，備機偵測主機存活 → 故障時 ARP 欺騙奪取 VIP → 切換瞬間可能短暫請求失敗，架構較「山寨」且風險較高。

綜合考量效能上限與工程成本，方案 A 為 Windows 平台 L7 軟負載較務實選擇。