最近协议层DoS又冒出新玩法。HTTP/2 Bomb这种攻击不用海量僵尸网络砸流量，一台普通电脑、百兆带宽就能在十几二十秒内把目标服务器内存顶到几十GB，直接拖垮服务。攻击者先往HPACK动态表里塞一个几乎空的头，然后用一字节索引反复引用，服务器端每引用一次就得分配一整块结构内存；紧接着把流控窗口设成零，再一点点喂WINDOW_UPDATE，把内存死死钉住不释放。结果是进程内存暴涨，swap起来，其他请求全变慢甚至OOM。

这和大家熟悉的Tbps级洪泛完全两码事。传统体积攻击拼的是带宽和清洗中心容量，而这类协议攻击拼的是实现细节和资源记账。默认配置的nginx、Apache httpd、IIS、Envoy等主流服务器都中招过，单连接就能把Apache或Envoy顶到32GB级别。补丁陆续出来了，nginx加了max_headers，Apache也修了cookie拆分计数，但没升级或没加限制的源站依然暴露。更麻烦的是，很多站点开了HTTP/2却没在边缘做严格头字段数量和流生命周期控制。

看看实际场景。今年6月印度CBSE重评门户上线当天就遭短时DoS，两分钟内1.5百万次命中，第二天又记到近380万恶意包。系统撑住了，但并发用户高峰叠加攻击，任何协议层漏洞都会被放大。教育、考试、报名这类短窗口高并发门户，攻击者最爱挑这个时候下手——合法流量本身就高，异常帧混进去更难一眼看穿。类似短时突袭在体育博彩、应急通知、天气服务上也出现过，几分钟就结束，传统告警还没反应过来。

高防边缘这时候价值就出来了。单纯源站加补丁、关HTTP/2是应急，但生产环境长期靠这个不现实，性能和兼容性都受影响。正确做法是把HTTP/2终止点前移到边缘。高防CDN或高防服务器在接入层就完成协议解析，强制限制每请求头字段数量（包括cookie碎片）、并发流数、单流存活时间，哪怕攻击者一直喂WINDOW_UPDATE也直接切断。异常HPACK模式、密集小头引用、零窗口拖住，这些都能在边缘用规则或行为模型拦掉，根本不让脏连接打到源站。

实操上分几步走。先摸清家底：扫一遍公网服务，哪些开了h2、跑的是哪版软件、有没有反向代理。能打补丁的立刻升，nginx 1.29.8+、对应mod_http2版本优先。升不了的，临时在监听上关掉HTTP/2，或者前面挂一层已经做好限制的代理。部署高防CDN时，重点检查是否支持细粒度协议约束——头数量上限、流控超时、内存压力联动限流。基石云这类高防服务就是把清洗和协议检查放在边缘节点，正常业务走加速，异常帧直接丢，源站只看到干净流量。

监控别只看带宽和QPS。盯进程RSS、swap使用率、worker内存曲线。一旦某个worker内存陡升又不掉，优先怀疑被钉住的流。可以给容器或进程加cgroup内存上限，让被炸的worker早点被OOM杀掉重启，总比整机卡死好。日志里抓HTTP/2帧异常、超高头计数、长时间半开流，喂给简单规则或自建检测。有人自己搞了从access log抽可疑探针、集中更新IP/ASN黑名单的小系统，每分钟同步到各节点，配合nginx ban，对付刮擦和低频DoS挺管用。高防侧再加一层全局情报和自动封禁，效果更稳。

常见误区不少。一是觉得“我有CDN就万事大吉”，其实如果CDN只做体积清洗、不严格管HTTP/2帧和头，攻击照样能穿透到源。二是只测大流量，不测低带宽协议攻击——很多团队红队只砸SYN或UDP flood，真正上线才发现内存炸弹。三是补丁打了却忘了配置上限，或者cookie拆分没计入字段限制。四是高峰期临时关防护，结果攻击正好撞上。

多层才是正经路子。网络层清洗大流量，应用层看行为速率和异常序列，协议层卡头和流。高防服务器或CDN把这几层叠在一起，边缘智能一点，能自动识别短时复合向量。rockcloud在这块做的是通用高防能力：边缘终止、实时策略下发、源站隐藏，适合考试门户、API网关、业务高峰站点。部署时记得开严格模式，定期用模拟低带宽攻击验证，别等出事再调。

协议攻击门槛低了，AI还能帮忙组合老技巧成新链。以后类似“小流量大破坏”的玩意只会更多。与其被动等补丁，不如主动把防御前移到边缘，把资源记账和流生命周期管死。日常多演练短时突袭场景，内存和协议指标一起盯，出问题也能秒级切。高防不是摆设，用对了才能在真实攻击窗口里真正扛住。