服务器发送事件与WebSocket：你应该使用哪个？

介绍

服务器发送事件和WebSocket都保持连接开放，以便数据可以在没有重复短轮询的情况下到达。SSE通过HTTP传送从服务器到客户端的文本流。WebSocket切换到全双工的分帧协议，任一端点都可以发送文本或二进制消息。

从流量形状中选择，而不是实时标签。如果浏览器主要是监听，而普通HTTP已经处理了命令，SSE通常符合系统。如果两边都发送频繁的独立消息，WebSocket则避免在流旁边建立第二个交互通道。

方向决定基本契合

SSE从服务器发送到浏览器。单独的POST、PUT或其他HTTP请求承载用户行为。这对通知、进度、日志和响应令牌流媒体是干净的，因为上游命令是稀少的，并且已经适合API。

WebSocket允许双向独立流量。聊天、协作光标、多玩家控制和快速变化的订阅都受益于一个双工通道。 RFC 6455 定义了WebSocket握手和帧；应用程序命令仍然需要其自己的架构。

文本事件与分帧消息

SSE具有面向行的UTF-8格式，包含数据、事件、ID和一个重连延迟字段。命名事件和ID提供了一个小的应用词汇，而无需另一个协议库。

WebSocket支持文本和二进制消息、分片和控制帧。当二进制负载频繁或紧凑的分帧是重要时更好。如果JSON序列化、应用程序工作、数据库调用或网络延迟占主导地位，则不要基于微小的合成帧比较做出决定。

重连和重放

事件源会自动重连，并且可以发送最后事件ID，但重放仅在服务器保留有序历史时有效。应用程序必须定义ID范围、保留窗口和快照行为。

浏览器WebSocket API不会自动重连。WebSocket应用程序决定延迟、重新订阅、身份验证续订，以及光标或快照是否恢复状态。 SSE标准 使更多的重连行为本地化，而不是完整的。

基础设施兼容性

SSE是一个长期存在的HTTP响应，因此它可以通过支持流媒体的HTTP路由、身份验证和可观察性系统。必须禁用缓冲，空闲超时需要对齐，私有流不得缓存。

WebSocket需要在负载均衡器、网关和服务器之间支持握手和长期连接。连接排放和节点所有权会变成明显的操作问题。当事件源于持有客户端连接以外的节点时，两者都需要一个代理或共享日志。

身份验证和授权

本地事件源通常依赖于cookies或经过仔细限定的URL，因为它不提供任意请求头。基于取的SSE客户端可以提供更多的头控制，但必须自行实现流解析和重连行为。

WebSocket身份验证可以在握手期间或在初始应用程序消息中进行。验证来源，避免持久的URL秘密，并授权每个订阅和命令。 浏览器WebSocket标准 描述了客户端安全模型，而业务授权仍然是服务器策略。

慢速客户端和背压

这两种设计可以在客户端读取速度慢于服务器发布时积累数据。SSE服务器应限制响应缓冲，合并可替换值，并关闭超过政策的流。

经典浏览器WebSocket API也缺乏内置的背压。服务器需要每个连接的队列限制和与应用程序语义匹配的消息丢弃规则。度量显示可能仅保留最新值；审计流可能需要持久存储和基于光标的赶上，而不是无限内存队列。

一个可以演变的决定

当交付是单向的、文本足够、HTTP集成有价值且自动事件源行为减少代码时选择SSE。当产品已经需要频繁的上游消息、二进制帧或单个交互会话协议时选择WebSocket。

混合架构可以安全地演变。首先使用HTTP命令加SSE更新，然后在双向频率占主导地位时将某个功能移到WebSocket。在实时协作使用套接字时，即使仍在HTTP中保持持久的资源读取。

服务器发送事件与 WebSocket 验证计划

SSE 是单向的；WebSocket 是双向的。方向是最明确的首要决策。验证该声明是否贯穿整个生产路径。从一个小的代表性交换开始，记录客户端和边缘的协商行为，并确认应用程序通过相同的网关、代理、证书终止点和实际流量使用的网络策略接收预期的字段、帧或事件。

将第一个设计假设变成失败练习：写下哪个方向启动消息。然后检查第二个假设周围的资源压力：决定是否需要二进制有效载荷。正确的实现应在记录的限制内失败，释放连接和缓冲状态，并留下一个不暴露凭证或私有有效载荷的结果解释。

生成文本和实时协作练习设计的不同部分，因此兼容性测试应包括与之相关的两种流量形态。添加一个当前浏览器、一个非浏览器客户端、一个较慢的网络路径，和支持的最老中介。记录版本选择、连接生命周期、消息或响应年龄、队列深度以及首选路径及其回退的关闭原因。

在测试过程中将语义和传输视为独立层。成功的连接并不能证明应用程序正确处理了排序、授权、取消、缓存、重播或状态恢复。同样，应用程序错误也并不能证明协商的协议失败。用资源、用户范围、逻辑操作和连接标识符标记观察，然后比较每个端点认为发生了什么。这种分离使容量工作更加有用：团队可以看出延迟是来自连接设置、网络传递、排队、应用程序处理、序列化还是慢接收者。在常规遥测中保持私有内容的安全，同时保留足够的时序和结果数据以再现决策。

服务器发送事件与 WebSocket 在实践中的表现

服务器发送事件与 WebSocket 生产检查列表

• 写下哪个方向启动消息。 将这个点转化为书面接受测试，以便审阅者能够区分预期行为与意外实现细节。
• 决定是否需要二进制有效载荷。 命名拥有该设置的组件以及在其观察行为变化时做出响应的人员或团队。
• 定义重播和快照行为。 捕获日志或跟踪中相关的信号，然后验证该信号在真实路径中的每个代理、网关和服务边界中都存活。
• 选择适合浏览器 API 的身份验证机制。 用正常情况、慢速对等、关闭连接、超大输入和版本或功能不匹配测试该决定。
• 测试代理缓冲和空闲超时。 记录安全默认值以及允许例外的确切条件；隐藏的例外在后期更改中会变成互操作性问题。
• 限制每个客户端队列。 从一个代表性的浏览器或客户端检查此行为，而不是仅依靠本地单元测试或服务器端配置屏幕。
• 规划多节点事件路由。 设置有限的资源限制，并使结果拒绝对操作员和调用应用程序均可见。
• 授权每个主题和命令。 保留足够的标识符以关联客户端、边缘、应用程序和任何异步工作者之间的逻辑交换。
• 在客户端测量事件年龄。 在流量形状变化后审查选择，因为连接数、负载大小和消息频率可能会改变正确的设计。
• 保持可通过HTTP访问的持久资源状态。 保持可观察和测试的后备路径，以便兼容性不依赖于一个悄悄停止工作的旧路径。

结论

SSE是单向的；WebSocket是双向的。方向是最清晰的第一个决定。两者都需要背压和授权设计。打开连接并不会消除应用程序限制。用明确的限制、可观察的状态和由代表性客户端测试的后备来应用这两个事实，而不是从配置中假设。

参考文献

• Scrapeless抓取浏览器文档
• Scrapeless抓取浏览器产品概述
• Scrapeless WebSocket帧捕获指南