sec-websocket-protocol 是 websocket 官方定义的子协议协商字段，可安全传递短期 token 实现握手阶段鉴权；其值仅支持 ascii 字母、数字、短横线和点，需服务端在握手时解析校验，避免 onopen 后鉴权导致资源滥用。
WebSocket 的子协议和身份认证是两个独立但可协同使用的机制。子协议本身不负责鉴权，但它可以作为传递认证信息的“通道”，尤其在标准浏览器环境下无法自定义 Authorization 请求头时，是一种被广泛验证的变通方案。
子协议（Sec-WebSocket-Protocol）不是认证手段，但能安全传 Token
WebSocket 握手阶段支持 Sec-WebSocket-Protocol 头，用于协商通信语义（如 chat-v2、json-rpc）。这个字段本意是协议协商，但因其可由客户端自由指定、服务端可读取、且不会像 URL 参数那样明文暴露在日志或开发者工具地址栏中，所以常被借用来携带短期 token：
- 客户端创建连接时，把 token 嵌入子协议字符串，例如：
const ws = new WebSocket('wss://api.example.com/ws', ['Bearer eyJhbG...']); - 服务端（如 Node.js +
ws库）在connection事件中获取：const protocol = req.headers['sec-websocket-protocol'];
再提取并校验 Bearer 后的 token - 相比 URL 传参，这种方式更隐蔽：Nginx access_log、浏览器网络面板通常不记录该 header，代理层也较少默认透传或落盘
身份认证必须在握手完成前完成，不能靠 onopen 后发消息
WebSocket 协议升级一旦成功，连接即建立。此时服务端已无法拒绝该连接，也无法中断已打开的通道。因此任何“先连上、再发 auth 消息”的做法都存在安全缺口：
- 恶意用户可跳过 auth 消息，直接发送业务帧（如订阅私有频道、调用删除接口）
- 未鉴权连接会提前占用服务端 socket 资源，构成 DoS 风险
- CDN、WAF、反向代理等中间件只参与握手阶段，不解析后续 WebSocket 帧内容，无法补救
推荐组合：子协议传短期 Token + 服务端即时绑定用户上下文
真正落地时，需前后端配合形成闭环：
- 前端从 localStorage 或内存中取出有效期 ≤5 分钟的临时 token（非登录态 JWT），拼入子协议数组
- 服务端解析
Sec-WebSocket-Protocol，用jsonwebtoken校验签名、过期时间、用户 ID 和绑定信息（如 IP 或 UserAgent） - 验证通过后，立即将用户 ID、角色、权限等挂载到 socket 实例上，例如：
socket.userId = payload.userId;socket.role = payload.role; - 后续所有消息处理，都基于该 socket 实例上的属性做权限判断，而非重新查库或解析消息
其他可行路径及适用场景
除子协议外，还有几种方式可选，取决于你的部署环境：
- URL 查询参数：最简单，兼容性最好，适合内网系统或调试阶段；生产环境必须搭配短期、一次性、带绑定信息的 token
-
反向代理注入：前端用干净 URL 连接，Nginx/Traefik 根据 Cookie 或上游 Header 注入
Authorization，后端从 upgrade request 中读取；适合已有成熟鉴权体系的团队 -
预检 handshake 接口：先发一个带
Authorization头的 HTTP 请求（如POST /ws/handshake），服务端返回一个加密的 handshake token，再用它创建 WebSocket 连接；适合对安全性要求极高、且能接受多一次 RTT 的场景
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
