WebSocket 无HTML5全局数量限制，实际受限于浏览器（同域6～10个）、操作系统（ulimit文件描述符）和服务端准入策略；防DDoS需分层验证、连接限流、空闲清理及边缘过滤。
WebSocket 连接本身没有 HTML5 规范强制的全局数量限制，但实际限制由浏览器、操作系统和服务器共同决定；防 DDoS 的关键不在于“堵连接数”，而在于建立分层验证与资源节制机制。
浏览器与系统层面的实际连接上限
现代浏览器对同一域名（含子域）的并发 WebSocket 连接数通常限制在 6～10 个（Chrome/Firefox 类似 HTTP/1.1 的连接池限制），超出会排队或直接失败。这个限制不可通过前端代码绕过，且不区分 WebSocket 或普通 HTTP 请求。操作系统层面（如 Linux 的 ulimit -n）还约束进程级文件描述符总数，每个 WebSocket 连接占用一个 socket 句柄，达到上限后新连接会被内核拒绝（报错 EMFILE）。
- 开发时可通过 chrome://net-internals/#sockets 查看当前 Chrome 的 socket 使用情况
- 服务端启动前应检查并合理设置 ulimit -n 65536 等值，避免被默认 1024 卡住
- 不要依赖前端控制连接数量——用户可禁用 JS、改写代码或使用 curl/ws 工具直连
服务端必须实施的准入控制策略
真正有效的 DDoS 防御发生在服务端入口：仅靠前端限频或简单 token 校验远远不够。需组合使用连接生命周期管理、上下文验证与速率熔断。
- 握手阶段强校验：在 Upgrade 请求中检查 Origin、Referer（非绝对可靠但有参考价值）、自定义 header（如预签发的短期 JWT）；拒绝无有效凭证或来源异常的升级请求
- 连接即限流：为每个新连接分配独立的滑动窗口计数器（如每秒最多 5 条消息），超限则静默关闭或发送错误帧；避免共享计数器导致误杀
- 空闲连接自动清理：设置 ping/pong 超时（建议 30～45 秒），未响应者立即断开；防止攻击者建大量“僵尸连接”耗尽内存
利用反向代理与边缘层做前置过滤
Nginx、Cloudflare 或 API 网关等边缘组件能承担部分清洗压力，减轻应用服务器负担。
- Nginx 可配置 limit_conn 按 IP 或 key 限制并发 WebSocket 连接数（需配合 map 提取真实客户端 IP）
- 启用 Websocket subprotocol 检查，只允许已知协议名（如 "json-v1"），非法 protocol 字段直接 400 拒绝
- 在 CDN 层开启 Bot Management 或自定义 WAF 规则，拦截已知恶意 User-Agent、高频短连接模式或 TLS 指纹异常流量
监控与弹性响应不能缺位
防御不是静态配置，而是持续观测 + 快速反馈的过程。没有告警的限流等于摆设。
- 实时采集指标：每秒新建连接数、平均连接时长、消息吞吐量、异常关闭率（特别是 1008/1011 错误码）
- 设置动态水位线：当连接数突增 300% 且 70% 连接存活时间
- 保留最近 1 小时原始访问日志（至少含 IP、时间、Upgrade 头、响应状态），便于事后溯源攻击特征
不复杂但容易忽略：真正的瓶颈往往不在协议本身，而在连接背后的身份识别粒度、资源绑定逻辑和响应退避策略。WebSocket 是双工通道，也是双刃剑——设计之初就要把它当作“可被滥用的持久入口”来对待。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
