BITS 客户端未能指定 HTTP Range 标头

Question

我们的系统旨在部署到网络连接不可靠和/或不足的区域。我们构建自己的容错数据复制服务，使用BITS。

由于某些安全和维护需求，我们在服务器端实现了自己的 ASP.NET 文件下载服务，而不是让 IIS 提供文件。 当 BITS 客户端进行 HTTP 下载时通过指定文件范围的请求，我们的 ASP.NET 页面将请求的文件段拉入内存并将其作为 HTTP 响应提供。这就是理论。 ;) 这个理论在人工实验室场景中失败了，但我不会让系统部署在现实生活场景中，除非我们能够克服这一点。

实验室场景：我在同一台开发人员机器上安装了 BITS 客户端和 IIS，因此实际上我拥有巨大的网络“带宽”，而 BITS 的智能足以检测到这一点。随着BITS客户端发现无限带宽，它变得越来越“贪婪”。在每个 HTTP 请求中，BITS 想要获取越来越大的文件范围（我们正在谈论下载 CD iso 文件、视频），在单个 HTTP 请求中要求 20-40MB，我不愿意在服务器端一气呵成。我可以通过给予少于要求的东西来克服这一点。没关系。

但是，BITS 在不指定下载范围的情况下获得真正“自信”和“傲慢”的文件要求，即，它希望在单个请求中获取整个文件，这就是问题所在。对于 600MB 的文件，我不知道如何回答该响应。如果我只提供文件的起始 1MB 范围，BITS 客户端会继续发送对同一文件的 HTTP 请求而没有下载范围以继续，它强调了它想要一次性完成整个文件的观点。由于我不愿意提供整个文件，BITS经过多次尝试放弃并报告错误。

有什么想法吗？

Answer 1

看来，我们可以解决这个问题。有几件事：

• 我们需要控制每个传入的请求，因此我们不能只让 IIS 单独处理请求。但是，仍然没有必要为了方便下载而将文件拉入内存：Request.TransferFile(...) 实际上无需将文件拉入内存即可完成所有繁重的工作，而我们仍然保持对处理请求的控制。
• BITS 实现看起来非常智能，如何处理各种情况。我们了解到，如果 BITS 请求没有指定范围的完整文件，即使是几个 GB，我们也可以让它拥有它。一旦它收到第一个 HTTP 数据包并发现它比它可以吞下的大，它立即取消请求并在适当的范围内重新请求它。
• BITS 允许配置最大带宽并安排何时允许使用网络资源。虽然此配置适用于客户端，但在我们的特定情况下是可以的。