Frage Unter welchen Umständen schneidet TCP-over-TCP deutlich schlechter ab als TCP (2014)?


Viele Admins verewigen - auf ServerFault und anderswo - wie schlecht eine Idee TCP-über-TCP ist, z. in VPNs. Dass selbst der geringste Paketverlust dazu führt, dass zumindest eine starke Durchsatzverschlechterung auftritt, wenn TCP-Kernschmelze nicht auftritt, und TCP-über-TCP daher unbedingt zu vermeiden ist. Und das war wahrscheinlich einmal alles richtig, z.B. 2001 wann Dieser Beitrag wurde geschrieben, auf die immer noch Bezug genommen wird.

Aber seitdem haben wir große Fortschritte in Technologie und Protokollen gesehen. Heutzutage haben wir 'Selective ACK' fast überall implementiert, und Moores Gesetz hat uns so viel mehr Speicher gegeben, und mit ihm kamen große TCP-Puffer, die für Gbit-Uplinks optimiert waren. Auch der Paketverlust ist heutzutage bei Nicht-Funkverbindungen viel weniger ein Problem. All dies sollte das TCP-über-TCP-Problem erheblich verringern, oder?

Beachten Sie, dass es reale Szenarien gibt, in denen z. TCP-basierte VPNs sind einfacher zu implementieren und zu betreiben als UDP / ESP-basierte (siehe weiter unten). Deshalb meine Frage:

Unter welchen Umständen (Linkpaketverlust und Latenzzeit) ist TCP-over-TCP wesentlich schlechter als TCP alleine, unter der Annahme einer SACK-Unterstützung und einigermaßen großer TCP-Puffer an beiden Enden?

Es wäre großartig, einige Messungen zu sehen, die die Korrelationen zwischen (äußerer Verbindung) Paketverlust / Latenz und (innerer Verbindung) Durchsatz / Jitter - für TCP-über-TCP und für TCP allein zeigen. ich fand dieser interessante Artikel, aber es scheint sich nur um die Latenz zu kümmern und um (äußeren) Paketverlust nicht zu adressieren.

Außerdem: Gibt es empfohlene Einstellungen (z. B. TCP-Optionen, Puffereinstellungen, Reduzieren von MTU / MSS usw.), um die Leistungslücke zwischen TCP und TCP-über-TCP zu verringern?


Update: Unsere Begründung.

Diese Frage ist in einigen realen Szenarien immer noch sehr relevant. Z.B. Wir setzen Embedded Devices in großen Gebäuden ein, die Sensordaten sammeln und via VPN in unsere Plattform einspeisen. Das Problem, mit dem wir konfrontiert sind, sind Firewalls und falsch konfigurierte Uplinks, die wir nicht in unserer Hand haben, kombiniert mit widerwilligen IT-Abteilungen. Sehen Sie sich ein ausführliches Beispiel an Hier.

In vielen Fällen ist der Wechsel von Nicht-TCP zu einem TCP-basierten VPN (sehr einfach, wenn Sie OpenVPN wie wir verwenden) eine schnelle Lösung, die es uns ermöglicht, Fingerzeigkämpfe zu umgehen. Z.B. oft ist TCP-Port 443 im Allgemeinen erlaubt (zumindest über Proxy), oder wir können Path-MTU-Probleme überwinden, indem wir einfach die MSS-Option von TCP reduzieren.

Es wäre gut zu wissen, unter welchen Umständen ein TCP-basiertes VPN als eine brauchbare Alternative betrachtet werden kann, so dass wir eine fundierte Entscheidung treffen können, die die Vor- und Nachteile beider Optionen überwiegt. Zum Beispiel wissen wir, dass TCP-VPN für uns auf Nicht-Funk-Verbindungen in Ordnung ist, aber wir haben einen fairen Anteil von Remote-Clients auf 3G-Uplinks mit erheblichem Paketverlust und hoher Latenz - wie würde ein TCP-VPN dort funktionieren?

Ich habe versucht, den Titel und die zentrale Frage entsprechend zu verbessern; Ich hoffe es macht Sinn.


24
2017-09-24 10:07


Ursprung


Sie werden den Unterschied zwischen TCP über TCP gegenüber UDP (usw.) gegenüber TCP-VPNs schnell erkennen, wenn Sie sie für interaktive Sitzungen verwenden, z. ssh. Sie werden eine Latenz bemerken, wenn die Sitzung nicht unterbrochen wird. YMMV, TIAS - Daniel S. Sterling
Nur wenn die "äußere" Verbindung in erster Linie einem gewissen Grad an Latenz oder Paketverlust unterliegt. Ich habe viele SSH-Sitzungen über TCP-basierte VPNs, und viele arbeiten gut, ohne spürbare Verzögerung. - Nils Toedtmann
In der Tat - es funktioniert, wenn Sie ein gutes Netzwerk haben. Wenn Sie nicht immer ein gutes Netzwerk haben, funktioniert es nicht immer - Daniel S. Sterling


Antworten:


Ich denke, es ist tatsächlich mehr diskutiert, als Sie es erscheinen lassen. Es gibt eine zugegebenermaßen alte, verwandte Linux-FAQ: http://www.tldp.org/HOWTO/VPN-HOWTO/

Ich habe seit mehr als 12 Jahren eine PPP-over-ssh-over-ADSL verwendet, und es hat mich nie im Stich gelassen, also würde ich aus meiner Erfahrung zu sagen wagen, dass die Untergangssünder wahrscheinlich übertreiben. TCP über TCP ist wahrscheinlich eine schlechte Idee mit RTC-Verbindungen, Satellitenverbindungen und anderen Links mit entweder sehr geringem Durchsatz oder sehr langen Verzögerungen, aber für die meisten Anwendungen funktioniert einfach.

Nun ist die wahre Frage: Warum würden Sie TCP über TCP verwenden überhaupt? Als ich mein PPP-over-ssh eingerichtet habe, war es hauptsächlich, weil es damals der einfachste Weg war, ein schnelles VPN aufzubauen; dann habe ich es seitdem aus reiner Faulheit benutzt.

Heutzutage gibt es praktische, einfach zu installierende Tools wie OpenVPN, IPSec VPNs, so dass Sie dieses TCP-über-TCP-Problem nicht einmal stören sollten.


6
2017-09-26 05:36



Es gibt Situationen, in denen TCP-over-TCP eine einfache Lösung für eine Reihe von Netzwerkproblemen ist. Ich fügte einen Abschnitt hinzu, der unsere Begründung darlegte. - Nils Toedtmann
Ich hoffe auf eine spezifischere Antwort zu den Bedingungen, unter denen TCP-over-TCP zum Problem wird. Einer unserer Anwendungsfälle ist Funkverbindungen mit unterschiedlichen Latenz- und Paketverlusten. - Nils Toedtmann
TCP über TCP über TCP (TCP-Verkehr in einem TCP-OpenVPN, auf den über eine TCP-SSH-Weiterleitung zugegriffen wird) kostet mich etwa 5 MB / s. Es hat mich nie im Stich gelassen, aber ich würde es nicht empfehlen, nur weil es eine riesige Verschwendung ist. - Sirens