這文章解釋了為什麼 TCP-over-TCP 可能會造成效能災難。
我對此問題的理解是，「外部」TCP 連線處理資料包遺失和網路擁塞，並透過增加逾時（從而降低吞吐量）來相應地採取行動。然而，「內部」TCP 連線看不到這些網路狀況，因為它們是由外部 TCP「固定」的。因此，「內部」TCP 繼續以先前的速度發送資料包，從而破壞了「外部」TCP 連接的內部發送緩衝區。
我的問題是：
- 我的理解正確嗎？
- 看起來 TCP-over-TCP 崩潰只是內部的（即，它只影響本地緩衝區），但它是否也會影響網路？它是否會導致網路更加擁塞並且是否會降低同一網路上的其他連接的效能？
- 基於TCP的VPN如何解決這個問題？ OpenVPN 有一個文章對此，但它沒有說明為什麼這在實踐中不是問題（或者是嗎？）
非常感謝您的回答！
答案1
以我的理解，「tcp 熔毀」問題並不難解決：只需為內部 tcp 連接設定一個較大的重傳逾時時間即可。
透過大幅提高內層TCP連線的最小重送逾時時間，我們有效地停用了內層TCP的逾時重送機制。因此，避免了TCP熔斷問題。
例如，在linux中，您可以使用ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12s將透過OpenVPN建立的所有內部連線的最小重傳逾時時間從0.2秒增加到12秒（假設192.168.168.1/24是您的OpenVPN網段）。
您可以將上述指令設定為OpenVPN的up事件回呼。這樣一來，我們其實已經透過簡單的方式避免了tcp熔斷問題。
我們使用這種方法來優化 tcp-over-tcp 連結。即使在高延遲（數百毫秒）和高丟包的線路上，我們也沒有發現任何不利影響。
PS：在高延遲、高丟包、高頻寬的線路上，顯然需要為內部tcp連線準備一個大的視窗來佔用全部頻寬。
更新：
這裡的問題是，為什麼 TCP-over-TCP 對基於 TCP 的 VPN 沒有明顯的影響？
因為在很少丟包的高品質線路上，TCP熔斷現象並不突出。
答案2
我認為這與以下方式有更多關係傳輸控制協定有效，但不適用於 OpenVPN 本身。這是長篇大論和我的幾分錢：
我的理解正確嗎？
大致上是的，但是內部 TCP 連線不受「保護」。如果外部丟棄資料包且吞吐量變低或延遲變高，內部連線也會受到此限制，請注意，它無法充分利用效能並開始回退。
看起來 TCP-over-TCP 崩潰只是內部的（即，它只影響本地緩衝區），但它是否也會影響網路？
您將只有一個到伺服器的 TCP 連接，因此這只會影響該特定連接及其中的任何內容。崩潰指的是我在之前的答案中描述的內容。
它是否會導致網路更加擁塞並且是否會降低同一網路上的其他連接的效能？
不，但我需要在這裡定義“網路”。如果您的網路連線狀況不佳，那麼是的，所有內容都會出現資料包遺失或其他傳輸問題。如果您的意思是您的客戶端 <=> 伺服器連線有問題，那麼您的非 VPN 連線不會受到影響。
基於TCP的VPN如何解決這個問題？
透過使用與伺服器的單一連接，在該連接內發送流量並期待最好的結果。
OpenVPN有一篇關於這個的文章，但沒有說為什麼在實務上不是問題，在實務上是否有問題。
是的。 TCP 在封包大小方面的開銷比 UDP 高得多，因此您總是會因為連線中包含兩個 TCP 標頭（內部加外部）而付出尺寸損失。重新發送和 TCP 加速也會影響您的效能。如果您有良好的連接，即無斷線、低延遲和高頻寬，那麼您將不會看到太多的斜坡上升/回退/重新發送，因此不會注意到這一點。如果連接不好，那麼第一個答案就會發揮作用，外部連接可能會下降，這將影響內部流量，而內部流量也會下降，數據包可能會變得混亂並被重新發送等等，這肯定會影響內部流量。
答案很長。我希望這對比我更多的人有意義。