使用Golang进行WebSocket长连接的并发压力测试

大量连接卡在handshake因http.transport默认配置宽松导致tcp连接未及时释放，需显式设置dialer超时、禁用http/2、限制本地端口范围、避免复用client实例。

用 gorilla/websocket 模拟高并发连接时，为什么大量连接卡在 handshake？

因为默认的 http.Transport 对连接复用和超时控制太宽松，底层 TCP 连接没及时释放，dialer 会阻塞在 DNS 解析或 TLS 握手阶段。尤其在短时发起数千连接时，本地端口耗尽、TIME_WAIT 积压、DNS 缓存未生效都会放大问题。

• 显式设置 Dialer.Timeout 和 Dialer.KeepAlive，比如 10 * time.Second 和 30 * time.Second
• 禁用 HTTP/2：http.DefaultTransport.(*http.Transport).TLSNextProto = make(map[String]func(string, *tls.Conn) http.RoundTripper)，避免握手协商开销
• 用 net.Dialer 控制本地端口范围（如 LocalAddr: &net.TCPAddr{Port: 0}）避免 bind 失败
• 别复用同一个 http.Client 实例做千级并发 dial —— 每个 goroutine 应该用独立 Dialer 实例，否则锁争用严重

websocket.WriteMessage 频繁报 write tcp: use of closed network connection 怎么办？

不是网络问题，是连接被主动关闭后，还有 goroutine 在往已关闭的 *websocket.Conn 写数据。常见于：心跳检测失败后只关读、没同步关写；或 panic 后 defer 没覆盖全部路径。

• 写操作前加 if conn == nil || conn.IsClosed() { return }，IsClosed() 是 gorilla/websocket v1.5+ 提供的非阻塞判断
• 写逻辑必须包裹在 select 中监听 conn.CloseNotify() 或自定义 done channel，一收到关闭信号立刻退出写循环
• 避免在 WriteMessage 后立刻调用 Close() —— 改用 WriteControl(websocket.CloseMessage, ...) 主动发 close 帧，再等对方响应
• 测试时用 conn.SetWriteDeadline(time.Now().Add(500 * time.Millisecond)) 暴露写阻塞问题，比默认无限等待更易定位

压测中 CPU 突增但 QPS 上不去，runtime/pprof 显示大量 websocket.preparedMessage 占用堆内存

这是典型的消息预分配滥用：每次调用 WriteMessage 都会拷贝 payload 并封装成 preparedMessage，如果反复发送相同小消息（如心跳 ping），对象分配频率极高，GC 压力陡增。

• 对固定内容（如 "ping"）提前构建 websocket.PreparedMessage 实例，复用而非每次都 new
• 用 conn.WriteControl() 发送 ping/pong —— 它不走 message 编码流程，零分配
• 关闭 WriteBufferPool（设为 nil）反而更稳：压测场景下 pool 的 lock 争用常比分配还重
• 检查是否误将大结构体 json 序列化后直传给 WriteMessage —— 应先序列化到 []byte 再传，避免闭包捕获导致逃逸

如何让单机压出 10w+ WebSocket 连接而不 OOM 或卡死？

关键不在 Go 并发模型多强，而在 OS 层和连接生命周期管理是否精细。golang 能跑满连接数，但系统限制和连接“假活”才是瓶颈。

立即学习“go语言免费学习笔记（深入）”；

• 调高系统参数：ulimit -n 1000000、sysctl -w net.core.somaxconn=65535、关闭 net.ipv4.tcp_tw_reuse（压测环境可开，但需确认服务端也配好）
• 每个连接必须带独立 context，并在 goroutine 启动时就监听 cancel —— 别等 write/read 报错才退出
• 禁用 SetReadDeadline 的绝对时间模式，改用 SetReadLimit + 心跳计数器，避免大量 timer 对象堆积
• 连接建立后立即发一次 ping 并等待 pong，失败则立刻 close —— 防止“半开连接”占着 fd 不放

真正难的不是启动连接，是让它们按预期断开。很多压测脚本卡在 8w 连接不动，其实是 2w 连接早已静默断连却没被回收，fd 被占着，新连接 bind 失败。盯着 /proc/<pid>/fd</pid> 和 ss -s 才能看清真相。