我们部署到本地开发服务器，而某些用户（并非所有用户）遇到信号器问题，其中serverSentEvents将无法连接并且它会回退到长轮询...通常这样会很好但是需要5秒钟才能完成回来了，用户体验太可怕了。
请求在chrome的开发人员工具网络选项卡中获得“已取消”状态，最终我们最终使用signalr的longPolling进行连接。这是来自signalr的日志记录：
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Client subscribed to hub 'chat'. jquery.signalR-2.0.0.js:75
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Negotiating with '/signalr/negotiate?connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&clientProtocol=1.3'. jquery.signalR-2.0.0.js:75
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Attempting to connect to SSE endpoint 'http://mysubdomain.mydomain.com/signalr/connect?transport=serverSentEvents&con…bYUr2xEEBuw%3D%3D&connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&tid=6'. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: serverSentEvents timed out when trying to connect. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: EventSource calling close(). jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: This browser supports SSE, skipping Forever Frame. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: Opening long polling request to 'http://mysubdomain.mydomain.com/signalr/connect?transport=longPolling&connecti…bYUr2xEEBuw%3D%3D&connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&tid=2'. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: Long poll complete. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: LongPolling connected.
一旦客户端最终通过长轮询连接，该网站工作正常但我仍然需要弄清楚为什么serverSentEvents不工作。
我可以禁用serverSentEvents来解决这个问题，但它适用于某些人，而不适用于其他人，因此我想知道是否有某种方法可以找出为什么某些人而不是其他人失败的原因。
有关如何诊断的建议吗？
答案 0 :(得分：3)
从Server-Sent Events传输回退需要5秒钟，因为这是SignalR的默认TransportConnectTimeout。这个TimeSpan可以在应用开始时通过GlobalHost.Configuration.TransportConnectTimeout缩短。
SSE可能失败的原因有很多。例如，SignalR服务器和客户端之间可能存在路由器或防火墙，它们正在合并或关闭服务器发送事件传输所依赖的分块HTTP响应。当我所知道的是连接超时时，很难确定SSE问题的确切原因是什么。