.net - WCF 服务卡在 SendResponse 中

Question

我有一个 WCF REST 服务，托管在 IIS 中。客户端(主要是浏览器)一直在提示偶尔的挂起。我终于亲自体验了这一点，并能够从服务器获取一些调试信息。我从 IIS 管理控制台抓取了以下屏幕截图。

显然这些请求已经存在太久了。

当这些请求挂起时，服务器能够很好地处理其他请求。我回收了应用程序池几次，但没有明显效果。在此期间，来自浏览器的任何请求都会挂起，然后被浏览器超时。我同一台计算机上的其他浏览器能够毫无问题地连接到同一服务。我还启动了 Fiddler，然后能够通过 Fiddler 从我的“挂起”浏览器发出请求。当我关闭 Fiddler 时，浏览器再次“挂起”。当我最终完全关闭浏览器时，连接就消失了。

一个潜在的重要点:您无法在屏幕截图中看出，但请求全部卡在向客户端发送二进制流(照片和视频)的调用上。在幕后，我从 Azure Blob 存储打开一个流(使用 OpenRead())，然后从我的函数返回相同的流。因此，我在一侧通过网络进行读取，并将数据发送到另一侧的网络。

那么这是怎么回事？如何防止连接挂起，或者至少让它们在某个合理的时间点超时？

更新:看来浏览器可能是问题所在。如果我有一个 HTML5 <video>页面上的元素，并且视频足够大，浏览器似乎打开一个连接来下载文件并使其永远保持打开状态。我对此只有大约 75% 的把握，但如果/当我确定时，我会在此处添加更新。

Answer 1

下次发生这种情况时，运行同一浏览器的单独实例并启动其他浏览器(Firefox、Chrome、IE 等)。您需要确定问题是否与特定浏览器有关。

我认为您已经发现了浏览器中的一个错误。事实上，Fiddler 的介入暂时解决了这个问题，这表明它与通过特定协议(protocol)栈进行连接的状态管理有关。如果是这样，那么您会发现问题是特定浏览器实例的本地问题。

除了向浏览器供应商报告之外，您对此无能为力。

如果您可以证明该错误仅在 IE 和 Azure 之间出现，那么该错误可能是由 Azure 的某些怪癖触发的，在这种情况下，因为这是单一供应商问题，您获得解决方案的机会会从“滚雪球”提高在 hell ”到“不要屏住呼吸”。