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


194

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


Sie können auch das Tag "tcp" hinzufügen, da es sich auch um TCP handelt.
Cristian Ciupitu

5
Was bedeutet "allgemeiner Protokollnachrichtenaustausch"? Die Frage muss klären, worum es bei Effizienz geht. Wollen wir weniger Latenz für eine kleine Nachricht? Oder wollen wir einen höheren Durchsatz für einen kontinuierlichen Datenstrom?
Johan Boulé

Tcp bietet mit Ausnahme der Geschwindigkeit mehr bessere Funktionen als UDP.
RAJKUMAR NAGARETHINAM

3
Die Frage von TCP vs. UDP-Geschwindigkeit ist strittig. Die Frage in Ihrer Überschrift stimmt tatsächlich nicht mit dem Hauptteil der Frage überein. Sowohl TCP- als auch UDP-Pakete werden auf demselben Medium mit genau derselben Geschwindigkeit übertragen.
Ron Maupin

Antworten:


86

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).


19
Es gibt tatsächlich viele Fälle, in denen TCP tatsächlich schneller als UDP ist. Siehe meine Antwort unten.
Robert S. Barnes

2
Was schneller ist, hängt ganz von den Verkehrseigenschaften ab.

4
Obwohl die Antwort richtig sein mag, beantwortet sie die Frage nicht und wiederholt das an anderer Stelle erwähnte Wissen wiederholt. Erwähnt auch nicht, dass zuverlässige UDP-Methoden mit ACK deutlich schneller als TCP sein können.
Elliot Woods

268

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).


18
Gute Antwort, ich würde sogar allgemeiner auf "Flusskontrolle" eingehen (im Gegensatz zur Überlastungskontrolle, die eine Teilmenge der Flusskontrolle ist). Nicht nur mehrere TCP-Verbindungen können eine Verbindung gemeinsam nutzen, sondern es wird auch verhindert, dass der Sender den Puffer des Empfängers überläuft, wenn er die Verarbeitung eingehender Daten aus irgendeinem Grund unterbricht.
Alex B

1
@AaronLS: Paketverlust und RTT-Erhöhungen (Roundtrip-Zeit) (die als Proxy für Warteschlangenverzögerungen angesehen werden können) sind / können (z. B.: WiFi-Netzwerke können Pakete ohne echte Überlastung verlieren und einige TCP-Überlastungssteuerungsalgorithmen zur Vermeidung von Überlastungen verleiten). Überlastungsindikatoren.
Ninjalj

2
UDP ist ein Bastard, mit dem man sich befassen muss ... Ich bin schon ausgebrannt. Egal was ich mache, ich kann anscheinend kein Gleichgewicht zwischen Leistung, Latenz, Durchsatz und Zuverlässigkeit finden. Großartig für Echtzeit-Dinge wie Dinge auf Timern ... aber ich arbeite an einem TCP-Ersatz mit UDP und Forward Error Correction und das ist viel schwieriger als ich dachte. Überlastungskontrolle. Ein universelles System, das in 1-GB-Netzwerken und drahtlosen Netzwerken funktioniert, ist ein Kunstwerk. Ich habe das Gefühl, ich versuche, Pakete wieder zusammenzusetzen, die in eine Schrotflinte geladen wurden.
Jason Nelson

1
Ein weiterer Vorteil von TCP ist, dass es von Natur aus verbindungsorientiert ist, was die Logik für die Handhabung von Anwendungsclients erheblich vereinfacht ( listen-> accept-> Der Clientstatus ist natürlich unabhängig von anderen Clients). Insbesondere die Verarbeitung mehrerer Verbindungen von einem einzelnen Client aus wird mit UDP schwierig. Ein Vorteil für UDP ist, dass UDP-Stacks sehr einfach zu implementieren sind. Dies ist ein großes Plus für eingebettete Systeme (Mikrocontroller, FPGAs usw.). Insbesondere eine TCP-Implementierung für ein FPGA ist im Allgemeinen etwas, das Sie nur von jemand anderem kaufen möchten und nicht darüber nachdenken).
Jason C

