我在 MVC4 站点中使用 NuGet 的最新 SignalR。使用sample hub code (或任何代码)，我遇到一些奇怪的连接问题。一切加载正常，SignalR 进行协商调用并记录“EventSource Connected”并返回 connectionid。当它使用任何传输方式发出 signalR/connect 请求时，问题就开始了。它返回带有正确 header 的 200 响应，但连接保持打开状态。如果被调用的集线器方法在调用者或客户端上执行方法，则它不会在浏览器中执行直到下一个请求或10-30秒后 如果你坐下来等待。就像有东西卡在管道中，它会被下一个请求或某些清理机制刷新。
我在一个具有自己的应用程序池的新网站中为此创建了一个干净的项目。该问题仅发生在一台机器上，并且仅在 IIS7.5 下发生。在 IIS Express 或 Cassini 下的同一台计算机上运行的同一项目运行良好。大约一个月前，我上次处理这个项目时运行良好。我尝试过不同的浏览器和不同的 jQuery 版本。我尝试重新启动整个机器，并在 fiddler/debugger 中花费了几个小时，但无济于事。
这是测试运行的服务器端代码:
public class Chub : Hub {
public void CallMeBack() {
Caller.callme();
}
}
折腾了一整天，希望有人能帮忙!
最佳答案
压缩不能很好地处理 SignalR 使用的 EventSource、ForeverFrame 等流响应，因此关闭压缩是目前唯一的解决方案。
也许可以仅针对 ~/signalr 路径关闭压缩，我稍后会尝试并用结果更新此答案。
更新:经过彻底分析，我发现只有当 IIS 中的应用程序池设置为“经典模式”并启用动态压缩时才会出现此问题。请参阅我对 this 的评论SignalR 问题。如果您使用“集成模式”应用程序池，则不会受到影响，并且 SignalR 按预期工作(即使启用了压缩)。
如果您无法使用经典模式 + 动态压缩，请将以下内容添加到您的 web.config 中，以仅关闭/signalr 路径的压缩:
<location path="signalr">
<system.webServer>
<urlCompression doDynamicCompression="false"/>
</system.webServer>
</location>
关于iis - SignalR 连接挂起，大约 30 秒后调用客户端，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12887976/