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

Question

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

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

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

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

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

Answer 1

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

如果您想将它用于流式传输二进制数据，那肯定不是正确的 API。主要事实是 SSE 是一个基于文本的协议(protocol)(它由 '\n' 分隔并且每一行都以文本标记开头。如果您仍然想通过 SSE 试验二进制文件，一个快速而肮脏的 hack 可能是提交二进制文件Base 64 中的数据。

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