我们要求所有下载请求均具有有效的登录名(非http)，并且每次下载都会生成交易凭单。如果我们要转到下载链接之一并尝试"重播"交易，我们将使用HTTP代码转发我们以获取新的交易凭单。对于大多数用户来说，这很好用。但是，有一小部分正在使用"下载加速器"，它们只是尝试多次重播交易凭单。

因此，为了确定我们是否希望甚至可以支持下载加速器，我们试图了解它们的工作方式。

与提供静态文件的Web服务器的第二个，第三个或者第四个并发连接如何如何加快下载过程？

加速器程序做什么？

解决方案

来自：http://askville.amazon.com/download-accelerator-protocol-work-advantages-benefits-application-area-scope-plz-suggest-URLs/AnswerViewer.do?requestId=9337813

引用：
加速下载的最常见方法是打开并行下载。许多服务器限制一个连接的带宽，因此更多并行打开会增加速率。通过指定应开始下载的偏移量来工作，HTTP和FTP都支持该偏移量。

当然，这种加速方式非常"不合社会"。带宽限制的实现是为了能够服务更多数量的客户端，因此使用此技术会降低能够下载的对等设备的最大数量。这就是为什么许多服务器限制并行连接数(通过IP识别)的原因，例如许多FTP服务器都这样做，因此如果我们下载文件并尝试继续使用浏览器进行浏览，则会遇到问题。从技术上讲，这是两个并行连接。

增加下载速率的另一种技术是点对点网络，其中不同的来源例如由上传侧异步DSL限制的用于下载。

我相信这个想法是许多服务器限制或者平均分配连接间的带宽。通过建立多个连接，我们正在欺骗该系统，并获得了超出带宽"公平"份额的收益。

全部与利特尔定律有关。具体地说，到Web服务器的每个流都看到一定数量的TCP延迟，因此只能携带这么多数据。诸如增加TCP窗口大小和实现选择性ack之类的窍门虽然有帮助，但实施效果不佳，通常会导致更多问题，而无法解决。

拥有多个流意味着随着整体吞吐量的整体提高，每个流看到的等待时间就不再那么重要了。

即使使用单线程，下载加速器的另一个主要优点是，它通常比使用内置在下载工具中的Web浏览器更好。例如，如果网络浏览器决定退出，下载工具将继续。并且下载工具可能支持诸如暂停/恢复内置浏览器不支持的功能。

大多数下载的"加速器"实际上根本没有加快任何速度。他们擅长的工作是阻塞网络流量，重击服务器并破坏自定义脚本，如我们所见。基本上，它是如何工作的，而不是发出一个请求并从头到尾下载文件，而是发出四个请求……第一个从0-25％下载，第二个从25-50％下载，依此类推，并同时使它们全部。唯一有帮助的特殊情况是，他们的ISP或者防火墙进行某种流量调整，以使单个下载速度被限制为小于其总下载速度。

就个人而言，如果给我们带来麻烦，我只是说一声通知，不支持下载加速器，让用户正常下载加速器，或者仅使用单个线程下载加速器。

他们一般不会。

为了回答问题的实质，假设服务器正在按连接限制下载速率，因此同时下载多个块将使用户能够在其末端充分利用可用带宽。

我们将在Wikipedia上获得有关Download Accelerators的更全面概述。

加速是多方面的

第一的

托管/加速下载的一个重要好处是，该工具可以记住传输的开始/停止偏移量，并使用" partial"和" range"标头来请求文件的部分而不是全部。

这意味着，如果某事物在中间事务中死亡(即：TCP超时)，它只会重新连接到中断处，而我们不必从头开始。

因此，如果连接是间歇性的，则总传输时间将大大减少。

第二

下载加速器喜欢使用相同的起止范围机制将单个传输分成相同大小的几个较小段，并并行执行，这大大缩短了慢速网络的传输时间。

有一种令人讨厌的事情，称为带宽延迟乘积，其中两端的TCP缓冲区的大小与ping时间一起进行一些数学运算，以获得实际的体验速度，这实际上意味着较大的ping时间会限制速度所有临时连接都具有几兆位/秒的速度。

但是，此限制似乎是"每个连接"，因此到单个服务器的多个TCP连接可以帮助减轻高延迟ping时间的性能影响。

因此，住在附近的人不太需要进行分段传输，但是居住在遥远位置的人更可能从分段中发疯。

第三

在某些情况下，可能会找到提供相同资源的多个服务器，有时是将单个DNS地址循环到多个IP地址，或者服务器是某种镜像网络的一部分。并且下载管理器/加速器可以检测到这一点，并在多台服务器之间应用分段传输技术，从而使下载器可以获得更多的集体带宽。

支持

我个人建议将第一种加速作为"最小"支持。通常，由于它使用户的生活变得容易，并且由于用户不必重复获取相同的内容，因此减少了我们必须提供的聚合数据传输量。

为了方便起见，它建议我们计算它们已经转移了多少票，并且直到票证看起来"完成"(将流量绑定到使用票证的第一个IP)时才到期，或者给定的"合理"时间下载已通过。即：在要求他们获得新票之前，给他们一个宽限期。

支持第二名和第三名会给我们加分，用户通常至少希望获得第二名，这主要是因为国际客户不仅仅因为更长的ping时间而不喜欢被视为第二等客户，而且客观上不会消耗更多任何重要的带宽。发生的最坏情况是，它们可能导致总吞吐量对于服务的运行方式而言是不良的。

合理地直接提供第一种好处，而不是仅通过限制单张票的并发转账次数来允许第二种好处。

我的理解是，下载加速器使用的一种方法是通过打开许多并行的TCP连接，每个TCP连接只能运行得如此之快，并且通常在服务器端受到限制。

TCP被实现为如果发生超时，则超时时间会增加。这对于防止网络过载非常有效，但要以单个TCP连接的速度为代价。

下载加速器可以通过以下方法解决此问题：打开数十个TCP连接，然后将速度较慢的连接降低到特定阈值以下，然后再打开新的TCP连接来替换速度较慢的连接。

虽然对单个用户有效，但我认为这通常是不好的礼节。

我们会看到下载加速器尝试使用我建议忽略这些请求的相同交易凭单重新进行身份验证。