net/http长连接性能瓶颈源于内核epoll_ctl开销与goroutine调度延迟，fasthttp吞吐下降40%因workerpool模型不适用长连接，gnet“无调度器”设计引发内核级陷阱；需调优idletimeout、tcp参数、numa绑定及心跳策略。
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 唤醒风暴叠加所致。
实操建议：
- 显式设置
IdleTimeout（如30 * time.Second），避免连接无限空闲挂起 - 调大
tcp_fin_timeout内核参数（需匹配IdleTimeout），防止连接卡在 FIN-WAIT-2/TIME-WAIT - 在 NUMA 架构机器上，用
numactl --cpunodebind=0 --membind=0启动服务，避免跨节点缓存失效
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 引用，内存带宽被悄悄吃满
实操建议：
- 禁用
workerPool（设WorkersCount = 0），改用 per-connection goroutine，让 runtime 调度器接管 - 手动为每个连接分配独立
bufio.Reader（不要复用），避免 cache line 伪共享 - 务必检查
ctx.Request.Header.Host()，fasthttp 默认不校验 Host 头，易被域前置攻击利用
gnet 的 “无调度器” 承诺在长连接里埋了三个内核级陷阱
gnet 宣称“绕过 Go scheduler”，实际是用 epoll_wait+readv/writev 手动轮询，但这在长连接场景触发三重内核风险：
-
SO_KEEPALIVE探针与用户层心跳冲突，TCP 栈重复发送 ACK 导致乱序重传 - 没有 runtime 的
netpoll插桩，setsockopt(TCP_NODELAY)无法动态生效，Nagle 算法在空闲连接上悄然积累延迟 - 所有连接共用一个
epoll实例，fd 数量增长后epoll_wait性能退化明显（O(1) → O(n)）
实操建议：
- 关闭内核
tcp_keepalive_time，完全由应用层控制心跳节奏 - 对每个连接单独调用
setsockopt(TCP_NODELAY, 1)，且在连接建立后立即执行 - 按 CPU 核心数分片，每个
epoll实例绑定固定 goroutine + OS thread（runtime.LockOSThread()）
长连接不是连接，而是一段跨越数分钟的协议状态漂流。真正决定性能上限的，从来不是 Goroutine 分配快慢，而是你是否清楚自己正在和内核 TCP 栈、Go runtime 调度器、NUMA 内存子系统三方共舞——任何一方节奏错拍，都会在凌晨三点以 cpu_collision 每秒 37 万次的形式准时报到。
