azure - 管理大文件下载的最佳方式

Question

我正在寻找管理我的产品在网络上下载的最佳方法。每个的重量在 2 到 20 Go 之间。我们的客户每天大约下载这些文件 1 到 1000 次。

我尝试过使用 Amazon S3，但下载速度不好，而且很快就会变得昂贵。我尝试过使用 Amazon S3 + CloudFront，但文件太大且下载次数太少:文件没有保留在缓存中。另外，我无法在 S3 中创建 torrent 文件，因为文件太大。我猜云解决方案(例如 S3、Azure、Google Drive...)仅适用于小文件，例如图像/css/等。

现在，我正在使用自己的服务器。它工作得很好，但管理起来确实更复杂......

有没有更好、更完美的方式来管理此类下载？

Answer 1

这是一个巨大的问题，我们在与电影或媒体行业的人员打交道时看到了这一点:他们生成巨大的视频文件，需要在紧迫的时间内共享。其中一些采用物理运输硬盘驱动器的方式。

当需要“有序且有保证的数据传输”时(例如 HTTP、FTP、rsync、nfs 等)，网络传输通常使用 TCP 执行。但 TCP 实现对数据包丢失、往返时间 (RTT) 以及发送方和接收方之间的管道大小非常敏感。一些 TCP 实现也很难填充大管道(最大带宽延迟乘积的限制；BDP = 比特率 * 传播延迟)。

理想的解决方案需要解决所有这些问题。

减少 RTT 通常意味着减少发送方和接收方之间的距离。根据经验，将 RTT 减少一半可以使最大吞吐量加倍(或将周转时间减半)。仅供引用，我看到从美国东海岸到美国西海岸的 RTT 约为 80-85 毫秒。

大型部署通常使用 Akamai 或 AWS CloudFront 等内容交付网络 (CDN) 来减少 RTT(例如约 5-15 毫秒)。简而言之，CDN 服务提供商与本地/区域电信公司安排在许多城市部署本地内容缓存服务器，并向您出售使用它们的权利。

但是对缓存资源的生存时间 (TTL) 的控制可能取决于您的服务级别协议(protocol) ($)。而且缓存内存不是无限的，因此可能会清除空闲资源，为新请求的数据腾出空间，特别是在与其他人共享缓存的情况下。

就您的情况而言，在我看来，您希望有意义地减少 RTT，同时保留对缓存行为的完全控制，因此您可以设置非常长的缓存 TTL。 IMO 中最好的性价比解决方案是部署自己的运行 CentOS 7 + NGINX 的缓存服务器，并打开 proxy_cache 和足够的磁盘空间，并为每个主要区域(例如西海岸和东海岸)部署一个缓存服务器。您的最终用户可以选择距离他们最近的区域，或者您可以添加一些代码来自动检测最近的区域缓存服务器。

在 AWS EC2 上部署这些缓存服务器绝对是一个选择。您的最终用户可能会看到比直接连接到 AWS S3 更好的性能，并且没有带宽上限。

对于您的卷，当前的 AWS 定价约为 0.09 美元/GB(对于 Internet 上的 BW)。假设您有大约 50 个文件，平均大小为 10GB，那么从缓存服务器到最终用户的 BW 约为每月 50 美元 - 不错吧？对于低/平均使用率区域(79 美元/月)，您可以从 c4.large 开始。使用率较高的区域可能会花费您约 150 美元/月 (c4.xl)、约 300 美元/月 (c4.2xl) 等。您可以通过竞价实例获得更好的定价，并且可以根据您的业务模式(例如 VIP)调整性能与尽力而为)。

就能够“填充管道”和对网络丢失的敏感性(例如拥塞控制、拥塞避免)而言，您可能需要考虑像 SuperTCP 这样的优化 TCP 堆栈(完全免责声明，我是开发总监) )。这里的想法是拥有一个每个连接自动调整的 TCP 堆栈，背后有大量的工程，因此它可以填充像 AWS 区域之间的巨大管道，并且不会像常规 TCP 那样对网络丢失 react 过度，尤其是在发送到 Wi-Fi 端点。

与 UDP 解决方案不同，它是单侧安装(<5 分钟)，您无需支付硬件或存储费用，无需担心防火墙，并且不会淹没/杀死您自己的防火墙网络。您需要将其安装在发送设备上:区域缓存服务器和将新请求推送到缓存服务器的源服务器。

优化的 TCP 堆栈可以将健康网络的吞吐量提高 25%-85%，而且我在糟糕的网络上见过 2 到 10 倍的吞吐量。