我们遇到了这个链接，它指定了不同的超时属性： https ://github.com/SignalR/SignalR/wiki/Configuring-SignalR
还有这篇关于 SignalR 客户端和 SignalR 服务器之间如何断开和重新连接的精彩帖子（何时重新连接 signalR？ ）。
只是为了从上面的帖子中重新迭代不同的情况：
“当客户端脱机然后很快重新连接时会发生集线器重新连接。SignalR 配置值在很大程度上决定了以下示例的时间戳，因此不要逐字记录时间。
以下是涉及重新连接行为的几个示例及其结果（时间格式 m:ss）：
情况一
0:00 - 客户端连接到服务器，触发 OnConnected
0:10 - 客户端由于 ISP 问题而失去连接（并意识到它失去了连接）
0:15 - 客户端重新连接
0:16 - OnReconnected 事件被触发
情况2
0:00 - 客户端连接到服务器，触发 OnConnected
0:10 - 客户端由于拉动以太网电缆而失去连接（没有意识到它已断开连接）
0:15 - 客户端重新连接
这里可能会发生两件事
A: 0:16 - 没有任何反应，客户端继续之前的连接
B: 0:~45 - 客户端意识到其断开连接 *
B: 0:46 - 客户端转换到重新连接状态
B: 0:47 - 客户端成功重新连接并触发 OnReconnected 事件。
情况 3
0:00 - 客户端连接到服务器，触发 OnConnected
0:10 - 客户端由于拉动以太网电缆而失去连接（没有意识到它已断开连接）
0:~45 - 客户端意识到其断开连接 *
0:46 - 客户端转换到重新连接状态
1:15 - 服务器确定客户端已经离开太久然后忘记它，排队等待客户端接收的“断开连接”命令，如果它稍后重新连接。***
1:15 - OnDisconnect 被触发 1:16 - 客户端重新连接
1:17 - 客户端执行“软”重新连接（不触发 OnReconnected）
1:18 - 客户端检索“断开连接”命令
1:19 - 客户端调用“停止”并进行软断开（不触发 OnDisconnected）
情况4
0:00 - 客户端连接到服务器，触发 OnConnected
0:10 - 客户端由于拉动以太网电缆而失去连接（没有意识到它已断开连接）
0:~45 - 客户端意识到其断开连接 *
0:46 - 客户端转换到重新连接状态
1:15 - 服务器确定客户端已经离开太久然后忘记它，排队等待客户端接收的“断开连接”命令，如果它稍后重新连接。***
1:15 - 触发 OnDisconnect 1:30 - 客户端停止尝试重新连接（尝试时间过长）**
1:30 - 客户端转换为断开连接状态
- 由于客户端保持活动检查：用于确定客户端何时由于缺乏保持活动而离线。不用于长轮询传输
** 由于客户端断开连接超时：用于确定客户端何时重新连接太长时间，并且服务器可能在此期间忘记了客户端
*** 由于服务器断开连接超时：用于确定何时应该忘记客户端。这是一个时间跨度，一旦连接在服务器上被标记为死，就会开始累积。最终，服务器为客户端的主题排队一个断开命令，告诉客户端（如果它重新连接）它需要开始一个新的连接。清理主题后，该命令将从服务器中消失。”
我们发现，我们经常在 .NET SignalR 客户端和 ASP.NET MVC SignalR 服务器之间断开和重新连接（上面的 1 和 2），并且断开连接不会导致重新连接（上面的 3 和 4）。我们知道正在使用 ServerSentEvents 协议。
很难知道我们需要调整（增加或减少）哪些超时属性：
- 减少断开和重新连接的次数。
- 根本不会出现在情况 3 和 4 中。
这里需要注意的重要一点是，我们的 .NET SignalR 客户端实际上是一个始终连接到服务器的 Windows 服务。
我们目前只保留了默认值，它们是：
- 连接超时 = 110 秒
- DisconnectTimeout = 30 秒
- KeepAlive = 30 秒
此外，我们使用的是 SignalR 1.0.1。