基于 Windows Http.sys (内核态) + HttpWebRequest (用户态) 实现七层负载均衡的技术可行性、性能瓶颈、可靠性方案深度剖析。
架构模型
- 前端接收： Http.sys 内核态管理 TCP 连接、解析 HTTP 协议，性能有保障。
- 后端转发： HttpWebRequest 用户态重新组装请求（拷贝 URI/Header/Cookie/Body）转发至 RealServer。
五大性能瓶颈
- 连接风暴： 默认每请求新建连接，受限于 65535 端口上限。对策： 启用 RealServer Keep-Alive 复用连接。
- 内存拷贝开销： HttpListener 解析对象 → HttpWebRequest 重新序列化，全量内存拷贝。难以规避。
- 响应回程拷贝： 大响应体回程再经 Proxy 拷贝，且无法像 LVS DR 模式绕过 Proxy。无法规避。
- HTTP 协议串行限制： 管道化受限（POST 不支持、首请求不支持、批量失败风险），无法像 SIP 纯异步匹配。协议层面硬伤。
- APM 异步模型 GC 压力： HttpListener 旧式
Begin/End 模式高频产生 IAsyncResult 对象，无对象池。需升级 EAP 模式或改用 SocketAsyncEventArgs。
- 用户/内核态双重切换： 每请求两次态切换。Linux LVS/KTCPVS 可内核态七层转发，Windows 需 TDI/NDIS 开发，成本极高。
可靠性方案对比
| 方案 | 架构 | 优点 | 缺点 |
|---|
| 方案一（推荐） | 前置四层 LB (HAProxy/F5) → 多台七层 Proxy 共享哈希策略 | 四层 LB 健康检查剔除故障 Proxy；所有 Proxy 对等处理任意请求；无单点 | 需额外四层 LB 设备/软件 |
| 方案二 | 七层 Proxy 双机热备 + ARP 欺骗漂移 VIP | 节省四层 LB | 切换有秒级中断；ARP 欺骗不稳定；属山寨方案 |
结论：Windows 做七层软负载受限于协议栈与运行时架构，高性能/高可靠场景建议“前置四层 LB + 多 Proxy 横向扩展”，或直接上 Linux LVS/NGINX/OpenResty。
