SignalR长轮询场景下服务端无法给特定用户发消息的技术问询

嘿，你遇到的这个问题我之前帮好几个开发者排查过，核心就是SignalR的连接超时设置在搞事情，咱们一步步拆解清楚：

1. 对应的核心设置及默认值影响 #

首先得区分你用的是传统ASP.NET SignalR还是ASP.NET Core SignalR，两者的设置略有不同，但原理一致：

传统ASP.NET SignalR（非Core版本） #

最关键的设置是GlobalHost.Configuration.ConnectionTimeout，默认刚好是30分钟。这个参数的作用很直接：如果客户端和服务端之间整整30分钟没有任何通信——不管是用户发的消息、调用的方法，还是SignalR自动发的心跳包——服务端就会把这个连接标记为“已死”，并从用户和连接的映射表里删掉它。

这时候你再调用Clients.User(xxx).SendAsync(...)，服务端找不着这个用户的有效连接，消息自然就发不出去了。但为啥用户还能调用服务端方法？因为长轮询的客户端在发起调用请求时，会自动重新和服务端建立新连接，服务端会把新连接重新绑定到这个用户身上，所以调用能成功，但之前丢的消息就找不回来了。

ASP.NET Core SignalR #

如果是Core版本，对应的是HubOptions.ClientTimeoutInterval和HubOptions.ServerTimeoutInterval，默认都是30秒——不过你说的是30分钟，大概率是手动把超时改到了30分钟，或者用的是传统SignalR。原理和上面一样：超时后服务端清掉连接映射，定向消息找不到目标。

另外还有个和超时配合的心跳设置：传统版是KeepAlive（默认10秒），Core版是HubOptions.KeepAliveInterval（默认15秒）。这个是服务端主动发心跳包的间隔，正常情况下心跳能维持连接活跃，不会触发超时，但如果客户端网络静默断了（比如手机锁屏、防火墙拦截心跳），心跳发不到客户端，服务端就会触发超时清理。

2. 修改这个设置的影响 #

• 调大超时值：比如改成1小时，确实能减少这类丢包情况，用户闲置更久也能收到消息，但代价是服务端要维护更多闲置连接，内存和连接数压力会变大，如果你的用户量很大，得考虑服务器扛不扛得住。
• 调小超时值：会更快清掉闲置连接，节省资源，但用户稍微闲置一会儿就可能收不到消息，体验会打折扣。
• 要和心跳设置配合调：比如你把超时改成60分钟，最好把心跳间隔调到20秒左右，让服务端能及时检测连接是否真的活著，别误判。

3. 默认值设为30分钟的原因 #

这个是SignalR团队在用户体验和服务器资源之间找的平衡点：

• 30分钟是个很常见的用户临时闲置时长——比如用户开着页面去开个短会、吃个饭，回来还能正常收消息，不用重新加载页面或者重连。
• 同时，30分钟也不会让服务端一直占着大量闲置连接资源，避免浪费服务器性能。

4. 哪些场景容易碰到这个问题 #

• 长轮询传输模式：长轮询是基于HTTP请求的，没有持久连接，服务端只能靠超时判断连接死活，不像WebSocket那样有实时的连接状态反馈，所以更容易出现这类问题。
• 客户端静默离线：比如用户把浏览器最小化挂后台、手机锁屏、网络突然断了但客户端没触发重连（长轮询客户端只有在发下一次请求时才知道连接断了）。
• 用户完全闲置无交互：用户打开页面后啥也不干，连心跳包都因为网络问题没传过来，超过30分钟就会触发超时。
• 服务端资源紧张：如果服务器内存不够、连接数到上限了，可能会提前清掉闲置连接，哪怕没到超时时间。

最后给你个排查小技巧：在服务端的Hub里重写OnDisconnectedAsync方法，打印断开的原因，看看是不是超时导致的；同时在客户端监听onclose事件，看客户端有没有收到断开通知，这样就能精准定位问题了。

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