聊聊四种实时通信技术:长轮询、短轮询、WebSocket 和 SSE

这篇文章,我们聊聊 四种实时通信技术:短轮询、长轮询、WebSocket 和 SSE 。

1 短轮询 浏览器 定时(如每秒)向服务器发送 HTTP 请求,服务器立即返回当前数据(无论是否有更新)。

 

  • 优点:实现简单,兼容性极佳

  • 缺点:高频请求浪费资源,实时性差(依赖轮询间隔)

  • 延迟:高(取决于轮询频率)

  • 适用场景:兼容性要求高,延迟不敏感的简单场景。

笔者职业生涯印象最深刻的短轮询应用场景是比分直播:

添加图片注释,不超过 140 字(可选)

如图所示,用户进入比分直播界面,浏览器定时查询赛事信息(比分变动、黄红牌等),假如数据有变化,则重新渲染页面。 这种方式实现起来非常简单可靠,但是频繁的调用后端接口,会对后端性能会有影响(主要是 CPU)。同时,因为依赖轮询间隔,页面数据变化有延迟,用户体验并不算太好。 2 长轮询 浏览器发送 HTTP 请求后,服务器 挂起连接 直到数据更新或超时,返回响应后浏览器立即发起新请求。

 

  • 优点:减少无效请求,比短轮询实时性更好

  • 缺点:服务器需维护挂起连接,高并发时资源消耗大

  • 延迟:中(取决于数据更新频率)

  • 适用场景:需要较好实时性且无法用 WebSocket/SSE 的场景(如消息通知)

长轮询最常见的应用场景是:配置中心,我们耳熟能详的注册中心 Nacos 、阿波罗都是依赖长轮询机制。

 

客户端发起请求后,Nacos 服务端不会立即返回请求结果,而是将请求挂起等待一段时间,如果此段时间内服务端数据变更,立即响应客户端请求,若是一直无变化则等到指定的超时时间后响应请求,客户端重新发起长链接。 3 WebSocket 基于 TCP 的全双工协议,通过 HTTP 升级握手(Upgrade: websocket)建立持久连接,双向实时通信。

 

  • 优点:最低延迟,支持双向交互,节省带宽

  • 缺点:实现复杂,需单独处理连接状态

  • 延迟:极低

  • 适用场景:聊天室、在线游戏、协同编辑等 高实时双向交互 需求

笔者曾经服务于北京一家电商公司,参与直播答题功能的研发。

 

直播答题整体架构见下图:

 

Netty TCP 网关的技术选型是:Netty、ProtoBuf、WebSocket ,选择 WebSocket 是因为它支持双向实时通信,同时 Netty 内置了 WebSocket 实现类,工程实现起来相对简单。 4 Server Send Event(SSE) 基于 HTTP 协议,服务器可 主动推送 数据流(如Content-Type: text/event-stream),浏览器通过EventSource API 监听。

 

  • 优点:原生支持断线重连,轻量级(HTTP协议)

  • 缺点:不支持浏览器向服务器发送数据

  • 延迟:低(服务器可即时推送)

  • 适用场景:股票行情、实时日志等 服务器单向推送 需求。

SSE 最经典的应用场景是 : DeepSeek web 聊天界面 ,如图所示:

 

当在 DeepSeek 对话框发送消息后,浏览器会发送一个 HTTP 请求 ,服务端会通过 SSE 方式将数据返回到浏览器。

 

5 总结

特性

短轮询

长轮询

SSE

WebSocket

通信方向

浏览器→服务器

浏览器→服务器

服务器→浏览器

双向通信

协议

HTTP

HTTP

HTTP

WebSocket(基于TCP)

实时性

极高

资源消耗

高(频繁请求)

中(挂起连接)

低(长连接)

选择建议:

  • 需要 简单兼容性 → 短轮询

  • 需要 中等实时性 → 长轮询

  • 只需 服务器推送 → SSE

  • 需要 全双工实时交互 → WebSocket

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值