PHP 文件上传带宽
我有一个页面将文件上传到我的服务器，然后通过 move_uploaded_file 将文件复制到永久目录。这一切似乎都很有效，但在现实生活中，我预计文件会比我成功发送的文件大得多。
我已经通过更改 IIS 站点设置中的连接超时来解决文件上传超时问题 - 因此文件将继续上传长达六个小时 (-_-) - 但这就是我遇到当前问题的地方 - 它可能只需要六个小时！
在上传过程超过 10% 左右（在 300 meg 文件上）后，我注意到文件继续上升，但我的上传速率似乎“下降” - 例如，我观察到更快的速度我开始了转移，比我看到的要进行一半。这里的数字不一定相关，因为我知道我的上传（在上传时，仍然是 2 Mbps）能够比实际速度更快，并且另一端的服务器是在光纤上。
我想知道以前是否有人遇到过这种情况，如果是的话，您是否已经确定了解决方法。任何帮助表示赞赏。谢谢。
I have a page that uploads a file to my server, where it then gets copied to a permanent directory via move_uploaded_file. This all seems to work great, with the exception that in a real-life scenario I will be expecting much larger files than I have successfully sent up.
I have already tacked the timeout for the file upload by changing the connection timeout in my site settings in IIS - so the file continues to upload up to six hours ( -_- ) - but this is where I run into my current problem - It might just take six hours!
After getting the upload process to get past 10% or so ( on a 300 meg file ), I noticed that the file continues to push up, but my upload rate seems to be 'falling off' - as in, I observed faster speeds when I started the transfer, than I am seeing halfway through it. The numbers here aren't necessarily relevant, as I know that my upload ( while Im uploading, still 2 Mbps ) is capable of pushing faster than it is, and the server on the other end is on fiber.
I wonder if anyone has encountered this before, and if so, have you determined a work-around. Any help appreciated. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不应该使用 HTTP 来执行此任务。您可能已经观察到，所有“文件锁”服务（以及其他涉及上传文件的服务，例如苹果的在线音乐服务）都为您提供“上传器”程序，而不是使用浏览器。这是有原因的。
首先，传输编码的开销很大。您获取（大概是二进制）数据，并对其进行 Base64 编码；相当于 33% 的开销。因此，如果使用 HTTP 需要四个小时，那么使用二进制协议只需要三个小时 - 而且这还不考虑分块传输开销，因此现实情况可能更加严峻。
其次，无法在 HTTP 中“恢复”上传。因此，如果您的连接中断，您要么必须编写特定于应用程序的代码来处理恢复，要么从头开始。
第三，HTTP 服务器并不是为超长寿命的连接而设计的：它们通常有有限的或小的工作池来服务（通常在开始时为数秒长的）客户端请求，并且有时它们对连接的大小有较小的限制。请求数据（2GB是常见的，PHP默认只有几MB）。
我强烈建议使用文件传输协议来传输文件（例如FTP）。您不必向每个人提供单个用户名/密码对：您可以拥有一个与您已有的任何身份验证系统集成的网守。 FTP-over-TLS 也存在并且相对成熟。
此处对两种协议之间的差异进行了相当好的总结。请注意，由于您的具体情况，您不会从列出的 HTTP 优点中获得任何好处。
不要觉得仅限于 FTP - rsync 也是传输文件的一个很好的协议，特别是如果您只更改文件的一部分（它甚至可以更改二进制增量！）。 git 还可以通过安全连接甚至 HTTP 有效地传输大型 blob（如果您坚持使用）。
You should not be using HTTP for this task. You may have observed that all the "file locker" services (and others which involve uploading files, such as Apple's online-music service) provide you with an "uploader" program rather than making use of the browser. There are reasons for this.
First off, the overhead of the transfer encoding is large. You take your (presumably binary) data, and Base64 encode it; that's 33% overhead. So if it would take four hours with HTTP, it would only take three with a binary protocol - and that's disregarding the chunked-transfer overhead, so the reality is probably more severe.
Second, there's no way to "resume" an upload in HTTP. So if your connection is broken, you'll either have to write application-specific code to handle the resumption, or start all over.
Third, HTTP servers are not designed for super-long-lived connections: they usually have a finite or small pool of workers to service the (usually seconds-long at the outset) client requests, and occasionally they have smallish limits on the size of request data (2GB is common, and PHP by default has only a few MB).
I strongly recommend using a file transfer protocol to transfer files (such as FTP). You don't have to give out a single username/password pair to everyone: you can have a gatekeeper which integrates with whatever authentication system you already have in place. FTP-over-TLS also exists and is relatively mature.
There is a fairly good summary of the differences between the two protocols here. Note that you gain nothing from any of the advantages of HTTP listed, due to your circumstances.
Don't feel limited to FTP - rsync is a great protocol for transferring files as well, especially if you only change part of the file (it even does binary deltas!). git can also efficiently transport large blobs over secure connections or even HTTP, if you insist on using that.