服务器如何给客户端发消息？，有哪些实现方法？

服务器给客户端发消息，本质是建立一条从服务器主动发起的数据通道，核心技术是WebSocket、SSE或MQTT，选型取决于实时性要求和连接场景。

很多人误以为网页只能“请求-响应”，服务器没法主动开口，从早期的轮询，到现在的WebSocket和SSE，服务器主动“说话”的技术已经非常成熟，下面直接拆解实现方式、适用场景和选型成本。

加载中

TCP服务器端和客户端

嵌入式菌

5334393

原视频地址

为什么服务器需要主动发消息

传统HTTP协议里，客户端是“甲方”，每次对话都由它发起，但很多真实业务要求服务器当“乙方”时也能主动汇报，举个例子，你在电商平台下单后，后台一审核通过，页面上的状态就得立刻从“待审核”变成“已通过”，如果靠用户手动刷新，体验极差，再比如股票App的行情跳动、协同文档里同事光标的实时移动，这些都需要服务器把最新状态主动推送到客户端。

行业共识认为，实时交互已经成为应用的基础能力，不只是聊天工具专属，实现这种“服务器开口说话”的能力，主流有四种方案,它们的实时性和资源消耗差异很大。

服务器推送的四种主流机制

轮询：最朴素的“假装主动”

短轮询是早期方案，客户端每隔几秒问一次：“有更新吗？”服务器每次都得回答，哪怕没有新内容，这种方案实现最简单，但浪费带宽，服务器压力大，实时”是假的，延迟取决于轮询间隔，现在除了极简单的场景,基本不推荐。

长轮询：改进版的“挂起等待”

长轮询解决了短轮询的一部分浪费，客户端发请求后，服务器先“挂起”连接，有数据了才响应，或者等超时再返回，它比短轮询实时性好，但连接频繁建立和断开，对服务器资源消耗依然不小，在WebSocket普及前,这是主流方案。

WebSocket：真正的全双工长连接

WebSocket是目前服务器给客户端发消息最常用的方案，一次握手建立TCP长连接，之后两端都能随时发数据，没有HTTP头部的重复开销，它适合高频、双向交互场景，比如实时弹幕、协作白板、在线游戏。

SSE：单向推送的轻量选择

SSE（Server-Sent Events）是HTTP协议上的单向推送，客户端连上后，服务器可以持续发消息，但客户端不能通过这条连接回传数据，它基于HTTP，实现简单，支持断线重连，适合服务器单向广播的场景，比如股票行情刷新、日志实时输出、AI回复逐字打印。

WebSocket实战：从握手到消息推送

WebSocket是现在最热门的方案，我们看一个具体实现,前端JavaScript创建连接：

const socket = new WebSocket('wss://example.com/ws');
// 连接建立后，服务器就能主动发消息了
socket.onmessage = function(event) {
    console.log('收到服务器消息:', event.data);
};
socket.onopen = function() {
    // 可以发送鉴权信息
    socket.send(JSON.stringify({type: 'auth', token: 'your-token'}));
};

后端以Node.js为例，使用ws库：

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', (ws, req) => {
    // 解析用户身份，比如从token获取userID
    const userId = parseToken(req);
    // 保存连接，方便后续定向推送
    clients.set(userId, ws);
    ws.on('message', (data) => {
        // 处理客户端发来的消息
        console.log('收到:', data.toString());
    });
    ws.on('close', () => {
        clients.delete(userId);
    });
});
// 服务器主动给客户端发消息
function sendToUser(userId, message) {
    const ws = clients.get(userId);
    if (ws && ws.readyState === WebSocket.OPEN) {
        ws.send(JSON.stringify(message));
    }
}

这里有几个关键点：

• 心跳检测：服务器定期发ping，客户端回pong,避免连接假死。
• 鉴权处理：通常通过query参数或子协议传递token,不能省略。
• 连接管理：用Map或对象存储连接,用户断开时及时清理。

SSE实战：适合服务器单向广播

SSE实现更轻量,前端代码：

const eventSource = new EventSource('/api/stock/price');
eventSource.onmessage = function(event) {
    const data = JSON.parse(event.data);
    updateStockPrice(data);
};
eventSource.onerror = function() {
    console.log('连接断开，浏览器会自动重连');
};

后端是普通HTTP接口,但设置特定响应头：

app.get('/api/stock/price', (req, res) => {
    res.writeHead(200, {
        'Content-Type': 'text/event-stream',
        'Cache-Control': 'no-cache',
        'Connection': 'keep-alive'
    });
    // 定时推送数据
    const timer = setInterval(() => {
        res.write(`data: ${JSON.stringify({symbol: 'AAPL', price: 189.5})}\n\n`);
    }, 1000);
    req.on('close', () => clearInterval(timer));
});

