为什么SIgnalR更喜欢Forever Frames轮询？

我正在学习使用SignalR，到目前为止，我在这方面取得了成功。我可以实现集线器，我可以实现业务逻辑，我可以从服务器调用客户端功能，我可以从客户端调用服务器端方法，这很棒。令我困惑的是理论。为什么SIgnalR更喜欢Forever Frames轮询？

事实上，我从这个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。这是一个事实吗？如果是这样，这是所有浏览器或子集的事实吗？

来源

2016-09-16 Lajos Arpad

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

来源

2016-09-16 02:27:20 Pawel

理解并感谢您的答复，这已经是值得赞赏的。但是，我想知道是否可以真实地确认每次轮询器发送数据时由于需要打开HTTP通道而产生的3倍延迟实际上存在。 –

发送数据的方式相同 - 在这两种情况下都会创建一个新的http请求，所以我会说在发送数据时foreverFrame和longPolling之间的延迟没有区别。 – Pawel

接收时有延迟吗？ –

为什么SIgnalR更喜欢Forever Frames轮询？

回答

相关问题