net/http长连接性能问题源于内核TCP栈与Go runtime隐式耦合；fasthttp吞吐下降40%是因workerPool模型与长连接场景错配；gnet“无调度器”引发三重内核级陷阱；务实优化需调整IdleTimeout、LockOSThread及MaxBytesReader。
net/http 在长连接场景下不是“慢”，而是状态管理开销被严重低估；fasthttp 的吞吐反而可能下降 40%，这不是 bug，是 Linux 内核调度与 Go 运行时协同失效的必然结果。
为什么 net/http 在 10 万长连接时 p99 延迟飙升但 CPU 很低
根本原因不在 serveHTTP 函数，而在内核 TCP 栈与 Go runtime 的隐式耦合。当连接长期空闲（如 WebSocket、SSE、HTTP/2 流），net/http.Server 依赖 net.Conn.SetReadDeadline 触发超时检测，而该调用在 Linux 6.1+ 上会触发频繁的 epoll_ctl(EPOLL_CTL_MOD) 操作——每次修改都需遍历红黑树并重排就绪队列。更致命的是，大量 goroutine 长期阻塞在 read 系统调用上，导致 runtime 的 findrunnable 调度路径变长，goroutine 抢占延迟上升。此时你看到的 /proc/net/softnet_stat 第 11 列（cpu_collision）狂飙，本质是 softirq 处理器间缓存伪共享 + epoll wait 唤醒风暴叠加所致。
fasthttp 在长连接下吞吐反降 40% 的真实原因
fasthttp 的 workerPool 模型假设连接是“短命+高周转”的，它把每个 net.Conn 绑定到固定 worker goroutine，并复用 RequestCtx 对象。但长连接意味着：
- workerChan 长期被单个连接独占，pool 中其他 worker 闲置，实际并发度远低于 GOMAXPROCS
- 每次心跳或空闲读都会触发 bufio.Reader.Reset，而 fasthttp 的 sync.Pool 并未覆盖该路径，造成高频小对象逃逸
- 它绕过 Go netpoll 直接调用 syscall.Read，失去 runtime 对 net.Conn 的生命周期感知，导致 GC 无法及时回收关联的 fd 和内核 socket buffer 引用，内存带宽被悄悄吃满
实测中，当长连接维持超过 3 分钟，fasthttp 的 runtime.NumGoroutine() 不降反升，且 pprof -http 显示 68% 时间花在 runtime.mallocgc 的标记阶段——这不是代码写得不好，是模型与场景错配。
gnet 的“无调度器”承诺在长连接里埋了三个内核级陷阱
gnet 宣称“绕过 Go scheduler”，实际是用 epoll_wait + readv/writev 手动轮询，但这在长连接场景触发三重内核风险：
- SO_KEEPALIVE 探针与用户层心跳冲突，TCP 栈重复发送 ACK 导致乱序重传
- 没有 runtime 的 netpoll 插桩，setsockopt(TCP_NODELAY) 无法动态生效，Nagle 算法在空闲连接上悄然积累延迟
- 所有连接共用一个 epoll fd，当某连接触发 EPOLLHUP 或 EPOLLRDHUP，整个 event loop 必须逐个扫描所有连接状态，O(n) 复杂度在 5 万连接时直接卡住主线程
Linux 6.1 已确认该问题：gnet 的 eventfd 通知机制与 cgroup v2 的 cpu.max 限流存在竞态，会导致 write(eventfd, &val, 8) 阻塞超过 2 秒——这正是凌晨三点告警群里看到的 “p99 突破 800ms” 的物理根源。
真正能稳住长连接的务实做法
别迷信“替换 HTTP 库”，重点做三件事：
- 把 net/http.Server.IdleTimeout 设为 0（禁用 idle close），改用应用层心跳 + SetReadDeadline 精确控制，避免内核超时干扰
- 对每个长连接 goroutine 显式调用 runtime.LockOSThread()，防止其被 runtime 迁移导致 cache line 污染
- 在 http.HandlerFunc 开头插入 if req.Header.Get("Connection") == "keep-alive" { http.MaxBytesReader(...) }，强制限制单连接资源消耗
这些改动加起来不到 10 行代码，但比换框架更能守住长连接的稳定性底线——因为问题从来不在 Go，而在你是否看清了内核、runtime 和协议栈之间那层薄如蝉翼的契约。
