如何实现服务器通知浏览器？

服务器通知浏览器，即“服务器向浏览器推送消息”的能力，打破了传统 HTTP 的“请求-响应”模型。主要应用于消息推送、在线状态变更、实时通知、弹幕等实时性场景。

实现方式有以下几种，按现代架构常见性与可靠性排序如下：

---

✅ 1. WebSocket（推荐）

✅ 原理：

建立客户端与服务器之间的持久化双向连接，服务器可以主动发送数据给浏览器。

✅ 特点：

• 全双工通信、实时性强；

• 连接建立一次后保持长连接，节省 TCP 握手/HTTP 请求开销；

• 浏览器与服务端通过统一的 ws:// 或 wss:// 协议通信；

• 多用于 聊天室、游戏、交易系统、实时协作等场景。

✅ 示例（JS 端）：

const socket = new WebSocket('wss://example.com/socket');
socket.onmessage = function(event) {
    console.log('收到服务端消息:', event.data);
}

---

✅ 2. Server-Sent Events（SSE）

✅ 原理：

基于 HTTP 协议的单向推送通道，浏览器发起一个长连接，服务端可以持续推送文本数据。

✅ 特点：

• 浏览器内置支持（EventSource），使用简单；

• 只支持服务端 → 浏览器的单向通信；

• 基于 HTTP 协议，支持断线重连、事件 ID 追踪；

• 适合低频推送、通知类场景（如状态更新提示、进度通知等）；

✅ 示例（JS 端）：

const source = new EventSource('/sse');
source.onmessage = function(event) {
    console.log('收到服务器消息:', event.data);
};

---

✅ 3. Long Polling（长轮询）

✅ 原理：

浏览器发起一个阻塞请求，服务端等有数据再响应，浏览器再重新发起请求，形成“伪实时”。

✅ 特点：

• 向下兼容所有浏览器；

• 服务端处理压力大，不是真正意义上的推送；

• 不推荐高并发场景使用，仅作兼容方案或过渡方案；

---

✅ 4. HTTP/2 推送（Server Push）

✅ 原理：

在 HTTP/2 协议中，服务器可以在客户端请求前主动推送资源（如 JS/CSS 文件）。

✅ 注意：

• 属于资源预加载优化，不适合业务级别的“消息推送”；

• 并不能实现主动向浏览器发送业务通知；

• 被大部分浏览器逐步弃用（如 Chrome 已放弃支持）。

---

✅ 场景对比

技术方式	通信方向	实时性	连接开销	是否支持断线重连	兼容性	适用场景
WebSocket	双向	高	低	需自行实现	高（广泛支持）	聊天室、实时通知、游戏
SSE（EventSource）	单向（服务端 → 浏览器）	中等	低	支持	限于现代浏览器（不支持 IE）	实时日志、进度推送
Long Polling	单向（伪推送）	一般	高	支持	全面	通用兼容型系统
HTTP/2 Push	非业务推送	低	低	-	有局限性	静态资源预加载优化

---

🔚 总结推荐：

实时推送需求	建议使用
✅ 实时双向交互	WebSocket
✅ 简单单向通知	SSE（轻量）
✅ 浏览器兼容性优先	Long Polling
❌ 非业务场景	HTTP/2 Push（不推荐用于通知）