UDP vs TCP, wie viel schneller ist es? [geschlossen]

Für den allgemeinen Austausch von Protokollnachrichten, der einen gewissen Paketverlust tolerieren kann. Wie viel effizienter ist UDP über TCP?

UDP ist schneller als TCP, und der einfache Grund liegt darin, dass sein nicht vorhandenes Bestätigungspaket (ACK) einen kontinuierlichen Paketstrom zulässt, anstelle von TCP, das eine Reihe von Paketen bestätigt, die anhand der TCP-Fenstergröße und der Umlaufzeit berechnet werden (RTT).

Für weitere Informationen empfehle ich die einfache, aber sehr verständliche Skullbox-Erklärung (TCP vs. UDP).

Die Leute sagen, dass das Wichtigste, was TCP Ihnen bietet, die Zuverlässigkeit ist. Das stimmt aber nicht wirklich. Das Wichtigste, was TCP Ihnen bietet, ist die Überlastungskontrolle: Sie können 100 TCP-Verbindungen über eine DSL-Verbindung mit maximaler Geschwindigkeit ausführen, und alle 100 Verbindungen sind produktiv, da sie alle die verfügbare Bandbreite "erfassen". Versuchen Sie dies mit 100 verschiedenen UDP-Anwendungen, bei denen alle Pakete so schnell wie möglich übertragen werden, und sehen Sie, wie gut die Dinge für Sie funktionieren.

In größerem Maßstab verhindert dieses TCP-Verhalten, dass das Internet in einen "Überlastungskollaps" gerät.

Dinge, die dazu neigen, Anwendungen in Richtung UDP zu treiben:

• Semantik der Gruppenzustellung: Es ist möglich, eine zuverlässige Zustellung an eine Gruppe von Personen wesentlich effizienter durchzuführen als die Punkt-zu-Punkt-Bestätigung von TCP.

• Lieferung außerhalb der Reihenfolge: In vielen Anwendungen ist es Ihnen egal, in welcher Reihenfolge sie eingehen, solange Sie alle Daten erhalten. Sie können die Latenz auf App-Ebene reduzieren, indem Sie einen Block außerhalb der Reihenfolge akzeptieren.

• Unfreundlichkeit: Auf einer LAN-Party ist es Ihnen möglicherweise egal, ob Ihr Webbrowser einwandfrei funktioniert, solange Sie Updates für das Netzwerk so schnell wie möglich veröffentlichen.

Aber selbst wenn Sie Wert auf Leistung legen, möchten Sie wahrscheinlich nicht mit UDP arbeiten:

• Sie sind jetzt auf dem Weg zur Zuverlässigkeit, und viele Dinge, die Sie möglicherweise tun, um die Zuverlässigkeit zu implementieren, können langsamer sein als das, was TCP bereits tut.

• Jetzt sind Sie netzwerkunfreundlich, was in gemeinsam genutzten Umgebungen zu Problemen führen kann.

• Am wichtigsten ist, dass Firewalls Sie blockieren.

Sie können möglicherweise einige Probleme mit der TCP-Leistung und -Latenz überwinden, indem Sie mehrere TCP-Verbindungen miteinander "trunking". iSCSI führt dies aus, um die Überlastungskontrolle in lokalen Netzwerken zu umgehen. Sie können jedoch auch einen "dringenden" Nachrichtenkanal mit geringer Latenz erstellen (das "DRINGENDE" Verhalten von TCP ist vollständig fehlerhaft).

In einigen Anwendungen ist TCP schneller (besserer Durchsatz) als UDP.

Dies ist der Fall, wenn viele kleine Schreibvorgänge relativ zur MTU-Größe ausgeführt werden. Ich habe zum Beispiel ein Experiment gelesen, bei dem ein Stream von 300-Byte-Paketen über Ethernet (1500-Byte-MTU) gesendet wurde und TCP 50% schneller als UDP war .

Der Grund dafür ist, dass TCP versucht, die Daten zu puffern und ein vollständiges Netzwerksegment zu füllen, wodurch die verfügbare Bandbreite effizienter genutzt wird.

UDP hingegen stellt das Paket sofort auf die Leitung und überlastet so das Netzwerk mit vielen kleinen Paketen.

Sie sollten UDP wahrscheinlich nicht verwenden, es sei denn, Sie haben einen bestimmten Grund dafür. Zumal Sie TCP durch Deaktivieren des Nagle-Algorithmus die gleiche Latenz wie UDP geben können (z. B. wenn Sie Echtzeit-Sensordaten übertragen und sich keine Sorgen machen, das Netzwerk mit vielen kleinen Paketen zu überlasten).

