我有一個頁面上傳文件到我的服務器，然後通過move_uploaded_file複製到永久目錄。這一切似乎都很好，除了在真實場景中，我會預期比我成功發送的文件大得多。PHP文件上傳帶寬
我已經通過更改IIS中的網站設置中的連接超時來增加文件上傳的超時時間 - 因此文件可以繼續上傳長達六個小時（-_-） - 但這是我碰到我的地方目前的問題 - 可能只需要六個小時！
在獲得上傳過程以獲得超過10％左右（在300兆文件上）之後，我注意到文件繼續向上推進，但是我的上傳速度似乎「下降」 - 如在當我開始轉移時觀察到更快的速度，比我在中途看到的速度更快。這裏的數字並不一定相關，因爲我知道我的上傳（當Im上傳時，仍然是2 Mbps）能夠比它更快地推動，而另一端的服務器則是光纖上的。
我不知道有沒有人遇到過這個，如果是的話，你有沒有確定一個解決方法。任何幫助讚賞。謝謝。
您不應該爲此任務使用HTTP。您可能已經觀察到，所有「文件櫃」服務（以及涉及上載文件的其他服務，例如Apple的在線音樂服務）都爲您提供「上傳」程序，而不是使用瀏覽器。這是有原因的。
首先，傳輸編碼的開銷很大。你把你的（可能是二進制）數據，Base64編碼;這是33％的開銷。因此，如果HTTP需要四個小時，那麼只需要三個二進制協議 - 這不考慮分塊傳輸開銷，所以現實可能更嚴重。
其次，無法「恢復」HTTP中的上傳。因此，如果您的連接中斷，您將不得不編寫特定於應用程序的代碼來處理恢復，或者重新開始。第三，HTTP服務器不是爲超長壽命的連接而設計的：它們通常有一個有限或者小量的工作服務器來處理客戶端的請求（通常是一秒鐘），偶爾它們有小的限制對請求數據的大小（2GB是常見的，而PHP默認只有幾MB）。
我強烈建議使用文件傳輸協議來傳輸文件（如FTP）。您不必向每個人發放一個用戶名/密碼對：您可以擁有一個網守，該網守可與您已有的任何認證系統集成。 FTP-over-TLS也存在並且相對成熟。
這兩個協議here之間的區別有一個相當不錯的總結。請注意，由於您的情況，您無法從HTTP列出的任何優點中獲益。
不要只侷限於FTP-rsync也是一個很好的傳輸文件的協議，特別是如果你只更改文件的一部分（它甚至會執行二進制增量！）。如果你堅持使用它，git還可以通過安全連接甚至HTTP高效地傳輸大塊數據塊。
http不是專爲文件上傳而設計的協議，ftp是（甚至有文件名） – 2012-02-10 22:39:24
這不是一個很好的答案。 FTP是我試圖從這裏離開的工作。與其將FTP用戶和密碼分發給我的整個組織，然後在每次更改時必須將所有人都填入循環中，並且必須在40臺計算機上安裝FTP，我正在遷移到HTTP上載方法。我很清楚，行業標準是使用FTP，但這正是我試圖避免的。 – DigitalJedi805 2012-02-10 22:41:42
好吧，如果你遺漏了基本信息，我可以猜測。 – 2012-02-10 22:47:31