服务器如何向客户端推送消息，有哪些常见方法？

服务器向客户端推送消息，本质上就是让服务器主动发起通信，而不是等待客户端轮询，目前主流方案包括WebSocket、SSE（Server-Sent Events）以及长轮询技术，选择哪种取决于你的应用场景对实时性、兼容性和资源消耗的要求。

服务器推送消息的几种主流方式对比

说到服务器主动推送消息，很多人第一反应是WebSocket，没错，它确实是目前最普及的方案，但并非唯一选项，根据业务需求的不同，你还可以选择SSE、长轮询甚至短轮询,下面逐一拆解它们的工作方式和适用边界。

加载中

线报酷第十七讲：Server酱推送

线报酷

362314-

原视频地址

WebSocket：全双工通信的王者

WebSocket通过在HTTP协议上发起一次握手，升级为持久化的TCP连接，一旦建立，客户端和服务端可以随时互相发送数据，不再受限于请求-响应模型。

• 连接建立：客户端发送HTTP Upgrade请求，服务端返回101状态码,之后通信协议切换为WebSocket。
• 数据格式：支持文本和二进制帧，适合传输JSON、图片流等。
• 优势：实时性最高，双向通信，延迟可达毫秒级，多数浏览器原生支持，库资源丰富（如Socket.IO、ws）。
• 短板：连接维护成本略高，需要处理心跳、重连、断线恢复,防火墙或代理可能拦截非标准端口。

SSE：单向推送的轻量选择

SSE（Server-Sent Events）是HTML5标准的一部分，专门用于服务端向客户端单向推送文本数据，它基于HTTP长连接，浏览器通过EventSource API订阅。

• 连接建立：客户端发起HTTP GET请求，服务端返回Content-Type为text/event-stream的响应,保持连接不断开。
• 数据格式：纯文本，按行以event、data、id等字段组织,支持自动重连。
• 优势：实现简单，只需普通HTTP服务器；自带断线重连机制；兼容大部分现代浏览器且不需要额外库。
• 短板：仅支持单向推送（服务器到客户端），无法发送二进制数据,低版本IE不支持。

长轮询与短轮询：传统方案的妥协

在WebSocket和SSE普及之前，轮询是常见的“伪推送”方案。

• 短轮询：客户端每隔固定时间（如3秒）发送HTTP请求，询问是否有新数据，服务端在每次请求中立即返回，无论是否有新数据，实现简单，但大量请求浪费带宽,实时性差。
• 长轮询：客户端发起请求后，服务端保持连接挂起，直到有新数据才返回响应，客户端收到后立即再次发起请求，形成“请求-等待-响应-请求”循环，实时性比短轮询好，但依然有HTTP请求开销,且服务器长时间占用连接资源。

WebSocket和SSE对比：如何选择实时推送方案

很多开发者在做实时推送时会纠结WebSocket和SSE到底选哪个，其实两者各有侧重，不存在绝对的优劣，核心判断依据是：你的业务是否需要双向通信。

双向通信 vs 单向推送

• 如果你的应用需要双向实时交互，比如在线聊天、多人协作编辑、实时游戏，WebSocket是唯一选择，SSE无法满足客户端向服务器推送数据的需求，只能依赖额外的HTTP请求来补足,这样反而增加了复杂度。
• 如果你的场景只是服务端主动推送更新，比如股票行情、系统通知、日志流、数据看板，SSE完全够用，它的实现更轻量，自带断线重连和事件ID机制,开发和维护成本远低于WebSocket。

兼容性与降级策略

WebSocket在主流浏览器中支持度极高，但一些老旧网络环境（如企业防火墙）可能阻止WebSocket的Upgrade请求，SSE在部分浏览器（如IE、Edge旧版）中不支持，但可以通过polyfill（如eventsource-polyfill）降级为长轮询。

行业共识认为，对于需要覆盖广泛用户群体的生产环境，通常会采用渐进增强策略：优先使用WebSocket，在连接失败时降级为SSE或长轮询，这也是Socket.IO等库的核心设计思路。

资源消耗与性能

• 服务端连接数：WebSocket需要维护每个连接的状态，单个节点的连接数上限取决于内存和操作系统配置，SSE同样维护长连接，但因为是HTTP协议，更容易被反向代理（如Nginx）管理。
• 带宽对比：WebSocket的帧协议开销很小，适合高频小数据包，SSE每次发送都是完整的文本行，如果数据量小,头部开销相对较大。
• 开发成本：SSE可以用任意后端语言实现，只需设置响应头并不断输出文本，WebSocket需要额外库来处理握手、帧解析、心跳等,调试也更复杂。

实际部署中的推送方案选型指南

知道了技术原理，下一步就是落地，不同业务场景对推送的要求差异很大,选错方案会造成资源浪费或开发反复。

聊天应用：必须上WebSocket

聊天场景要求消息发送后立即到达对方，且用户随时可能发送消息，使用WebSocket可以实现真正的双向即时通信，如果追求高并发，可以结合消息队列和Redis做分布式推送，常见架构是客户端通过WebSocket连接到网关服务，网关将消息投递到后端业务逻辑,再通过WebSocket推送给目标用户。

