问处理此问题的最佳方法是什么:在文件完全下载之前，通过PHP +来自client = script超时的缓慢连接进行大规模下载

EN

我的客户想要一种方式提供下载给用户，但只有在他们填写注册表格(基本上是姓名和电子邮件)。向用户发送带有可下载内容链接的电子邮件。这些链接包含包、文件和用户特有的注册散列，它们实际上转到一个PHP页面，该页面记录每个下载，并通过将文件写入stdout (以及适当的标头)将文件推送出去。这种解决方案有其固有的缺陷，但这正是他们想要做到的。需要说的是，我把他们逼到了1。)限制可下载文件和2的大小。)考虑使用CDN (他们有国际客户，但在美国托管在两个镜像服务器和一个负载均衡器，使用粘性in )。不管怎样，它“适合我”，但他们的一些国际客户的连接非常慢(d/l速率~60 MB/秒)，其中一些文件相当大(150 MB)。因为这是一个为这些文件提供服务的PHP脚本，所以它被脚本超时设置绑定。起初，我把这个设置为300秒(5分钟)，但这对一些测试版用户来说是不够的。因此，我尝试根据文件的大小除以100 So /秒的连接来计算脚本超时，但其中一些用户甚至比这还要慢。

现在，客户机只想提高超时值。我不想一起删除超时，以防脚本以某种方式进入无限循环。我也不想继续任意地为某些捕获-所有最低的公共分母连接速率(大多数人下载速度远远快于100 to /秒)的超时。我还想在某个时候告诉客户：“看，这些文件太大了，无法用这种方式处理。这40多分钟的连接会影响到网站其他部分的性能。我们要么需要重新思考它们是如何传递的，要么使用更小的文件。”

我想到了几个解决方案，它们如下：

1. CDN --将文件移动到CDN服务，如亚马逊或谷歌。我们仍然可以通过PHP记录下载尝试，但随后将浏览器重定向到真正的文件。这样做的一个缺点是，一旦用户有了URL，就可以绕过脚本直接从CDN下载(可以通过查看HTTP报头来收集URL)。这还不错，但不是desired.
2. Expand服务器场--将服务器场从2扩展到4+服务器，并从负载均衡器中删除粘性IP规则。缺点:这些都是Windows服务器，所以很昂贵。没有理由让它们成为Linux机箱，但是设置所有新的服务器所需的时间可能比客户端为这些下载allow.
3. Setup 2提供新服务器所需的时间更长--基本上与#2相同，但我们至少可以将网站的其他部分与这个特定的进程隔离开来(并调整新服务器的配置)。我们还可以很容易地让这些Linux boxes.
4. Detect成为用户连接速率--我想到了一种检测用户当前速度的方法，方法是在下载登陆页面上使用AJAX，知道下载一个已知文件大小的静态文件需要多长时间，然后将该信息发送到服务器，并根据该信息计算超时时间。这并不理想，但它比估计连接速度过高或过低要好。不过，我不知道如何将速度信息返回到服务器，因为我们目前使用的是从服务器发送的重定向头。

有可能#的1-3会被拒绝，或者至少会被推开。那么4是一个很好的方法来做这件事，还是有什么我没有考虑过的？

(可以随时挑战原来的解决方案。)