为什么使用Server-Sent Events而不是简单的HTTP chunked流？

Question

我刚刚阅读RFC-6202并且无法找出使用SSE的好处，而不是简单地请求分块流。作为一个示例用例，想象一下您希望实现客户端和服务器，客户端希望＆＃34;订阅＆＃34;使用纯HTTP技术处理服务器上的事件。当新事件出现时，服务器保持初始HTTP请求打开然后偶尔发送新块会有什么缺点？ 我发现了一些反对这种流式传输的论据，其中包括以下内容：

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

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

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

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

Answer 1

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

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

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

Answer 2

你是正确的SSE是一个很好的API在分块HTTP之上。 API很好，它也支持重新连接。

关于你关于SSE二进制的问题，我没有这样做的经验。但是，您可以通过HTTP发送二进制文件。所以我认为没有理由不这样做。虽然，您可能最终必须使用JavaScript转换它。