最近在公司做数据备份方案的时候，碰上一个挺头疼的问题：明明千兆带宽，传输文件却卡得像老牛拉车。查了一圈才发现，问题出在网桥配置上。延迟高得离谱，导致备份任务动不动就超时，重试又加重网络负担，恶性循环。
网桥不是插上线就能用
很多人觉得网桥就是把两个网络段连起来，通了就行。但实际上，配置不当的网桥会成为性能瓶颈。尤其是在数据备份这种需要持续高吞吐的场景下，延迟一上来，效率直接打对折。
我们当时用的是 Linux 的 bridge-utils 搭的网桥，系统默认的转发延迟（forward delay）是 15 秒。听起来不多，但在频繁建立连接的备份任务里，每次都要等 STP（生成树协议）收敛，实际体验就是“断一下、卡一下”。
关闭不必要的 STP 或调整参数
如果网桥连接的是可信且结构固定的设备，比如备份服务器和存储节点之间，完全可以关掉 STP。省去探测和等待的时间，延迟立马下来。
brctl stp br0 off如果不放心全关，也可以调低 forward delay：
brctl setfd br0 4把延迟从 15 秒压到 4 秒，对大多数内网环境来说已经足够安全又高效。
检查 NIC 和驱动是否支持 offload
另一个容易被忽略的点是网卡的卸载功能。特别是开启网桥后，如果没打开 TSO、GSO、GRO 这些特性，CPU 得亲自处理每一个小包，负载一高，延迟自然飙升。
用下面命令看看当前状态：
ethtool -k eth0 | grep offload确保 gro、gso、tso 是 on 状态。如果不是，手动打开：
ethtool -K eth0 gso on
ethtool -K eth0 gro on
ethtool -K eth0 tso on物理拓扑也要理清楚
有一次我们发现延迟还是高，最后追到物理链路——网桥两端的交换机端口速率不一致，一边是千兆全双工，另一边协商成了百兆半双工。这种“肠梗阻”式连接，再怎么调软件参数都没用。
建议在关键备份链路上固定速率和双工模式，避免自动协商出问题：
ethtool -s eth1 speed 1000 duplex full autoneg off调完这一圈，原本 80ms 的平均延迟降到了 12ms 左右，备份速度从 3MB/s 涨到 110MB/s，效果立竿见影。网桥看着简单，真要榨出性能，还得一个个细节抠。”}