UDP vs TCP, wie viel schneller ist es?

Für den allgemeinen Protokoll-Nachrichtenaustausch, der einige Paketverluste tolerieren kann. Wie viel effizienter ist UDP über TCP?

   

UDP ist schneller als TCP, und der einfache Grund ist, weil sein nicht existierendes Bestätigungspaket (ACK) einen kontinuierlichen Paketstrom anstelle von TCP zulässt, der eine Menge von Paketen bestätigt, die unter Verwendung der TCP-Fenstergröße und Umlaufzeit (RTT) berechnet werden ).

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

Leute sagen, dass die Hauptsache, die TCP Ihnen gibt, Zuverlässigkeit ist. Aber das stimmt nicht wirklich. Das Wichtigste, was TCP Ihnen bietet, ist die Überlastungskontrolle: Sie können 100 TCP-Verbindungen über eine DSL-Verbindung laufen lassen, die alle mit maximaler Geschwindigkeit laufen, und alle 100 Verbindungen sind produktiv, weil sie alle die verfügbare Bandbreite “spüren”. Versuchen Sie das mit 100 verschiedenen UDP-Anwendungen, die alle so schnell wie möglich pushen und sehen, wie gut es für Sie läuft.

In einem größeren Maßstab ist dieses TCP-Verhalten, was das Internet davon abhält, in “Stauzusammenbruch” zu sperren.

Dinge, die dazu tendieren, Anwendungen auf UDP zu verschieben:

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

  • Out-of-Order-Lieferung: In vielen Anwendungen ist es egal, wie lange Sie alle Daten erhalten. Sie können die Latenz auf App-Ebene reduzieren, indem Sie einen Out-of-Order-Block akzeptieren.

  • Unfreundlichkeit: Auf einer LAN-Party ist es Ihnen vielleicht egal, ob Ihr Webbrowser so lange funktioniert, wie Sie Updates für das Netzwerk so schnell wie möglich aktualisieren.

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

  • Sie sind jetzt auf der sicheren Seite für Zuverlässigkeit, und viele der Dinge, die Sie tun können, um Zuverlässigkeit zu implementieren, können am Ende langsamer als das sein, was TCP bereits tut.

  • Jetzt sind Sie netzwerkunfreundlich und können Probleme in gemeinsam genutzten Umgebungen verursachen.

  • Am wichtigsten ist, dass Firewalls Sie blockieren.

Sie können möglicherweise einige TCP-performances- und Latenzprobleme überwinden, indem Sie mehrere TCP-Verbindungen gemeinsam “trunking”; iSCSI tut dies, um die Überlastungskontrolle in lokalen Netzwerken zu umgehen, aber Sie können auch einen “dringenden” Nachrichtenkanal mit niedriger Latenz erstellen (das “DRINGENDE” Verhalten von TCP ist völlig kaputt).

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

Dies ist der Fall, wenn viele kleine Schreibvorgänge im Verhältnis zur MTU-Größe ausgeführt werden. Zum Beispiel lese ich ein Experiment, in dem ein Strom 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.

Auf der anderen Seite setzt UDP das Paket sofort auf die Leitung, wodurch das Netzwerk mit vielen kleinen Paketen überlastet wird.

Sie sollten UDP wahrscheinlich nur verwenden, wenn Sie einen ganz bestimmten Grund dafür haben. Vor allem, weil Sie TCP die gleiche Art von Latenz wie UDP geben können, indem Sie den Nagle-Algorithmus deaktivieren (zum Beispiel, wenn Sie Echtzeit-Sensordaten übertragen und Sie nicht befürchten, das Netzwerk mit vielen kleinen Paketen zu überlasten).

mit Verlust tolerant

Meinst du “mit Verlusttoleranz”?

Grundsätzlich ist UDP nicht “verlustbehaftet”. Sie können 100 Pakete an jemanden senden, und sie erhalten möglicherweise nur 95 dieser Pakete, und einige könnten in der falschen Reihenfolge sein.

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

