tcp_wmem 不直接控制 Go 的 conn.Write() 行为
go 的 net.conn.write() 默认是阻塞调用，但它的行为不等于把数据直接塞进内核 tcp_wmem 缓冲区。实际路径是：go runtime 先拷贝到用户态的 write buffer（如 bufio.writer），再调用系统 sendto() 或 write()，此时才真正尝试写入内核发送缓冲区。如果 tcp_wmem 已满或对端接收窗口小，write() 会阻塞或返回 eagain（非阻塞模式下）。
常见误解是“调大 tcp_wmem 就能让 Go 写得更快”，但真实瓶颈常在：
- Go 应用层未做批量写（比如每条日志都 conn.Write([]byte{...})）
- 对端接收太慢，导致滑动窗口收缩，内核无法推进发送
- 网络丢包/重传多，cubic/bbr 拥塞算法主动压低发送速率
Go 默认不启用 TCP_NODELAY，但 tcp_wmem 影响 Nagle 效果
Go 的 net.Conn 默认未设置 TCP_NODELAY（即 Nagle 算法开启）。这意味着小包可能被内核缓存合并发送——但这个缓存不是 tcp_wmem，而是 Nagle 自身的“等待 ACK + 更多数据”逻辑。不过：
- 如果 tcp_wmem 最小值设得太小（如仍为默认 4096），而应用突发发送多个小包，内核可能因缓冲区紧张提前触发 Nagle 合并或延迟确认
- 若已设 conn.SetNoDelay(true)，Nagle 关闭，此时 tcp_wmem 的默认值和最大值就更关键：它决定了单次 Write() 能否“一气呵成”推入足够数据，避免频繁系统调用
建议场景：
- 实时 RPC（gRPC/HTTP2）：设 tcp_wmem="4096 65536 16777216" + conn.SetNoDelay(true)
- 大文件上传：保持默认 tcp_wmem，靠自动缩放（tcp_window_scaling=1）和 BDP 匹配即可，不必硬塞 16MB
tcp_wmem 三元组中“默认值”才是 Go 新建连接的实际起点
Go 创建新 TCP 连接（net.Dial()）时，内核为其分配的初始发送缓冲区大小，取自 tcp_wmem 的第二个值（默认值），而非第一个（最小值）或第三个（最大值）。例如：
net.ipv4.tcp_wmem = 4096 16384 4194304
意味着每个新连接起始有 16KB 发送缓冲区。这个值会影响：
- 初次握手后，应用第一次 Write() 能否不阻塞地塞入数据
- 在 RTT 高、带宽大的链路上，若默认值远小于 BDP（Bandwidth-Delay Product），内核需多次扩窗，吞吐爬升慢
- 若业务连接生命周期短（
验证方式：
- ss -i dst <ip>:<port></port></ip> 查看某连接当前 wscale 和 send-q
- cat /proc/net/snmp | grep TcpOutSegs 观察单位时间发包数变化
tcp_wmem 最大值不是越大越好，尤其对高并发 Go 服务
tcp_wmem 第三个值（最大值）限制的是单个连接能占的发送缓冲区内存上限。但它和 net.ipv4.tcp_mem 联动：当所有 TCP 连接的发送缓冲区总用量超过 tcp_mem 的 high 值，内核会强制回收、丢包甚至拒绝新连接。
Go 服务若每秒新建数千短连接（如 HTTP client），每个连接即使只用 1MB 缓冲区，1000 个连接就是 1GB；若 tcp_wmem 最大值设为 16777216（16MB），再叠加连接数，极易触达 tcp_mem 上限，引发 TIME_WAIT 积压或 Connection refused。
安全做法：
- 先算清预期并发连接数 × 平均活跃时间 × 估算平均缓冲区占用
- 把 tcp_wmem 最大值设为略高于 BDP（如 100Mbps × 50ms ≈ 625KB），而非盲目上 16MB
- 配合 tcp_tw_reuse=1 和 ip_local_port_range="1024 65535" 缓解端口耗尽
最易被忽略的一点：Go 的 http.Transport 默认复用连接，但若服务端主动断连（如 Nginx keepalive_timeout 过短），客户端会频繁重建连接——此时 tcp_wmem 最大值的影响，远大于长连接场景下的默认值。
