WebSocket 和 Server-Sent Events (SSE) 实现原理详解

---

💝💝💝欢迎莅临我的博客，很高兴能够在这里和您见面！希望您在这里可以感受到一份轻松愉快的氛围，不仅可以获得有趣的内容和知识，也可以畅所欲言、分享您的想法和见解。

• 推荐：「stormsha的主页」👈，「stormsha的知识库」👈持续学习，不断总结，共同进步，为了踏实，做好当下事儿~

• 专栏导航

  • Python系列: Python面试题合集，剑指大厂
  • Git系列: Git操作技巧
  • GO系列: 记录博主学习GO语言的笔记，该笔记专栏尽量写的试用所有入门GO语言的初学者
  • 数据库系列: 详细总结了常用数据库 mysql 技术点,以及工作中遇到的 mysql 问题等
  • 运维系列: 总结好用的命令，高效开发
  • 算法与数据结构系列: 总结数据结构和算法,不同类型针对性训练,提升编程思维

  非常期待和您一起在这个小小的网络世界里共同探索、学习和成长。💝💝💝 ✨✨ 欢迎订阅本专栏 ✨✨

  💖The Start💖点点关注，收藏不迷路💖

---

在现代 Web 开发中，实时通信已经成为一种必不可少的功能。无论是即时消息应用、在线游戏，还是实时数据流展示，开发者都需要选择一种高效的方式来实现服务器与客户端之间的实时数据传输。WebSocket 和 Server-Sent Events (SSE) 是两种常见的实时通信技术，它们各自有着独特的实现原理和应用场景。本文将深入探讨 WebSocket 和 SSE 的实现原理，帮助开发者在合适的场景中做出最佳选择。

一、WebSocket 的实现原理

1.1 概述

WebSocket 是一种全双工通信协议，允许服务器和客户端之间建立持久的连接，并在连接建立后，双方可以随时相互发送数据。它是为了解决传统 HTTP 协议下的通信瓶颈而设计的。通过 WebSocket，服务器可以在没有客户端请求的情况下，主动向客户端推送数据，实现真正的实时通信。

1.2 握手过程

WebSocket 连接的建立始于一个 HTTP 握手请求。客户端发送一个标准的 HTTP 请求到服务器，其中包含了 Upgrade 头，表示希望将这个连接升级为 WebSocket 连接。以下是一个典型的 WebSocket 握手请求：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

服务器接收到这个请求后，如果同意升级，则会返回一个 HTTP 101 状态码响应，表示协议切换成功：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

在这之后，连接正式从 HTTP 切换为 WebSocket 协议，双方可以通过这个持久连接随时进行数据传输。

1.3 数据帧格式

WebSocket 使用了一种特殊的帧结构来传输数据。每一帧包含一个固定的头部和可变长度的负载数据。头部的信息包括操作码（opcode）、是否是最后一帧、负载数据长度等。通过这些帧结构，WebSocket 实现了文本和二进制数据的传输。

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |           (16/64)            |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +

1.4 全双工通信

一旦连接建立，WebSocket 就提供了全双工通信通道，这意味着客户端和服务器都可以在同一时间互相发送数据。这种特性使得 WebSocket 非常适合需要频繁、低延迟数据交换的场景，例如在线游戏、股票行情、聊天应用等。

1.5 连接的关闭

WebSocket 的关闭也是通过帧控制的。关闭帧（opcode 为 0x8）可以由客户端或服务器发送。当一方发送关闭帧后，另一方必须回复一个关闭帧，并且双方都应在发送完关闭帧后立即关闭连接。

二、Server-Sent Events (SSE) 的实现原理

2.1 概述

Server-Sent Events (SSE) 是一种单向通信协议，它允许服务器主动向客户端发送数据更新，但客户端无法向服务器发送数据。SSE 使用了 HTTP 协议，并且通过保持 HTTP 连接的开放状态来持续推送数据。相比于 WebSocket，SSE 的实现更为简单，并且原生支持重连机制和事件类型。

2.2 数据传输格式

SSE 使用纯文本格式来传输数据。服务器通过特定的 MIME 类型 text/event-stream 告诉客户端这是一个 SSE 连接。传输的数据格式如下：

data: 这是一个示例消息
event: customEvent
id: 1234

data: 这是另一个消息

每个数据块由若干字段组成，主要包括：

• data: 传输的数据主体，可以包含多行。
• event: （可选）事件名称，用于在客户端区分不同的事件类型。
• id: （可选）消息 ID，用于标识消息并支持自动重连后的消息恢复。

2.3 建立连接

SSE 的连接建立非常简单，客户端通过发送一个普通的 HTTP GET 请求来启动连接：

const eventSource = new EventSource('/events');

服务器返回的响应头部会包含 Content-Type: text/event-stream，表明这是一个 SSE 连接。之后，服务器会持续不断地向客户端发送数据。

2.4 重连机制

SSE 天生支持自动重连机制。如果连接断开，浏览器会自动尝试重新连接，除非明确设置了不允许重连。重连时，服务器可以根据上次断开的 id 来确定从哪里继续发送数据。

retry: 3000
data: 这是重连后的消息

retry 字段指定了重连的时间间隔（以毫秒为单位）。

2.5 事件处理

SSE 提供了事件驱动的机制，允许开发者监听不同类型的事件。例如，可以使用 addEventListener 来监听自定义事件：

eventSource.addEventListener('customEvent', function(event) {
    console.log('Received a custom event:', event.data);
});

2.6 优缺点对比

• WebSocket 提供了双向通信能力，非常适合需要频繁、实时交互的场景，但其实现和维护相对复杂。
• SSE 简单易用，特别适合需要服务器主动推送更新的应用，但由于其单向通信的特性，不能用于需要客户端向服务器频繁发送数据的场景。

三、应用场景和最佳实践

3.1 WebSocket 适用场景

• 在线聊天应用：需要实时的双向通信。
• 实时游戏：要求低延迟和高频率的交互。
• 实时数据分析：例如股票行情、运动跟踪等需要频繁数据更新的场景。

3.2 SSE 适用场景

• 实时通知系统：如新闻推送、社交媒体通知。
• 实时日志监控：通过服务器持续推送日志更新到客户端。
• 轻量级数据流：例如推送简单的文本消息，数据流量较小且只需单向通信。

3.3 性能和扩展性

在高并发和高流量的情况下，WebSocket 的性能通常优于 SSE，因为 WebSocket 的帧结构更加紧凑，并且支持二进制数据传输。然而，SSE 更容易实现和部署，特别是在不需要双向通信的场景下。

结论

WebSocket 和 Server-Sent Events (SSE) 各自有着独特的实现原理和应用场景。WebSocket 提供了更强大的双向通信能力，但实现复杂；而 SSE 则是轻量级、单向通信的理想选择，特别适合服务器向客户端推送更新的场景。开发者在选择这两者时，应该根据具体的业务需求、性能要求和扩展性来做出权衡，以实现最优的解决方案。

---

🔥🔥🔥道阻且长,行则将至,让我们一起加油吧！🌙🌙🌙

💖The End💖点点关注，收藏不迷路💖