Für die meisten anderen Dinge ist jedoch ein fehlendes oder “neu angeordnetes” Paket kritisch. Sie müssten etwas zusätzlichen Code schreiben, um über UDP zu laufen, um zu versuchen, wenn Dinge verpasst wurden, und die richtige Reihenfolge durchzusetzen. Dies würde an bestimmten Stellen ein wenig Overhead hinzufügen.

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

Stellen Sie sich das so vor: Wenn ein Paket verloren geht, würden Sie lieber das nächste Paket so schnell wie möglich holen und fortfahren (UDP verwenden), oder benötigen Sie tatsächlich diese fehlenden Daten (verwenden Sie TCP). Der Overhead spielt keine Rolle, es sei denn, Sie befinden sich in einem echten Edge-Case-Szenario.

Welches Protokoll (in Bezug auf den Durchsatz) besser ist – UDP oder TCP – hängt wirklich von den Netzwerkeigenschaften und dem Netzwerkverkehr ab. Robert S. Barnes zum Beispiel weist auf ein Szenario hin, in dem TCP bessere Ergebnisse erzielt (kleine Schreibvorgänge). Betrachten Sie nun ein Szenario, in dem das Netzwerk überlastet ist und über TCP- und UDP-Datenverkehr verfügt. Sender im Netzwerk, die TCP verwenden, spüren die “Überlastung” und reduzieren ihre Übertragungsraten. UDP hat jedoch keine Überlastungsvermeidungs- oder Überlastungskontrollmechanismen, und Absender, die UDP verwenden, würden weiterhin Daten mit der gleichen Rate einpumpen. Allmählich würden TCP-Sender ihre Übertragungsraten auf ein absolutes Minimum reduzieren und wenn UDP-Sender genug Daten haben, die über das Netzwerk gesendet werden, würden sie den Großteil der verfügbaren Bandbreite in Anspruch nehmen. In einem solchen Fall haben UDP-Sender einen höheren Durchsatz, da sie den größten Anteil der Netzwerkbandbreite erhalten. In der Tat ist dies ein aktives Forschungsthema – Wie man den TCP-Durchsatz bei Vorhandensein von UDP-Verkehr verbessert. Ein Weg, von dem ich weiß, mit welchen TCP-Anwendungen der Durchsatz verbessert werden kann, ist das Öffnen mehrerer TCP-Verbindungen. Auf diese Weise kann der Durchsatz aller TCP-Verbindungen zwar begrenzt sein, die Gesamtsumme des Durchsatzes aller TCP-Verbindungen ist jedoch möglicherweise größer als der Durchsatz für eine Anwendung, die UDP verwendet.

Jede TCP-Verbindung erfordert einen ersten Handshake, bevor Daten übertragen werden. Außerdem enthält der TCP-Header viel Overhead, der für verschiedene Signale und die Nachrichtenübermittlungserkennung bestimmt ist. Für einen Nachrichtenaustausch wird UDP wahrscheinlich ausreichen, wenn eine geringe Fehlerwahrscheinlichkeit akzeptabel ist. Wenn der Empfang bestätigt werden muss, ist TCP die beste Option.

@Andrew , ich bitte mich zu unterscheiden. In einigen Anwendungsbereichen ist UDP aufgrund von performancesanforderungen die erste Wahl. Ein klassisches Beispiel ist Videokonferenz. Diese Art von Anwendung reactjs nicht gut auf die TCP-Steuerung.

Ein weiterer Aspekt, der in Betracht gezogen werden sollte, ist, wenn Sie Multicast benötigen. Wenn ja, benutze UDP.

Wenn wir von “Was ist schneller” sprechen, gibt es mindestens zwei sehr unterschiedliche Aspekte: Durchsatz und Latenz.

Wenn man über den Durchsatz spricht – TCPs Flusskontrolle (wie in anderen Antworten erwähnt), ist extrem wichtig und macht alles vergleichbar über UDP, während sicherlich möglich, wäre ein Big Headache ™. Als Ergebnis – UDP zu verwenden, wenn Sie Durchsatz benötigen, selten als eine gute Idee (es sei denn, Sie wollen einen unfairen Vorteil gegenüber TCP bekommen).

