Was ist TCP-over-TCP und wie vermeidet OpenVPN im TCP-Modus das Problem?

Was ist TCP-over-TCP und wie vermeidet OpenVPN im TCP-Modus das Problem?

DasArtikelerklärt, warum TCP-over-TCP zu einer Leistungskatastrophe führen kann.

Nach meinem Verständnis ist das Problem so, dass die „äußere“ TCP-Verbindung mit Paketverlusten und Überlastungen des Netzwerks zurechtkommt und entsprechend reagiert, indem sie die Timeouts erhöht (und so den Durchsatz reduziert). Die „innere“ TCP-Verbindung bemerkt diese Netzwerkbedingungen jedoch nicht, da sie vom äußeren TCP „behoben“ werden. Daher sendet das „innere“ TCP weiterhin Pakete mit der vorherigen Geschwindigkeit und lässt so den internen Sendepuffer der „äußeren“ TCP-Verbindung explodieren.

Meine Fragen sind:

  1. Habe ich das richtig verstanden?
  2. Es scheint, dass der TCP-over-TCP-Zusammenbruch nur intern ist (d. h. er betrifft nur lokale Puffer), aber betrifft er auch das Netzwerk? Führt er zu mehr Überlastungen im Netzwerk und verschlechtert er andere Verbindungen im selben Netzwerk?
  3. Wie lösen TCP-basierte VPNs dieses Problem? OpenVPN hat eineArtikeldazu, aber es wird nicht gesagt, warum es in der Praxis kein Problem ist (oder doch?)

Vielen Dank für jede Antwort!

Antwort1

Meines Wissens nach ist das Problem des „TCP-Meltdowns“ nicht schwer zu lösen: Sie müssen lediglich ein großes erneutes Übertragungs-Timeout für die interne TCP-Verbindung festlegen.

Indem wir das minimale Wiederholungszeitlimit der internen TCP-Verbindung deutlich erhöht haben, haben wir den Timeout-Wiederholungsmechanismus des internen TCP effektiv deaktiviert. Dadurch wird das TCP-Meltdown-Problem vermieden.

Beispielsweise können Sie unter Linux ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12sdas minimale Neuübertragungs-Timeout aller über OpenVPN hergestellten internen Verbindungen von 0,2 Sekunden auf 12 Sekunden erhöhen (dabei wird davon ausgegangen, dass 192.168.168.1/24 Ihr OpenVPN-Netzwerksegment ist).

Sie können den obigen Befehl als Up-Event-Callback von OpenVPN festlegen. Auf diese Weise haben wir das TCP-Meltdown-Problem tatsächlich auf einfache Weise vermieden.

Wir verwenden diese Methode, um die TCP-über-TCP-Verbindung zu optimieren. Selbst auf Leitungen mit hoher Latenz (Hunderte von Millisekunden) und hohem Paketverlust haben wir keine nachteiligen Auswirkungen festgestellt.

PS: Auf einer Leitung mit hoher Latenz, hohem Paketverlust und hoher Bandbreite ist es offensichtlich, dass Sie ein großes Fenster für die internen TCP-Verbindungen vorbereiten müssen, um die gesamte Bandbreite in Anspruch zu nehmen.

AKTUALISIEREN:

Die Frage hier ist, warum TCP-over-TCP keinen spürbaren Effekt auf TCP-basiertes VPN hat?

Denn auf einer qualitativ hochwertigen Leitung, auf der selten Pakete verloren gehen, tritt das TCP-Meltdown-Phänomen nicht auf.

Antwort2

Ich würde sagen, das hat mehr damit zu tun, wieTCPfunktioniert, und nicht mit OpenVPN an sich. Hier kommt eine lange Tirade und meine paar Cents:

Habe ich das richtig verstanden?

Grob gesagt ja, aber die innere TCP-Verbindung ist nicht „geschützt“. Wenn die äußere Verbindung ein Paket verwirft und der Durchsatz geringer oder die Latenz höher wird, wird dadurch auch die innere Verbindung eingeschränkt. Sie kann dann nicht mehr die volle Leistung nutzen und beginnt, langsamer zu werden.

Es scheint, dass der TCP-over-TCP-Zusammenbruch nur intern ist (d. h., er betrifft nur lokale Puffer), aber betrifft er auch das Netzwerk?

Sie haben nur eine TCP-Verbindung zum Server, daher betrifft dies nur diese bestimmte Verbindung und alles, was darin enthalten ist. Worauf sich der Zusammenbruch bezieht, habe ich in der vorherigen Antwort beschrieben.

Führt es zu mehr Überlastungen im Netzwerk und verschlechtert es die Qualität anderer Verbindungen im selben Netzwerk?

Nein, aber ich müsste hier "Netzwerk" definieren. Wenn Sie eine schlechte Verbindung zum Internet haben, dann würden alle unter Paketverlusten oder anderen Übertragungsproblemen leiden. Wenn Sie meinen, dass es nur ein Problem mit Ihrer Client<=>Server-Verbindung gibt, dann wären Ihre Nicht-VPN-Verbindungen nicht betroffen.

Wie lösen TCP-basierte VPNs dieses Problem?

Verwenden Sie eine einzelne Verbindung zum Server, senden Sie den Datenverkehr innerhalb dieser Verbindung und hoffen Sie das Beste.

OpenVPN verfügt über einen Artikel zu diesem Thema, der jedoch nicht erklärt, warum dies in der Praxis kein Problem darstellt bzw. ob es in der Praxis ein Problem darstellt.

Ja. TCP hat in Bezug auf die Paketgröße einen viel höheren Overhead als UDP, sodass Sie immer einen Größennachteil in Kauf nehmen, wenn Sie zwei TCP-Header (inneren und äußeren) in Ihrer Verbindung haben. Erneute Sendungen und TCP-Hochlauf wirken sich ebenfalls auf Ihre Leistung aus. Wenn Sie eine gute Verbindung haben, also keine Unterbrechungen, geringe Latenz und hohe Bandbreite, werden Sie von Hochlauf/Backoff/erneuten Sendungen nicht viel sehen und dies daher nicht bemerken. Wenn Sie eine schlechte Verbindung haben, kommt die erste Antwort ins Spiel: Die äußeren Verbindungen könnten heruntergefahren werden, was sich auf den internen Verkehr auswirkt, der heruntergefahren wird, Pakete können in der falschen Reihenfolge sein und erneut gesendet werden usw., was sich definitiv auf die Tunnelleistung auswirkt.

Lange Antwort ist lang. Ich hoffe, das hat für jemanden mehr Sinn ergeben als für mich.

verwandte Informationen