【发布时间】：2012-09-13 10:01:21
【问题描述】：
我希望将 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 如何处理这个上游连接（即，当它实际需要来自源的数据时，强制它打开一个新连接，或者让它意识到源关闭了连接）？
【问题讨论】：
标签： iis-7 reverse-proxy