衛星連接的 RTT 通常約為 500 毫秒。儘管有大量頻寬，但連線通常會受到次優傳輸速度的影響，因為 TCP 確認需要很長時間才能到達。
我的理解是，解決 TCP 連線問題的一個好方法是將 TCP 視窗大小設定為連線速度（以位元為單位）乘以 RTT（以秒為單位）。因此，衛星上的 1mbps 連線的視窗大小應為 512kb。
這其中有哪些陷阱？是否還需要進行其他類似的調整來優化衛星連線？我知道許多現代作業系統會自動修改視窗大小，但是它們是否會足夠積極地將視窗大小設定得足夠大以適合衛星通訊？
順便說一句，我假設在經常丟棄資料包的網路上不希望使用大的視窗大小，因為重傳將在視窗大小上進行，並且您可能會將大部分頻寬用於重傳開銷。
謝謝您，我仍在學習大量有關網路的知識，並感謝您的意見。
答案1
您通常應該使用實作適當視窗縮放的 TCP 堆疊。但當然，您的視窗大小需要與頻寬延遲乘積（BDP）相匹配，這是正確的。如果您有不同的 BDP，您可以將視窗大小設定為您期望的常見「最壞」情況。有趣的是，如果視窗大小大於 BDP，大多數連線不會受到太大影響（不應該方式當然太大了），但如果視窗大小遠小於 BDP，則效能會下降。
要檢查您的 TCP/IP 堆疊是否正確增加了視窗大小，您應該使用 Wireshark 或任何其他流量嗅探器。您可以直接查看標題中的視窗大小標誌（考慮到縮放係數！）。 Wireshark 還可以透過考慮縮放因子來顯示有效視窗大小。
請參閱本教學課程，了解如何繪製 TCP 視窗大小隨時間變化的函數這裡。
答案2
這完全是學術性的，因為沒有人透過衛星連線運行 TCP。我不知道有哪個衛星提供者能做到這一點。它們都在衛星上運行特定於衛星的協議，並將 TCP 端點放置在地面站。
當網路上的機器向衛星終端發送TCP SYN包時，衛星終端會向衛星發送TCP代理請求。這指示地面站開啟與網際網路上某個伺服器的 TCP 連線。地面站透過 TCP 與互聯網伺服器進行通訊。衛星終端不透過衛星使用 TCP，而是使用針對衛星使用而最佳化的協定。地面站充當衛星終端和互聯網伺服器之間的代理。
答案3
為了方便起見，有可用的頻寬延遲乘積計算器 - 其中一個計算器是這裡。至於大視窗在丟包時會導致問題 - 這正是 TCP 視窗可變的原因。資料包遺失後，視窗大小將減小，從而減少傳輸中的數據，從而降低傳輸速度。一段時間後視窗大小將重新協商。
對於衛星來說，延遲實際上並沒有那麼糟糕 - 1s RTT @ 1M 只是一個 125K 視窗。許多現代作業系統可以輕鬆地開箱即用地支援這一點，因此可能不需要進行額外的修改。
順便說一句，有些人在使用市場上的各種廣域網路優化器方面運氣很好。這些往往會優化 TCP 視窗大小，並利用快取和壓縮來推動更多的連結並提高明顯的回應能力。