Frage:
Was ist der Unterschied zwischen VPN über TCP und UDP?
David Drohang
2013-01-10 10:50:47 UTC
view on stackexchange narkive permalink

Mein VPN-Anbieter bietet mir die Möglichkeit, UDP und TCP für Verbindungen zu verwenden. Laut dieser Seite ist UDP auf kurzen Strecken schneller. Ich bin auf dem gleichen Kontinent wie mein Server. Wird das als kurze Entfernung angesehen? Gibt es einen Test, den ich ausführen kann, um die beiden zu vergleichen?

Hinzufügen zu der Frage, was passiert, wenn TCP-Verkehr über UDP-VPN-Tunnel gesendet wird?
Fünf antworten:
Thomas Pornin
2013-01-10 18:23:18 UTC
view on stackexchange narkive permalink

Ein VPN dient zum Umschließen roher IP-Pakete in eine Art "Tunnel" zwischen zwei Standorten (einer der Standorte wird möglicherweise auf einen Computer reduziert, d. h. Ihren). TCP ist ein Protokoll, das sich über IP befindet und IP-Pakete verwendet (die "unzuverlässig" sind: Sie können verloren gehen, dupliziert, neu angeordnet werden ...), um einen zuverlässigen bidirektionalen Kanal für bereitzustellen Datenbytes, wobei Bytes den Empfänger immer in der Reihenfolge erreichen, in der sie gesendet wurden. TCP verwendet dazu ein komplexes Sortiment von Metadaten mit expliziten Bestätigungen und Neuemissionen. Daher verursacht TCP einen geringen Netzwerk-Overhead.

Wenn das VPN TCP verwendet, verwenden Ihre eigenen TCP-Verbindungen IP-Pakete, die über das VPN gesendet werden, sodass Sie am Ende das TCP bezahlen Overhead zweimal. Ein UDP-basiertes VPN hat somit das Potenzial für eine etwas bessere Leistung. Andererseits erfordert der kryptografische Schutz des VPN eine gewisse Statusverwaltung, die für die VPN-Implementierung bei Verwendung von UDP möglicherweise schwieriger ist. Daher ist es möglich, dass das UDP-basierte VPN einen zusätzlichen Overhead hat.

Daher ist die Leistungssituation nicht klar und Sie sollten messen.

