javascript如何实现实时通信_WebSocket与长轮询有何不同？

WebSocket实现全双工持久化TCP连接，低延迟毫秒级；长轮询基于HTTP伪实时，有头部开销、空窗期和高资源消耗。选型依场景：高频低延用WebSocket，兼容旧环境或低频同步用长轮询。

JavaScript 实现实时通信主要靠 WebSocket，它建立的是浏览器与服务器之间的**全双工、持久化 TCP 连接**，消息可随时双向收发；而 长轮询（Long Polling） 是一种“伪实时”方案，本质仍是 HTTP 请求-响应模型，靠反复发起请求来模拟实时性。两者核心区别不在代码写法，而在通信机制和性能表现。

WebSocket：一次连接，持续通信

WebSocket 在首次握手时通过 HTTP 升级（Upgrade: websocket）切换协议，之后完全脱离 HTTP，使用独立帧格式传输数据。客户端用 new WebSocket(url) 创建连接，监听 onmessage 接收消息，调用 send() 发送消息。

• 连接建立后无请求头开销，消息轻量（最小仅2字节帧头）
• 服务端可主动推送，延迟通常在毫秒级
• 需服务端支持 WebSocket 协议（如 Node.js 的 ws 库、Nginx 配置 proxy_pass + Upgrade 头）
• 不兼容老旧环境（IE9 及以下不支持），但现代浏览器全覆盖

长轮询：HTTP 的“等待式”妥协

客户端发一个 GET 请求，服务端不立即响应，而是挂起请求，直到有新数据或超时（如30秒）才返回。客户端收到响应后，立刻发下一个请求，形成“请求→等待→响应→再请求”的循环。

• 所有通信走标准 HTTP，天然兼容代理、CDN 和旧浏览器
• 每次请求都有完整 HTTP 头部（至少几百字节），频繁建立连接带来额外开销
• 存在“空窗期”——上一个响应结束到下一个请求发出之间，可能错过消息
• 服务端需维护连接等待队列，高并发下资源消耗比 WebSocket 显著更高

怎么选？看场景，不看技术偏好

若项目要求低延迟、高频交互（如在线协作文档、实时游戏、交易看板），优先用 WebSocket；若需支持 IE8/9、内网老旧网关，或只是偶尔同步状态（如通知红点、订单状态变更），长轮询更稳妥。实际开发中，可用 Socket.IO 这类库自动降级：先尝试 WebSocket，失败则 fallback 到长轮询，开发者只需写一套接口。

标签： javascript java js node.js node nginx 浏览器 字节 websocket proxy