☰

SignalR 長池在 IIS 7.5 和 Windows Server 2008 R2 上靜默斷開連接

tag-icon • tag-icon windows-server-2008-r2 iis-7.5 long-polling
SignalR 長池在 IIS 7.5 和 Windows Server 2008 R2 上靜默斷開連接

（我在 StackOverflow 上問了這個問題，它包含我在這裡省略的程式碼，但我認為也適合在這裡詢問，因為這是我面臨的網路問題）

我有一個 API (WebAPI)，其中 SignalR 託管在 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 進行診斷時，我注意到在我的本地或測試環境中，客戶端啟動的長池連接一直保持活動狀態，直到客戶端發送一些數據，然後連接結束，伺服器沒有數據，另一個連接啟動。同時，在我的測試環境中，即使我的客戶端發送數據，長池連線也會繼續運作。我認為發生這種情況是因為伺服器一開始就沒有識別客戶端連接，但我認為提及這種行為會很有用。

綜上所述，我想知道：

  1. 我應該在 IIS 上配置什麼才能使 LongPoolingTransport 工作嗎？
  2. 知道為什麼我的客戶“認為”它仍然連接嗎？
  3. 什麼會導致長池請求像這樣被丟棄？我該如何診斷？

謝謝！

相關內容