SignalR 长池在 IIS 7.5 和 Windows Server 2008 R2 上静默断开连接

2024-5-31 • tag-icon

SignalR 长池在 IIS 7.5 和 Windows Server 2008 R2 上静默断开连接

（我在 StackOverflow 上问了这个问题，它包含我在这里省略的代码，但我认为在这里问也是合适的，因为这是我面临的网络问题）

我有一个带有 SignalR 的 API（WebAPI），托管在 Windows Server 2008 R2（生产环境）的 IIS 7.5 上，并且我通过运行在 Windows 10 上的桌面应用程序连接到我的集线器。

我在与 LongPollingTransport 建立连接时遇到问题（由于服务器的配置，我明确使用它 - 据我所知，WebSockets 在 Windows Server 2008 R2 上不起作用）：首先，客户端成功连接并且 SignalR 的 Hub 成功接收到连接。

但是随后，客户端显然断开了连接，但是客户端没有捕获如上所述的任何断开连接事件，它保持“连接”状态，即使我知道当我调用 API 端点时确实应该将数据发送到我的客户端。

此问题仅发生在该生产环境中，但我还在本地/开发环境 (Windows 10) 和测试环境 (Windows Server 2012) 中进行了测试，并且运行正常。启用日志后，我可以看到，在生产环境中，TransportHeartBeat 出现了此“已死”消息：

SignalR.Transports.TransportHeartBeat Information: 0 : Connection 96c15a60-dd1d-47fb-ac57-ea898712738f is New.
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection 96c15a60-dd1d-47fb-ac57-ea898712738f
SignalR.Transports.LongPollingTransport Information: 0 : Abort(96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.LongPollingTransport Information: 0 : End(96c15a60-dd1d-47fb-ac57-ea898712738f)

同时，在本地或测试环境中，日志显示“KeepAlive”消息（我希望它在我的生产环境中发生）：

SignalR.Transports.TransportHeartBeat Information: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d is New.
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)

此外，在我的客户端应用程序中，我有一种将数据发送到服务器的方法。在使用 Fiddle 进行诊断时，我注意到在我的本地或测试环境中，客户端启动的长池连接保持活动状态，直到客户端发送一些数据，然后连接结束时服务器没有数据，另一个连接启动。同时，在我的测试环境中，即使我的客户端发送数据，长池连接也会继续。我认为发生这种情况是因为服务器首先不识别客户端连接，但我认为提及这种行为会很有用。

因此，综上所述，我想知道：

我需要在 IIS 上进行什么配置才能使 LongPoolingTransport 正常工作？
知道为什么我的客户“认为”它仍然是连接的吗？
什么原因会导致长池请求被丢弃？我该如何诊断？

谢谢！

相关内容