公司每天晚上10点准时开始备份服务器数据，可最近总要拖到凌晨2点才完成。运维老张盯着监控图看了一周，发现网络吞吐量始终卡在60%上下，CPU却不高，磁盘也没满——问题不在硬件。
瓶颈藏在“通信流程”里
数据从一台机器传到备份存储，不是简单地“复制粘贴”。它得经过操作系统里的协议栈，一层层打包、传输、解包。这个过程就像寄快递：你把文件装进信封（应用层），贴上地址单（传输层），再放进物流箱（网络层），最后由快递车发走（链路层）。
如果每个环节都慢半拍，哪怕带宽再大，实际传输效率也会打折扣。这就是为什么有时候千兆网线跑不满100MB/s——协议栈没调好，成了隐形瓶颈。
常见卡点：小包多、中断频
备份任务有个特点：频繁发送小数据块。比如每次只传几KB的日志片段。这种场景下，TCP每发一个包都要等确认（ACK），来回折腾，时间全耗在路上了。
更麻烦的是，每个网络包到达时都会触发一次CPU中断。一天几百万次中断下来，CPU光处理“收快递通知”就累够呛，哪还有力气干活？
几个实用优化手段
开启TSO（TCP Segmentation Offload）能让网卡自己拆分大数据包，减轻CPU负担。对应的还有LRO（Large Receive Offload），把多个小包合并后再交给系统，减少中断次数。
在Linux上可以这样检查：
ethtool -k eth0 | grep tso
ethtool -k eth0 | grep lro如果显示off，可以用下面命令打开：
ethtool -K eth0 tso on
ethtool -K eth0 gso on
ethtool -K eth0 lro on调整缓冲区大小也很关键
默认的TCP接收缓冲区可能只有几十KB，面对高速网络根本不够用。可以修改内核参数提升吞吐：
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728改完后执行 sysctl -p 生效。注意别设太大，否则内存吃紧。
实际效果：从两小时到四十分钟
老张在备份服务器上启用了TSO/GSO，并调大了缓冲区。第二天晚上的任务进度条明显快了一截，凌晨0:40就完成了。他看了眼流量统计，平均速率从原来的70MB/s冲到了210MB/s。
后来他们还上了多队列网卡，配合RPS（Receive Packet Steering）把中断分散到多个CPU核心，进一步榨干性能。
这些改动不花一分钱硬件成本，却让整个备份窗口缩短了七成。有时候，不是设备不行，而是默认设置太保守。
如果你也觉得数据同步“明明不该这么慢”，不妨看看协议栈这块黑盒子——它可能正默默拖后腿。