被CC攻击时如何保持websocket长连接不断开

遭遇CC攻击时，WebSocket长连接频繁掉线，根源往往不在于攻击流量本身有多大，而在于你的架构中存在几个致命的单点瓶颈。攻击者通过大量伪造的HTTP请求或半开连接，耗尽服务器文件描述符、占满TCP连接队列、拖垮反向代理的线程池，最终导致正常的WebSocket连接因心跳超时或资源不足而被强制断开。要解决这个问题，不能只靠一味地加大带宽或升级服务器配置，必须从协议层、网络层、架构层和应用层四个维度，构建一套立体化的抗CC与长连接保持机制。

大多数CC攻击工具是针对HTTP协议发起的，如果你的WebSocket服务与常规Web服务共用同一个端口（如443），攻击流量会直接冲击Nginx或Apache的worker进程。一旦worker进程被占满，WebSocket的升级请求和维持中的长连接都会受到影响。最直接的防御手段是启用独立端口。将WebSocket服务监听在非标准端口上，例如9443或8088，并在CDN或防火墙层面只对业务域名开放HTTP/HTTPS端口的访问，而WebSocket端口仅允许经过验证的客户端IP或通过内部专线连接。这样，即使攻击者对80和443端口发起大规模CC攻击，WebSocket端口依然可以保持低负载运行，长连接不会受到牵连。

如果业务必须共用443端口，那么反向代理的配置就变得至关重要。Nginx从1.3.13版本开始支持WebSocket代理，但默认配置下，攻击者可以通过发送大量非Upgrade请求来消耗连接资源。你需要严格限制只有携带特定Header的请求才能升级为WebSocket。在Nginx中，利用$http_upgrade变量判断，如果请求不包含Upgrade: websocket，直接返回444（关闭连接且不返回任何响应），这样可以在极短时间内释放资源。同时，针对WebSocket的location块，单独设置超小范围的proxy_read_timeout和proxy_connect_timeout，防止慢速攻击。对于非WebSocket请求，使用limit_req_zone和limit_conn_zone模块进行频率和并发数限制，确保攻击流量不会挤占WebSocket升级所需的资源。

CC攻击中有一类专门针对TCP三次握手的SYN Flood变种，它会制造大量半开连接，填满服务器的SYN队列。WebSocket本质上是TCP长连接，一旦服务器的SYN队列被占满，新的WebSocket连接请求就无法建立，旧的连接也可能因为网络拥塞导致心跳包丢失而被断开。你需要调整Linux内核参数来增强抗压能力。将net.ipv4.tcp_synack_retries降低到1或0，减少半开连接的重试次数。增大net.core.somaxconn和net.ipv4.tcp_max_syn_backlog的值，让服务器能够容纳更多待处理的连接请求。启用net.ipv4.tcp_syncookies等于1，在不占用SYN队列的情况下验证连接请求的合法性。最关键的是，设置net.ipv4.tcp_tw_reuse和调整timewait状态的回收速度，避免连接断开后长时间占用端口资源，导致可用端口耗尽。

很多WebSocket应用依赖服务端单点下发心跳，一旦服务端负载过高，心跳包发送延迟，客户端就会误判连接断开而主动关闭。正确的做法是将心跳机制设计为客户端主导。客户端每秒或每两秒发送一个轻量级的Ping帧，服务端仅做Pong回应。同时，客户端需要实现指数退避重连算法，在检测到连接断开后，不要所有客户端同时重连，否则会形成重连风暴，效果等同于二次攻击。每个客户端根据自身ID哈希值计算出一个随机延迟窗口，在这个窗口内随机选择重连时间点。这样即使服务端刚从攻击中恢复，也不会被瞬间涌入的重连请求再次冲垮。

不能让任意请求轻易升级为WebSocket连接。在客户端发起WebSocket连接之前，先通过一个受保护的HTTP API获取一次性令牌。这个API可以部署在独立的轻量级服务上，并加上验证码或PoW（工作量证明）机制。客户端拿到令牌后，在WebSocket握手请求的Header中携带该令牌。反向代理或应用网关在握手阶段验证令牌的有效性和唯一性，验证不通过直接断开TCP连接，连升级的机会都不给。令牌设置极短有效期，比如5秒，且使用一次后立即失效。这种机制能有效阻挡那些直接向WebSocket端点发起洪水连接的自动化攻击工具，因为它们无法预先获取合法令牌。

