.NET 7 MVC应用SignalR请求量异常偏高及WebSocket修复后疑问

一、SignalR请求量是否正常？ #

50-60并发用户，10分钟内产生21000+次SignalR请求，明显不符合仅用于提示框和少量UI更新的场景预期。正常情况下，SignalR在WebSocket模式下仅需维持持久连接，加上默认每30秒一次的心跳帧（非HTTP请求），总请求量应该远低于这个数值。

二、WebSocket未启用是否是请求量偏高的核心原因？ #

是的，这是导致请求量激增的关键因素：

• 未启用WebSocket时，SignalR会自动降级为长轮询（Long Polling）模式。该模式下，客户端会持续发送请求到服务器等待消息，若无消息则超时返回空响应，随后客户端立即发起新请求。50-60个活跃用户的话，10分钟产生2万+请求完全符合长轮询的行为特征。
• 启用WebSocket后，SignalR会建立持久双向连接，仅需少量心跳帧维持连接，业务推送也通过已建立的连接传输，不会产生大量HTTP请求，请求量会大幅下降。

三、其他潜在问题排查方向（结合代码） #

1. 客户端异常重连 #

• 检查前端TypeScript代码：是否存在连接频繁断开后立即重连的逻辑，未设置指数退避等合理重连策略；是否在页面跳转/组件渲染时未销毁旧连接，导致单个用户存在多个活跃连接。
• 排查Azure App Service实例是否存在频繁重启/缩放，导致连接被强制中断触发重连。

2. 心跳配置不合理 #

• 确认是否修改了SignalR默认的KeepAliveInterval或ClientTimeoutInterval为过小值，导致心跳请求频率异常升高；是否存在自定义心跳逻辑，额外产生请求。

3. 业务逻辑错误触发频繁推送 #

• 检查AppGlobalHub：是否存在循环推送、重复订阅事件的逻辑；是否在业务操作中无意触发了大量提示框推送。
• 检查控制器注入Hub上下文后的推送逻辑：是否存在批量推送时的重复发送错误。

4. 连接管理不当 #

• 确认前端是否在用户登录后重复创建SignalR连接，未正确销毁旧连接，导致单个用户占用多个连接资源，每个连接都会产生请求。

四、诊断方法 #

1. 分析Application Insights请求详情
   • 筛选/global和/global/negotiate请求，查看请求分布：是否来自同一批客户端IP，是否存在短时间内大量重复请求的客户端；查看响应状态码，是否有大量400/500错误（连接异常信号）。
2. 启用SignalR详细日志
   • 在Startup.cs中添加日志配置：

     builder.Logging.AddFilter("Microsoft.AspNetCore.SignalR", LogLevel.Debug);
     builder.Logging.AddFilter("Microsoft.AspNetCore.Http.Connections", LogLevel.Debug);
     

     通过日志查看连接建立、断开、重连的细节，以及消息传输情况。
3. 前端调试
   • 在浏览器开发者工具Network标签中筛选SignalR请求，观察请求频率、类型（轮询请求/WebSocket帧），以及是否触发重连逻辑；查看控制台是否有连接错误、断开的日志。
4. 确认Azure配置
   • 在Azure门户的App Service配置（设置>配置>常规设置>WebSocket）中确认已启用WebSocket，且代码中未禁用：

     app.UseEndpoints(endpoints =>
     {
         endpoints.MapHub<AppGlobalHub>("/global");
         // 确保无.DisableWebSocket()配置
     });
     

五、代码检查要点 #

• Startup.cs：确认SignalR服务注册正确，Redis背板配置无误，未禁用WebSocket。
• AppGlobalHub.cs：检查OnConnectedAsync/OnDisconnectedAsync方法是否有异常逻辑，Hub方法是否被频繁调用。
• 前端TypeScript：确认连接创建逻辑仅执行一次，重连策略合理，正确处理连接状态变化。

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