Ich habe es nicht verstanden, "TCP-Overhead zweimal zu bezahlen", wenn VPN über TCP-Verbindungen verwendet wird. Können Sie es bitte etwas näher erläutern?
TCP stellt einen bidirektionalen Tunnel für Daten bereit, stützt sich jedoch auf Pakete, sodass einige "administrative" Pakete vorhanden sind, z. bestätigt: Dies ist der TCP-Overhead. Wenn beispielsweise Maschine A 10 MB an Maschine B sendet, sendet Maschine B auch einige Pakete an A, um den Empfang zu bestätigen. Wenn Sie ein VPN über TCP durchführen, hat das VPN einen eigenen TCP-basierten Overhead. _Und_ transportiert die Verwaltungspakete für jede Verbindung innerhalb des VPN - dies ist die "doppelte Zahlung".
Hier sind ein paar Bilder für Sehbehinderte.Sie sind wahrscheinlich nicht ganz richtig und vielleicht ein bisschen vereinfacht, aber sie sollten Ihnen die Idee geben.[HTTP-Anforderung über TCP-VPN] (https://i.stack.imgur.com/yUPoY.png) und [HTTP-Anforderung über UDP-VPN] (https://i.stack.imgur.com/3BXBR.png).Beachten Sie das zusätzliche Hin und Her zwischen dem VPN-Client und dem VPN-Server in der Mitte: Dies ist Ihr zusätzlicher Overhead (der VPN-Server muss die gekapselten Pakete vom Client bestätigen und umgekehrt - einschließlich der SYN / ACK-Pakete zwischen dem Clientund Zielserver)
NULLZ
2013-01-10 12:05:27 UTC
view on stackexchange narkive permalink

Sie können versuchen, eine Datei mit beiden Methoden herunterzuladen und festzustellen, ob sich die Download-Geschwindigkeiten drastisch unterscheiden.

Die Kompromisse zwischen TCP und UDP (unabhängig von der VPN-Nutzung) sind immer gleich: Sie opfern Geschwindigkeit für Zuverlässigkeit, da UDP verbindungslos ist und es dem Server, der die Daten theoretisch sendet (abhängig von der Implementierung), egal ist, ob er das Ziel erreicht oder nicht. Dies ist in Dingen wie Internet-Spielen in Ordnung, bei denen jedes Paket eine Bewegung eines Benutzers sein könnte, aber in Dingen wie Verschlüsselung, bei denen fehlende Datenbits bedeuten, dass möglicherweise eine gesamte Nachricht erneut gesendet werden muss, wäre TCP mit der Zeit willkommener Durch die Verwendung von UDP gewonnene Daten können verloren gehen, wenn eine gesamte Nachricht erneut gesendet werden muss.

Auf demselben Kontinent zu sein, wird im Allgemeinen nicht als kurze Entfernung angesehen. Ich würde in Betracht ziehen, im selben Gebäude zu sein, vielleicht in der gleichen Stadt wie ein kurzes Stück, aber nicht viel weiter. Je mehr Sprünge ein Paket durchlaufen muss, desto wahrscheinlicher ist es, dass es irgendwann auf dem Weg beschädigt wird. Wenn Sie sehen möchten, wie viele Sprünge erforderlich sind, um an Ihr Ziel zu gelangen, führen Sie einen Befehl "trace route" aus.

Ich hoffe, ich habe geholfen.

Stimmen Sie nicht zu, dass Sie Geschwindigkeit gegen Zuverlässigkeit tauschen. Erstens muss ein TCP-Stream zuverlässig bereitgestellt werden - es spielt keine Rolle, ob er direkt im zugrunde liegenden Netzwerk implementiert ist oder ob er in UDP-Paketen optimiert ist -, wenn Pakete in die Irre gehen, müssen sie erneut gesendet werden, um den Stream zu verarbeiten. Manchmal sind die Methoden zur Überlastungskontrolle in TCP jedoch kontraproduktiv. In einem Netzwerk mit hohem BDP kann die Wiederherstellung nach einigen verworfenen Paketen sehr lange dauern. Der Speicherplatz geht zur Neige ... Die kurze Antwort hängt von Ihrem Netzwerk ab. Es ist nicht so einfach, wie auf dieser Seite angegeben. Sie müssen Ihr Netzwerk testen
mgjk
2013-01-11 01:16:56 UTC
view on stackexchange narkive permalink

UDP wird für VPNs bevorzugt, der Overhead ist geringer. Diese Diskussion über die Unzuverlässigkeit von UDP ist umstritten. Da wir optimieren, gibt es keinen Unterschied zwischen einem im offenen Internet verlorenen TCP-Datagramm und einem in einem TCP-Tunnel verlorenen TCP-Datagramm oder einem in einem UDP-Tunnel verlorenen TCP-Datagramm. Alle werden erneut übertragen.

Ein Problem mit UDP-Tunneln besteht darin, dass sie zustandslos sind. Dies erschwert die Sicherung an der Firewall. Antwortpakete unterscheiden sich nicht von Quellpaketen. Aus Sicherheitsgründen sind TCP-Tunnel einfacher.

AJ Henderson
2013-01-10 20:39:37 UTC
view on stackexchange narkive permalink

Dies ist wirklich dasselbe wie TCP und UDP normalerweise. TCP ist ein System, bei dem garantiert wird, dass jedes Paket in der richtigen Reihenfolge ankommt. Wenn ein Paket nicht in der richtigen Reihenfolge empfangen wird, wird es gespeichert, und wenn ein Paket nicht angezeigt wird, um eine Lücke zu füllen, wird es erneut angefordert. Dies stellt einen vollständigen Datenstrom ohne Datenverlust sicher, bedeutet jedoch, dass eine Verbindung möglicherweise von einem fehlenden Paket gehalten wird, während die Informationen erneut angefordert werden.

UDP übernimmt dagegen keine solche Garantie, und die Informationen werden dies nicht tun in beliebiger Reihenfolge ankommen und als solche verarbeitet werden. Ich bin mir über die Auswirkungen auf die Sicherheit nicht sicher, aber Sie würden wahrscheinlich immer noch eine ähnliche Verzögerung bei UDP erhalten, wenn Sie eine nicht parallelisierbare Verkettungsstromverschlüsselung verwenden, da alle Pakete in der richtigen Reihenfolge eintreffen müssten, aber dies könnte auch durch überwunden werden Verwenden eines Verschlüsselungsmodus, der die parallele Entschlüsselung unterstützt.

Das einzige, was VPN dem typischen TCP / UDP-Mix hinzufügt, ist, dass es die Art der Verschlüsselungsmodi ein wenig einschränkt, dies aber ist ansonsten der typische Kompromiss.

Ich werde meine typische Frage stellen, warum die Abwertung? Ich weiß, dass der TCP / UDP-Teil korrekt ist. Gab es etwas, das ich an den Auswirkungen auf ein VPN verpasst habe?
GdD
2013-01-10 19:36:58 UTC
view on stackexchange narkive permalink

Die tatsächliche physische Entfernung von Punkt zu Punkt bedeutet nichts in der Internetwelt, alles hängt von den ISP-Verbindungen ab. Einmal habe ich einen Server im Rack neben mir gepingt und es hatte eine Verzögerung von 300 ms, weil die Pakete über den Pazifik und zurück geleitet wurden, weil die ISPs auf diese Weise miteinander verbunden waren. Wenn die Server direkt verbunden gewesen wären, wäre die Verzögerung in Mikrosekunden gewesen. Die Server waren nur wenige Zentimeter voneinander entfernt, aber die tatsächliche Entfernung, die die Pakete über alle Hopfen zurücklegten, lag in der Größenordnung von 25.000 Meilen! Das ist ein extremes Beispiel, aber es zeigt, dass man der Distanz nicht vertrauen kann.

Anstelle der Entfernung müssen Sie die Latenz betrachten. Dies ist die Umlaufzeit, die ein an das VPN-Ziel gesendetes Echo benötigt, um beantwortet zu werden. Welche Umlaufzeit UDP zu einer besseren Wahl als TCP machen würde, weiß ich nicht, und es ist nicht so einfach, da es andere Faktoren gibt:

  • Paketverlust und Jitter: UDP ist sehr Es reagiert empfindlich auf Paketverlust und Jitter (Paket außerhalb der Reihenfolge) und verfügt nicht über einen integrierten Korrekturmechanismus wie TCP. Jede Latenz oder jeder Jitter beeinträchtigt die Vorteile der Verwendung von UDP gegenüber TCP.
  • Effizienz des IP-Stacks des Betriebssystems: Die VPN-Anwendung verwendet den TCP / IP-Stack des Betriebssystems, der auch UDP-Pakete verarbeitet. Ein Großteil der relativen Effizienz von TCP im Vergleich zu UDP hängt davon ab, wie gut das Betriebssystem (und alle Paketfilter oder Firewalls im Weg) TCP im Vergleich zu UDP verarbeitet.
  • Anwendungscodierung: Die Qualität der VPN-Anwendung wird eine große Rolle spielen Unterschied, ebenso wie die VPN-Software auf dem Gerät, mit dem Sie eine Verbindung herstellen. Wie wird es beispielsweise von verlorenen UDP-Paketen wiederhergestellt? Kann es Neuübertragungen anfordern oder verlässt es sich auf die Upstream-Anwendungen, um Neuübertragungen anzufordern?

Es gibt zu viele Faktoren, um eine endgültige Antwort zu geben, da dies von zu vielen Faktoren abhängt. Sie müssen einfach beide Methoden ausprobieren und sehen.

Die UDP-Pakete werden nicht erneut angefordert, aber das getunnelte TCP-Paket wird erneut angefordert, indem diese Anforderung innerhalb eines neuen UDP-Pakets getunnelt wird. TCP-in-TCP bedeutet natürlich, dass * beide * erneut angefordert werden.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...