挂在 SendResponse 中的 WCF 服务答案

【问题标题】：WCF service hanging in SendResponse挂在 SendResponse 中的 WCF 服务
【发布时间】：2012-05-04 03:30:51
【问题描述】：

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

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

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

一个潜在的重要点：您无法在屏幕截图中看出，但请求都挂在向客户端发送二进制流（照片和视频）的调用上。在幕后，我从 Azure Blob 存储打开一个流（使用 OpenRead()），然后从我的函数中返回相同的流。所以我一方面通过网络读取数据，另一方面将数据输出到网络。

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

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

【问题讨论】：

标签： .net wcf iis azure

【解决方案1】：

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

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

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

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

【讨论】：

我确实这样做了。最初的冻结是在 Chrome 中，但同一台机器上的 Firefox 和 IE9 就可以了。我也让其他用户报告了这些浏览器中的错误，这让我相信这不是特定于浏览器的问题。

【解决方案2】：

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

【讨论】：

我们没有自动代理。即使我们这样做了，其他浏览器似乎也会受到影响。此外，我还收到了关于完全独立网络上的用户发生这种情况的报告。
我的回答是基于这样一个事实，即回收应用程序池您的连接不会立即终止。如果在服务和客户端（如负载均衡器）之间存在控制数据流的中间人，则可能是原因。
好的，我知道你要去哪里了。服务器前面有一个负载平衡器。但是浏览器无法再向该服务器发送任何请求，我认为这意味着从服务器到浏览器的连接一直保持打开状态。

【解决方案3】：

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

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

在<video> 标签上添加preload="none" 属性。
默认不显示视频。而是显示一个图像，然后在用户单击它时动态呈现<video> 标签。

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

【讨论】：