普通的IP频率限制在CC攻击面前效果有限，因为攻击者可能动用大量代理IP。你需要结合行为特征进行速率限制。在WebSocket连接建立后，记录每个连接在单位时间内发送的消息数、消息长度总和、无效帧数量。正常用户的聊天或数据推送行为有明显的模式，而攻击连接往往表现为高频发送固定内容或随机垃圾数据。当某个连接的行为指标偏离正常基线两个标准差时，服务端主动发送Close帧将其断开，并将该IP和Token特征加入临时黑名单。这种应用层的速率限制不会影响正常用户的长连接，但能快速清除混入的恶意连接，释放服务端资源。

如果你的WebSocket服务面向全球用户，单点源站无论怎么优化，面对大流量CC攻击时带宽都会被塞满。采用支持WebSocket的CDN或边缘计算平台，通过Anycast网络将攻击流量分散到数十个甚至上百个边缘节点。每个节点只承受总攻击流量的一小部分，节点内部再执行上述的过滤和限速策略，只把清洗后的合法WebSocket连接回源到你的核心服务器。这样源站看到的始终是低负载、高质量的长连接，攻击流量在边缘就被消化掉了。需要注意的是，选型时要确认边缘节点支持WebSocket协议的全双工通信和长连接保持，避免因为节点超时设置不当导致连接被意外中断。

WebSocket长连接最大的脆弱点在于服务端内存中维护了大量连接状态，一旦服务端进程重启或崩溃，所有连接都会丢失。为了在攻击期间保持连接不中断，你需要将连接状态外置到分布式缓存中。每次建立WebSocket连接时，生成一个唯一的Connection ID，将用户身份、订阅频道、会话上下文等状态信息序列化后存入Redis或类似的KV存储中。当服务端节点因攻击负载过高而被迫扩容或发生故障转移时，新节点可以根据客户端重连时携带的Connection ID，从缓存中恢复连接状态，实现无缝接管。客户端感知到的只是一次短暂的网络抖动，而不是连接彻底断开。

服务端做得再完善，也无法100%保证连接永远不断。客户端的重连逻辑是最后一道防线。重连不能是简单的死循环尝试，需要设计状态机。当检测到连接关闭时，首先判断关闭码，如果是1000（正常关闭）或1001（端点离开），则停止重连。如果是1006（异常关闭）或1008（策略违规），则进入重连流程。重连过程中，优先尝试连接备用域名或备用IP，避免所有客户端同时冲击同一个IP。同时，客户端应在重连成功后，重新订阅之前的所有频道，并拉取断线期间丢失的消息，确保业务数据的完整性。

以下是一段Nginx配置片段，展示了如何将WebSocket隔离、协议验证和速率限制结合起来：

# 定义WebSocket连接限制区域
limit_conn_zone $binary_remote_addr zone=ws_conn:10m;
limit_req_zone $binary_remote_addr zone=ws_req:10m rate=10r/s;

server {
    listen 443 ssl;
    server_name example.com;

    # 非WebSocket请求的通用处理
    location / {
        limit_req zone=ws_req burst=20 nodelay;
        limit_conn ws_conn 10;
        proxy_pass http://backend_web;
    }

    # WebSocket专用处理
    location /ws {
        # 仅允许包含Upgrade头的请求
        if ($http_upgrade != "websocket") {
            return 444;
        }
        
        limit_conn ws_conn 5;
        proxy_pass http://backend_ws;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        
        # 关闭缓冲，实时传输
        proxy_buffering off;
    }
}

静态的规则无法应对不断演变的攻击手法。你需要在WebSocket服务中埋入连接数、消息吞吐量、错误率、心跳延迟等关键指标的实时监控。当监控系统检测到连接数在短时间内异常飙升，或心跳延迟普遍增大时，自动触发防御策略。例如，动态提升PoW难度、缩短令牌有效期、暂时切换为仅允许白名单IP连接。这种自动化响应机制可以在攻击造成实际影响之前，将防御等级提升到与攻击强度匹配的水平，保障正常用户的长连接体验不受干扰。

保持WebSocket长连接在CC攻击下不断开，本质上是一场资源争夺战。你需要通过端口隔离、协议验证、内核调优、准入控制、行为分析、分布式架构和智能重连这七层防线，确保合法连接始终能获得所需的计算、网络和内存资源。每一层防线都针对攻击者的特定消耗手段进行反制，组合起来就能在汹涌的攻击流量中，为你的WebSocket长连接撑起一把保护伞。