WCF服务挂在SendResponse中

Question

我有一个托管在IIS中的WCF REST服务。客户（主要是浏览器）一直在抱怨偶尔挂起。我终于经历了这个，并且能够从服务器获取一些调试信息。我从IIS管理控制台抓取了以下屏幕截图。

显然，这些要求已经存在了很长时间。

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

一个可能重要的一点：您无法在屏幕截图中看出，但请求全部挂在将二进制流（照片和视频）发送到客户端的呼叫上。我将在Azure Blob Storage中打开一个Stream（使用OpenRead（）），然后从我的函数中返回相同的Stream。所以我一边是通过网络阅读，另一边是将数据输出到网络。

那么这里发生了什么？如何防止连接挂起，或者至少让它们在某个合理的点上超时？

更新：似乎浏览器可能存在问题。如果我在页面上有一个HTML5 <video>元素，并且视频足够大，浏览器似乎打开一个连接来下载文件并永远打开它。我只有75％的确定，但如果/当我确定的时候，我会在这里添加更新。

Answer 1

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

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

除了向浏览器供应商报告之外，您无法做任何事情。

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

Answer 2

Fidler是一个代理，它会在进程中注入自己而不是现有的代理。这使我相信您（和其他人）在自动代理设置或其他一些代理设置相关问题上存在问题。

Answer 3

事实证明问题完全在浏览器中。我有一些页面中包含多个<video>标记。事实证明，在某些情况下，浏览器会为每个视频打开一个连接并将其保持打开状态，直到视频播放完毕。

至少有几种不同的浏览器端解决方法：

1. 在<video>标记上添加preload="none"属性。
2. 默认情况下不显示视频。而是显示图像，然后在用户点击它时动态呈现<video>标记。

另外，我向回应此事的人道歉。我只是没有给你足够的信息来找到正确的答案，所以你从来没有真正有机会。