网络协议栈调优适合哪些场景？这些真实情况你可能正遇到

家里千兆宽带，测速却卡在200Mbps；公司内网传大文件，同一台交换机下A机器快如闪电，B机器慢得像拨号；游戏里频繁掉线、延迟忽高忽低，重启路由器也没用——这些都不是玄学，很可能是Linux系统默认的TCP/IP协议栈参数，压根没跟上你的硬件和业务节奏。

高并发Web服务上线前

一台4核8G的云服务器跑Nginx+PHP，突然要支撑每秒3000个HTTP连接。默认的net.core.somaxconn只有128，连接还没进队列就被丢弃；net.ipv4.tcp_tw_reuse关着，TIME_WAIT状态占满端口，新请求直接502。这时候调大监听队列、开启TIME_WAIT复用、调整tcp_fin_timeout，几行命令就能让QPS翻倍：

sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_fin_timeout=30

数据中心内部微服务通信

Kubernetes集群里，Service间调用走的是iptables+conntrack，默认的nf_conntrack_max常设为65536，一旦Pod数量上来、接口调用链变长，连接跟踪表就爆了，出现‘connection refused’或随机超时。实测把conntrack表扩容到50万，并调小超时时间：

sysctl -w net.netfilter.nf_conntrack_max=524288
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300

视频直播/远程桌面这类实时流

推流端用FFmpeg往SRS服务器送4K流，但偶尔花屏卡顿，Wireshark一看全是TCP重传。原因往往是默认的拥塞控制算法（Cubic）偏保守，而网络实际是低延迟、高带宽的局域网或专线。换成bbr后，带宽利用率从60%拉到95%，卡顿率下降八成：

echo 'net.core.default_qdisc=fq' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_congestion_control=bbr' >> /etc/sysctl.conf
sysctl -p

老旧设备跑新业务

某工厂PLC数据采集网关用的是ARM嵌入式Linux，内存仅256MB，跑MQTT客户端持续上报。结果三天一假死，查日志发现net.ipv4.route.max_size被撑爆，路由缓存溢出导致ARP失效。降低缓存上限、缩短邻居表老化时间，问题当场消失：

sysctl -w net.ipv4.route.max_size=2048
sysctl -w net.ipv4.neigh.default.gc_thresh1=256
sysctl -w net.ipv4.neigh.default.gc_thresh2=512
sysctl -w net.ipv4.neigh.default.gc_thresh3=1024

别盲目调，先看瓶颈在哪

不是所有场景都该调。比如普通家用NAS，Samba共享百兆文件，CPU和磁盘才是瓶颈，狂改tcp_slow_start_after_idle反而引发乱序重传；又比如OpenWrt路由器做软路由，RAM只有64MB，把net.core.rmem_max设到16MB，结果OOM Killer直接干掉sshd。调之前先用ss -s、cat /proc/net/snmp、sar -n TCP查看当前连接状态、丢包、重传、内存占用，再对症下手。