.net - BITS 客户端无法指定 HTTP 范围 header

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 允许配置最大带宽并安排何时允许使用网络资源。虽然此配置适用于客户端，但在我们的特殊情况下是可以的。