Warum ist UDP mit Zuverlässigkeit (auf Anwendungsebene implementiert) kein Ersatz für TCP?

TCP bietet Zuverlässigkeit auf Transportebene, UDP nicht. UDP ist also schnell. Ein Protokoll auf Anwendungsebene kann jedoch einen zuverlässigen Mechanismus implementieren, wenn UDP verwendet wird.

Warum ist UDP mit Zuverlässigkeit (in der Anwendungsschicht implementiert) in diesem Sinne kein Ersatz für TCP, wenn UDP schneller als TCP ist, obwohl Zuverlässigkeit erforderlich ist?

TCP ist ungefähr so ​​schnell, wie Sie mit seinen Zuverlässigkeitseigenschaften etwas anfangen können. Wenn Sie beispielsweise nur Sequenzierung und Fehlererkennung benötigen, kann UDP einen einwandfreien Dienst leisten. Dies ist die Grundlage für die meisten Echtzeitprotokolle wie Sprache, Video-Streaming usw., bei denen Verzögerung und Jitter wichtiger sind als die "absolute" Fehlerkorrektur.

Grundsätzlich sagt TCP, dass man sich irgendwann auf seine Streams verlassen kann. Wie schnell das ist, hängt von den verschiedenen Timern, Geschwindigkeiten usw. ab. Die zur Behebung von Fehlern benötigte Zeit kann unvorhersehbar sein. Die grundlegenden Vorgänge sind jedoch so schnell wie möglich, wenn keine Fehler vorliegen. Wenn ein System etwas über die Art der wahrscheinlichen Fehler weiß, kann es möglicherweise etwas tun, was mit TCP nicht möglich ist. Wenn beispielsweise Einzelbitfehler besonders wahrscheinlich sind, können Sie für diese Bitfehler eine fehlerkorrigierende Codierung verwenden. Dies ist jedoch in der Verbindungsschicht viel besser implementiert. Ein weiteres Beispiel: Wenn kurze Bursts mit Gesamtpaketverlust häufig auftreten, können Sie dies mit Mehrfachübertragung beheben, ohne auf den Verlust zu warten. Dies ist jedoch offensichtlich bandbreitenintensiv. Oder verlangsamen Sie die Geschwindigkeit, bis die Fehlerwahrscheinlichkeit vernachlässigbar ist: auch in Bezug auf die Bandbreite teuer. Schlussendlich,

In Bezug auf die Implementierung werden Sie feststellen, dass der in TCP investierte Programmierer jahrhundertelang schneller ist als alles, was Sie sich leisten können, und auch in den dunklen Randfällen zuverlässiger ist.

TCP bietet: eine allgegenwärtige Verbindungsmethode (unerlässlich, wenn die kommunizierenden Systeme keine gemeinsame Kontrolle haben), die einen zuverlässigen, geordneten (und deduplizierten) Zwei-Wege-Bytestrom mit Fenstern und Überlastungskontrolle über Multi-Hop-Netze mit beliebiger Entfernung ermöglicht.

Wenn für eine Anwendung keine Allgegenwart erforderlich ist (Ihre Software wird auf beiden Seiten ausgeführt) oder wenn nicht alle TCP-Funktionen erforderlich sind, verwenden viele Benutzer andere Protokolle, häufig zusätzlich zu UDP, profitabel. Beispiele hierfür sind TFTP (minimalistisch, mit wirklich ineffizienter Fehlerbehandlung), QUIC, mit dem der (noch als experimentell gekennzeichnete) Overhead verringert werden soll, und Bibliotheken wie lidgren, mit denen genau gesteuert werden kann, welche Zuverlässigkeitsmerkmale erforderlich sind. ]

UDP mit Zuverlässigkeit kann in der Tat ein Ersatz für TCP sein. Wir haben bereits ein Beispiel dafür: Es heißt QUIC .

Aus Wikipedia:

Unter anderem verbessert QUIC die Leistung von verbindungsorientierten Webanwendungen, die derzeit TCP verwenden. Dazu werden mehrere Multiplexverbindungen zwischen zwei Endpunkten über UDP (User Datagram Protocol) hergestellt.

Der Vorteil der Verwendung von UDP gegenüber der Erstellung eines brandneuen Transportschichtprotokolls besteht darin, dass Router und andere Netzwerkgeräte dies bereits verstehen.

Sie können UDP verwenden, um die TCP-Funktionalität auf der Anwendungsebene zu implementieren (Zuverlässigkeit, Anpassungsfähigkeit). Genauso gut können Sie TCP verwenden, es sei denn, etwas, das Ihre Anwendung wirklich benötigt, kann nicht mit TCP durchgeführt werden. Wenn Sie diese Funktionen selbst implementieren, erhalten Sie höchstwahrscheinlich ein viel schlechteres Ergebnis als mit TCP. Der zusätzliche Aufwand verringert auch die Gesamteffizienz.

TCP ist nicht langsam - es ist lediglich ein Handshake vor dem Senden und ein Anpassen des Übertragungsfensters an den Kanal erforderlich. Es kann seinen Durchsatz zum jeweiligen Übertragungskanal sehr gut formen und sich an Änderungen während des Flusses anpassen, was UDP (allein) nicht kann.

