问题标签 [forever-frame]

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

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

我试图找出这个问题的答案，我发现据传，与永远帧相比，长轮询的最大延迟时间是 3 倍。这是事实吗？如果是，是所有浏览器的事实，还是部分浏览器的事实？

这个问题和这个问题非常相似：web sockets, long polling, server-sent events and forever frame有什么区别？

但是，这个问题的答案没有提到 SSE 和 Forever-frame 之间的区别。
让我给你简要解释一下。

对于SSE来说，这个系统确实很像Comet，但和Comet不同的地方是数据发送后不会断开连接。因此，从服务器到客户端的连接是长期有效的，并且客户端会接收到整个数据的一系列片段。

另一方面，永远框架似乎与我非常相似。在 Forever 框架中，首先客户端接收包含 iframe 标记的页面，在隐藏的 iframe 内建立长期连接。然后客户端从服务器接收分块数据，并在客户端已经拥有的第一个文档上使用一些函数来操作 DOM。

我假设不同之处在于 Forever-frame 在机制中使用 iframe 标签，但 SSE 没有，并且 SSE 可以通过更多方式实现。我对吗？

在使用 HTTP 流的 WebSocket 回退中，我可以看到XmlHttpRequest#responseText每次readystate更改时都会调用它（并且 >= 3）。

WHATWG 生活标准说文本响应是

...decode使用回退编码字符集在接收到的字节上运行的结果。

我认为这意味着每次以这种方式进行更改时，都会创建一个大小与将自发出 HTTP 流请求以来收到的所有数据编码为 UTF-16 的结果相对应的新字符串。readystate

我观察到周期性（即对于 HTTP 流响应缓冲区较大的时期 - 它会定期重置）在使用这种技术时 JavaScript 堆中的大量内存搅动，每秒大约有 5 条消息传入客户端并认为它是与上述方法有关。

这听起来合理吗？

有没有人找到任何技术来减少这种 HTTP 流技术对内存子系统的影响（例如，缩短每个 HTTP 流连接的寿命）？

我有一个基于 SignalR 的 .NET 4.5 应用程序。服务器后端是用 C# 编写的，我只有 Javascript 客户端连接到我的集线器。目前我正在测试最新的 SignalR 版本 2.2.2。

我的应用程序通常托管在较旧的 Windows Server 2008 R2 和 IIS 7.5 上，而且我的用户也在 IE10 或 IE11 上。这会减少对 foreverFrame 和 longPolling 的可用传输。

最近我们开始收到更多关于 JS 客户端断开连接的报告。我很快注意到 ForeverFrame 不再工作了，所有的 JS 客户端都在使用 longPolling。

这个问题现在专门针对 ForeverFrame 不起作用（如有必要，我将发布一个关于 longPolling 问题的单独问题）。

以下是我如何重现该问题（foreverFrame 传输不起作用）：

• 我的应用程序在 Windows Server 2008 R2 和 IIS 7.5 上运行（服务器定期使用安全和关键补丁进行修补）
• 使用 IE11 访问我的测试页面
• 远程连接（换句话说，不是从服务器本地连接）
• 在控制台中我看到：SignalR：尝试连接时，foreverFrame 传输超时。"
• SignalR 回退到 longPolling，它开始正常
• 在集线器方面，我已经覆盖了 OnConnected 和 OnDisconnected，有趣的是我没有看到 OnConnected 触发，但 OnDisconnected 触发了
• 在 Developer Tools Network 选项卡中，我看到 foreverFrame 的 (Abort)：

URL Protocol Method Result Type Received Taken Initiator Wait‎‎ Start‎‎ Request‎‎ Response‎‎ Cache read‎‎ Gap‎‎ /MMCI/signalr/connect?transport=foreverFrame&clientProtocol=1.5&connectionToken=4MQ9IexTBePfDa7ilqJuKLoxAW5cpgSSK171zjD18vmXtdEKNEIWyFnFYYWlEKjTt49Ou9lLps961D3LTMxGNzW0GzIlBsLtmIA%2BgVQZz0nL71f6fK6jkfrOn5dcHoyz&connectionData=%5B%5D&tid= 10&frameId=1 HTTP (Aborted) 0 B < 1 ms 帧导航 484 0 0 0 0 5335

有趣的是，如果我在本地连接，则不会发生此问题。我什至可以在本地的旧服务器上使用 IE8，并且 foreverFrame 启动正常。或者我可以在我的笔记本电脑上本地使用 IE11 并在 IIS Express 上运行我的应用程序，一切都很好。但是当我远程浏览到我的网站时，foreverFrame 无法启动。

值得一提的是我的 ConnectionTest.html 的代码：

这也是刷新我的测试页面时来自 IE11 的完整调试控制台输出：

这是从服务器本身在本地访问相同的 URL 时 IE8 的输出（相同的结果在我的笔记本电脑上本地发生，带有 IE11 和 IIS Express）：

所以....有什么想法吗？:)

更新： 我可以反过来测试：使用 IE8 从 Win2008R2 服务器连接到笔记本电脑上的 IIS Express。在这种情况下，ForeverFrame 完全正常启动。所以目前这似乎是一个 IE11 问题。试图弄清楚如何进一步调试......

更新 2： 经过更多测试后，我得出结论，当满足以下所有条件时，foreverFrame 不起作用：

• 带有 IE11 的 Win 7 工作站
• 连接到远程站点（意味着不是本地主机）
• 使用 URL 中的 IP 地址连接

但是，如果以下任何一项为真，那么 foreverFrame 似乎立即起作用：

• 连接到 localhost 而不是远程服务器，或者
• 使用更新的 Windows 版本（但仍然是 IE11），或
• 使用 FQDN 而不是 IP 地址进行连接。

非常非常奇怪...我也发布到 ASP.NET 论坛、IE11 论坛和 IE11 开发者论坛，但那里没有真正的帮助。我现在决定不再深入探讨这个问题。此外，我也不会进一步调查 longPolling 问题。我刚刚编写了自己的心跳机制和连接重启处理程序......

所以这个问题仍然没有答案，但对我来说不再是一个真正的问题。

更新 3： 不幸的是，我不再有可能使用旧操作系统 Win 7 或 Win Server 2008 进行测试。此外，我已经更新到最新的 SignalR。所以这个问题仍然是一个谜，但我不再需要答案。

如何在 Fiddler 中查看 Signalr Forever-Frame 消息？

我在 Fiddler 中切换 Stream，但没有看到从我的服务器到客户端的 Forever-Frame 消息，如何在 Fiddler 中看到它？