Wenn man jedoch von Latenzen spricht – das Ganze ist komplett anders. Während sich TCP und UDP bei fehlendem Paketverlust äußerst ähnlich verhalten (etwaige Unterschiede sind marginal), ändert sich das gesamte Muster drastisch, nachdem das Paket verloren gegangen ist.

Nach jedem Paketverlust wartet TCP auf Retransmit für mindestens 200ms (1sec pro Abschnitt 2.4 von RFC6298, aber praktische moderne Implementierungen neigen dazu, es auf 200ms zu reduzieren). Darüber hinaus werden mit TCP selbst die Pakete, die den Zielhost erreicht haben, nicht an Ihre App geliefert, bis das fehlende Paket empfangen wird (dh die gesamte Kommunikation wird um ~ 200 ms verzögert) – BTW, dieser Effekt, bekannt als Head-of -Line Blocking, ist in allen zuverlässigen geordneten Streams, ob TCP oder zuverlässig + UDP bestellt. Um die Sache noch schlimmer zu machen – wenn das erneut übertragene Paket ebenfalls verloren geht, dann sprechen wir von einer Verzögerung von ~ 600 ms (aufgrund des sogenannten exponentiellen Backoffs, 1. Retransmit ist 200 ms, und das zweite ist 200 * 2 = 400 ms). Wenn unser Kanal einen Paketverlust von 1% hat (was nach heutigen Standards nicht schlecht ist), und wir haben ein Spiel mit 20 Updates pro Sekunde – so werden im Durchschnitt alle 8 Minuten Verzögerungen von 600 ms auftreten. Und 600ms sind mehr als genug, um dich in einem rasanten Spiel zu töten – nun, es ist ziemlich schlecht für das Gameplay. Diese Effekte sind genau das, warum Gamedevs oft UDP über TCP bevorzugen.

Wenn Sie jedoch UDP verwenden, um Latenzen zu reduzieren, ist es wichtig zu erkennen, dass “UDP” nicht ausreicht, um eine wesentliche Latenzverbesserung zu erzielen. Es geht darum, wie Sie UDP verwenden. Während RUDP-Bibliotheken normalerweise diesen “exponentiellen Backoff” vermeiden und kürzere Retransmit-Zeiten verwenden, müssen sie, wenn sie als “zuverlässig geordneter” Stream verwendet werden, immer noch unter Blockade der Head-of-Line leiden (also im Falle eines Double Paketverlust, statt dieser 600ms werden wir etwa 1,5 * 2 * RTT bekommen – oder für eine ziemlich gute 80ms RTT ist es eine ~ 250ms Verzögerung, was eine Verbesserung ist, aber es ist immer noch möglich, es besser zu machen). Auf der anderen Seite, wenn Sie Techniken verwenden, die in http://gafferongames.com/networked-physics/snapshot-compression/ und / oder http://ithare.com/udp-from-mog-perspective/#low-latency diskutiert werden. Komprimierung , es ist möglich, Head-of-Line-Blockierung vollständig zu eliminieren (bei einem Double-Packet-Verlust für ein Spiel mit 20 Updates / Sekunde beträgt die Verzögerung 100ms, unabhängig von RTT).

Und als Nebenbemerkung – wenn Sie nur Zugriff auf TCP haben, aber kein UDP (wie im Browser, oder wenn Ihr Client hinter einem von 6-9% der hässlichen Firewalls steht, die UDP blockieren), scheint es einen Weg zu geben Implementieren Sie UDP-over-TCP, ohne dass zu viele Latenzen auftreten, siehe hier: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (Lesen Sie auch Kommentare (!)).

UDP ist meiner Erfahrung nach etwas schneller, aber nicht viel. Die Auswahl sollte nicht für die performance, sondern für den Inhalt der Nachricht und die Komprimierungstechniken getroffen werden.

