问题从哪儿来
你有没有遇到过这种情况：服务平时跑得好好的，一到促销活动或者用户高峰，网络延迟飙升，连接超时满天飞？别急，问题很可能出在协议栈上。尤其是在高并发场景下，TCP/IP 协议栈的默认配置往往扛不住压力，这时候光靠加机器解决不了根本问题。
缓冲区调优是第一步
Linux 系统默认的 socket 接收和发送缓冲区大小，在高负载下很容易成为瓶颈。比如，当大量请求同时涌入，接收缓冲区满了但应用还没来得及读取，新数据就只能被丢弃，触发重传，延迟自然上去了。
可以通过调整内核参数来扩大缓冲区：
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728这些值分别设置了最大接收/发送缓冲区和 TCP 的动态范围。数值单位是字节，上面的例子把上限设到了 128MB，适合大吞吐场景。
开启 TCP Fast Open 减少握手延迟
每次建立连接都要三次握手，看着不多，但在每秒几万连接的场景下，累积开销惊人。TCP Fast Open（TFO）能让客户端在第一次 SYN 包里就带上数据，省去一次往返。
启用方式很简单：
net.ipv4.tcp_fastopen = 3服务端和客户端都支持的情况下，效果非常明显，尤其对短连接密集的应用，比如 API 网关或微服务调用。
避免 TIME_WAIT 堆积
主动关闭连接的一方会进入 TIME_WAIT 状态，默认持续 60 秒。高并发短连接场景下，可能瞬间积累几万个 TIME_WAIT 连接，耗尽本地端口。
可以适当开启端口复用：
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1注意，tcp_tw_reuse 依赖 timestamps 开启，且只适用于客户端场景，服务端慎用。
使用 SO_REUSEPORT 提升并发 Accept 性能
传统多进程/多线程服务绑定同一个端口时，会有“惊群”问题——一个新连接到来，所有等待 accept 的进程都被唤醒，只有一个能成功。SO_REUSEPORT 允许多个套接字监听同一端口，内核自动做负载均衡，避免争抢。
代码示例：
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
int reuse = 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEPORT, &reuse, sizeof(reuse));
bind(sockfd, ...);
listen(sockfd, BACKLOG);配合多进程启动，每个进程独立 accept，性能提升明显。
关闭不必要的协议特性
像 TCP Cork、Nagle 算法这类合并小包的机制，在低延迟要求高的场景反而拖后腿。如果你的应用本身已经做了批量处理，可以考虑关闭：
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(int));比如实时游戏服务器或金融交易系统，追求的是快速响应，宁可多发几个小包。
监控才是优化的前提
改参数不是瞎调，得看数据。ss、netstat、sar 都能帮你查看连接状态、重传率、缓冲区使用情况。比如用 ss -it 查看每个连接的详细信息，包括 cwnd（拥塞窗口）、retrans（重传次数），这些才是判断协议栈健康的关键指标。
有时候你以为是协议栈的问题，结果发现是应用层处理太慢，数据积压在 buffer 里。所以，先观测，再动手。”}