1
Dies alles setzt nur voraus, dass wir an der Bereitstellung umfangreicher Daten interessiert sind (ohne uns zu sehr um die Latenz zu kümmern). In einigen Apps (Spiele / VoIP) ist die Situation drastisch anders: Wir haben eine sehr kleine Datenmenge, kümmern uns aber sehr um Latenzen. Es ist diese einfache Sache, die 99% der legitimen Verwendungen für UDP ausmacht. Und ein paar Nitpicks: (a) Gruppenzustellung funktioniert NICHT über das Internet (und wird es wahrscheinlich nie tun), es handelt sich also nur um das Intranet. (b) Laut Google haben nur 8-9% der Internetbevölkerung Probleme mit UDP. (c) "Netzwerk unfreundlich" gilt nicht für Streams mit fester Rate
No-Bugs Hare

93

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).


3
Ich habe tatsächlich Benchmarks zu diesem Effekt durchgeführt. Ich habe Pakete gesendet, die so groß waren, wie UDP sie unterstützen würde, ohne Ausnahmen auszulösen (in Java), und TCP war viel schneller. Ich würde vermuten, dass viele Betriebssystem-, Treiber- und Hardwareoptimierungen ebenfalls Teil davon sind.
Charlie

14
@Myforwik: Erstens ist dies keine definierte Implementierung, sondern Teil des TCP-Protokolls. Es heißt Nagle-Algorithmus. Es hilft zu verhindern, was allgemein als Silly Window Syndrom bekannt ist. Schlagen Sie beide Begriffe nach. Zweitens gibt es kein Konzept für Pakete aus dem TCP-POV. Schließlich widmet das Buch "Effektive TCP / IP-Programmierung" diesem Thema ein ganzes Kapitel und dem verwandten Thema mehrere weitere Kapitel, in denen es darum geht, zu wissen, wann TCP vs. UDP verwendet werden muss. Ich spreche diese Situation an (die eigentlich ziemlich häufig ist), weil das OP eine allgemeine Frage gestellt hat, und dies ist eine der vielen möglichen Antworten.
Robert S. Barnes

46
@ Myforwik. Wenn Sie anderen einen Moronismus vorschlagen, versuchen Sie zu erkennen, dass wir alle Wissenslücken haben - Sie eingeschlossen. SO ist schließlich ein Forum für den Wissensaustausch. Nahezu alle Ego-Shooter verwenden UDP, und es kommt selten vor, dass sie Pakete in Größen senden, die annähernd so groß sind wie die MTU. Wenn Sie John Carmack vorschlagen möchten, was für ein Idiot er für diesen Ansatz war, würde ich Sie ermutigen, sich diesbezüglich zunächst gründlich zu unterrichten. 15 Jahre, und der Wert einer Branche für Hochleistungs-Netzwerkcode legt sich nicht hin und stirbt, weil Sie denken, dass er "schwachsinnig" ist.
Ingenieur

2
" Ich habe 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. " - Können Sie dieses Experiment verknüpfen?
Leviathan

3
@ Leviathan Es ist in dem Buch Effektive TCP / IP-Programmierung.
Robert S. Barnes

31

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.


1
5 von 100 Paketen? Es ist ziemlich viel. Ich denke, es ist nur ein Beispiel. Frage: In der realen Situation, wie viele Pakete können verloren gehen? Denn wenn es zum Beispiel 2 von 10000 (plus minus 1) ist, würde ich mir darüber keine Sorgen machen.
freakish

1
@Freakish, ja, es war nur ein Beispiel. Die tatsächliche Höhe des Paketverlusts hängt von Ihrer Verbindung, den Upstream-Netzwerken usw. ab. Früher habe ich viele Online-Spiele gespielt, und ich würde feststellen, dass ich keinen Paketverlust erhalten würde, wenn ich nur die Internetverbindung verwenden würde Sobald ich einen Hintergrund-Download starten würde, würde ich einige bekommen (vielleicht 10% -20%). Dies war jedoch vor ungefähr 5 Jahren, und schnellere Internetverbindungen können helfen.
Orion Edwards

