javascript WebSocket怎么用_它与HTTP在实时通信上有什么优劣？_技术教程

WebSocket适合实时通信因其双向低延迟、省带宽、状态可控；HTTP为文档获取设计，单向且高开销；使用需注意兼容性、代理拦截、服务端成本及手动实现重连等。

WebSocket 在 JavaScript 中用起来很直接，但关键在于理解它和 HTTP 的本质差异——不是“怎么写代码”，而是“什么时候该换通信方式”。它解决的不是功能问题，而是实时性、资源消耗和交互模型的问题。

创建连接、监听事件、发送数据，三步就能跑通：

建立连接：用 new WebSocket(url, protocols)，url 是 ws:// 或加密的 wss://，protocols 可选（比如 'chat'），用于服务端协商子协议。
监听核心事件：
- onopen：握手成功，可开始发消息；
- onmessage：收到服务器推送的数据，event.data 是字符串或 ArrayBuffer；
- onclose：连接关闭，event.code 和 event.reason 可查原因；
- onerror：出错时触发（注意：它不提供具体错误信息，需结合日志或网络面板排查）。
发送与关闭：
- 发送文本：直接 socket.send('hello')；复杂结构先 JSON.stringify()；
- 发送二进制：用 ArrayBuffer 或 Blob；
- 主动断开：socket.close(code, reason)，code 一般用 1000（正常关闭）。

它不是“比 HTTP 快一点”，而是彻底改变了通信逻辑：

真正双向、低延迟：连接建立后，服务器无需等请求，随时能推数据（如聊天新消息、股价跳动）；HTTP 每次都要客户端发起请求，哪怕只差 100ms，累积起来就是卡顿感。
省带宽、减负载：一次握手后复用 TCP 连接，没有 HTTP 头部（几十字节）、无 Cookie、无状态重传；轮询场景下，1 秒一次 HTTP 请求，90% 流量都在传重复头部。
连接状态可控：通过 readyState（0=connecting, 1=open, 2=closing, 3=closed）可判断当前是否可发数据；HTTP 每次都是全新连接，状态不可延续。

不是 HTTP 不好，而是设计目标不同——它为“文档获取”而生，不是为“持续对话”：

单向请求-响应模型：客户端永远是发起方，服务器不能“主动喊你”；想模拟推送只能靠轮询（浪费资源）或长轮询（连接易断、延迟难控）。
每次通信都有开销：TCP 三次握手 + TLS 握手（HTTPS）+ HTTP 头部解析，毫秒级延迟在高频更新中会被放大（比如每秒 5 次行情推送，HTTP 就得建 5 次连接）。
无原生连接保活机制：HTTP/1.1 虽支持 keep-alive，但超时时间由服务器控制，客户端无法感知断连；WebSocket 有 ping/pong 帧保活，且断连后可通过 onclose 明确捕获并重连。

用 WebSocket 不等于一劳永逸，有些坑必须提前填：

兼容性要兜底：IE10+、现代所有浏览器都支持，但老旧内嵌 WebView（如某些银行 App）可能不支持，得准备长轮询 fallback。
代理和防火墙可能拦截：部分企业网络或运营商网关会丢弃 Upgrade 请求或长时间空闲的 WebSocket 连接，建议设置合理心跳（如 30 秒 ping）。
服务端成本真实存在：每个连接占内存（几 KB 到十几 KB），万级并发需评估服务器承载力；HTTP 短连接反而更“轻量”（用完即释放）。
没内置重连和消息确认：断网重连、离线消息补推、消息送达回执，这些都要自己实现或借助库（如 reconnecting-websocket）。