Protokolle oberhalb der Transportschicht sind hier jedoch nicht zum Thema.

In einem sauberen Netzwerk sind sie ziemlich gleichwertig. Es gibt Fälle, in denen TCP für einige Zeit hängen bleibt (hat jemand jemals ein Einfrieren des HTTP-Bildschirms beim Laden gesehen?), Aber es liefert keinen Müll oder vermischt Pakete und gibt selten vollständig auf.

UDP kann der Anwendungsebene mehr Kontrolle über den Datenverkehr geben, was sehr viel Arbeit kostet.

Die Antwort auf Ihre Frage ist, manchmal wird es so gemacht. Spiele, die eine geringe Latenz erfordern, tun oft genau das. Es ist viel mehr Arbeit, aber die Möglichkeit, genau zu steuern, wie viele ausstehende Pakete Sie haben können und wie oft sie wiederholt werden, lohnt sich oft.

Insgesamt besteht der Unterschied darin, dass TCP eine sehr gute Allzweckimplementierung ist, aber UDP kann bestimmte Aufgaben erfüllen, die TCP entweder nur sehr schlecht oder gar nicht erfüllt - zum Beispiel:

• NIEMALS aufgeben (bei TCP hängt die Verbindung manchmal und Sie müssen die Verbindung trennen und neu starten)
• Senden Sie einen schnellen Strom von Paketen, für die keine Antworten erforderlich sind, und verpassen Sie gelegentlich einige (wobei nur das neueste Paket wichtig ist und alle anderen verworfen werden können) "Springen" statt in jedem Schritt, aber Sie erhalten das gleiche Ergebnis schneller und zuverlässiger.
• Umgang mit fragwürdigen Netzwerken durch Analysieren von Paketverlusten und dynamisches Ändern der Häufigkeit und des Zeitpunkts, zu dem Sie es erneut versuchen - möglicherweise sogar der maximalen Paketgröße.

Aber im Allgemeinen lohnt es sich nicht, TCP ist ziemlich optimal. Warum also all die zusätzliche Arbeit auf sich nehmen und eine (große) Chance auf das Hinzufügen von Fehlern und Sicherheitslücken aufbauen?

UDP ist nicht schnell, weil es UDP ist. TCP ist nicht langsam, weil es TCP ist.

Beide Protokolle sind mit bestimmten Garantien ausgestattet und Raw-TCP bietet mehr Garantien als Raw-UDP.

Und die Faustregel lautet: Der Preis für Garantien ist Leistung .

Es gibt nichts, was Sie daran hindert, TCP-Garantien über UDP zu implementieren. Aber dann bekommt man mehr Garantien und muss den Preis bezahlen. Daher reduzieren Sie die Leistung auf TCP oder schlechter (aufgrund von UDP-Overhead). Es sei denn, Sie kennen eine bessere TCP-Implementierung, was unwahrscheinlich ist. Und wenn Sie es dann tun (hoffnungsvoll), enthüllen Sie es und wir machen das Standard-TCP schneller. Und wir sind wieder da, wo wir angefangen haben. :)

Sie können auch mit diesen Garantien spielen. Ändern Sie dies leicht, ändern Sie das leicht. Und dann haben Sie ein Protokoll wie QUIC, das über UDP läuft und TCP + TLS sehr ähnlich ist. In vielen Fällen ist es schneller als TCP (obwohl es laut diesem Artikel eine Latenz von bis zu 5% und eine Pufferung von bis zu 15% gibt, was IMO keine große Sache ist), aber in einigen Szenarien (z. B. zuverlässiges Netzwerk oder keine Notwendigkeit für Verschlüsselung) ist dies tatsächlich der Fall langsamer (siehe Erklärung hier ).

Sie können diese Garantien auch schwächen, und dann ist es sinnvoller. Angenommen, Sie streamen und alte Pakete sind nicht interessant. Nur die aktuellste. Aber die Überlastung ist immer noch wichtig. Sie nehmen also einige Garantien von TCP, aber nicht alle. Und ja, die Leute machen das tatsächlich (zB Echtzeitspiele). Dies führt zu einer besseren Leistung auf Kosten einiger Garantien.

Ihre Idee wäre gut im Weltraum.

Die richtige Antwort lautet "es kommt darauf an" und "weil dies das gesamte Netzwerk beschädigen würde". TCP / IP ist sehr netzwerkfreundlich und passt sich automatisch an die richtige Geschwindigkeit an, um schnell zu sein, generiert jedoch keine Tonnen von ICMP-Rückgabepaketen.

Wenn ein Router mit nicht genügend RAM plötzlich eine Menge von Paketen empfängt, beispielsweise von Tsunami, Bittorrent oder FDT, wird diese verworfen und ein kleines Paket zur Fehlerbestätigung an den Absender zurückgeschickt. Jetzt muss Ihr UDP-Server diesen Teil manuell verfolgen und erneut übertragen. Einige ISP-Router formen Bittorrent so sehr, dass dies dem Tsunami schadet.

