javascript - 自 Chrome 88 以来的 SignalR 和/或计时器问题

Question

我们有一个 ASP.Net WebForms 应用程序，它使用 SignalR (v2.4.1) 在服务器和客户端之间进行一些双向通信。多年来一直运行良好:连接稳定，数百名用户使用它，等等。
然而，我们已经开始从我们的客户群中收到零星的连接问题报告，所有报告都报告相同的事情:如果浏览器 (Chrome) session 空闲超过 5 分钟，则连接在后台断开。页面中的所有计时器都停止定期运行，这(除其他外)停止“keepalives”停止发送，最终连接失败并出现客户端错误:

The client has been inactive since <date> and it has exceeded the inactivity timeout of 50000 ms. Stopping the connection.

此后的标准程序是自动重新启动连接，但这没有任何作用。如果/当用户重新激活页面(例如，通过切换到选项卡)，一切都开始恢复活力，尽管 SignalR 连接关闭。
经过大量调查，我们似乎受到了 this change 的影响。在 Chrome v88 中引入，其中计时器( setTimeout s)受到严格限制，如果

页面已隐藏超过 5 分钟

计时器已被“链接”了 5 次或更多次——我假设这类似于递归，即计时器调用自身。

页面已“静默”30 秒

5 分钟/30 秒条件符合我们得到的报告。然而，我们在页面上运行非常基本的 Javascript: setTimeout 只有两种用途。在我们自己的代码中，它们都不能“链接”(递归)到自己身上。我们也无法复制这个问题:它在测试中发生在我们身上，但我们无法让它可靠地发生。通过 chrome://flags/#intensive-wake-up-throttling 禁用此功能似乎可以缓解这个问题 - 但当然，我们不能将此作为使用我们网站的要求。
网站上唯一运行的其他 Javascript 是 jquery.signalR-2.4.1.js ，并且来自 SignalR 源，有很多 setTimeout s 在里面。 SignalR 是否会受到 Chrome 中的这种变化的影响？也许当它在临时网络问题或其他不可预知的事件后尝试静默重新连接时？
如果没有，是否有任何方法可以在任何浏览器或 IDE 中跟踪已启动的计时器(更重要的是，“链式”)，以便我们可以看到是什么触发了此限制？

Answer 1

我们也面临着我们的 signalR(WebSockets 作为传输)的问题。我们无法在我们的实验室复制它。我们客户的 HAR 文件和扩展日志记录仅向我们提供了以下信息:客户端“仅在关注感兴趣的组后才消费”没有在保持连接所需的默认 30 秒内发送 ping。因此服务器关闭连接。我们在 signalR 客户端库中添加了日志，只看到 ping 计时器没有按时命中。没有错误，什么都没有。 (客户端是 JavaScript，并且问题发生在 chrome 87 中的客户站点上(已经为一半的 chrome 用户实现了节流 - https://support.google.com/chrome/a/answer/7679408#87))
世界正在慢慢意识到“一个问题”:https://github.com/SignalR/SignalR/issues/4536
我们对客户的快速帮助将是从服务器站点创建一个具有手动广播乒乓机制的 ET，每个客户都必须回答。在提供“更好”的解决方案或修复之前，避免依赖于 signalR 库中的 JavaScript ping。