从流式输出到 websocket 与 SSE

__不想说话__
831 阅读5分钟

前言

随着近两年 ChatGPT 的爆火以及国内众多大模型厂商的崛起，流式输出被越来越多的用户、研发、产品所认可与追捧。很多人通过对 ChatGPT 的分析了解到了 SSE 这一协议，并且狂热的认为流式就是要用 SSE。

但是作为前端开发的我们应该要认识到，页面的效果与实际的协议并没有过多的关系。像是微软的 Bing 其实就是直接使用 websocket 来进行前后端交互。

那么 SSE 和 websocket 到底都是什么？又有什么优劣和应用场景呢？让我们来浅浅的看一下。

什么是 SSE 和 websocket

WebSocket 和 SSE 都是用于实现服务器与客户端之间实时双向通信的技术。

WebSocket 是基于独立的 TCP 连接实现的，使用自定义的协议。客户端和服务器之间可以建立持久的全双工通信的连接，可以双向发送和接收数据。WebSocket 协议是基于帧的，可以通过发送不同类型的帧进行通信。 schemat 2.png

SSE 是基于传统的 HTTP 协议实现的，采用了长轮询（long-polling）机制。客户端通过向服务器发送一个 HTTP 请求，服务器保持连接打开并周期性地向客户端发送数据。SSE 通过 EventSource 对象来实现，在客户端可以通过监听 onmessage 事件来接收服务器端发送的数据。 schemat 1.png

优缺点对比

WebSocket

优点:

  1. 浏览器兼容性相对较好
  2. 支持双向通信，实时性更高，可以实现更丰富的交互效果
  3. 支持传输任何形式的数据（文本、二进制等），并允许自定义数据格式，这为应用层提供了高度灵活性

缺点:

  1. 需要独立的 TCP 连接，对服务器压力更大
  2. 在某些特殊的网络环境下可能会遇到问题

SSE (Server-Sent Events)

优点:

  1. 简单易用，对服务器压力小
  2. SSE 基于 HTTP 协议，对于只需要服务器推送数据的场景更为高效

缺点:

  1. 只支持单向通信，无法进行双向交互
  2. 浏览器兼容性对比 WebSocket 略差
  3. 主要用于传输文本数据，并且数据格式有一定的规范，比如每条消息前会有特定的事件字段、数据字段等，适合简单的数据推送场景

应用场景

WebSocket

  • 实时聊天应用：由于 WebSocket 支持双向通信，它非常适合用于实时聊天应用。用户可以即时发送和接收消息，无需等待服务器的响应
  • 在线游戏：在线游戏需要实时的、双向的数据交互，因此 WebSocket 是一个很好的选择。玩家的操作可以立即发送到服务器，并接收到游戏的实时状态
  • 实时协作应用：在实时协作应用中，如 Google Docs 或在线白板应用，用户的每一次操作都需要实时地反映到其他用户的界面上，这需要快速、双向的数据通信，因此 WebSocket 是一个理想的选择

SSE (Server-Sent Events)

  • 实时新闻推送：SSE 适用于需要服务器向客户端单向推送实时更新的数据，例如新闻更新
  • 股票价格更新：在股票交易应用中，服务器需要实时向客户端推送最新的股票价格。由于这种场景只需要服务器向客户端单向推送数据，因此 SSE 是一个很好的选择
  • 实时通知：在很多应用中，服务器需要向客户端推送实时通知，例如电子邮件通知、系统状态更新等。这些场景通常只需要服务器向客户端单向推送数据，因此 SSE 是一个理想的选择

关于兼容性的补充

WebSocket

image.png

SSE (Server-Sent Events)

image.png

  • SSE 是单向的。你只能从服务器向客户端发送消息。这对于创建只读实时应用程序（如股票行情）非常有用，但对于许多其他类型的实时应用程序可能会有限制。
  • SSE 受到打开连接数量的限制，这可能在打开多个标签页时特别痛苦，因为限制是每个浏览器设置的，且数量非常小

总的来说，WebSocket 的浏览器兼容性更好，但 SSE 在某些应用场景下可能更简单、更快。具体选择哪种技术，取决于你的具体需求和应用场景。

总结

总的来说，选择使用 WebSocket 还是 SSE 主要取决于你的具体需求。

如果你只需要服务器向客户端单向推送数据，并且希望保持简单易用和兼容性好，那么SSE是一个不错的选择。

如果你需要实现双向通信，或者需要更高级的功能和控制，那么WebSocket可能更适合你的需求。

每一种技术都是最佳的选择，只是看你如何使用。

avatar
文章
阅读
粉丝