有沒有人有過使用跨多個並行請求的HTTP字節範圍來加速下載的經驗？使用HTTP字節範圍標頭進行加速下載
我有一個應用程序需要從網絡服務（1MB +）下載相當大的圖像，然後發送修改後的文件（調整大小和裁剪）到瀏覽器。有很多這樣的圖像，所以緩存可能無效 - 即緩存很可能是空的。在這種情況下，我們在等待圖像下載時遇到了相當大的延遲時間，500 m/s +，這是我們應用程序總響應時間的60％以上。
我想知道是否可以通過使用一組並行的HTTP範圍請求來加速下載這些圖像，例如，每個線程下載100kb的數據並將響應連接回完整的文件。
有沒有人有過這種事情的經驗？額外下載的開銷會否增加速度或者實際上這種技術可能會起作用？該應用程序是用紅寶石編寫的，但來自任何語言的經驗/示例都有幫助。
有關安裝了幾個具體問題：
由於
我想，使用任何P2P網絡將是無用的，因爲有更多的排列然後經常使用的文件。
下載文件的並行少數部分只能在慢速網絡（慢於4-10Mbps）時才能改善。
爲了獲得使用並行下載的任何改進，您需要確保將有足夠的服務器電源。從你目前的問題（等待超過500毫秒的連接），我假設你已經有問題的服務器：
再次，如果500ms是總響應時間的60％，那麼你的服務器超負荷，如果你認爲他們不是你應該搜索連接/服務器性能瓶頸。
我通過谷歌搜索找到你的帖子，看看是否有人已經寫了一個wget的並行模擬，這是否做到這一點。這對於通過相對高延遲鏈路的超大文件是絕對有可能的，並且會有所幫助：通過多個並行TCP連接，速度提高了10倍以上。
也就是說，既然您的組織運行的應用程序和Web服務，我猜你的鏈接是高帶寬和低延遲，所以我懷疑這種方法不會幫助你。
由於您正在傳輸大量小文件（按照現代標準），我懷疑您實際上正在被連接設置燒燬，而不是通過傳輸速度。您可以通過加載一張充滿小圖片的類似頁面來測試。在你的情況下，你可能想要串行而不是並行：看看你的HTTP客戶端庫是否有使用持久HTTP連接的選項，這樣three-way handshake每頁只能執行一次或更少，而不是每個圖像執行一次。
如果你最終變得對TCP延遲很狂熱，那麼也可以將cheat作爲某些主要的Web服務來使用。 （我自己的問題涉及到TCP性能頻譜的另一端，長時間的往返時間真的開始拖延我的多TB文件傳輸帶寬，所以如果你打開一個並行HTTP庫，我很樂意聽到這個消息，我發現的唯一一個叫做「puf」的工具是通過文件而不是字節範圍來並行化的，如果上述方法不能幫助你，而且你真的需要一個並行傳輸工具，那麼請聯繫：我可能已經放棄了，然後寫出來。）
+1有趣的問題。 – Gumbo 2010-11-06 16:27:35
+1。我的直覺表明，這將無濟於事，因爲（付費？）Web服務不太可能強制執行每個連接的帶寬限制（這就是爲什麼該技術適用於下載加速器） - 但有興趣聽到其他內容。 – SimonJ 2010-11-06 18:18:34
這裏沒有強制執行帶寬限制。 – matth 2010-11-07 15:07:00