我目前正在构建聊天,只是为了好玩。我之前从未这样做过,而且我在一般情况下尝试在JavaScript
中试用EventSource API (Server-Sent Events)
。我刚刚听说它约3天前,我认为这比设置WebSocket
更有趣,也更容易。
我知道漫长的民意调查耗费了大量资源。但是,由于我从未听说过EventSource,它如何影响服务器?它是否耗尽了相同数量的资源?
我注意到在Networks Tab
的{{1}}中,EventSource会创建一个内容大(随时间变化)的请求。最好有1个内容大的请求吗?
我的聊天目前正在运行两个EventSource。一个用于聊天本身(每个Google Chrome Developers Tool
运行)和聊天中的“正在输入...”机制(每2500ms
运行一次)。
在聊天大约一分钟后,两个请求的合并内容大小约为250ms
。这会增加更多的消息。
我担心我的主人会暂停我的帐户。这是我的一个朋友发生的事情,他使用了民意调查或长期民意调查(我忘了)。我不确定EventSource是否使用尽可能多的资源来进行轮询或长轮询。
答案 0 :(得分:3)
长轮询比EventSource使用更多资源,因为它不断建立和销毁连接。使用EventSource,只使用一个连接,客户端正在等待数据,而不是检查服务器是否有新数据。
使用长轮询时,客户端将在以下条件下断开连接:
当服务器没有数据时,客户端将等到其超时,直到服务器有数据。如果有数据,客户端将断开连接并创建另一个连接。如果客户端超时,客户端将断开连接并建立另一个连接。因此,您可以从许多地方看到开销。
长轮询
<强>的EventSource 强>
GET
标题Accept: text/event-stream
请求发起
<强>的WebSockets 强>
HTTP GET
标题Upgrade: websocket
请求启动
资源消耗:
EventSource的开销主要是存在连接。它类似于这种意义上的websockets,其中建立和维护单个连接。因此,由于常量的建立/销毁周期,来自websockets的第二大开销(因为它们是双向的),并且来自EventSource(单向),所以使用长轮询将获得最大的开销。
更好的选择:
对于客户端和服务器之间的实时和双向通信,您实际上没有比websocket更好的东西。这是客户端和服务器正在监听彼此数据的一种解决方案,而不是互相推送数据。
SSE请求
我认为您在假设您认为Chrome中显示的内容是个别请求时会问这个问题。由于EventSource与服务器建立套接字,因此实际上是在读取通过EventSource套接字发送的累积数据量。因此,当您发送数据时,您正在重用相同的连接,并且您无需担心请求大小。
总之,大多数主机暂停轮询的原因是由于短轮询和长轮询所需的大量请求。如果使用EventSource或websockets,则使用的是使用套接字的实时通信,这些套接字不会通过请求“垃圾”HTTP服务器。 (如果我发送了100个数据有效负载,EventSource和websockets将使用相同的连接,长轮询将重新连接至少100次)这里你唯一需要注意的是服务器可以处理的最大并发连接数,因为套接字使用比轮询更少的CPU和资源。
关于EventSource / SSE的事情要考虑:
答案 1 :(得分:1)
要了解SSE对服务器的影响,您需要了解它们的工作原理。我将首先解释一下长轮询,因为它是最接近的选择。
长轮询
通过长轮询,客户端向服务器发送请求,服务器保持该状态;如果没有什么可说的,它就不会发送回复。对于您的聊天示例,您可以发送一个请求,其中包含您收到的最新消息的ID,服务器将延迟发送响应,直到他们需要向您发送新消息为止,此时响应将被释放。
缺点是即使没有使用连接并且脚本正在运行(可能不时地轮询DB以获取新消息),连接也会保持活动状态。每次服务器向客户端发送内容时,您仍需要新连接。
与常规民意调查相比,优势在于流量大大减少,因为只有在有话要说时才会给出响应。
服务器已发送事件
SSE非常像长轮询,因为它需要来自客户端的连接,并且只有在有话要说时才发送消息,但最大的区别在于连接没有用第一条消息关闭。显然,不必为每条消息建立新连接是一种胜利,不幸的是,服务器上的负面效果是相似的:连接保持活动状态,服务器脚本保持运行。优点是客户端只发送一个请求。
网络套接字
Web套接字提供真正的双向通信,但保持连接打开的原则是相同的。您可以从这里获得的优势是您可以按照自己的意愿打包信息。
需要注意的是,不同的服务器可以以不同方式处理这些情况。由于它专注于异步事件,无论您使用长轮询,SSE还是Web套接字,NodeJS似乎都更适合作为聊天系统的服务器组件。
至于你的最后一个问题,这在很大程度上取决于你所处的情况以及“更好”的意思。如果更好地意味着更少的网络流量,那么大响应应该比多个短响应少得多。
总结一下: