上个月我把家里宽带升级到了500M，想着开视频会议总该丝滑了。结果周一下午的例会，画面还是卡成PPT，同事的声音断断续续像在听收音机。当时我差点打电话骂运营商，直到我打开路由器后台看到实时流量曲线——那曲线根本不像一条平缓的河，而是心电图，每隔几秒就飙升到80Mbps，然后又掉回20Mbps。这就是脉冲流量，也就是突发流量，它才是让你觉得“带宽永远不够”的真正原因。平均带宽看起来挺高，但你的设备接收的是瞬间速率，不是平均值。
脉冲流量到底怎么坑你的？想象一下你用一个水管往桶里灌水，正常流量是细水长流，但脉冲流量就是开一秒阀门、关一秒，再开两秒。管子里会产生水锤效应，桶里的水花四溅。网络设备也一样，你的路由器、交换机的缓冲区有限，当脉冲流量瞬间涌进来时，数据包在缓冲区排队，排不下的直接丢弃。TCP协议发现丢包就会触发拥塞控制，把发送窗口减半，然后慢慢恢复，再遇到脉冲又减半，反复横跳，最终你体感就是“卡到妈都不认识”。这不是带宽不够，是脉冲流量把缓冲区撑爆了。
我印象最深的一次故障排查是去年在一家电商公司帮忙。他们的服务器CPU占用不到30%，内存也充足，但数据库时不时就超时10秒。我蹲在机房里盯着监控看了一个下午，发现每隔15分钟，后台会跑一次数据同步任务，这个任务会产生一次持续约2秒的脉冲流量，大约20Mbps。平时这个量不算大，但恰好叠加在每小时的整点报表请求高峰上，两个脉冲撞一起，直接把核心交换机的缓冲打穿了。那一刻我意识到，没人关心你的平均利用率是多少，真正的杀手是那些瞬间高出正常值5倍的尖峰。
怎么治理？我的答案不是加大带宽，而是用流量整形把脉冲“削平”。在Linux服务器上，我习惯用tc命令配合令牌桶（tbf）来做这个事。具体操作不复杂，三步走：第一步，先确认网卡名字，比如eth0；第二步，清掉根上已有的qdisc规则，防止旧配置干扰；第三步，创建tbf队列，关键参数是rate、burst和latency。举个例子，如果我想把出口流量限制在平均10Mbps、突发不会超过32KB，就敲这些命令：tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 50ms。注意burst单位是字节还是bit容易搞混，我这里用的是32kbit，也就是4KB，对于普通业务来说够用。latency代表令牌桶里排队等待的最大时间，50ms比较合适，太高会明显增加延迟。
说到这，我想给你一个跟主流观点不太一样的建议：别只盯着运营商给的95计费账单，也别只看网管系统里的平均流量饼图。你得把监测维度拉到秒级，甚至毫秒级，去算峰值带宽和平均带宽的比例，我管它叫“脉冲系数”。我们公司有一个重要系统运维核心指标是“峰均比超过4:1的次数”，这个数值一旦频繁飙升，哪怕平均带宽只用了30%，我也会主动去加流量整形或调整应用的重试策略。不信你下次遇到网络卡顿，先别怪带宽小，打开抓包工具看一眼流量瞬时曲线，你就知道脉冲流量这头野兽有多猛了。