2
Internet-Router lassen udp vor tcp fallen
user1496062

19

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.


2
Dies ist nicht korrekt. Router löschen UDP vor TCP. Auf einem gemeinsam genutzten Kabel können Sie von UDP ertrinken, aber was in einer Überversorgungssituation wahrscheinlich passiert, hängt von der Technologie ab, aber es ist für UDP recht einfach, sich so weit zu verschlechtern, dass nur noch Kollisionen gesendet werden.
user1496062

Ich mag deine Erklärung, bekomme aber keinen Punkt. Wenn UDP-Verbindungen den gesamten Verkehr erhalten können (wenn die Bandbreite niedrig oder die Daten hoch sind), wird Ihre Anwendung in diesem Fall, wenn Sie TCP verwenden, grundsätzlich als Geisel für diejenigen gehalten, die UDP verwenden. Wenn alle Anwendungen TCP verwenden, "spielen" sie gut miteinander. Warum sollte UDP dann überhaupt auf dem Rauter zugelassen werden?
Igor Čordaš

@PSIXO: Nun, TCP und UDP erfüllen unterschiedliche Anwendungsanforderungen, sodass beide von Anwendungen verwendet werden. Ihr Vorschlag impliziert, dass wir eine unterschiedliche Netzwerkinfrastruktur für TCP- und UDP-Verkehr haben sollten - eine teure Angelegenheit, die wir jetzt sicherlich nicht tun können, insbesondere bei all den bereits getätigten Investitionen. Aus diesem Grund suchen Forscher nach alternativen Möglichkeiten, um den Konflikt in „Software“ auszugleichen.
Gjain

Im Grunde genommen wäre es eine perfekte Lösung, zwei Infrastrukturen zu haben, aber leider ist dies nicht plausibel. Was ich mit meinem Kommentar sagen wollte, war, dass Sie den UDP-Treffer für TCP überbewerten, denn wenn es ein so hoher Faktor wäre, würden die Leute einfach UDP auf dem Router deaktivieren (wie es manchmal in Unternehmen der Fall ist), wenn sie TCP benötigen, um schnell zu funktionieren. Beachten Sie auch, dass UDP-Pakete eine höhere Wahrscheinlichkeit haben, dass sie hängen bleiben als TCP. Über den Rest der Fakten in Ihrer Antwort stimme ich voll und ganz zu und finde es sehr hilfreich, aber ich denke nur, dass Sie bestimmte Effekte überschätzen.
Igor Čordaš

18

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 (!)).


13

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.


Geringe Ausfallwahrscheinlichkeit und Begrenzung der Paketgröße.

11

@ 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.


8
UDP wird auch verwendet, da es wahrscheinlich sowieso zu spät ist, wenn Sie ein oder zwei Pakete verpassen, und Sie es wahrscheinlich am besten einfach überspringen und weitermachen, damit Sie weiter schauen können. Ein kleiner Fehler im Video aufgrund einiger verworfener Pakete ist viel besser als eine Menge Überlastungen.
Kibbee

1
Richtig - Multi-Casting des Netzwerks ist ziemlich selten, die meisten Router blockieren es.
user1496062

8

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.


1
Irgendwelche Referenzen?
Gerard

8

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


7

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.


5

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.


5

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

Eine weitere ähnliche proprietäre experimentelle Sache

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.


3

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.


1

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.

1
Um den Benchmark für das Internet der realen Welt relevant zu machen, müssen Sie ihn mit einem Paketverlustsimulator wie netem erneut ausführen. Wenn Sie es richtig machen (und mit einer simulierten RTT von beispielsweise 100 ms und einem simulierten Paketverlust von 1%), unterscheiden sich die Ergebnisse drastisch. Kurz gesagt - während die TCP- und UDP-Latenzen bei null Paketverlust tatsächlich gleich sind - beginnen sie sich für jedes verlorene Paket VIEL zu unterscheiden.
No-Bugs Hare
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.