出口带宽限速那些事儿：从踩坑到优雅部署的实战指南

大家好，我是33blog的运维老司机。今天想和大家聊聊出口带宽限速这个看似简单实则暗藏玄机的话题。上周我们机房就因为这个踩了个大坑，差点被业务部门集体投诉。所以决定把这次经验教训整理出来，分享几个你可能不知道的限速策略部署技巧。

1. 为什么单纯的TC限速会翻车？

最开始我们直接用经典的TC命令做限速：

tc qdisc add dev eth0 root tbf rate 100mbit burst 100kb latency 50ms

看起来完美对吧？结果业务高峰期时，监控显示实际带宽只有80Mbps左右。后来发现是因为没考虑协议开销！TCP/IP头部、帧间隙这些都会占用带宽。我的经验是：实际限速值要比标称值高15%左右，比如要限100Mbps，应该设置115Mbps。

2. 多租户环境下的智能限速方案

当有多个业务共享出口时，简单的全局限速就是灾难。我们改用HTB（Hierarchical Token Bucket）实现了动态分配：

tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 300mbit ceil 500mbit  # 高优先级业务
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 200mbit ceil 300mbit  # 普通业务

这个方案妙在ceil参数允许突发，既保证了公平性，又充分利用了带宽。部署后业务投诉直接降为零。

3. 容易被忽略的DNS限速陷阱

有一次限速后CDN性能暴跌，排查半天才发现是DNS查询被误限了！解决方案是给DNS流量打标记：

iptables -t mangle -A OUTPUT -p udp --dport 53 -j MARK --set-mark 0x1
tc filter add dev eth0 parent 1: protocol ip handle 1 fw flowid 1:30

单独给DNS分配5%的保障带宽后，CDN响应时间立即恢复正常。这个小技巧救了我们很多次。

4. 云环境下的限速新思路

在AWS/GCP上，传统的TC可能和虚拟网卡驱动冲突。我们改用云厂商自带的限速API反而更稳定。比如AWS的Network ACL规则：

{
  "NetworkAclEntries": [
    {
      "RuleNumber": 100,
      "Protocol": "-1",
      "RuleAction": "allow", 
      "Egress": true,
      "CidrBlock": "0.0.0.0/0",
      "PortRange": {"From": 0, "To": 65535},
      "TrafficLimit": 100000000  // 100Mbps
    }
  ]
}

虽然精度不如TC，但在云环境下反而更可靠，不会出现莫名其妙的丢包。

5. 监控比限速本身更重要

最后分享一个血泪教训：没有监控的限速就是在裸奔。我们现在用Prometheus+Granafa实时监控：

• TC分类流量统计
• 丢包/延迟指标
• 业务关键指标联动报警

当限速影响业务时，10秒内就能收到报警，比用户投诉快多了。

限速看似简单，但要做得优雅真的需要不断踩坑。如果你们也有什么独门技巧，欢迎在评论区交流！下次我会分享如何用eBPF实现更精细的流量控制，敬请期待~