公司内网最近总有人反映视频会议卡顿，远程桌面操作延迟高得像在拨号上网。查了一圈设备，交换机、路由器都没问题，最后发现罪魁祸首是中间那台老型号网桥。抓包一看，每秒几十万个小包来回穿梭，CPU直接飙到90%以上。这其实是个典型问题——网桥在处理小包时性能容易拉胯。
为啥小包特别吃资源？
大文件传输时，数据被打成一个个1500字节左右的“标准包裹”，网桥转发起来效率高。可像VoIP通话、心跳检测、工业控制这类应用，动不动就发64字节甚至更小的数据帧。虽然单个包很轻，但数量一多，转发负担就上来了。
每次收到一个包，网桥都要做完整流程：从物理层接收、校验CRC、查找MAC地址表、决定转发端口、再重新封装发出。这个过程叫“每包处理开销”。包越小，单位数据付出的CPU成本越高。好比用卡车运鸡蛋，一趟能拉一万颗，但如果每次都只运一颗，油钱和过路费早就亏穿了。
中断风暴：小包带来的隐藏杀手
很多低端网桥使用传统中断驱动模式。每个进来的包都会触发一次硬件中断，通知CPU来处理。当小包密集到达时，比如每秒20万个64字节包，意味着CPU每秒要响应20万次中断。哪怕每次处理只要几十微秒，累计下来也占满了一个核心的算力。
这时候你会发现，明明带宽才用了不到100Mbps，系统却已经忙得喘不过气。这就是所谓的“中断风暴”——不是带宽瓶颈，而是调度太频繁。
缓存与批处理能力不足
高端设备通常支持NAPI（New API）或类似机制，能把多个小包攒成一批统一处理，减少上下文切换。但不少老旧网桥还在用老式轮询+中断混合模式，缺乏有效聚合能力。
举个例子，两台服务器之间跑着ZooKeeper集群，每隔几毫秒互发一次心跳。这些64字节的小包像机关枪一样扫射网桥，如果设备不支持DMA批量搬运或零拷贝技术，内存和CPU就在不停搬数据中耗尽。
MAC表查找频率过高
虽然MAC地址表本身查找很快，但高频访问也会带来压力。特别是当网络中存在大量短连接或动态设备时，网桥不仅要频繁查表，还得不断更新老化计时器。每秒处理十万级小包的情况下，这部分开销不容忽视。
解决方案不是换设备就完事
当然可以换个支持线速转发的千兆网桥，但这不是唯一出路。实际排错中，先看看能不能从应用层优化：
比如调整TCP_NODELAY选项，避免应用程序过早发送小数据；或者启用TSO/LRO等卸载功能，让网卡自己合并包。有些场景下，把多个小报文打包成一个应用层消息再发送，效果立竿见影。
还有就是检查网桥固件是否支持中断合并（Interrupt Coalescing）。开启后，设备会稍等片刻，把多个中断合并成一次处理，虽然增加一点点延迟，但能大幅降低CPU占用。
遇到这类问题别急着甩锅硬件，很多时候是流量特征和设备能力不匹配。搞清楚背后原理，才能对症下药。