mit verlusttolerant

Meinen Sie "mit Verlusttoleranz"?

Grundsätzlich ist UDP nicht "verlusttolerant". Sie können 100 Pakete an jemanden senden, der möglicherweise nur 95 dieser Pakete erhält, und einige befinden sich möglicherweise in der falschen Reihenfolge.

Für Dinge wie Video-Streaming und Multiplayer-Spiele, bei denen es besser ist, ein Paket zu verpassen, als alle anderen dahinter liegenden Pakete zu verzögern, ist dies die offensichtliche Wahl

Für die meisten anderen Dinge ist jedoch ein fehlendes oder neu angeordnetes Paket kritisch. Sie müssten zusätzlichen Code schreiben, um auf UDP ausgeführt zu werden, um es erneut zu versuchen, wenn etwas übersehen wird, und die richtige Reihenfolge durchzusetzen. Dies würde an bestimmten Stellen einen kleinen Overhead verursachen.

Zum Glück haben einige sehr, sehr kluge Leute dies getan und sie nannten es TCP.

Stellen Sie sich das so vor: Wenn ein Paket verloren geht, möchten Sie lieber das nächste Paket so schnell wie möglich abrufen und fortfahren (UDP verwenden), oder benötigen Sie tatsächlich die fehlenden Daten (TCP verwenden). Der Overhead spielt keine Rolle, es sei denn, Sie befinden sich in einem wirklich schwierigen Szenario.

Welches Protokoll (hinsichtlich des Durchsatzes) eine bessere Leistung erbringt - UDP oder TCP - hängt wirklich von den Netzwerkeigenschaften und dem Netzwerkverkehr ab. Robert S. Barnes weist beispielsweise auf ein Szenario hin, in dem TCP eine bessere Leistung erbringt (kleine Schreibvorgänge). Stellen Sie sich nun ein Szenario vor, in dem das Netzwerk überlastet ist und sowohl TCP- als auch UDP-Verkehr aufweist. Absender im Netzwerk, die TCP verwenden, werden die Überlastung erkennen und ihre Sendegebühren senken. UDP verfügt jedoch über keine Mechanismen zur Vermeidung von Überlastungen oder zur Kontrolle von Überlastungen, und Absender, die UDP verwenden, würden weiterhin Daten mit derselben Rate einpumpen. Allmählich würden TCP-Absender ihre Senderaten auf ein Minimum reduzieren, und wenn UDP-Absender über genügend Daten verfügen, um über das Netzwerk gesendet zu werden, würden sie den größten Teil der verfügbaren Bandbreite beanspruchen. In einem solchen Fall also UDP-Absender haben einen höheren Durchsatz, da sie den größeren Teil der Netzwerkbandbreite erhalten. Tatsächlich ist dies ein aktives Forschungsthema - Wie kann der TCP-Durchsatz bei Vorhandensein von UDP-Verkehr verbessert werden? Eine mir bekannte Möglichkeit, mit welchen TCP-Anwendungen der Durchsatz verbessert werden kann, besteht darin, mehrere TCP-Verbindungen zu öffnen. Auf diese Weise kann, obwohl der Durchsatz jeder TCP-Verbindung begrenzt sein kann, die Gesamtsumme des Durchsatzes aller TCP-Verbindungen größer sein als der Durchsatz für eine Anwendung, die UDP verwendet.

Wenn man von "was ist schneller" spricht, gibt es mindestens zwei sehr unterschiedliche Aspekte: Durchsatz und Latenz.

Wenn es um den Durchsatz geht, ist die Flusskontrolle von TCP (wie in anderen Antworten erwähnt) äußerst wichtig, und alles, was über UDP vergleichbar ist, ist zwar durchaus möglich, würde aber große Kopfschmerzen verursachen. Infolgedessen ist die Verwendung von UDP, wenn Sie einen Durchsatz benötigen , selten eine gute Idee (es sei denn, Sie möchten einen unfairen Vorteil gegenüber TCP erzielen).

Wenn es jedoch um Latenzen geht, ist das Ganze völlig anders. Während sich TCP und UDP ohne Paketverlust extrem ähnlich verhalten (etwaige Unterschiede sind geringfügig), ändert sich das gesamte Muster drastisch, nachdem das Paket verloren gegangen ist.

