为什么Websockets比Server Sent Events更快

Question

您好我目前来到this paper，我无法弄清楚为什么服务器发送事件从服务器推送到客户端的速度较慢。

由于XHR的HTTP开销，我可以看到SSE对于聊天应用等双向通信的速度较慢。

Answer 1

如果您查看第6页上的图表，您会发现该声明主要基于＆＃34;服务器更新＆＃34; SSE上的速度较慢。

这是正确的，因为服务器端事件是一种将数据推送到客户端而不是将数据发送到服务器的技术！那些需要新的HTTP请求，并且可能建立新的TCP（有时是TLS）连接，这对于卫星链路和CPU和内存较慢的移动设备而言非常昂贵。

这使得论文的作者可以争辩说，无论交互类型和传输数据的类型如何，websocket都更快，这对于普遍存在的状态并不完全正确。

我不是在这里比较功能。 Websocket和SSE清楚地解决了类似但不同的问题，应该被评估为适用于特定项目，不应该有一个普遍的答案来使用这些。

Answer 2

我认为这里结合了两种效果，导致声称WebSockets更快＆＃34;比SSE。

效果1：SSE具有较低的有效负载消息比率 正如您所指出的那样，一般来说，与双向通信模式中更紧凑的有效负载和使用WebSockets的仔细协议设计相比，HTTP请求/响应的开销更大。

效果2：SSE可能涉及会话重新连接 正如@alexsergeyev指出的那样，SSE会话可以重新连接，但在大多数现代浏览器中，只是意味着SSE会话确实使用池化TCP连接重新创建，因此对

的影响

结合这两种效果，并以字节/秒为单位定义吞吐量作为指标，我希望我们可以看到，即使是单向服务器到客户端的通信，由于这两种影响，WebSockets的吞吐量也会更好。

据我所知，随着WebSocket感知中介的采用起飞，SSE的角色将随着时间的推移而减少。现在，如果您依赖HTTP来处理安全性故事，除非您有严格的实时要求，否则可以选择SSE。如果您这样做，Kaazing Enterprise WebSocket网关为大多数安全系统提供内置的SSO集成。