SSE是单向的，但浏览器自带自动重连机制，代码简单，还能通过HTTP/2多路复用减少连接数，对于只需要服务器推送、不需要客户端频繁上报的场景,SSE比WebSocket更省资源。

不同场景怎么选

需要双向实时通信，比如聊天、在线游戏、多人协作编辑，选WebSocket，它延迟低,双向自由通信。

只需要服务器单向推送，比如新闻订阅、行情刷新、AI生成内容流式输出，选SSE，它实现简单，自带重连,穿防火墙更容易。

物联网设备推送，比如智能家居控制、传感器数据上报，选MQTT，它基于发布/订阅模型，协议轻量,适合网络不稳定环境。

兼容性要求高、低频场景，可以用长轮询，但实时性差,连接开销大。

成本方面，WebSocket需要维护长连接状态，服务器内存占用高，分布式部署时还要处理连接迁移问题，SSE基于HTTP，无状态，配合Nginx负载均衡更简单，对于国内用户较多、需要买服务器部署的情况，服务器价格是个实际考量：WebSocket长连接对内存和带宽要求更高,同样配置下能支撑的并发连接数少于SSE。

服务器选型与部署注意事项

选择国内服务器时，需要考虑地域对连接延迟的影响，如果用户集中在华东，部署在杭州或上海的机房延迟更低，国内服务器通常需要完成ICP备案才能使用域名访问,这会影响上线时间线。

对于WebSocket服务，建议使用独立的子域名（如ws.example.com），方便负载均衡和证书管理，Nginx配置反向代理时,需要设置升级头：

location /ws {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

连接数限制是另一个坑，一个进程默认文件描述符上限是1024，生产环境需要调大ulimit，长连接会占用大量内存，每连接约几十KB，一台8GB内存的服务器，理论支撑的连接数在几万到十几万之间,具体取决于业务消息频率。

部署层面，多实例时用Redis Pub/Sub做消息中转，一个实例收到推送请求，通过Redis广播给其他实例，由持有目标连接的实例真正下发，这样能水平扩展，支撑更大规模的并发连接。

常见问题排查

WebSocket连接频繁断开：先检查是否有反向代理的超时设置，Nginx默认proxy_read_timeout是60秒，需要调大,再确认心跳机制是否正常。

浏览器报跨域错误：WebSocket遵循同源策略，服务器需要校验Origin头,只允许可信域名连接。

消息乱序：TCP保证有序，但多实例下消息可能走不同路径,业务逻辑上需要自带序号或时间戳。

服务器内存持续增长：极大可能是连接泄漏，客户端断开时没清除Map里的引用,或者事件监听器没移除。

服务器给客户端发消息与服务器推送的区别

这两个概念经常被混淆。服务器给客户端发消息是广义动作，包括推送，也包括客户端发起请求后服务器的即时响应。服务器推送特指服务器在客户端没有请求的情况下主动发送数据，本文讨论的所有技术，都属于服务器推送范畴，本质都是让服务器具备“开口说话”的能力。

服务器给客户端发消息常见问题解答

服务器给客户端发消息用什么协议好？

没有绝对答案，按场景选，双向高频通信选WebSocket，单向广播选SSE，物联网选MQTT，低频简单场景用轮询或长轮询也够，实时聊天选WebSocket，AI聊天逐字输出选SSE,智能家居控制选MQTT。

WebSocket和轮询哪个更省资源？

连接数少、频率低时，轮询更简单省事，连接数多、频率高时，WebSocket更省资源，轮询每次都要带HTTP头部，服务器要反复处理请求；WebSocket只需要一次握手，后续是轻量帧传输，但WebSocket的连接是长期占用的，空闲也占内存。高频场景选WebSocket，低频场景轮询更划算。

国内服务器做WebSocket推送需要备案吗？

使用域名和80/443端口对外提供服务，就需要ICP备案，如果直接用IP加端口访问，可以绕过备案，但不推荐生产环境使用，备案一般需要1-2周，规划上线时间时要留出余量，购买服务器时，不同服务商的服务器价格差异不小，性能相近的配置，价格可能相差20%左右,选型时要综合考虑。

服务器推送技术的核心，是选对协议并用好连接管理，WebSocket适合交互密集的场景，SSE适合广播推送，MQTT适合物联网，国内部署时，留出备案时间，选好机房地域，把心跳和断线重连做好,系统就能稳定支撑实时业务。