BITS 客户端无法指定 HTTP Range 标头

Question

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

由于一些安全和维护要求，我们在服务器端实现了自己的 ASP.NET 文件下载服务，而不是仅仅让 IIS 提供文件。当 BITS 客户端使用指定的文件范围，我们的 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 允许配置最大带宽并安排何时允许使用网络资源。虽然此配置适用于客户端，但在我们的特定情况下是可以的。