iis-7 - IIS ARR (edge) cache (reverse proxy) - 上游连接超时问题

Question

我希望将 IIS 应用程序请求路由用作反向代理缓存。我研究了几种不同的选择，得出的结论是它最符合我的需要。但是，我遇到了一种死胡同，真的可以使用对 ARR 模块有更多经验的人的一些意见。

我有以下设置:

• IIS ARR 缓存代理请求到内部服务器场(加权循环负载平衡以使用最近的源服务器)。
• 在 IIS 代理中禁用 Keep alive。
• 服务器场由 nginx 网络服务器组成。
• IIS 服务器有 RAM 磁盘缓存。

用例是这样的，边缘服务器将接收字节范围请求，并且当它向最终用户提供内容时，它将对其进行缓存(首先在内存缓存中存储 60 秒，然后将其写入 RAM 磁盘)。到目前为止一切正常，但是当下一个最终用户开始请求相同的字节范围(现在在缓存中)时，我开始看到 IIS 边缘和 nginx 起源之间的一些奇怪行为:在第一个字节范围请求(由第二个最终用户提出)时，IIS 服务器打开到它不使用的 nginx 源的连接，因为它已经在缓存中有请求的段。由于连接未被使用，它最终因超时(60 秒)而被 nginx 关闭。与此同时，第二个最终用户仍在请求缓存中的文件段。然后，这就是问题发生的地方，第二个最终用户到达文件中不在缓存中的点。我在这里期望 IIS 的行为(禁用 keep-alive)是它会打开一个到源的新连接并开始获取不在缓存中的文件部分。然而，我看到的行为是 IIS 尝试重用它在请求开始时打开的相同连接(没有意识到它已被源丢弃)。我也使用“失败的请求跟踪”来验证这一点，结果是 IIS 没有从源头获得预期的答复(因为连接不再存在)，然后返回一个502.3 到最终用户。

我已经证实增加源上的连接超时将“解决”问题，但这并不是一个真正可行的解决方案，因为我基本上必须设置无限超时，这可能会导致一系列全新的问题起源的一面。有什么方法可以控制 IIS 如何处理此上游连接(即强制它在实际需要来自源的数据时打开一个新连接，或者让它意识到源关闭了连接)？

Answer 1

对于可能遇到相同问题的任何人；在与 Microsoft 反复讨论后，这实际上是 ARR 模块中的错误，将在即将发布的版本中解决。