Nach jedem Paketverlust wartet TCP mindestens 200 ms auf die erneute Übertragung (1 Sekunde gemäß Abschnitt 2.4 von RFC6298, aber praktische moderne Implementierungen neigen dazu, ihn auf 200 ms zu reduzieren). Darüber hinaus werden mit TCP auch die Pakete, die den Zielhost erreicht haben, erst dann an Ihre App übermittelt, wenn das fehlende Paket empfangen wurde (dh die gesamte Kommunikation wird um ~ 200 ms verzögert). Übrigens, dieser Effekt wird als Head-of bezeichnet -Line Blocking ist allen zuverlässigen geordneten Streams inhärent, egal ob TCP oder zuverlässiges + geordnetes UDP. Um die Sache noch schlimmer zu machen - wenn das erneut übertragene Paket ebenfalls verloren geht, sprechen wir von einer Verzögerung von ~ 600 ms (aufgrund des sogenannten exponentiellen Backoffs beträgt die erste erneute Übertragung 200 ms und die zweite 200 * 2 = 400 ms). Wenn unser Kanal einen Paketverlust von 1% hat (was nach heutigen Maßstäben nicht schlecht ist), und wir haben ein Spiel mit 20 Updates pro Sekunde - solche Verzögerungen von 600 ms treten durchschnittlich alle 8 Minuten auf. Und da 600 ms mehr als genug sind, um dich in einem rasanten Spiel umzubringen - nun, es ist ziemlich schlecht für das Gameplay. Genau aus diesen Gründen bevorzugen Gamedevs häufig UDP gegenüber TCP.

Wenn Sie jedoch UDP verwenden, um Latenzen zu reduzieren, ist es wichtig zu wissen, dass die bloße Verwendung von UDP nicht ausreicht, um die Latenz erheblich zu verbessern. Es geht darum, wie Sie UDP verwenden. Insbesondere während RUDP-Bibliotheken normalerweise dieses "exponentielle Backoff" vermeiden und kürzere Neuübertragungszeiten verwenden - wenn sie als "zuverlässig geordneter" Stream verwendet werden, müssen sie dennoch unter Head-of-Line-Blocking leiden (also im Falle eines Double) Paketverlust, anstelle dieser 600 ms erhalten wir ungefähr 1,5 * 2 * RTT - oder für eine ziemlich gute 80 ms RTT ist es eine Verzögerung von ~ 250 ms, was eine Verbesserung darstellt, aber es ist immer noch möglich, es besser zu machen). Auf der anderen Seite, wenn Techniken verwendet werden, die unter http://gafferongames.com/networked-physics/snapshot-compression/ und / oder http: // ithare beschrieben werden. ist es möglich, die Head-of-Line-Blockierung vollständig zu beseitigen (bei einem Verlust von zwei Paketen für ein Spiel mit 20 Updates / Sekunde beträgt die Verzögerung unabhängig von RTT 100 ms).

Und als Randnotiz: Wenn Sie zufällig nur auf TCP, aber kein UDP zugreifen (z. B. im Browser, oder wenn sich Ihr Client hinter einer von 6-9% der hässlichen Firewalls befindet, die UDP blockieren), scheint es einen Weg zu geben Implementieren Sie UDP-over-TCP, ohne zu viele Latenzen zu verursachen. Weitere Informationen finden Sie hier: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (Lesen Sie auch die Kommentare (!)).

Jede TCP-Verbindung erfordert einen ersten Handshake, bevor Daten übertragen werden. Außerdem enthält der TCP-Header viel Overhead für verschiedene Signale und die Erkennung der Nachrichtenübermittlung. Für einen Nachrichtenaustausch reicht UDP wahrscheinlich aus, wenn eine geringe Ausfallwahrscheinlichkeit akzeptabel ist. Wenn der Empfang überprüft werden muss, ist TCP die beste Option.

@ Andrew , ich bitte zu unterscheiden. UDP ist aufgrund der Leistungsanforderungen die Wahl für einige Arten von Anwendungen. Ein klassisches Beispiel sind Videokonferenzen. Diese Art von Anwendung reagiert nicht gut auf die TCP-Steuerung.

Ein weiterer zu berücksichtigender Aspekt ist, wenn Sie Multicast benötigen. Wenn ja, verwenden Sie UDP.

Wenn Sie schnell eine Nachricht über das Internet zwischen zwei IPs senden müssen, die noch nicht einmal gesprochen haben, kommt ein UDP mindestens dreimal schneller an, normalerweise fünfmal schneller.