股票行情/实时数据看板：SSE足够

股票报价、期货行情、监控大屏这类场景，数据流是单向的服务器不断推送价格变化，客户端只负责展示，SSE的简洁性在这里体现得淋漓尽致：后端只需按数据源事件流输出，客户端用EventSource监听，自动重连，无需额外代码，如果数据量极大，可考虑在SSE内做数据聚合,减少推送频率。

通知推送：综合方案

站内通知、告警消息、订单状态更新，通常需要兼顾实时性和可靠性，很多团队选择“SSE + 轮询”组合：先用SSE推送新通知，如果连接断开，则降级为长轮询，服务端保留通知历史，客户端启动时通过HTTP接口拉取未读消息，这种架构既保证了实时体验,又避免了丢消息。

物联网（IoT）设备通信：WebSocket or MQTT

物联网场景中，设备端通常算力有限，且要求低功耗，WebSocket在设备端支持较好，但MQTT（消息队列遥测传输）更具优势，因为其协议更轻量、支持QoS级别，如果你已经在用MQTT，可以通过WebSocket桥接实现浏览器端接收设备消息,这是很多物联网平台的典型做法。

服务器推送消息的部署成本与价格考量

推送方案的选择直接影响服务器资源消耗和云服务账单，虽然没有标准定价,但可以从几个维度估算成本。

自建推送服务的成本

• 服务器规格：WebSocket长连接会占用连接数，一台4核8G的云服务器可以支撑大约5000-10000个WebSocket连接（取决于业务逻辑复杂度），SSE连接数类似，但因为是HTTP,Nginx反向代理可以分担部分压力。
• 带宽成本：推送频率越高、数据包越大，带宽消耗越大，对于实时行情场景，每秒推送一次，每次1KB，1万个连接每小时约消耗36GB带宽,按云厂商标准计算成本不低。
• 开发与运维：自建需要处理心跳、断线重连、分布式场景下的连接路由,人力成本不可忽视。

云服务商提供的推送服务价格

大多数云厂商提供托管推送服务，例如简米云移动推送、酷番云通信、AWS SNS等，这些服务按量计费，价格因地域和规格而异，以国内厂商为例，基础版的推送服务通常包含每月100万次推送额度，超出部分按每万次0.5-2元收费，对于需要全球部署的场景，海外节点定价通常比国内高30%-50%。

注意：托管服务简化了连接管理，但锁定了平台，迁移成本较高，如果你的业务用户量不大，自建可能更划算；如果用户量在百万级以上,托管服务的运维优势更明显。

从零搭建推送服务：实操步骤

理论聊完，上手实践，这里以最简单的SSE示例和WebSocket示例说明关键步骤,让你快速跑通核心流程。

用Python实现SSE推送

服务端（Flask）：

from flask import Flask, Response, stream_with_context
import time
app = Flask(__name__)
def event_stream():
    while True:
        time.sleep(1)
        yield f"data: {time.time()}nn"
@app.route('/events')
def sse():
    return Response(stream_with_context(event_stream()),
                    mimetype='text/event-stream')
if __name__ == '__main__':
    app.run(threaded=True)

客户端（HTML）：

<script>
    const source = new EventSource('/events');
    source.onmessage = function(event) {
        console.log('New time:', event.data);
    };
</script>

关键点：服务端必须设置Content-Type: text/event-stream，且不能缓存响应，每条消息以data:开头,两个换行符结尾。

用Node.js实现WebSocket推送

服务端（ws库）：

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', (ws) => {
    console.log('Client connected');
    // 每2秒推送一条消息
    setInterval(() => {
        ws.send(JSON.stringify({ time: Date.now() }));
    }, 2000);
});

客户端：

const ws = new WebSocket('ws://localhost:8080');
ws.onmessage = (event) => {
    console.log('Received:', event.data);
};

注意：生产环境需要添加心跳检测（ping/pong）,防止死连接占用资源。

服务器推送消息常见问题与解答

WebSocket和SSE可以同时使用吗？
完全可以，两者可以共存于同一应用，WebSocket负责双向通信（如聊天消息发送），SSE用于服务端事件推送（如在线用户列表更新），分工明确,各取所长。

服务器推送消息会增加服务器压力吗？
相比轮询，推送机制能大幅减少冗余请求，降低网络和服务器负载，但长连接本身会占用内存和文件描述符，当连接数达到数万级别时，需要评估单机瓶颈并考虑水平扩展，多数情况下,推送方案比轮询更省资源。

国内使用WebSocket是否需要备案？
WebSocket作为应用层协议，本身无需额外备案，但服务器域名和IP需要符合国家互联网管理规定，如果使用非标准端口，部分运营商可能屏蔽，建议使用443端口并通过TLS加密，对于涉及大量用户推送的场景,提前咨询云服务商的地域节点和合规要求是稳妥的做法。