SignalR 与 WebProxies 或加速器有问题吗？
SignalR 与 WebProxy 或 WAN 加速器是否存在任何已知问题或不兼容？
我正在考虑将这项技术用于许多不同的网络拓扑和设备
Are there any known issues or incompatibilities with SignalR with a WebProxy or WAN Accelerators?
I'm considering this technology for something that will be used across many different network topologies and devices
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
任何问题或不兼容性不一定是 SignalR 本身造成的，而是在 HTTP 客户端和服务器之间打开双工通信通道的一般机制（即又称为“Comet”的技术范围）造成的。
SignalR 被设计为在客户端和服务器都支持 Websocket 的情况下使用它（值得一提的是，Websocket 规范< /a> 目前处于候选推荐阶段，因此尚未最终确定，尽管已经接近）。这隐含的是客户端和服务器之间的代理也将支持它。
如果客户端、服务器和中间的代理不支持 Websocket，则 SignalR 将尝试回退到服务器发送事件，然后如果不支持 SSE，则进行长轮询。
重要的问题是这些技术通常依赖于以某种方式保持打开的持久连接。如果数据没有通过它们传输，您的代理/加速器很可能会认为它们效率低下并关闭它们；在这种情况下，SignalR 客户端将按照设计再次打开连接，但代价是再次建立连接所花费的时间。
您可以配置代理来检查已打开的连接类型，以及是否可能是到 SignalR 端点的连接，以使其在关闭连接方面不那么激进。
Any issues or incompatibilities would not necessarily be as a result of SignalR itself, but rather the general mechanism for opening a duplex communication channel between an HTTP client and server (i.e. the range of techniques AKA 'Comet').
SignalR is designed to use Websocket if both client and server support it (and its worth mentioning, that the Websocket spec is currently at Candidate Recommendation, so hasn't been finalised although it is close). Implicit in this is that the proxies inbetween the client and server will also support it.
If client, server and proxies inbetween do not support Websocket then SignalR will attempt to fallback to Server Sent Events, and then if SSE not supported, long polling.
The significant issue is that these techniques generally rely on a persistent connection being held open in some way. Your proxies/accelerator may well decide that these are inefficient and close them down if data is not being streamed across them; in which case the SignalR client will open the connection again by design, but at the cost of time spent in setting up the connection again.
You might be able to configure your proxies to check the type of connection that has been opened, and if it is likely to be a connection to a SignalR endpoint to make it less aggressive with respect to closing the connection.