Ich werde nur die Dinge klarstellen. TCP / UDP sind zwei Autos, die auf der Straße gefahren werden. Angenommen, Verkehrszeichen und Hindernisse sind Fehler. TCP kümmert sich um Verkehrszeichen und respektiert alles in der Umgebung. Langsames Fahren, da dem Auto etwas passieren kann. Während UDP losfährt nur, keine volle Geschwindigkeit auf Straßenschilder achten. Nichts, ein verrückter Fahrer. UDP hat keine Fehlerbehebung. Wenn es ein Hindernis gibt, kollidiert es einfach damit und fährt dann fort. Während TCP sicherstellt, dass alle Pakete perfekt gesendet und empfangen werden, gibt es keine Fehler. Das Auto passiert also nur Hindernisse, ohne zu kollidieren. Ich hoffe, dies ist ein gutes Beispiel für Sie, um zu verstehen, warum UDP beim Spielen bevorzugt wird. Gaming braucht Geschwindigkeit. in Downloads bevorzugt wird oder heruntergeladene Dateien möglicherweise beschädigt sind. TCP

UDP ist meiner Erfahrung nach etwas schneller, aber nicht viel. Die Wahl sollte nicht nach Leistung, sondern nach Nachrichteninhalt und Komprimierungstechniken getroffen werden.

Wenn es sich um ein Protokoll mit Nachricht ist Austausch , würde ich vorschlagen , dass die sehr geringe Leistung treffen Sie mit TCP nehmen ist mehr als wert. Sie erhalten eine Verbindung zwischen zwei Endpunkten, die Ihnen alles bietet, was Sie brauchen. Versuchen Sie nicht, Ihr eigenes zuverlässiges Zwei-Wege-Protokoll über UDP herzustellen, es sei denn, Sie sind wirklich sehr, sehr sicher, was Sie unternehmen.

Beachten Sie, dass TCP normalerweise mehrere Nachrichten auf Draht hält. Wenn Sie dies in UDP implementieren möchten, haben Sie eine Menge Arbeit, wenn Sie dies zuverlässig tun möchten. Ihre Lösung wird entweder weniger zuverlässig, weniger schnell oder unglaublich arbeitsintensiv sein. Es gibt gültige Anwendungen von UDP, aber wenn Sie diese Frage stellen, ist Ihre wahrscheinlich nicht.

Es wurden einige Arbeiten durchgeführt, damit der Programmierer die Vorteile beider Welten nutzen kann.

SCTP

Es ist ein unabhängiges Transportschicht-Protolol, kann jedoch als Bibliothek verwendet werden, die eine zusätzliche Schicht über UDP bereitstellt. Die grundlegende Kommunikationseinheit ist eine Nachricht (die einem oder mehreren UDP-Paketen zugeordnet ist). Es ist eine Überlastungskontrolle eingebaut. Das Protokoll verfügt über Regler und Drehknöpfe zum Einschalten

• in der Reihenfolge der Zustellung von Nachrichten
• Automatische Neuübertragung verlorener Nachrichten mit benutzerdefinierten Parametern

wenn dies für Ihre spezielle Anwendung erforderlich ist.

Ein Problem dabei ist, dass der Verbindungsaufbau ein komplizierter (und daher langsamer Prozess) ist.

Andere ähnliche Sachen

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

Eine weitere ähnliche proprietäre experimentelle Sache

• https://en.wikipedia.org/wiki/QUIC

Dies versucht auch, den Triple-Way-Handshake von TCP zu verbessern und die Überlastungskontrolle zu ändern, um schneller mit schnellen Leitungen umgehen zu können.

Es ist sinnlos, über TCP oder UDP zu sprechen, ohne die Netzwerkbedingungen zu berücksichtigen. Wenn das Netzwerk zwischen den beiden Punkten eine sehr hohe Qualität aufweist, ist UDP absolut schneller als TCP. In einigen anderen Fällen, z. B. im GPRS-Netzwerk, ist TCP möglicherweise schneller und zuverlässiger als UDP.

Das Netzwerk-Setup ist für alle Messungen von entscheidender Bedeutung. Es macht einen großen Unterschied, ob Sie über Sockets auf Ihrem lokalen Computer oder mit dem anderen Ende der Welt kommunizieren.

Drei Dinge, die ich zur Diskussion hinzufügen möchte:

1. Sie können finden hier einen sehr guten Artikel über TCP vs. UDP im Zusammenhang mit der Entwicklung von Spielen.
2. Darüber hinaus ist iperf ( jperf erweitert iperf mit einer GUI) ein sehr schönes Werkzeug, um Ihre Frage selbst durch Messen zu beantworten.
3. Ich habe einen Benchmark in Python implementiert (siehe diese SO-Frage ). Im Durchschnitt von 10 ^ 6 Iterationen beträgt der Unterschied zum Senden von 8 Bytes für UDP etwa 1-2 Mikrosekunden.