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

Question

我刚刚阅读了RFC-6202，并且不明白使用SSEs相比于简单请求分块流的好处。例如，当你想要使用纯HTTP技术实现客户端和服务器之间的事件“订阅”时，会遇到什么问题？如果服务器保持初始HTTP请求打开，并在新事件出现时偶尔发送新的数据块，这会有什么缺点呢？

我发现一些反对此类流媒体的观点，其中包括以下内容：

• 由于传输编码是逐跳传输而非端到端传输，因此中间代理可能会尝试在将响应转发给客户端之前合并这些数据块。
• TCP连接需要在客户端和服务器之间始终保持打开状态。

然而，在我的理解中，这两个观点同样适用于SSEs。我可以想象另一个潜在的观点是，JavaScript浏览器客户端可能没有机会实际获取相应的数据块，因为重新组合它们是在更低的级别上处理的，对客户端来说是透明的。但我不知道是否真的是这种情况，因为视频流必须以某种类似的方式工作，或者不是吗？

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

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

- n1try

Answer 1

你说得对，SSE是基于分块HTTP的一个很好的API。这个API很好用，而且还支持重新连接。

关于你提到的在SSE上发送二进制数据的问题，我没有相关经验。不过，你可以通过HTTP发送二进制数据，所以我认为你应该是可以做到的。不过，你可能需要在JavaScript中进行转换。

- baynezy

Answer 2

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

如果您想将其用于流式传输二进制数据，那么肯定不是正确的API。主要原因是SSE是基于文本的协议（它由“\n”分隔，并且每行都以文本标签开头）。如果您仍然想尝试在SSE上使用二进制，一个快速而脏的解决方法可能是将二进制数据提交为Base 64。

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

- Mario