我有一个在 IIS 服务器上运行的 Blazor 服务器应用程序。我没有意识到我需要在 IIS 中启用 WebSockets，因此我的应用程序一直使用长轮询而不是 WebSockets 来运行其 SignalR 连接。
应用程序在大多数情况下运行良好，但如果我在新选项卡中快速打开很多链接，前几个选项卡加载页面没有问题，但随后其余选项卡部分加载页面并且选项卡“旋转” “ 图标永远保留。似乎每个后续选项卡的加载速度都不会变慢；相反，前几个选项卡加载速度很快，然后其余选项卡永远无法完成加载。
启用 WebSockets 后，我似乎不再遇到这个问题（或者至少在 20 个左右的选项卡上不会出现问题）。
当我使用长轮询时，什么会导致最后几个选项卡永远无法完全加载，以及使用 WebSockets 显然如何解决这个问题？我知道 WebSockets 更高效，但我认为长轮询只会更慢，而不是永远无法完成加载页面，或者每个后续选项卡的加载速度会比上一个选项卡逐渐慢，但最终会完成加载。
长轮询基于 HTTP 连接，因此容易受到 并发 HTTP 连接上的浏览器限制。
WebSocket 创建持久的全双工连接，可以同时打开多个页面，而不会因浏览器的并发连接限制而遇到性能问题。
相关链接
使用长轮询/Atmosphere 和 Firefox 或 Chrome 时无法打开超过 5 个浏览器选项卡
长轮询的解决方法
在 Signalr 中，使用 WebSocket 是最佳实践。