为什么使用服务器发送事件而不是简单的 HTTP 分块流？答案

【问题标题】：Why use Server-Sent Events instead of simple HTTP chunked streaming?为什么使用服务器发送事件而不是简单的 HTTP 分块流？
【发布时间】：2016-10-06 06:34:17
【问题描述】：

我刚刚阅读了RFC-6202，但无法弄清楚使用 SSE 而不是简单地请求分块流的好处。作为一个示例用例，假设您想要实现客户端和服务器，其中客户端想要使用纯 HTTP 技术“订阅”服务器上的事件。服务器保持初始 HTTP 请求打开，然后在新事件出现时偶尔发送新块的缺点是什么？我发现了一些反对这种流媒体的论据，其中包括：

由于Transer-Encoding 是跳到跳而不是端到端的，中间的代理可能会在将响应转发给客户端之前尝试合并块。
客户端和服务器之间的 TCP 连接需要始终保持打开状态。

但是，据我了解，这两个论点也适用于 SSE。我可以想象的另一个潜在论点是 JavaScript 浏览器客户端可能没有机会实际获取相应的块，因为重新组合它们是在较低级别处理的，对客户端透明。但我不知道事实是否如此，因为视频流必须以某种类似的方式工作，或者不是？

编辑：同时我发现 SSE 基本上只是一个分块流，由更易于使用的 API 封装，对吗？

还有一件事。 This page 首先告诉 SSE 不支持流式二进制数据（出于哪个技术原因？）然后（在底部），他们说这是可能的，但效率低下。有人可以澄清一下吗？

【问题讨论】：

标签： http server-sent-events

【解决方案1】：

是的，SSE 是一个基于 HTTP 的 API，它为您提供一些不错的功能，例如在客户端/服务器端自动重新连接或处理不同类型的事件。

如果您想将它用于流式传输二进制数据，请确保它不是正确的 API。主要事实是 SSE 是一个基于文本的协议（它由 '\n's 分隔，并且每一行都以文本标签开头。如果您仍然想在 SSE 上尝试二进制文件，那么可能会提交二进制文件Base 64 中的数据。

如果你想了解更多关于 SSE 的信息，也许你可以看看这个简单的库：https://github.com/mariomac/jeasse

【讨论】：

【解决方案2】：

你是对的 SSE 是基于分块 HTTP 的一个很好的 API。 API 不错，还支持重连。

关于您关于 SSE 上的二进制的问题，我没有这样做的经验。但是，您可以通过 HTTP 发送二进制文件。所以我看不出你为什么不能这样做。虽然，您最终可能不得不在 JavaScript 中转换它。

【讨论】：