為高延遲/高頻寬 tcp 傳輸調整視窗
如何通過芝加哥和倫敦之間的 100 mbps 鏈路加快 Windows 7 tcp 文件傳輸速度？
現在，我在兩個 sftp 會話中傳輸兩個 4GB 文件。每個文件傳輸以 500 KB/s (4 Mbits/sec) 的速率執行。（B == 字節，b == 位，自然）。這很慢，因為 iperf 測試顯示單個 TCP 流的速率為 16.8 Mbits/sec。那是 2 MB/秒。
啟動第二個 sftp 會話不會影響第一個 iota 的速度。這對我來說很有意義，因為我注意到我的 iperf 測試在 TCP 下受到限制——每個連接為 16 Mbps，這為更多連接留出了線上空間。通過執行許多並行連接，我能夠使 iperf 使我的線路飽和，這是頻寬的線性增加。也就是說，通過 5 個並行連接，我實現了大約 5x16 == 80 Mbps 的頻寬。
我注意到使用 sftp 的本地文件傳輸速度約為 30 MB/s……相當不錯。所以我不認為 SSH 通道加密是瓶頸。
我已經查看了通過高速、高延遲 WAN 連結傳輸單個大文件的最佳方式是什麼？以及其他伺服器故障問題，並且有很多有趣的工具，但我正在尋找一種調整 Windows 的 TCP 堆棧以確保我至少獲得完整的 2 MB 的方法……也許更多，因為iPerf 測試是在未調整的機器上進行的。
我還注意到，當我從芝加哥文件伺服器拖放倫敦機器上的文件時，它似乎以相當不錯的剪輯傳輸（如在傳輸過程中查看細節所示），但幾分鐘後它從懸崖跌落到 10 的 Kbps。這很奇怪。
我的延遲穩定在 88 毫秒左右，所以我認為網路基礎設施很好。我們有專線；這不是 Internet 上的 VPN 或類似的東西。
========
我有一個 Linux 虛擬機，它在網路方面“接近”我的 Windows 桌面。也就是說，它們位於不同的子網上，但兩台機器都進入交換機，而交換機又都進入另一個去往倫敦的交換機。現在我正在執行一個從 Linux 到倫敦的 sftp，它以 8 MB/s 的速度執行，而我的桌面繼續以 500 KB/s 的速度執行。
======== 好的，我將我的 Linux 筆記型電腦放在與我的台式機完全相同的開關上。此時桌面正在以 500 KB/s 的速度執行 sftp，而 Linux 筆記型電腦正在以 7.6 MB/s 的速度發送 4Gig 文件。當然，到倫敦的同一台伺服器。
======== 另一個測試：我使用的是 VanDyke Corp 的 SecureFX。我的 PC 上也有 Cygwin，我只是在那裡使用了 CLI sftp 命令。我剛剛將吞吐量提高了五倍……我現在獲得了 2.5 MB/s 而不是 500k！:-\ 這與我的 16 Mbps iPerf 結果相當。我本來會滿足的……儘管現在我注意到我的筆記型電腦的速度是它的三倍。
======== 另一個測試：在我的倫敦機器上，我啟動了一個 Windows Explorer 文件從芝加哥的文件伺服器複製到本地安裝的下載文件夾（即，在內部硬碟上）。吞吐量穩定在 5.49 MB/s，持續 12 分鐘左右。這對我來說已經足夠接近了！再一次，通過 SecureCRT 進行複制非常緩慢——穩定的 500 KB/s。
我唯一能得出的結論是，雖然 TCP 調整可能會有所幫助，但您使用的應用程序可以產生很大的不同！此外，我不知道為什麼前幾天我的文件副本表現得如此奇怪。如果再次發生，我將嘗試調試。
感謝您的建議和回复。
======================
好的，我關注了 Todd Wilcox 的連結並弄清楚了一些事情：
- 首先，根據微軟的說法，來自<https://technet.microsoft.com/en-us/library/cc957546.aspx?f=255&MSPPError=-2147217396>，“TCP 使用接收視窗……對於乙太網，預設值這個條目的大小是 0x4470（17,520，或 12 個段，每個段 1,460 字節）”好吧，我有一個延遲為 80 毫秒的 WAN，所以這太小了。
- 我已將系統資料庫中的 GlobalMaxTcpWindowSize 和 TcpWindowSize（後者在我的適配器上）設置為 1 MiB，然後轉到命令行並用於
netsh將接收視窗自動調整級別從正常更改為禁用。我的網路傳輸速度沒有改變，所以我重新啟動了我的機器並再次執行了從桌面到倫敦伺服器的 sftp。- 吞吐量驟降至 700 KB/s。不用說，我把所有東西都放回去並重新啟動。現在我的吞吐量恢復到 2.1 MB/s。
- 在 sftp 期間，Wireshark 對 TCP 視窗縮放顯示出一種奇怪的鋸齒模式，從大約 64000 字節變為 62000 字節，然後再次備份。循環大約需要 35 秒。
- 假設我的平均視窗大小為 63000 字節。因此，我的 Bps 吞吐量應該是（來自<http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/>），Window-Size（字節）/延遲（秒）== 700 KB/s。奇怪的是我得到了 2.1 MB/s ……這比理論值高！我確定兩者之間沒有 Wan 加速器或比 Cisco 4948 更複雜的東西。也許 Wireshark 的視窗縮放圖與視窗大小不同，我不知道，但Google搜尋告訴我那是我的地方d 找到 TCP 視窗大小。
- 事情沒有加起來。雖然我確實發現我的玩弄確實把事情搞砸了，但我不知道如何確定我的 TCP 視窗大小是多少。此外，經常出現的 Brad Hedlund 頁面提供了一些計算結果，這些計算結果並未反映在我的經驗中。
- 最後，這是我學到的最重要的一課：我想我會一個人呆著。如果我們發現我們需要更好的吞吐量，也許我會推荐一個 WAN 加速器。但是由於我們要跨越半個地球，我們不應該期望單個 TCP 連接提供驚人的頻寬。
計算最佳 TCP 視窗大小的公式（來源）：
每秒頻寬（以比特為單位）* 往返延遲以秒為單位 = TCP 視窗大小（以比特為單位）/8 = TCP 視窗大小（以字節為單位）
在您的情況下：100 000 000 * .088 = 8 800 000 位或 1 100 000 字節
這可在 Windows 系統資料庫中的 TcpWindowSize 鍵中配置，有效範圍為 0–0x3FFFFFFF（十進制為 1 073 741 823），因此該數字在有效範圍內。
預設值是以下中的最小值（注意：“只有在連接到支持 RFC 1323 Window Scaling 的其他系統時才能實現大於 64 KB 的值”）：
- 0xFFFF
- GlobalMaxTcpWindowSize（另一個系統資料庫參數）
- MSS（最大段大小）的四倍中的較大者
- 16384 向上取整為 MSS 的偶數倍
該堆棧還根據媒體速度進行自我調整：
- 低於 1 Mbps：8 KB
- 1 Mbps – 100 Mbps：17 KB
- 大於 100 Mbps：64 KB
來源（這個連結現在大部分都死了 - 還活著，但只有奇蹟才能把它帶回來）
另見：http ://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/
並且：https ://technet.microsoft.com/en-us/library/cc938219.aspx