通過高速、高延遲 WAN 連結傳輸單個大文件的最佳方式是什麼？
這看起來與此相關，但有些不同。
兩個公司站點之間有這個 WAN 連結，我們需要傳輸一個非常大的文件（Oracle 轉儲，~160 GB）。
我們有完整的 100 Mbps 頻寬（已測試），但由於 TCP 的工作方式（ACK 等），單個 TCP 連接似乎無法將其最大化。我們使用iperf測試了連結，當增加 TCP 視窗大小時，結果發生了顯著變化：使用基本設置，我們可以獲得約 5 Mbps 的吞吐量，使用更大的 WS，我們可以達到約 45 Mbps，但僅此而已。網路延遲約為 10 毫秒。
出於好奇，我們使用多個連接執行 iperf，我們發現，當執行其中四個時，它們確實會達到約 25 Mbps 的速度，從而填滿所有可用頻寬；所以關鍵看起來是在執行多個同時傳輸。
使用 FTP，情況會變得更糟：即使使用優化的 TCP 設置（高視窗大小、最大 MTU 等），單次傳輸也不能超過 20 Mbps。我們嘗試同時 FTP 傳輸一些大文件，確實比傳輸單個文件要好得多；但後來罪魁禍首變成了磁碟 I/O，因為從同一個磁碟讀取和寫入四個大文件很快就會出現瓶頸；此外，我們似乎無法將單個大文件拆分為較小的文件，然後將其合併回來，至少在可接受的時間內不能（顯然我們不能花費與轉移它）。
這裡理想的解決方案是一個多執行緒工具，可以同時傳輸文件的各個塊；有點像 eMule 或 BitTorrent 等點對點程序，但從單一來源到單一目的地。理想情況下，該工具將允許我們選擇使用多少並行連接，當然還可以優化磁碟 I/O，以免在文件的各個部分之間（過於）瘋狂跳轉。
有人知道這樣的工具嗎？
或者，任何人都可以提出更好的解決方案和/或我們已經沒有嘗試過的東西嗎？
PS 我們已經考慮將其備份到磁帶/磁碟並將其物理髮送到目的地；如果 WAN 不削減它，那將是我們的極端措施，但是，正如 AS Tanenbaum 所說，“永遠不要低估一輛滿載磁帶的旅行車在高速公路上疾馳而過的頻寬。”
搜尋“高延遲文件傳輸”會帶來很多有趣的結果。顯然，這是 CompSci 社區和商業社區都在考慮的問題。
一些似乎符合要求的商業產品：
- FileCatalyst的產品可以使用 UDP 或多個 TCP 流在高延遲網路上傳輸數據。他們還有很多其他的功能（即時壓縮、增量傳輸等）。
- Aspera的fasp文件傳輸“技術”似乎也符合您的需求。
在開源世界中，uftp項目看起來很有前途。您並不特別需要它的多播功能，但基本思想是將文件爆破到接收器，在傳輸結束時接收失去塊的 NAK，然後爆破 NAK 的塊（起泡、沖洗、重複）聽起來它可以滿足您的需求，因為在文件傳輸完成一次之前，接收器沒有 ACK（或 NAK）。假設網路只是潛在的，而不是有損的，這也可能滿足您的需求。