摘要：# 当CC攻击盯上你的WebSocket：一场悄无声息的“对话”劫持 我前两天刚翻过一个游戏站点的日志，那场面，真绝了。 凌晨三点，用户量本该平稳，但服务器CPU直接飙到100%。运维兄弟一开始以为是代码bug，查了半天，最后在WebSocket连接池…

当CC攻击盯上你的WebSocket：一场悄无声息的“对话”劫持

我前两天刚翻过一个游戏站点的日志，那场面，真绝了。

凌晨三点，用户量本该平稳，但服务器CPU直接飙到100%。运维兄弟一开始以为是代码bug，查了半天，最后在WebSocket连接池里发现了问题——十几万个“僵尸”连接挂在那里，不说话，不干活，就干耗着。说白了，这就是CC攻击（Challenge Collapsar，挑战黑洞）玩出了新花样，它不冲你HTTP页面了，它开始跟你“建立长连接”了。

这种感觉你懂吧？就像你家门铃（HTTP请求）没人乱按了，但突然多了几百个人一声不吭地挤在你家客厅（WebSocket连接）里，占着沙发，开着电视，让你真正的客人进不来。

WebSocket：为什么它成了新的“软肋”？

首先得说句大实话，很多团队上WebSocket，光想着它的好了——全双工、低延迟、实时推送，做聊天、游戏、实时数据大屏简直不要太爽。但问题往往不是技术不好，而是配错了防护思路。

传统的HTTP防护，像高防IP、WAF，盯着的是一个个独立的请求。你来一个请求，我验一个。但WebSocket不一样，它一旦握手成功，就建立起一条长期的、双向的通信通道。攻击者就钻这个空子：

1. 低成本建立连接：用脚本疯狂发起WebSocket握手请求（HTTP Upgrade）。这些请求本身可能完全合法，你的服务器得一个个响应，分配资源（内存、文件描述符）。
2. 连接挂起不释放：建立连接后，不发或极少发应用层数据，就让连接空转。一个这样的连接消耗不大，但十万个呢？连接池瞬间被占满，新用户连不上。
3. 慢速攻击变种：建立连接后，以极低的速度（比如每分钟一个字节）发送数据，保持连接活性，避免被超时清理，但持续消耗你的处理线程。

（我自己看过不少案例，问题根源就在这里——还用防HTTP那套规则去套WebSocket，能不漏风吗？）

攻击来了，你的业务会怎样？——不是卡，是“假死”

很多所谓防护方案，PPT很猛，真被打的时候就露馅了。CC攻击打WebSocket，症状很“阴”：

• 新用户连不上，老用户感觉卡：因为连接资源被占满，新握手请求直接被拒绝。已经在线的用户，由于服务器资源枯竭，消息推送延迟飙升。
• 服务器指标“看起来正常”：网络流量可能不大（因为没真数据传输），但CPU、内存，尤其是连接数这个指标，会爆表。在三里屯某咖啡店和运维朋友聊，他原话是：“流量没爆，但服务瘫了，老板还以为我在摸鱼。”
• 最难搞的是“混合攻击”：攻击者用少量流量CC你的WebSocket，让你核心实时功能瘫痪，同时用HTTP流量打你官网，形成多点打击。这种场景你应该不陌生吧？

那怎么办？——防护思路得换换

如果你的WebSocket服务还裸奔，或者只靠台前的Nginx限个流，你心里其实已经有答案了。防护得从“对话机制”本身入手。

1. 握手层：把好第一道门（别什么人都让进客厅）

这是最关键的一步。在TCP握手之后，HTTP Upgrade握手之前，就得设卡。

• 人机验证（Captcha）前置：对于来自异常IP或高频发起握手请求的客户端，在WebSocket握手前，先弹出一个简单的验证码。真正的用户多一步操作，但机器人脚本就卡住了。很多高防服务商现在都提供这种“协议级验证”能力。
• 强化握手验证：别只用默认的Sec-WebSocket-Key。可以在握手请求里加入自定义的、有时效性的Token，在业务后端验证，无效的直接拒绝。
• 源站隐藏是基础：别让你的WebSocket服务器（比如ws://your-domain.com:8080）直接暴露在公网。通过高防IP/高防CDN来代理，所有连接先经过清洗中心。攻击者打不到你真实IP，连接的建立与维持都由高防节点先扛一波。

2. 连接层：管理好客厅里的“客人”

连接建立后，不能放任不管。

• 设置严格的连接超时：如果连接建立后，在N秒内未收到任何合法的业务帧（比如身份认证包），强制断开。别让“哑巴连接”长期挂起。
• 实施心跳机制与活性检查：要求客户端定期发送心跳包（Ping）。服务端也主动发Ping，如果对方不应答（Pong），视为死连接，清理掉。心跳超时时间要设得比攻击者的“慢速发送”间隔更短。
• 连接数限制：基于IP、或用户ID，实施严格的连接数限制。一个正常用户，同时保持1-2个WebSocket连接顶天了。如果一个IP瞬间上来几十个连接，直接封禁。

3. 业务层：识别谁在“说废话”

到了应用层，防护就更细了。

• 快速业务认证：连接建立后，第一个数据包必须是登录或身份认证。未认证的连接，其消息队列优先级放到最低，甚至直接丢弃。
• 消息速率限制（Rate Limiting）：对每个连接，限制其发送消息的频率。比如，正常聊天用户一秒发几条消息顶天了，如果检测到某个连接每秒狂发上百条空消息或无效消息，直接踢掉。
• 协议合规性校验：严格检查WebSocket数据帧的格式。很多攻击工具生成的帧格式并不完全合规，可以借此识别并拦截。

方案组合：别指望一个银弹

说白了，没有一劳永逸的方案。你需要的是一个组合拳：

1. 前端：实现健全的重连和降级机制。万一WebSocket被攻击打瘫，能不能自动降级到HTTP长轮询？给用户留条后路。
2. 接入层（高防/代理）：负责握手验证、IP限速、连接数限制这些粗活累活，把大部分垃圾流量挡在外面。
3. 业务服务层：做好心跳管理、业务认证、消息速率控制，这是最后的、也是最精准的防线。
4. 监控与告警：别只监控流量和CPU。把 “WebSocket活跃连接数”、“异常握手请求数”、“未认证连接存活时长” 这些指标放到大屏上，设置智能告警。发现连接数曲线突然陡增，别犹豫，立刻拉响警报。

行了，不废话了。

最后再吐槽一句：很多团队把实时功能上线就当完工了，防护方案永远是“下次迭代再说”。真等攻击来了，就不是迭代，而是熬夜救火和写事故报告了。你的WebSocket对话通道，是时候安排几个靠谱的“保安”了。