为什么SIgnalR更喜欢Forever Frames而不是轮询?

时间:2016-09-16 01:06:01

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

我正在学习使用SignalR,到目前为止我已经成功地这样做了。我可以实现Hubs,我可以实现业务逻辑,我可以从我想要的服务器调用客户端功能,我可以从客户端调用服务器端方法,这个东西很棒。令我困惑的是理论。

事实上,我从这个video收集了信息。 SignalR正在使用WebSockets,它在单个full duplex channel连接上提供TCP。如果没有可用的WebSocket,则回退协议将为EventSource。如果不可用,则将使用Forever Frame。如果不可用,则将使用长轮询。对我来说,一个非常讨厌的解决方案,比如永久的框架比旧的惯例更受欢迎,我感到很奇怪,我对SignalR决定将永久帧作为第三选项并将其作为第四选项进行投票的理由感兴趣。

我试图找出这个问题的答案,但我发现传闻there is a 3x max latency time in the case of long polling compared to forever frames。这是事实,如果是这样,对所有浏览器或子集来说都是事实吗?

1 个答案:

答案 0 :(得分:1)

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

相关问题