我有一个页面将文件上传到我的服务器，然后通过move_uploaded_file将其复制到永久目录。这一切似乎都很有效，但在现实生活中我会期待比我成功发送的文件更大的文件。
我已经通过更改IIS中我的网站设置中的连接超时来确定文件上传的超时 - 因此文件会继续上传最多六个小时（-_-） - 但这是我遇到的当前状态问题 - 可能只需要六个小时！
让上传过程超过10％左右（在一个300兆字节的文件上）后，我注意到文件继续向上推，但我的上传率似乎“下降” - 就像在我看到的那样当我开始转移时速度更快，而不是我看到它的中途。这里的数字不一定相关，因为我知道我的上传（在上传时，仍然是2 Mbps）能够比它更快地推动，而另一端的服务器在光纤上。
我想知道是否有人之前遇到过这种情况，如果有的话，你有没有确定一个解决办法。任何帮助赞赏。感谢。
答案 0 :(得分：3)
您不应该使用HTTP执行此任务。您可能已经观察到所有“文件柜”服务（以及涉及上传文件的其他服务，例如Apple的在线音乐服务）为您提供“上传程序”程序，而不是使用浏览器。这是有原因的。
首先，传输编码的开销很大。您可以获取（可能是二进制）数据，并对其进行Base64编码;这是33％的开销。因此，如果使用HTTP需要四个小时，那么只需要三个二进制协议 - 这就是忽略了分块传输开销，所以现实可能更严重。
其次，没有办法在HTTP中“恢复”上传。因此，如果您的连接中断，您将需要编写特定于应用程序的代码来处理恢复，或者从头开始。
第三，HTTP服务器不是为超长期连接而设计的：它们通常有一个有限或很小的工作池来为客户端请求提供服务（通常在一开始就是长达数秒），有时它们的限制很小请求数据的大小（2GB是常见的，默认情况下PHP只有几MB）。
我强烈建议使用文件传输协议传输文件（例如FTP）。您不必为每个人提供一个用户名/密码对：您可以拥有一个与您已有的任何身份验证系统集成的网守。 FTP-over-TLS也存在且相对成熟。
两个协议here之间的差异有一个相当不错的总结。请注意，由于您的具体情况，您无法从列出的HTTP的任何优势中获益。
不要局限于FTP - rsync也是一个很好的传输文件的协议，特别是如果你只改变部分文件（它甚至可以进行二进制增量！）。如果你坚持使用它，git也可以通过安全连接甚至HTTP有效地传输大blob。