Das Tsunami-Protokoll verwendet UDP mit einem Kontrollkanal in TCP. http://tsunami-udp.sourceforge.net/ Ich fand eine Studie, die zeigt, dass es langsamer ist als ein Ding namens FDT.

Das legendäre Fast Data Transfer (FDT) -Protokoll von CERN ist in der Lage, jedes Netzwerk mit mehreren TCP-Streams zu überlasten. Wahrscheinlich ist es schneller, weil es weniger Neuübertragungen verursacht, als der Tsunami, der das Netzwerk mit so viel UDP überflutet, es teilweise nicht bis zum Ende schafft.

UDP wird von unzuverlässigen Anwendungen verwendet: Audio-Streaming, Spieleingabe / -Update-E / A, "Ping" ist tatsächlich ICMP, wird aber nicht garantiert, Bittorrent, Mosh-SSH ist äußerst reaktionsfähig, VOIP-Telefonie, Multicast, DNS wird über UDP-AFAIK gesendet. Alles, was nichts gegen das ein oder andere fehlende Paket hat und sofort "aufholen" kann.

TCP / IP war wirklich die Killer-Erfindung, die es App-Entwicklern ermöglichte, diese einfach zu setzen und zu vergessen. Ein Socket ist ein Paar von IP-Adressen und Ports, die eingerichtet werden können und stunden-, tag- oder sogar wochenlang bestehen bleiben, ohne dass eine erneute Verbindung hergestellt werden muss. E-Mail, Web, IRC und buchstäblich alle Killer-Apps verwenden TCP. Es kann jedoch zu merkwürdigen Download-Pausen kommen, die sich plötzlich beschleunigen ... und im Weltraum kann es zu Zeitüberschreitungen bei den Verbindungen kommen, sodass Transfers im Tsunami-Stil am besten für interstellare Dateitransfers geeignet sind - Sie könnten sich dort auf etwas befinden !!

Der Beweis ist in den abschließenden Bemerkungen dieses Wissenschaftsstudien-Auszuges zu finden, in denen die zunehmende Distanz erwähnt wird, auf die ich mich beziehe: Deep Space Von: https://uscholar.univie.ac.at/get/o:300623.pdf

Ohne Überlastung ist die Leistung von FDT und GridFTP mit TCP höher als die von Tsunami und UDT. Der höchste Durchsatz von FDT liegt bei 2,34 Gb / s mit einer RTT von 1 ms, nimmt jedoch nach 100 ms rasch ab, verglichen mit GridFTP, das eine bessere Leistung als FDT erzielt, wenn die RTT der Verbindung länger als 100 ms ist. Interessanterweise nahm der Durchsatz des Tsunami mit zunehmender RTT nicht ab, was zeigt, dass er mit zunehmender RTT die effektivste Überlastungskontrolle aufweist.

Andererseits ... gibt es tatsächlich ein Space-Protokoll, das einer E-Mail ähnelt und besser für den Space geeignet ist. Die Apps müssen keine Timeout-Werte wie für immer beachten.

TCP! = UDP + Zuverlässigkeit

TCP ist nicht einfach UDP mit zusätzlicher Zuverlässigkeit. TCP bietet mehr Funktionen als nur Zuverlässigkeit. Sie können in vielen RFCs darüber lesen.

Jedes dieser Merkmale "könnte" auf der Anwendungsschicht implementiert werden. Irgendwann wird es ein Punkt, an dem Sie anfangen, das Rad neu zu erfinden.

Um nur einige Features zu nennen, die TCP hat ...

• Herstellen und Beenden von Verbindungen: Führt Handshakes und Verbindungsabbrüche durch

• Flusskontrolle: Stellt sicher, dass Sender und Empfänger mit Raten senden, bei denen beide die Datenrate verarbeiten können.

• Ende-zu-Ende-Überlastungskontrolle: Ermöglicht es Endknoten, ihren Durchsatz basierend auf Verlusten zu drosseln. Lesen Sie mehr über langsamen Start, Vermeidung von Staus und schnelle Wiederherstellung.

Meiner Erfahrung nach wird UDP verwendet, wenn es um Geschwindigkeit und Zuverlässigkeit geht. Sie können eine Zuverlässigkeitsstufe auf Anwendungsebene hinzufügen, die nicht zu 100% so zuverlässig ist wie TCP. Wenn Sie beispielsweise weiterhin eine schnelle Leistung wünschen, können Sie eine Vorwärtsfehlerkorrektur (Forward Error Correction, FEC) implementieren, bei der Sie die Daten mehrmals übertragen. Sie erhalten immer noch eine gute Leistung und ein gewisses Maß an Zuverlässigkeit (beachten Sie die recht gute TCP-Zuverlässigkeit), ohne den gesamten hin- und hergehenden Chat, um verlorene Pakete zu erhalten. Der Nachteil ist, dass es die Netzwerknutzung erhöht, aber für Echtzeitanwendungen wie Spiele oder Streaming geeignet sein kann.