WebSocket是什么 WebSocket协议原理及工作流程详解【教程】-js教程-PHP中文网

WebSocket是基于TCP的全双工通信协议，通过HTTP握手升级建立持久连接，实现客户端与服务器间双向、低延迟、低开销实时通信。

websocket是什么 websocket协议原理及工作流程详解【教程】

WebSocket 不是 HTTP 的替代品，也不是“更高级的 AJAX”。它是一个独立的、基于 TCP 的全双工通信协议（RFC 6455），核心作用只有一条：**让浏览器和服务端之间维持一条持久、双向、低开销的数据通道**。如果你正在写实时聊天、行情推送、协同编辑或扫码登录，用 WebSocket 是对的；但如果你只是提交个表单、跳个页面，它反而会增加复杂度。

WebSocket 连接为什么必须走 HTTP 握手？

因为绝大多数企业防火墙、CDN、反向代理（如 Nginx）只认 HTTP 流量。直接裸连 TCP 端口会被拦截或重置。所以 WebSocket 设计了“升级机制”：客户端先发一个合法的 HTTP 请求，带特定头部，告诉服务器“我想换协议”，服务器确认后返回 101 Switching Protocols，之后同一 TCP 连接就切换成 WebSocket 帧协议——这个过程叫 handshake。

关键请求头必须包含：

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key（由客户端随机生成，服务端需用固定算法拼接响应）
Sec-WebSocket-Version: 13（当前唯一广泛支持的版本）

漏掉任意一项，服务端大概率拒绝升级，浏览器控制台会报 Failed to connect to WebSocket server: Error during WebSocket handshake 或类似错误。

WebSocket.onmessage 收不到数据？先检查帧类型和编码

WebSocket 数据不是裸字符串，而是按帧（frame）结构传输的。服务端发过来的如果是二进制数据（比如 ArrayBuffer、Blob），但前端用 event.data.toString() 强转，会得到乱码或空字符串；反过来，如果服务端期望接收 UTF-8 文本帧，你却用 socket.send(new Uint8Array([...])) 发二进制帧，可能被静默丢弃或触发 close 事件。

判断方式很简单：

文本消息：event.data 类型是 string
二进制消息：event.data 类型是 ArrayBuffer 或 Blob（取决于 socket.binaryType 设置）
发送前显式指定：socket.binaryType = 'arraybuffer' 或 'blob'

常见坑：socket.send(JSON.stringify(obj)) 没问题，但 socket.send(obj) 会直接报错——WebSocket 只接受 string、ArrayBuffer、Blob、ArrayBufferView 四种类型。

连接突然断开却没触发 onclose？可能是心跳或代理超时

WebSocket 连接看似“持久”，实则非常脆弱。中间任何一层（Nginx、ALB、公司防火墙、甚至某些运营商网关）都可能在空闲几秒后主动断开 TCP 连接，且不发 FIN 包。此时浏览器不会立刻感知，onclose 也不会触发，直到你下一次 send 或收到服务端心跳失败才报 onerror + onclose。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

解决方案只有两个：

服务端定期发 ping 帧（或自定义 {"type":"ping"} 消息），客户端收到后回 pong（或 {"type":"pong"}）
客户端自己定时 socket.send('') 或发保活消息，并监听超时（例如 30 秒没收到响应就 socket.close()）

Nginx 默认 proxy_read_timeout 是 60 秒，若你的业务允许空闲，务必在配置里调大，否则它会在 60 秒无数据时单方面断连。

ws:// 和 wss:// 的区别不只是加了个 S

ws:// 走明文 TCP，开发调试可以，但生产环境基本不可用：现代浏览器（Chrome/Firefox/Safari）在 HTTPS 页面中禁止新建 ws:// 连接，会直接抛 SecurityError；同时，所有中间设备都能看到传输内容。

wss:// 是 WebSocket over TLS，等价于 HTTPS 之于 HTTP。它要求服务端有有效 TLS 证书（不能是自签名），且必须监听在 443 端口（或显式指定端口如 wss://example.com:8443）。Nginx 反向代理 wss 时，需配置 proxy_pass https://backend 并透传 TLS，不能只 proxy 到 ws 后端再自己 terminate TLS——那样握手阶段就会失败。

容易忽略的一点：wss:// 的证书域名必须和 URL 中的 host 完全一致（包括子域），否则浏览器会拒绝连接，控制台显示 net::ERR_CERT_COMMON_NAME_INVALID 或类似错误。

真正难的从来不是写 new WebSocket(url)，而是理解它背后那条 TCP 连接在真实网络中如何被层层代理、超时、重置、加密。每一次 onclose 都该查三件事：服务端日志有没有 close 帧记录、Nginx access log 有没有 499/502、浏览器 Network 面板里 WebSocket 请求的 Response Headers 里有没有 101。