为什么 SIGnalR 更喜欢 Forever Frames 而不是轮询？答案

【问题标题】：Why does SIgnalR prefer Forever Frames over polling?为什么 SIGnalR 更喜欢 Forever Frames 而不是轮询？
【发布时间】：2016-09-16 01:06:00
【问题描述】：

我正在学习使用 SignalR，到目前为止，我在这方面取得了成功。我可以实现集线器，我可以实现业务逻辑，我可以从我想要的服务器调用客户端函数，我可以从客户端调用服务器端方法，这东西很棒。令我困惑的是理论。

事实上，我从这个video 收集了信息。 SignalR 正在使用WebSockets，它通过单个TCP 连接提供full duplex channel。如果没有可用的 WebSocket，则回退协议将为 EventSource。如果不可用，则将使用 Forever Frame。如果不可用，则将使用长轮询。对我来说很奇怪的是，一个非常老套的解决方案，比如永久框架比旧的约定更受欢迎，我对 SignalR 决定将永久框架作为第三个选项并将轮询作为第四个选项背后的基本原理感兴趣。

我试图找出这个问题的答案，我发现有传言说there is a 3x max latency time in the case of long polling compared to forever frames。这是事实吗？如果是，是所有浏览器的事实，还是部分浏览器的事实？

【问题讨论】：

标签： websocket signalr long-polling eventsource forever-frame

【解决方案1】：

foreverFrame 的工作方式有点像 serverSentEvents - 有一个长时间运行的 http 请求，服务器永远不会终止，而是用来将数据推送到客户端。 longPolling 的工作方式不同 - 每次有数据供客户端读取（或超时到期）时，服务器都会关闭一个 poll http 请求。如果客户端想要读取更多数据，它需要打开一个新的 http 请求，一旦客户端有任何数据，服务器就会再次关闭该请求。换句话说，在foreverFrame的情况下，服务器使用已经建立的通道将数据推送到客户端，而在longPolling的情况下，客户端不断创建http请求以从服务器获取数据。

【讨论】：

理解并感谢您的回答，您的回答值得一票。但是，我不知道您是否可以事实上确认由于轮询器每次发送数据时需要打开 HTTP 通道而导致的 3 倍延迟确实存在。
发送数据的工作方式相同——在这两种情况下都会创建一个新的 http 请求，所以我想说发送数据时，foreverFrame 和 longPolling 之间的延迟没有区别。
接收时有延迟吗？
是的，如果短时间内发送了多条消息。要接收第二条（以及后续）消息，longPolling 每次都需要启动一个新的 http 请求，而 foreverFrame 不必这样做，因为它使用一个请求来接收所有数据。