17370845950

确认 HTML5 原生 WebSocket 实例需同时满足：ws instanceof WebSocket 为 true、ws.url 以 'ws' 开头，且 Chrome Network 面板中协议类型显示为 WS。

WebSocket 连接成功后怎么确认是 HTML5 原生 WebSocket 实例

只要通过 new WebSocket(url) 创建的对象，就是 HTML5 原生 WebSocket —— 它和长轮询、SSE、Socket.IO 封装层有本质区别。关键看构造方式和原型链，而不是行为特征。

判断逻辑很简单：

• ws instanceof WebSocket 必须为 true
• typeof ws.send === 'function' 且 ws.url 可读（非私有属性，但现代浏览器已暴露）
• 检查 ws.constructor.name 是否等于 "WebSocket"，可排除 Socket.IO 的 Socket 实例
• 注意：某些 polyfill（如 websocket-polyfill）会覆盖全局 WebSocket，此时 instanceof 仍成立，但底层可能是 XMLHttpRequest 模拟 —— 这类不属于真正 HTML5 WebSocket

如何区分 WebSocket 和伪 WebSocket（如 Socket.IO、SSE、长轮询）

不能只看是否“实时”，得抓协议层和初始化痕迹：

• 打开 Chrome DevTools → Network → Filter 输入 ws：原生 WebSocket 显示为 WS 类型，协议为 ws:// 或 wss://；Socket.IO 初始请求是 XHR 或 POST /socket.io/?EIO=...，之后才升级为 WS
• SSE 使用 EventSource，Network 中类型为 EVENTSOURCE，响应头含 Content-Type: text/event-stream
• 长轮询没有持久连接，反复出现相同 URL 的 PENDING → 200 XHR 请求，且响应体通常是 JSON 数组或空字符串
• 用 ws.protocol 可读取子协议（如 "chat", "json"），但 Socket.IO 的 socket.protocol 是 undefined 或内部字符串

WebSocket 连接建立时的 HTML5 特征响应头识别

服务器对 WebSocket 升级请求的响应，必须包含特定 HTTP 头才能算合规 HTML5 WebSocket 握手：

立即学习“前端免费学习笔记（深入）”；

• 状态码必须是 101 Switching Protocols
• 响应头必须含：Upgrade: websocket、Connection: Upgrade
• Sec-WebSocket-Accept 是必有头，值由客户端 Sec-WebSocket-Key 经固定算法生成，不可伪造
• 若响应中出现 Access-Control-Allow-Origin: * 或对应域名，说明服务端支持跨域 —— 这是前端能直接 new WebSocket(...) 的前提之一

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

为什么 ws.readyState 不足以判断是否 HTML5 WebSocket

readyState 只反映连接状态（0–3），所有兼容 WebSocket API 的对象（包括降级 polyfill）都实现了它。真正容易被忽略的是：

• WebSocket.CLOSED 等常量在原生实现中是全局枚举值，polyfill 通常不挂载到 WebSocket 构造函数上
• 原生 WebSocket 对象不可枚举其事件处理器（如 ws.onmessage 是 getter/setter），而部分封装库直接暴露为普通属性
• 调用 ws.close(1001, "going away") 时，原生实现严格校验 code 范围（1000–4999，且不能是 1004/1005/1006 等保留值）；违规 code 会抛 SyntaxError，而封装层往往静默忽略

真要确认，最稳的方式是结合 instanceof WebSocket + ws.url.startsWith('ws') + Network 面板看协议类型 —— 三者缺一不可。