协议栈到底在做什么
每次打开网页、刷视频、打游戏，背后都离不开网络协议栈的运作。它像是一个快递分拣中心，负责把数据打包、拆包、转发。但当这个中心效率低下时，哪怕带宽再大，延迟照样高得离谱。
很多人遇到过这种情况：家里千兆宽带，测速也达标，可打游戏还是卡，视频加载转圈。问题可能不出在路由器或运营商，而是操作系统内部的协议栈扛不住流量压力。
常见瓶颈藏在哪
协议栈处理数据要经过多个环节：接收网卡数据、中断处理、内核协议解析、缓冲区管理、应用读取。任何一个环节卡住，都会拖慢整体速度。
比如老式网卡频繁触发中断，CPU光处理“有数据来了”这种通知就忙不过来。或者系统默认的接收缓冲区太小，高速下载时数据挤不进去，只能丢包重传，网速自然上不去。
再比如服务器并发连接数太大，每个连接都占一点内存和CPU，累积起来系统就开始抖动。这时候不是硬件不行，是协议栈配置没跟上业务需求。
看懂关键指标
用 netstat -s 或 ss -i 能看到协议栈的运行状态。如果发现大量 TCP retransmits（重传）、out of order（乱序）或者 drop（丢包），基本可以锁定是协议栈层面出了问题。
Linux 下还可以查 /proc/net/sockstat，看看 socket 使用情况。如果 used 数量接近 max，说明连接池快满了，新连接进不来。
动手优化几招实操
调整内核参数是最直接的办法。比如增大 TCP 缓冲区：
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728这能让大流量传输更稳，减少因缓冲区满导致的丢包。
开启 TSO/GSO（分段卸载）也能减轻 CPU 负担。网卡自己搞定大数据包的拆分，不用每次都劳烦 CPU：
ethtool -K eth0 tso on
tc qdisc add dev eth0 root fq最后这行用 FQ（Fair Queue）调度算法，能有效降低延迟，特别适合高并发场景。
应用层配合也很关键
别光指望系统自动优化。写程序时尽量用异步 IO，避免阻塞主线程。比如 Node.js 的非阻塞模型、Python 的 asyncio，都能更好利用协议栈能力。
还有个小细节：连接复用。HTTP/1.1 默认 keep-alive，但很多旧服务设得太短。适当延长空闲连接保持时间，能省下大量握手开销。
真实场景参考
某直播平台遇到推流卡顿，排查发现服务器协议栈每秒处理上万个小包，中断太密集。换成支持 RSS（接收侧缩放）的网卡，把中断分散到多个 CPU 核心，问题立马缓解。
另一个例子是手游后端，高峰期连接数暴增，系统开始丢包。通过调大 net.core.somaxconn 和应用层 listen backlog，撑住了三倍并发。
这些问题都不需要换设备，改几行配置就见效。关键是得知道往哪查、怎么调。