关闭tcp_slow_start_after_idle可避免空闲后cwnd重置为2/4导致的延迟升高；调大net.core.somaxconn至65535并匹配应用listen backlog可防止连接拒绝。

tcp_slow_start_after_idle 导致连接突然变慢

Linux 默认开启 tcp_slow_start_after_idle，空闲一段时间后重传会退回到慢启动状态——哪怕之前已经跑满带宽。这不是“优化”，是自废武功。

常见现象：长连接（如数据库连接池、HTTP/1.1 持久连接）在几秒无流量后，下一次请求明显延迟升高，ss -i 能看到 cwnd 从几十降回 2 或 4。

• 关掉它：sysctl -w net.ipv4.tcp_slow_start_after_idle=0
• 永久生效：写入 /etc/sysctl.conf 或 /etc/sysctl.d/99-tcp.conf，加一行 net.ipv4.tcp_slow_start_after_idle = 0
• 注意：内核 4.15+ 默认已是 0，但很多生产环境还在用 3.10/4.4，务必检查

net.core.somaxconn 和应用 listen() 的 backlog 不匹配

应用调用 listen(fd, backlog) 时传的值，会被内核截断到 net.core.somaxconn。如果后者太小（默认常为 128），高并发建连时大量 SYN 会直接被丢弃，客户端看到 Connection refused 或超时，而不是排队等待。

典型场景：Nginx、Redis、Node.js 等服务在压测初期就出现连接失败，netstat -s | grep -i "listen overflows" 输出非零值就是铁证。

• 先查当前值：sysctl net.core.somaxconn
• 设为 65535（足够覆盖绝大多数场景）：sysctl -w net.core.somaxconn=65535
• 同时确认应用层 listen 的 backlog 参数是否 ≥ 这个值（例如 Nginx 的 listen ... backlog=65535）
• 旧版内核（net.core.netdev_max_backlog 影响，若网卡收包队列溢出也会丢包，建议同步设为 5000+

rmem/wmem 设置不当引发吞吐瓶颈

TCP 接收/发送缓冲区大小直接影响单连接吞吐。过小（如默认的 256KB）会导致高延迟链路（跨机房、云厂商内网）无法填满带宽；过大则浪费内存，且可能加剧 bufferbloat。

关键不是“越大越好”，而是匹配你的 BDP（Bandwidth-Delay Product）：比如 10Gbps + 1ms RTT → BDP ≈ 1.25MB，接收缓冲至少要 ≥ 这个数，否则窗口永远打不开。

• 查看当前值：sysctl net.ipv4.tcp_rmem（输出三值：min default max）
• 合理设置（示例）：net.ipv4.tcp_rmem = 4096 262144 2097152（max 提到 2MB，default 保持 256KB 兼容小连接）
• 必须同步调 net.ipv4.tcp_wmem，尤其对上传密集型服务（如文件上传、视频推流）
• 不要只改 rmem_max，应用没显式调 setsockopt(SO_RCVBUF) 时，内核按 default 分配；max 只是上限

net.ipv4.tcp_congestion_control 选错算法影响真实环境表现

reno 是传统稳定选择，但对高丢包率、高延迟、共享带宽的云网络（如 AWS/Azure 内网、K8s Pod 网络）不够友好。cubic 是多数发行版默认，激进提速快但易抢占带宽；bbr 在单流大带宽场景优势明显，但可能和 cubic 流争抢不公平，且部分老内核不支持。

别盲目切 bbr——先看实际瓶颈：如果 ss -i 显示 cwnd 长期卡在低值、retransmits 高，说明拥塞控制在频繁退缩；如果 rtt 波动极大，可能是 bufferbloat，换算法也白搭。

• 查当前算法：sysctl net.ipv4.tcp_congestion_control
• 临时切换：sysctl -w net.ipv4.tcp_congestion_control=bbr（需内核 ≥ 4.9，且 lsmod | grep bbr 确认已加载）
• 生产环境建议先在灰度节点验证：用 curl -v --limit-rate 1M 模拟大文件下载，对比不同算法下的平均速率与抖动
• 注意：容器内修改 sysctl 需加 --sysctl 参数或 privileged 权限，普通 pod 默认被限制

真正卡住性能的往往不是单个参数，而是几个值之间的隐含依赖：比如调大了 rmem_max 却没开 tcp_window_scaling（其实现代内核默认开），或者换了 bbr 却忘了关 tcp_sack（它和 bbr 是兼容的，但某些定制内核有冲突）。改之前，先用 ss -i 和 tcpreplay 类工具复现问题，比背参数表管用得多。