使用Long Polling的SignalR快速开新标签页导致部分标签页加载失败

一、Long Polling模式下多标签页加载失败的原因 #

• 浏览器并发HTTP连接限制：浏览器默认对同一域名的并发HTTP连接数做了限制（通常是6个）。Long Polling的SignalR连接依赖持续的HTTP长连接，每个标签页的Blazor应用都会占用至少一个这类长连接。快速打开大量标签页时，超过限制的请求会被浏览器阻塞排队，而Blazor Server的页面初始化必须等SignalR连接建立完成才能继续，排队的请求迟迟无法完成连接，自然会让页面卡在加载状态。
• 服务器端连接资源耗尽：IIS本身有并发连接数的配置阈值（比如maxConcurrentRequestsPerCPU、maxConcurrentConnections）。Long Polling的长连接会持续占用服务器的连接资源，短时间内大量请求涌入，服务器资源被占满后，无法处理新的连接请求，后续标签页的SignalR连接建立失败，页面也就无法完成加载。
• 高开销导致的性能瓶颈：每个Long Polling请求都要走完整的HTTP握手流程，还要传输冗余的HTTP头部。大量这类请求同时发起时，服务器的CPU、内存消耗会急剧上升，处理能力跟不上，部分请求会因为超时或资源不足失败，最终表现为页面加载不完整。

二、WebSockets解决问题的核心原理 #

• 突破HTTP并发限制：WebSocket是独立于HTTP的TCP双向通信协议，不属于浏览器的HTTP并发连接限制范畴，浏览器对WebSocket的并发数限制远高于HTTP。每个标签页只需要一个WebSocket连接就能完成Blazor Server的所有双向通信，不会出现请求排队阻塞的情况。
• 极低的通信开销：WebSocket连接建立后，后续通信无需重复发送HTTP头部，数据传输的体积和服务器处理开销都大幅降低，服务器可以同时承载更多的连接，不会像Long Polling那样快速耗尽资源。
• 持久化实时通信：WebSocket是持久化的双向连接，Blazor Server可以通过这个连接实时推送页面初始化所需的内容，不需要像Long Polling那样等待请求响应，页面初始化流程能快速完成，不会因为连接延迟或超时导致加载停滞。

内容的提问来源于stack exchange，提问作者Ben Rubin