如何在Golang中优化TCP连接处理_Golang net TCP性能优化实践_技术教程

net.Conn 默认缓冲区不匹配业务节奏会导致延迟或系统调用频繁；应按短连接（4096）或长连接（65536）显式设置，并安全复用 sync.Pool 中的 bufio.Reader/Writer，同时正确配置 keepalive 和 SO_REUSEPORT。

为什么 `net.Conn` 的默认读写缓冲区会拖慢高并发连接

Go 的 net.Conn 默认使用操作系统级别的 socket 缓冲区（Linux 下通常为 212992 字节），但实际应用中，小包高频场景（如 MQTT 心跳、HTTP/1.1 短连接）容易因缓冲区过大导致延迟毛刺，或过小引发频繁系统调用。关键不是“调大”，而是匹配业务节奏。

短连接服务（如 API 网关）建议显式设置 SetReadBuffer(4096) 和 SetWriteBuffer(4096)，减少内核拷贝开销
长连接流式服务（如实时日志推送）可设为 65536，但需配合 SetNoDelay(false) 启用 Nagle 算法合并小包
切勿在 Accept 后立即调用 SetReadBuffer —— 此时连接可能尚未完成三次握手，部分系统（如 macOS）会静默失败

如何安全复用 `sync.Pool` 管理 `bufio.Reader/Writer`

每次新建 bufio.Reader 或 bufio.Writer 会分配内存并初始化缓冲区，在 QPS 过万时 GC 压力明显。用 sync.Pool 复用是有效解法，但必须注意生命周期边界。

Pool 中对象不能持有对 net.Conn 的强引用，否则连接关闭后 Reader/Writer 无法被回收
推荐模式：在 goroutine 内部从 Pool 获取，处理完立即 Put 回池，且不跨连接复用
缓冲区大小统一设为 4096，避免不同 size 导致 Pool 内存碎片化

var readerPool = sync.Pool{
    New: func() interface{} {
        return bufio.NewReaderSize(nil, 4096)
    },
}
func handleConn(conn net.Conn) {
defer conn.Close()
r := readerPool.Get().(*bufio.Reader)
r.Reset(conn) // 关键：复用前重置底层 io.Reader
// ... 读取逻辑
readerPool.Put(r)
}

`SetKeepAlive` 和 `SetKeepAlivePeriod` 的真实生效条件

很多服务开启 keepalive 却仍出现“连接被对端静默关闭”，问题常出在参数未真正下发到 socket 层，或平台限制未被绕过。

Linux 下必须同时调用 SetKeepAlive(true) 和 SetKeepAlivePeriod(30 * time.Second)，只设前者会使用内核默认值（通常是 2 小时）
macOS 和 Windows 不支持自定义间隔，SetKeepAlivePeriod 调用会被忽略，需改用应用层心跳（如发送 \n）
容器环境（如 Docker）中，若宿主机启用了 net.ipv4.tcp_fin_timeout 缩短 FIN_WAIT2 时间，keepalive 探测可能在连接真正断开前就超时失败