摘要：# 聊聊CDN高防那点事儿：WebSocket长连接，到底怎么保？ 不知道你有没有这种体验——自家网站或者App用上了WebSocket，实时消息、在线协作爽是爽了，可一到攻击来了，心里就直打鼓。普通的CDN高防，对付HTTP短连接还行，可面对WebSo…

聊聊CDN高防那点事儿：WebSocket长连接，到底怎么保？

不知道你有没有这种体验——自家网站或者App用上了WebSocket，实时消息、在线协作爽是爽了，可一到攻击来了，心里就直打鼓。普通的CDN高防，对付HTTP短连接还行，可面对WebSocket这种“长情”的连接，很多方案直接就“露馅”了。

我自己看过不少案例，问题往往不是没上防护，而是防护策略和业务特性压根没对上。今天咱就抛开那些华丽的PPT，聊聊CDN高防在WebSocket长连接场景下，到底该怎么配，尤其是那个让人头疼的连接数限制。

WebSocket：它可不是“加强版HTTP”

首先得说清楚，WebSocket和HTTP虽然都从握手开始，但本质是两码事。HTTP是“一问一答”，说完就散；WebSocket是“握手成功，长厢厮守”，一条通道建立起来，数据可以来回跑很久。

这就带来两个核心问题：

1. 攻击成本变低了：攻击者建立一个恶意长连接，可能占着茅坑不拉屎很久，消耗你的服务器资源（内存、CPU），比HTTP洪水攻击更“持久”。
2. 传统防护容易“误伤”：很多CDN高防的默认策略是基于请求频率和短时行为分析的。一个正常的WebSocket连接可能长时间没数据流动（比如挂机的用户），在高防眼里，这可能就成了“可疑连接”，给你误判了。

说白了，很多宣称能防WebSocket的高防，只是能透传WebSocket协议，但防护策略还是HTTP那一套。真遇到针对性的CC攻击，照样扛不住。

CDN高防的“组合拳”：不只是转发那么简单

那专业的方案该是啥样？我觉着，得从连接建立、连接维持、连接释放这三个阶段来看。

连接建立阶段（握手期） 这是第一道关卡。好的高防会在这里做严格校验：

• 协议合规性检查：是不是标准的WebSocket握手请求？头字段对不对？很多低级的攻击脚本在这里就能被过滤掉。
• 频率与源验证：单个IP在短时间内尝试建立大量WebSocket连接？这明显不对劲。结合人机验证（如JS Challenge）或者源IP信誉库，能把大部分“脚本小子”挡在门外。
• 我见过一个配置，把握手阶段的超时时间调得特别短，非正常客户端根本完不成握手。虽然有点激进，但对特定业务挺有效。

连接维持阶段（数据传输期） 握手成功了，不代表就能高枕无忧。这才是防护的核心。

• 心跳包监测：这是关键！高防节点可以（也应该）介入心跳机制。如果一条连接长时间（比如超过几分钟）没有任何合法的心跳包或业务数据，高防可以主动掐断它，释放后端资源。这能有效清理死连接和部分攻击连接。
• 数据帧检测：WebSocket传输的是数据帧。高防可以深度检测帧内容，过滤明显的恶意代码或攻击载荷（比如大量重复的垃圾消息）。当然，这需要一定的计算资源。
• 速率限制：不光针对建立速度，也针对单连接的数据发送速率。一个正常用户每秒发几条消息？如果一个连接突然以每秒几百条的速度狂发数据，那肯定有问题。

连接释放阶段 优雅地关闭连接，及时回收资源。高防需要正确传递关闭帧，避免给源站留下半开连接（Half-Open Connections），这也是DDoS攻击常利用的点。

连接数限制：那个最让人纠结的“阀门”

好了，来到最核心的问题——连接数限制。这玩意儿配不好，不是把用户挡在外面，就是让服务器被拖垮。

1. 为什么必须限制？ 道理很简单，资源是有限的。每个长连接在服务器（或高防节点）上都要占用内存、文件描述符等资源。不加限制，攻击者用低成本就能建立海量连接，直接撑爆你的服务。这可比打流量容易多了。

2. 限制策略怎么定？这才是体现功夫的地方

• 全局总连接数：这是最后底线。根据服务器或高防集群的承载能力设个上限。但光有这个太粗糙。
• 单IP连接数：这是最常用也最有效的策略之一。一个正常用户会有几个WebSocket连接？通常就1个。给单个IP设置一个合理的上限（比如5-10个），能极大增加攻击者的成本。但要注意，别误伤公司、学校这种共用出口IP的场景。
• 基于业务ID/用户会话的限制：更精细的做法。在握手阶段，通过Cookie或Token识别出用户身份，然后针对每个用户ID限制其最大连接数。这样，即使同一个IP，不同用户也会被区别对待。当然，实现起来复杂点。
• 分层分级限制：我推荐这种组合拳。比如：单IP默认限10个连接；已验证的登录用户，其用户ID限3个连接；同时，全局总连接数不超过10万。这样层层过滤，既安全又灵活。

3. 限制之后怎么办？ 限制不是目的，保障正常业务才是。触达限制后的处理策略很重要：

• 优雅拒绝：给新连接发送一个合理的错误帧（如1008、1011），并记录日志，而不是粗暴地断网。
• 排队与等待：对于某些高价值业务，可以考虑让新连接排队，等待其他连接释放后再接入。
• 动态调整：监控系统应该能实时观察连接数趋势。在业务高峰（比如活动发布）时，能否自动或手动临时放宽策略？这需要高防服务提供灵活的API或控制台。

几个“接地气”的配置建议

理论说完了，来点干的。如果你正在配，可以看看这几条：

• 千万别用默认配置：很多高防产品的WebSocket默认配置是“放行”，防护强度很低。务必根据业务压力测试结果，调整握手检查、心跳超时和连接数限制。
• 心跳包是关键钥匙：务必在高防层面开启并配置合理的心跳超时（比如60-120秒）。这是清除僵尸连接最有效的手段，没有之一。
• 连接数限制从小开始：先设置一个保守的数值（比如单IP限5个），观察业务日志和用户反馈，再逐步调整。宁紧勿松。
• 源站一定要“藏好”：WebSocket高防生效的前提，是流量必须都从高防过。确保你的WebSocket服务端（源站）只接受来自高防节点IP的连接，把真实IP捂严实了。很多被打穿的情况，都是源站IP泄露，攻击者绕过高防直接打源。
• 监控和告警要跟上：重点关注“新建连接速率”、“活跃连接数”、“心跳超时断开数”这几个指标。设置告警，异常波动时能第一时间知道。

最后的大实话

说到底，没有一劳永逸的“银弹”。CDN高防对WebSocket的防护，是一个动态调整的过程。它考验的不是产品功能列表有多长，而是运维人员对业务的理解有多深。

最怕的就是那种——上了最贵的高防，所有配置却用的默认值。真被打的时候，除了看着带宽图表飙升，一点办法都没有。防护方案，合适比贵重要，精细比齐全重要。

你的WebSocket服务，现在是怎么配的？心里有谱了吗？