端口级限速与全局限速在防护中的取舍权衡
端口级限速和全局限速没有绝对的优劣之分，核心取舍在于你是要“保业务稳定”还是“保单点服务不被打垮”，大多数场景下需要两者配合使用，而非二选一。理解它们的原理和代价,才能在攻击到来时做出正确决策。
限速的本质：用“丢弃”换“存活”
无论端口级限速还是全局限速，本质上都是主动丢弃一部分数据包，很多运维人员第一次配置限速时会有误解，以为限速是“让流量变慢”，其实不是，限速是“超出的部分直接扔”，让服务器从“全部处理不过来”变成“处理一部分，扔掉另一部分”,从而保证核心服务不整体瘫痪。
行业共识认为，在DDoS攻击和突发流量面前，没有任何设备能无上限地处理数据包,限速是最后一道防线。
端口级限速：精准打击，但要懂代价
端口级限速是指针对特定端口（比如TCP 443或UDP 53）设置带宽上限或包处理速率上限，它的最大优势是定位精准攻击者只打某个端口时，把这个端口的流量限制住,其他端口的正常业务完全不受影响。
端口级限速的适用场景
- 攻击流量集中在单一端口，比如游戏服务器被人打了TCP 443端口
- 业务端口之间有明显的优先级差异，需要确保高价值端口不被低价值端口拖累
- 多业务共用一个IP，每个业务走的端口不同，需要隔离相互影响
端口级限速的致命弱点
如果攻击流量同时打多个端口，或者攻击者换着端口打，端口级限速就会疲于奔命。 你限了443端口，攻击流量马上转向80端口；你限了80端口，它又去打8080端口，逐个端口去配置规则,往往跟不上攻击节奏。
端口级限速的另一个问题是配置复杂度会随端口数量线性增长，维护一套防火墙规则，每加一个端口就要同步更新，规则多了之后误配置的概率也会上升，如果某个端口的业务本身就跑得比较慢，限速阈值设置得不合理,反而会误伤正常用户。
全局限速：全局保命，但会殃及无辜
全局限速是指对整个IP、整个网卡或整个主机设置总带宽上限或总包处理速率上限，它的核心价值是保底无论攻击怎么打、打哪里，总流量被限定在安全范围内,设备不会因为过载而彻底宕机。
全局限速的典型使用场景
- 服务器被SYN Flood攻击，攻击流量分散在很多随机端口
- IDC机房整体带宽被打满，所有用户的上网体验都在恶化
- 服务器同时承载多个业务，某个业务被攻击时需要确保其他业务还能勉强运行
全局限速的最大问题
正常流量会被误伤。 全局限速只看总量，不区分哪个端口需要优先级，如果大促期间正常业务流量本身就很高，全局限速的阈值设置过低，用户会发现网页加载缓慢、接口超时这和被攻击的体验几乎一样。
全局限速对包处理速率（PPS）的限制尤其要小心，现代硬件的瓶颈往往不在带宽而在包转发率，小包攻击能用很小的带宽就打满CPU，设置全局限速时，需要同时关注带宽（Mbps）和包速率（pps）,两个维度都要限制。
端口级限速与DDoS攻击的攻防关系
在遭遇大流量DDoS攻击时，两种限速策略的表现差异非常明显，大流量攻击的特征是流量巨大且来源分散，攻击目标可能是固定端口,也可能扫端口。
- 如果攻击流量集中在固定端口，端口级限速能把伤害控制在小范围内，业务主流程保持可用
- 如果攻击流量分散，端口级限速就需要配合全局限速一起使用，先全局兜底，再端口细分处理
真实案例中，相当一部分攻击会首先探测服务器的开放端口，找到薄弱点后再集中火力，如果只配置端口限速，攻击流量变化后就等于裸奔；如果只配置全局限速，哪怕只有某一个端口被攻击,所有端口都会一起遭殃。
如何选择：从业务视角做取舍
要决定优先配置哪种限速,需要先回答以下几个问题：
判断攻击面是否集中
统计观察历史攻击中被打的端口分布。多数情况下，攻击者会盯着最常暴露的端口打，比如Web业务的80/443端口，如果你的业务端口单一，端口级限速的性价比很高；如果业务端口杂乱无章,全局限速更容易管理。
判断业务可容忍的崩溃区间
不同业务对“局部不可用”和“全部不可用”的容忍度完全不同，电商大促期间，全局瘫痪的损失远远大于牺牲个把端口；而一个跑在单独端口上的关键API接口，宁可其他端口全挂,也要保住这个接口的可用性。
判断机房冗余能力
如果你有多个IP或多个机房，可以灵活调度，全局限速配合DNS切换的收益更高，如果只有单机单IP,端口级限速是最后的保命手段。
实操配置：两张限速策略的落地示例
在Linux服务器上，常见的限速工具是iptables和tc，iptables用于包速率的限制,tc用于带宽的限制。
端口级限速示例
：限制目标端口为80的入站包速率
iptables -A INPUT -p tcp --dport 80 -m limit --limit 2000/s --limit-burst 5000 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP这条规则的意思是，每秒放行2000个新的TCP包，突发流量最多放行5000个，超出部分全部丢弃，注意这只能限制新建连接,对已建立的连接不生效。
全局限速示例：限制整个网卡的入站带宽为100Mbps
tc qdisc add dev eth0 handle 1: root htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit这个命令把eth0的带宽限制在100Mbps，超过部分会排队或丢弃,具体取决于队列策略。
组合使用示例：先限制全局总带宽，再对80端口额外加一道限制
# 全局限制200Mbps
tc class add dev eth0 parent 1: classid 1:1 htb rate 200mbit
# 对80端口的流量进一步限制在50Mbps
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport 80 flowid 1:20这种配置下，如果攻击80端口，总流量会被压到50Mbps以内；如果攻击随机端口,全局限速保证总流量不超过200Mbps。
限速之外：还需要做什么
限速只是防护的最后一环，不能把宝全部押在限速上，实际运维中，需要关注机房接入层的防护能力，许多成规模的IDC机房和云厂商都提供流量清洗服务，在流量进入机房之前就过滤掉攻击流量，据工信部数据,近年来基础电信企业的骨干网清洗能力已有明显提升。
在购买带宽或云服务器时，需要关注机房是否支持“弹性防护”和“黑洞触发阈值”，当流量超过阈值时会触发黑洞，将所有流量全部丢弃，这比任何限速手段都更极端，但有时也是无奈之选总比整台服务器被拖垮要好。
动态调整比固定的规则更重要
限速规则不能设一次就放着不管，正常情况下业务流量的波动、业务迁移、机房网络调整等都会影响限速策略的合理性。需要定期回看防火墙日志和流量监控图，发现限速误伤时及时调高阈值，发现被穿透时及时收紧策略。
简米云、酷番云等云服务商的控制台上都有安全组和DDoS高防的图形化配置，可以动态调整限速策略，比起命令行操作更直观,也能更快响应攻击变化。
常见限速配置失误与排查方向
- 限速阈值设置低于正常流量峰值：大多数情况是只看了平均值没有看峰值，正常业务瞬间冲击会触碰限速，导致用户访问异常，排查方法是对比监控曲线,看限速触发时是否伴随业务高峰。
-
只限制带宽不限PPS
：小包攻击可以打满CPU，造成服务器假死，实际上带宽占用并不高，排查方法是查看网卡PPS指标，正常情况下PPS与业务并发成正比,异常激增时说明有问题。 - iptables规则顺序错误：规则从上到下匹配，如果ACCEPT规则放在DROP规则之后，就永远不会生效,排查方法是逐条检查规则顺序。
- 忘了限制回程流量：某些攻击的响应流量比请求流量更大，比如UDP反射放大攻击，如果没有对出方向做限速，把出口带宽打满,同样会导致服务不可用。
- 本地限速与机房黑洞阈值冲突：本地限速设置得太低时，机房的防护设备还没触发清洗，本地就已经丢弃了大量正常流量；设置得太高则可能还没到限速上限就被黑洞了,需要同时参考机房的防护参数来定。
Q&A：端口级限速与全局限速常见疑问解答
问：如果突然被大流量攻击，先设置端口限速还是全局限速？
先临时设置一个全局限速兜底，避免服务器直接宕机，然后观察攻击日志判断流量集中在哪些端口，再精准配置端口级限速，如果一开始就配置端口限速，攻击流量一变就失去作用了，等攻击结束后,再把全局限速的阈值调回正常值。
问：服务器同时跑着Web服务和游戏服务，端口级限速怎么分配才合理？
按业务价值和流量占比分配，如果Web服务是面向客户的核心收入来源，端口443的限速阈值就要设得比游戏端口高；如果游戏服务在线人数更多，则相反，建议按平时业务峰值的2到1.5倍来设带宽阈值，留出一定的缓冲空间，注意观察两个端口的流量是否有交叉高峰，如果有，端口级限速只是物理隔离,总量上还需要全局限速来约束。
问到全局限速和防火墙的黑洞机制有什么区别？
黑洞是更极端的全局丢弃，通常由机房或ISP触发，一旦进入黑洞状态，所有入站流量全部丢弃，相当于服务器从互联网上消失，而全局限速是本地可控的，只限制吞吐量，服务器本身还能处理其他请求，黑洞一般在流量超过机房设定的阈值时自动触发，时间短则半小时长则数小时，如果你的业务对可用性要求高，全局限速上限要主动设置得比机房黑洞阈值低，尽量避免触发黑洞。本地限速是主动防御，黑洞是被动挨打。
最终一句话：端口级限速管“精度”，全局限速管“生死”，顺序上先保命再谈精度，动态调整才是王道。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/636884.html
