17370845950

WebSocket连接三步：构造函数创建、监听事件、send发送；长轮询靠客户端递归请求模拟实时；核心区别是全双工长连接vs单向HTTP“假连接”；选型依延迟与交互频率而定。

WebSocket 连接怎么写？关键就三步

直接用 WebSocket 构造函数就能建立双向通道，不需要额外库。但必须注意：服务端得支持 WebSocket 协议（比如 Node.js 用 ws 库，不是 Express 默认带的），否则会卡在连接阶段。

常见错误是直接访问 http:// 地址却传 ws://，或者 HTTPS 页面里用了 ws://（被浏览器拦截）——必须匹配协议：http 对应 ws://，https 对应 wss://。

• 创建实例：

  const ws = new WebSocket('wss://api.example.com');

• 监听事件：ws.onopen、ws.onmessage、ws.onerror、ws.onclose
• 发消息只用 ws.send()，参数只能是 string 或 ArrayBuffer（传对象要先 JSON.stringify()）

长轮询（Long Polling）是怎么模拟“实时”的？

它本质还是 HTTP 请求，只是服务端不立刻响应，而是等有新数据或超时才返回。客户端收到响应后，立刻发下一个请求，形成“假连接”。

典型实现是用 fetch 或 XMLHttpRequest，设置较长的 timeout，并在 then 里递归调用下一次请求。但它无法做到服务端主动推——所有推送动作都依赖客户端不断发起请求。

• 每次请求都有完整 HTTP 头开销（可能几百字节），频繁请求加重服务端压力
• 存在请求间隙，严格来说不是实时，延迟通常在几百毫秒到几秒
• 适合 WebSocket 不可用的老旧环境（如 IE9），或某些代理/防火墙强行阻断 WebSocket 升级的场景

WebSocket 和长轮询的核心区别在哪？

不是“谁更快”，而是通信模型根本不同：WebSocket 是真正的全双工长连接，长轮询是 HTTP 的“障眼法”。

• 连接状态：WebSocket 建立后保持一个 TCP 连接；长轮询每次都是新 HTTP 请求，连接不断断开重连
• 数据流向：WebSocket 允许服务端随时 send()；长轮询只能由客户端发起请求，服务端只能在该次响应中回传数据
• 首字节延迟：WebSocket 消息到达即达；长轮询需等待下次请求发起+网络往返+服务端处理，链路更长
• 兼容性代价：WebSocket 需服务端显式支持升级协议（Upgrade: websocket）；长轮询只要 HTTP Server 就能跑，但逻辑更复杂（要管理 pending 请求队列）

什么时候该选哪个？别被“实时”二字带偏

如果业务需要低延迟、高频率双向交互（比如协作编辑、实时游戏、行情推送），优先 WebSocket。但它的失败降级不能只靠“捕获 onerror 后切长轮询”——因为连接失败可能发生在握手阶段（HTTP 400/401/503），这时连 onerror 都不会触发，得靠 onclose 状态码和重试逻辑兜底。

• 长轮询更适合低频、容忍秒级延迟的场景（如通知提醒、离线消息拉取）
• 不要在 WebSocket 上做心跳包轮询：用 ws.ping()（服务端需配合）或发空字符串即可，避免引入 HTTP 轮询思维
• 真实部署中，Nginx 默认不转发 WebSocket 升级头，必须显式配置：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"

最常被忽略的是连接生命周期管理：WebSocket 断开后，前端自动重连不能无限制（会触发浏览器限流），得加退避策略；而长轮询的请求间隔一旦设死，容易在服务端过载时雪崩。这两者的“稳”，靠的都不是协议本身，而是你写的重连和限流逻辑。