Wenn es ein Protokoll mit Nachrichtenaustausch ist, würde ich vorschlagen, dass die sehr geringe performance, die Sie mit TCP eingehen, mehr als wert ist. Sie erhalten eine Verbindung zwischen zwei Endpunkten, die Ihnen alles geben, was Sie brauchen. Versuchen Sie nicht, Ihr eigenes zuverlässiges Zwei-Wege-Protokoll auf UDP zu erstellen, es sei denn, Sie sind wirklich, wirklich zuversichtlich, was Sie unternehmen.

Wenn Sie schnell eine Nachricht über das Netz zwischen zwei IPs, die noch nicht einmal gesprochen haben, sprengen müssen, dann wird ein UDP mindestens 3-mal schneller ankommen, normalerweise 5-mal schneller.

Denken Sie daran, dass TCP in der Regel mehrere Nachrichten drahtlos hält. Wenn Sie dies in UDP implementieren möchten, haben Sie eine Menge Arbeit, wenn Sie es zuverlässig machen wollen. Ihre Lösung wird entweder weniger zuverlässig, weniger schnell oder eine unglaubliche Menge an Arbeit sein. Es gibt gültige Anwendungen von UDP, aber wenn Sie diese Frage stellen, ist Ihre wahrscheinlich nicht.

Es wurde etwas getan, um dem Programmierer die Vorteile beider Welten zu ermöglichen.

SCTP

Es ist ein unabhängiges Transport Layer Protolol, aber es kann als eine Bibliothek verwendet werden, die eine zusätzliche Schicht über UDP bereitstellt. Die Basiseinheit der Kommunikation ist eine Nachricht (die einem oder mehreren UDP-Paketen zugeordnet ist). Es ist eine Überlastungskontrolle eingebaut. Das Protokoll hat Knöpfe und Schalter zum Einschalten

  • in der Reihenfolge der Zustellung von Nachrichten
  • automatische Übertragung von verlorenen 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 process) ist.

Andere ähnliche Sachen

Eine ähnliche proprietäre experimentelle Sache

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

Ich werde nur die Dinge klarstellen. TCP / UDP sind zwei Autos, die auf der Straße gefahren werden. Angenommen, Verkehrsschilder und Hindernisse sind Fehler TCP kümmert sich um Verkehrszeichen, respektiert alles um. Langsam fahren, weil dem Auto etwas zustoßen kann. Während UDP einfach losfährt, volle Geschwindigkeit ohne Rücksicht auf Straßenschilder. Nichts, ein verrückter Fahrer. UDP hat keine Fehlerbehebungsfunktion. Wenn ein Hindernis vorhanden ist, kollidiert es einfach damit und fährt fort. Während TCP sicherstellt, dass alle Pakete perfekt gesendet und empfangen werden, gibt es keine Fehler, so dass das Auto Hindernisse einfach passiert, ohne zu kollidieren. Ich hoffe, dies ist ein gutes Beispiel für Sie, warum UDP im Gaming bevorzugt wird. Gaming braucht Geschwindigkeit. TCP ist in Downloads bevorzugt, oder heruntergeladene Dateien sind möglicherweise beschädigt.

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 hat, ist UDP absolut schneller als TCP, aber in einem anderen Fall, wie dem GPRS-Netzwerk, könnte TCP schneller und zuverlässiger als UDP sein.

Das Netzwerk-Setup ist für alle Messungen entscheidend. Es macht einen großen Unterschied, ob Sie über sockets auf Ihrer lokalen Maschine oder mit dem anderen Ende der Welt kommunizieren.

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

  1. Sie können hier einen sehr guten Artikel über TCP vs. UDP im Rahmen der Spieleentwicklung finden.
  2. Darüber hinaus ist Iperf ( jperf verbessern iperf mit einer GUI) ein sehr nettes Werkzeug für die Beantwortung Ihrer Frage selbst durch Messen.
  3. Ich habe einen Benchmark in Python implementiert (siehe diese SO Frage ). Im Durchschnitt von 10 ^ 6 Iterationen beträgt die Differenz für das Senden von 8 Bytes ungefähr 1-2 Mikrosekunden für UDP.