原文链接：https://ably.com/topic/websocket-alternatives
什么是 WebSocket？
简而言之，WebSocket 是一种实时 Web 技术，可通过持久连接在客户端和服务器之间实现双向、全双工通信。 WebSocket 连接会根据需要保持活动状态（理论上，它可以永远持续），从而允许服务器和客户端以最小的开销随意发送数据。
了解更多：
什么时候应该考虑使用 WebSocket 替代方案？
对于实时或近实时发送和使用数据至关重要（或至少是理想的）的用例，WebSocket 是一个绝佳的选择。示例包括聊天应用程序、多人协作体验以及广播实时路况更新。
然而，很少有一种放之四海而皆准的协议：不同的协议比其他协议更好地服务于不同的目的。例如，如果您的应用程序严重依赖 CRUD 操作，并且用户不需要快速对更改做出反应，那么 HTTP 是比 WebSockets 更好的选择。另一个例子 - 如果您想传输音频和视频数据，WebRTC 是比 WebSockets 更好的选择。
我们要提到的最后一个例子：如果您只需要将文本（字符串）数据推送到浏览器客户端，并且您从不期望需要双向通信，那么您可以使用服务器发送事件（SSE）之类的东西。与 WebSocket 相比，SSE 的复杂性和要求较低，并且更易于扩展。
WebSocket 协议的五种替代方案
现在，我们将研究 WebSocket 协议的五种替代方案 - 您可以使用这些技术来构建实时应用程序，这些技术有些类似。
服务器发送的事件
服务器发送事件 (SSE)是一种 HTTP 服务器推送技术。这个想法很简单：浏览器客户端可以订阅服务器生成的事件流，并在新事件发生时接收更新。
服务器发送事件的优点
- 内置对重新连接的支持。
- 所有现代浏览器都支持。
- 轻量级协议。
服务器发送事件的缺点
- 它是单向的；只有服务器可以将数据推送到客户端。
- 每个浏览器在同一时间只能有六个并发 SSE 连接。
- 仅支持UTF-8文本数据； SSE 无法处理二进制数据。
对于不需要双向消息传递的场景（例如实时比分更新），SSE 是一个不错的选择。对于需要双向通信的用例，WebSocket 是更好的选择。
长轮询
长轮询是一种客户端拉取技术，它采用 HTTP 请求/响应轮询并使其更加高效。在长轮询中，服务器选择尽可能长时间地保持客户端连接打开，并在新数据可用或达到超时阈值时发送响应。
长轮询的优点
- 长轮询是在XMLHttpRequest的基础上实现的，它几乎受到设备的普遍支持，因此通常不需要实现任何后备。
- 在必须处理异常的情况下，或者可以查询服务器以获取新数据但不支持长轮询（更不用说其他更现代的技术标准）时，基本轮询有时仍然具有有限的用途，并且可以使用XMLHttpRequest，或通过简单的 HTML 脚本标记通过 JSONP。
长轮询的缺点
- 与 WebSocket 相比，长轮询在服务器上消耗更多资源。
- 长轮询可能会带来延迟开销，因为它需要在服务器和设备之间进行多次跳跃。
- 可靠的消息排序可能是一个问题。
长轮询是 WebSocket 的早期先驱。当谈到构建高性能、低延迟的实时应用程序时，WebSocket 几乎在各个方面都是一个优越的选择。这并不是说长轮询已经过时；而是说长轮询已经过时。在某些环境中，例如带有代理服务器的公司网络会阻止 WebSocket 连接。在这种情况下，长轮询作为 WebSocket 的后备机制非常有用。
MQTT
MQTT（消息队列遥测传输）是一种发布-订阅消息传递协议，其历史可以追溯到 1999 年，当时 IBM 的 Andy Stanley-Clark 和 Cirrus Link 的 Arlen Nipper发布了第一个迭代。
在 MQTT 架构中，我们有：
- 发布者（生产者）和订阅者（消费者）。请注意，发布者也可以是订阅者。
- 充当中间件 MQTT 服务器的代理，管理发布者和订阅者之间的消息交换。
MQTT 优势
- 轻量级协议非常适合带宽有限或连接不可预测的网络以及 CPU、内存和电池寿命有限的设备。
- 可靠协议，具有三种不同级别的数据传递保证：0（最多传递一次）、1（至少传递一次）和2（恰好传递一次）。
- 双向且灵活 - 它提供一对一、一对多和多对多通信。
MQTT 缺点
- 对于发送照片、视频或音频数据来说不是一个好的选择。
- 您无法将 MQTT 消息发送到浏览器，因为 Web 浏览器没有内置 MQTT 支持。
- 基本 MQTT 协议不使用加密通信。某些 MQTT 代理允许您使用 MQTT over TLS 来增强安全性，但这会导致 CPU 使用率增加，这对于受限设备来说可能是一个问题。
由于设计轻量，对于许多物联网用例（例如从温度或压力传感器实时收集数据）来说，MQTT 是比 WebSocket 更好的选择。但是，如前所述，MQTT 无法直接向浏览器发送消息。这就是为什么 WebSocket 通常被用作将 MQTT 数据流式传输到浏览器客户端的传输方式（基于 WebSocket 的 MQTT）。
网络RTC
Web 实时通信 (WebRTC)是一个框架，可让您向 Web 和移动应用程序添加实时通信 (RTC) 功能。 WebRTC 允许以点对点方式传输任意数据（视频、语音和通用数据）。
WebRTC优势
- 强大的安全保证，通过 WebRTC 传输的数据在安全实时传输协议 (SRTP)的帮助下进行加密和验证。
- 开源且免费使用。
- 平台和设备无关； WebRTC 应用程序可以在任何支持 WebRTC 的浏览器上运行，无论操作系统或设备类型如何。
WebRTC 的缺点
- 尽管 WebRTC 是一种点对点技术，您仍然需要管理 Web 服务器并为其付费。为了使两个对等点能够相互“交谈”，您需要使用信令服务器来建立、管理和终止 WebRTC 通信会话。
- 在处理视频内容和大量用户时，WebRTC 可能会占用大量 CPU 资源。
- WebRTC 入门很难。有很多概念需要探索和掌握：各种接口、编解码器、网络地址转换 (NAT) 和防火墙、UDP（WebRTC 使用的主要底层通信协议）等等。
WebRTC 主要设计用于流式传输音频和视频内容（通过 UDP），在这种情况下通常是比 WebSocket 更好的选择。另一方面，当数据完整性（保证排序和交付）至关重要时，WebSocket 是更好的选择，因为您可以从 TCP 的底层可靠性中受益。
通常，WebRTC 和 WebSocket 是互补技术。 WebRTC 对等点通过称为信令的过程来协调通信。需要注意的是，WebRTC 不提供标准的信令实现，允许开发人员为此目的使用不同的协议。WebSocket 协议通常用作 WebRTC 应用程序的信令机制。
网络传输
WebTransport是一项新兴的实时技术，通过HTTP/3提供客户端-服务器消息传递。 WebTransport 有两个关键概念：
- 数据报。数据报是一个独立的数据包，可以按任何特定顺序到达。专为需要低延迟且尽力而为的数据传输就足够好的用例而设计。
- 溪流。 Streams API 提供可靠、有序的数据传输。请注意，您可以创建单向和双向流。
网络传输优势
- 通过使用 Datagrams API 或通过多个 Streams API 实例，您不必担心队头阻塞。
- 建立新连接非常快——这是因为 HTTP/3 在底层使用了 QUIC；众所周知，QUIC 握手比通过 TLS 启动 TCP 更快。
Web传输的缺点
- WebTransport 仍然是一项新兴技术。截至 2022 年 11 月，WebTransport 是 W3C 的草案规范，与其工作方式相关的方面始终有可能发生变化。
- 并非所有浏览器都支持 WebTransport。例如，您无法在 Firefox 和 Safari 中使用 WebTransport。
与我们在本文中介绍的其他 WebSocket 替代方案（这些都是已经存在一段时间的成熟技术）不同，WebTransport 更像是 WebSocket 的未来潜在替代方案。我们不知道它在未来几年将如何发展，开发人员采用它的可能性有多大，或者它在生产就绪系统中使用时可能存在哪些陷阱。相比之下，WebSocket 已经存在十多年了；它是一种强大、稳定的技术，拥有庞大而活跃的社区，目前使其成为 WebTransport 的卓越替代品。
WebSocket 及其替代方案：头对头比较
下表显示了 WebSocket 与我们在本文中介绍的替代实时技术之间的主要区别和相似之处。
| 标准 | WebSockets | 长轮询 | 上证所 | MQTT | 网络RTC | 网络传输 |
|---|---|---|---|---|---|---|
| 底层协议 | 传输控制协议 | 传输控制协议 | 传输控制协议 | 传输控制协议 | UDP、TCP | WHO |
| 双向？ | 是的 | 不 | 不 | 是的 | 是的 | 是的 |
| 潜伏 | 低的 | 高的 | 低的 | 低的 | 低的 | 低的 |
| 带宽 | 低的 | 高的 | 低的 | 低的 | 高的 | 高的 |
| 浏览器支持 | 广泛支持 | 广泛支持 | 广泛支持 | 浏览器没有内置的 MQTT 支持 | Internet Explorer 和 Opera Mini 不支持 | 支持有限 |
| 使用方便 | 缓和 | 简单的 | 简单的 | 缓和 | 难的 | 简单的 |
| 到期 | 技术成熟 | 技术成熟 | 技术成熟 | 技术成熟 | 技术成熟 | 新兴科技 |
| 数据的完整性 | 高的 | 缓和 | 高的 | 高的 | 高的 | 高的 |
| 可扩展性 | 高的 | 缓和 | 高的 | 高的 | 低的 | 高的 |
| 它是干什么用的？ | 服务器和客户端之间的实时通信。 | 客户端发起的实时更新通信。 | 单向数据流（服务器推送）。 | 用于 IoT 和 M2M 通信的轻量级消息传递协议。 | 用于实时音频和视频流的点对点通信。 | 用于低延迟 Web 通信的多路复用传输协议。 |
使用多种协议提供实时体验
我们希望您发现本文对您发现 WebSocket 的潜在替代方案有所帮助。然而，现实情况是，许多生产就绪的实时系统不仅仅使用一种协议，而是多种协议的混合。
例如，如果您正在开发视频会议解决方案，WebRTC 是在对等点之间发送音频和视频数据的绝佳选择。在这种情况下，WebSocket 补充了 WebRTC，并经常用作WebRTC 对等方的信令机制。
另一个例子：由于其轻量级设计，MQTT 是从物联网传感器收集遥测数据的绝佳选择。但是，如果您想使用这些数据来支持可以在浏览器中监控的实时仪表板，则 MQTT 不适合，因为浏览器不支持它。您可以做的就是通过 WebSocket 将数据发送到浏览器。这就是为什么现在许多 MQTT 代理也支持 WebSocket（或基于 WebSocket 的 MQTT）。
如果您确实决定使用 WebSocket 作为您的用例的主要传输协议，您仍然需要考虑支持后备传输，因为某些环境会阻止 WebSocket 连接（例如，限制性的公司网络）。 SSE 和长轮询通常用作 WebSocket 的后备方案。
Ably，在任何规模下都能可靠运行的多协议实时平台
Ably 是一家实时体验基础设施提供商。我们的 API 和 SDK 可帮助开发人员构建和提供实时体验，而无需担心维护和扩展混乱的实时基础设施。
Ably 的主要特性和功能：
- 具有丰富功能的发布/订阅消息传递，例如消息增量压缩、连续性自动重新连接、用户状态、消息历史记录和消息交互。
- 多协议功能。 Ably 协议基于 WebSocket，但我们还支持长轮询作为后备、SSE、MQTT、AMQP、STOMP 和 HTTP/REST。
- 全球分布式数据中心网络和边缘加速接入点。
- 保证消息排序和传递。
- 全球容错和 99.999% 的正常运行时间 SLA。
- < 65 毫秒往返延迟 (P99)。
- 动态弹性，因此我们可以快速扩展以处理任何需求（发送到数百万个发布/订阅通道和客户端连接的数十亿条消息）。