我希望将 IIS 应用程序请求路由用作反向代理缓存。我查看了几个不同的选项，并得出结论，它最适合我的需求。但是，我遇到了一种死胡同，我真的可以从对 ARR 模块有更多经验的人那里获得一些意见。
我有以下设置：
- IIS ARR 缓存代理请求到内部服务器场（加权循环负载平衡以使用最近的源服务器）。
- 在 IIS 代理中禁用保持活动。
- 服务器场由 nginx 网络服务器组成。
- IIS 服务器具有 RAM 磁盘缓存。
用例是边缘服务器将接收字节范围请求，并在向最终用户提供内容时将其缓存（首先在内存缓存中 60 秒，然后将其写入 RAM 磁盘）。到目前为止一切正常，但是当下一个最终用户开始请求相同的字节范围（现在在缓存中）时，我开始看到 IIS 边缘和 nginx 来源之间的一些奇怪行为：在第一个字节范围请求时（由第二个最终用户）IIS 服务器打开一个到它不使用的 nginx 源的连接，因为它已经在缓存中有请求的段。由于没有使用连接，因此由于超时（60 秒），它最终被 nginx 关闭。同时，第二个最终用户仍在请求缓存中的文件段。然后，这就是问题发生的地方，第二个最终用户到达文件中不在缓存中的某个点。我在这里期望 IIS 的行为（即禁用 keep-alive）是它将打开到源的新连接并开始获取不在缓存中的文件部分。然而，我看到的行为是 IIS 尝试重用它在请求开始时打开的相同连接（没有意识到它已被源丢弃）。我也使用了“失败的请求跟踪”来验证这一点，结果是 IIS 没有从源端获得预期的回复（因为连接不再存在），然后又返回一个502.3 到最终用户。我在这里期望 IIS 的行为（即禁用 keep-alive）是它将打开到源的新连接并开始获取不在缓存中的文件部分。然而，我看到的行为是 IIS 尝试重用它在请求开始时打开的相同连接（没有意识到它已被源丢弃）。我也使用了“失败的请求跟踪”来验证这一点，结果是 IIS 没有从源端获得预期的回复（因为连接不再存在），然后又返回一个502.3 到最终用户。我在这里期望 IIS 的行为（即禁用 keep-alive）是它将打开到源的新连接并开始获取不在缓存中的文件部分。然而，我看到的行为是 IIS 尝试重用它在请求开始时打开的相同连接（没有意识到它已被源丢弃）。我也使用了“失败的请求跟踪”来验证这一点，结果是 IIS 没有从源端获得预期的回复（因为连接不再存在），然后又返回一个502.3 到最终用户。然而，我看到的行为是 IIS 尝试重用它在请求开始时打开的相同连接（没有意识到它已被源丢弃）。我也使用了“失败的请求跟踪”来验证这一点，结果是 IIS 没有从源端获得预期的回复（因为连接不再存在），然后又返回一个502.3 到最终用户。然而，我看到的行为是 IIS 尝试重用它在请求开始时打开的相同连接（没有意识到它已被源丢弃）。我也使用了“失败的请求跟踪”来验证这一点，结果是 IIS 没有从源端获得预期的回复（因为连接不再存在），然后又返回一个502.3 到最终用户。
我已经验证增加源端的连接超时将“解决”问题，但这并不是一个真正可行的解决方案，因为我基本上必须设置一个无限超时，这可能会在源端导致一系列全新的问题. 有什么方法可以控制 IIS 如何处理这个上游连接（即当它实际上需要来自源的数据时强制它打开一个新连接，或者让它意识到源关闭了连接）？