Wann ist es angebracht, UDP anstelle von TCP zu verwenden? [geschlossen]

Da TCP die Paketzustellung garantiert und somit als "zuverlässig" angesehen werden kann, garantiert UDP nichts und Pakete können verloren gehen. Was wäre der Vorteil der Datenübertragung mit UDP in einer Anwendung anstelle eines TCP-Streams? In welchen Situationen wäre UDP die bessere Wahl und warum?

Ich gehe davon aus, dass UDP schneller ist, da es nicht den Aufwand für das Erstellen und Verwalten eines Streams hat. Wäre das nicht irrelevant, wenn einige Daten niemals ihr Ziel erreichen?

Dies ist eine meiner Lieblingsfragen. UDP wird so missverstanden.

In Situationen, in denen Sie wirklich schnell eine einfache Antwort auf einen anderen Server erhalten möchten, funktioniert UDP am besten. Im Allgemeinen möchten Sie, dass die Antwort in einem Antwortpaket enthalten ist, und Sie sind bereit, Ihr eigenes Protokoll für die Zuverlässigkeit zu implementieren oder erneut zu senden. DNS ist die perfekte Beschreibung dieses Anwendungsfalls. Die Kosten für Verbindungsaufbauten sind viel zu hoch (DNS unterstützt jedoch auch einen TCP-Modus).

Ein anderer Fall ist, wenn Sie Daten liefern, die verloren gehen können, weil neuere eingehende Daten diese vorherigen Daten / Zustände ersetzen. Wetterdaten, Video-Streaming, ein Börsenkursdienst (der nicht für den tatsächlichen Handel verwendet wird) oder Spieldaten kommen in den Sinn.

Ein anderer Fall ist, wenn Sie eine enorme Menge an Status verwalten und die Verwendung von TCP vermeiden möchten, da das Betriebssystem nicht so viele Sitzungen verarbeiten kann. Dies ist heute ein seltener Fall. Tatsächlich gibt es jetzt User-Land-TCP-Stacks, die verwendet werden können, damit der Application Writer die Ressourcen, die für diesen TCP-Status benötigt werden, genauer steuern kann. Vor 2003 war UDP wirklich das einzige Spiel in der Stadt.

Ein anderer Fall betrifft den Multicast-Verkehr. UDP kann auf mehrere Hosts multicasted werden, während TCP dies überhaupt nicht kann.

Wenn ein TCP Paket verloren geht, wird es erneut gesendet. Dies ist nicht praktisch für Anwendungen, bei denen Daten in einer bestimmten Reihenfolge in Echtzeit verarbeitet werden müssen.

Beispiele sind Video-Streaming und insbesondere VoIP (z . B. Skype ). In diesen Fällen ist ein verworfenes Paket jedoch keine so große Sache: Unsere Sinne sind nicht perfekt, so dass wir es möglicherweise nicht einmal bemerken. Aus diesem Grund verwenden diese Anwendungstypen UDP anstelle von TCP.

Die "Unzuverlässigkeit" von UDP ist ein Formalismus. Die Übertragung ist nicht absolut garantiert. In der Praxis kommen sie fast immer durch. Sie werden nach einer Auszeit einfach nicht bestätigt und erneut versucht.

Der Aufwand beim Aushandeln eines TCP-Sockets und beim Handshake der TCP-Pakete ist enorm. Wirklich riesig. Es gibt keinen nennenswerten UDP-Overhead.

Am wichtigsten ist, dass Sie UDP problemlos durch zuverlässiges Handshaking bei der Lieferung ergänzen können, das weniger Overhead als TCP verursacht. Lesen Sie dies: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP ist nützlich für die Übertragung von Informationen in einer Publish-Subscribe-Anwendung. IIRC, TIBCO nutzt UDP in hohem Maße zur Benachrichtigung über Statusänderungen.

Jede andere Art von einseitiger "signifikanter Ereignis" - oder "Protokollierungs" -Aktivität kann mit UDP-Paketen problemlos behandelt werden. Sie möchten eine Benachrichtigung senden, ohne einen gesamten Socket zu erstellen. Sie erwarten keine Antwort von den verschiedenen Zuhörern.

System "Herzschlag" - oder "Ich lebe" -Nachrichten sind ebenfalls eine gute Wahl. Fehlen ist keine Krise. Ein halbes Dutzend (hintereinander) fehlt.

Ich arbeite an einem Produkt, das sowohl UDP (IP) als auch TCP / IP-Kommunikation zwischen Client und Server unterstützt. Es begann vor über 15 Jahren mit IPX, wobei die IP-Unterstützung vor 13 Jahren hinzugefügt wurde. Wir haben vor 3 oder 4 Jahren TCP / IP-Unterstützung hinzugefügt. Wilde Vermutung: Das Verhältnis von UDP zu TCP-Code liegt wahrscheinlich bei 80/20. Das Produkt ist ein Datenbankserver, daher ist Zuverlässigkeit von entscheidender Bedeutung. Wir müssen alle von UDP auferlegten Probleme (Paketverlust, Paketverdopplung, Paketreihenfolge usw.) behandeln, die bereits in anderen Antworten erwähnt wurden. Es gibt selten Probleme, aber sie treten manchmal auf und müssen daher behandelt werden. Der Vorteil der Unterstützung von UDP besteht darin, dass wir es ein wenig an unsere eigene Nutzung anpassen und die Leistung etwas verbessern können.

Jedes Netzwerk wird anders sein, aber das UDP-Kommunikationsprotokoll ist für uns im Allgemeinen etwas schneller. Der skeptische Leser wird zu Recht fragen, ob wir alles richtig umgesetzt haben. Und was können Sie von einem Mann mit einem zweistelligen Repräsentanten erwarten? Trotzdem habe ich gerade aus Neugier einen Test durchgeführt. Der Test las 1 Million Datensätze (wählen Sie * aus einer Tabelle). Ich habe die Anzahl der Datensätze, die mit jeder einzelnen Clientanforderung zurückgegeben werden sollen, auf 1, 10 und dann 100 festgelegt (drei Testläufe mit jedem Protokoll). Der Server war über ein 100-Mbit-LAN ​​nur zwei Sprünge entfernt. Die Zahlen schienen mit denen anderer übereinzustimmen (UDP ist in den meisten Situationen etwa 5% schneller). Die Gesamtzeiten in Millisekunden waren für diesen speziellen Test wie folgt:

1. 1 Datensatz
   • IP: 390.760 ms
   • TCP: 416.903 ms
2. 10 Datensätze
   • IP: 91.707 ms
   • TCP: 95.662 ms
3. 100 Datensätze
   • IP: 29.664 ms
   • TCP: 30.968 ms

Die insgesamt übertragene Datenmenge war für IP und TCP ungefähr gleich. Wir haben zusätzlichen Aufwand für die UDP-Kommunikation, da wir einige der gleichen Dinge haben, die Sie mit TCP / IP "kostenlos" erhalten (Prüfsummen, Sequenznummern usw.). Zum Beispiel zeigte Wireshark, dass eine Anforderung für den nächsten Satz von Datensätzen 80 Byte mit UDP und 84 Byte mit TCP betrug.

Hier gibt es bereits viele gute Antworten, aber ich möchte einen sehr wichtigen Faktor sowie eine Zusammenfassung hinzufügen . UDP kann mit der richtigen Abstimmung einen viel höheren Durchsatz erzielen, da keine Überlastungskontrolle verwendet wird . Die Überlastungskontrolle in TCP ist sehr sehrwichtig. Es steuert die Rate und den Durchsatz der Verbindung, um die Überlastung des Netzwerks zu minimieren, indem versucht wird, die aktuelle Kapazität der Verbindung abzuschätzen. Selbst wenn Pakete über sehr zuverlässige Verbindungen gesendet werden, wie beispielsweise im Kernnetzwerk, haben Router Puffer mit begrenzter Größe. Diese Puffer füllen sich bis zu ihrer Kapazität und Pakete werden dann verworfen, und TCP bemerkt diesen Abfall durch das Fehlen einer empfangenen Bestätigung, wodurch die Geschwindigkeit der Verbindung zur Schätzung der Kapazität gedrosselt wird. TCP verwendet auch einen sogenannten langsamen Start , aber den Durchsatz (eigentlich den Überlastungsfenster)) wird langsam erhöht, bis Pakete verworfen werden, und wird dann verringert und langsam wieder erhöht, bis Pakete verworfen werden usw. Dies führt dazu, dass der TCP-Durchsatz schwankt. Sie können dies deutlich sehen, wenn Sie eine große Datei herunterladen.

Da UDP keine Überlastungskontrolle verwendet, kann es sowohl schneller sein als auch weniger Verzögerungen erfahren, da nicht versucht wird, die Puffer bis zum Abwurfpunkt zu maximieren, dh UDP-Pakete verbringen weniger Zeit in Puffern und gelangen schneller mit weniger Verzögerung dorthin. Da UDP keine Überlastungskontrolle verwendet, TCP jedoch, kann es TCP Kapazität entziehen, die zu UDP-Flows führt.

UDP ist jedoch immer noch anfällig für Überlastungen und Paketverluste. Daher muss Ihre Anwendung darauf vorbereitet sein, diese Komplikationen irgendwie zu bewältigen, wahrscheinlich mithilfe von Codes für die erneute Übertragung oder Fehlerkorrektur.

Das Ergebnis ist, dass UDP:

• Erzielen Sie einen höheren Durchsatz als TCP, solange die Netzwerk-Drop-Rate innerhalb der Grenzen liegt, die die Anwendung verarbeiten kann.
• Liefern Sie Pakete schneller als TCP mit weniger Verzögerung.
• Stellen Sie Verbindungen schneller her, da kein erster Handshake zum Einrichten der Verbindung erfolgt
• Übertragen Sie Multicast-Pakete, während TCP mehrere Verbindungen verwenden muss.
• Übertragen Sie Pakete mit fester Größe, während TCP Daten in Segmenten überträgt. Wenn Sie ein UDP-Paket mit 300 Bytes übertragen, erhalten Sie am anderen Ende 300 Bytes. Mit TCP können Sie dem sendenden Socket 300 Bytes zuführen, aber der Empfänger liest nur 100 Bytes, und Sie müssen irgendwie herausfinden, dass 200 weitere Bytes unterwegs sind. Dies ist wichtig, wenn Ihre Anwendung Nachrichten mit fester Größe anstelle eines Bytestroms überträgt.

Zusammenfassend kann UDP für jeden Anwendungstyp verwendet werden, den TCP ausführen kann, sofern Sie auch einen ordnungsgemäßen Mechanismus für die erneute Übertragung implementieren. UDP kann sehr schnell sein, hat weniger Verzögerung, ist nicht von einer Überlastung auf Verbindungsbasis betroffen, überträgt Datagramme mit fester Größe und kann für Multicasting verwendet werden.

UDP hat weniger Overhead und eignet sich zum Streamen von Echtzeitdaten wie Audio oder Video oder in jedem Fall, wenn Daten verloren gehen.

UDP ist ein verbindungsloses Protokoll und wird in Protokollen wie SNMP und DNS verwendet, in denen Datenpakete, die nicht in der richtigen Reihenfolge ankommen, akzeptabel sind und die sofortige Übertragung des Datenpakets von Bedeutung ist.

Es wird in SNMP verwendet, da die Netzwerkverwaltung häufig durchgeführt werden muss, wenn das Netzwerk unter Stress steht, dh wenn eine zuverlässige, überlastungsgesteuerte Datenübertragung schwierig zu erreichen ist.

Es wird in DNS verwendet, da kein Verbindungsaufbau erforderlich ist, wodurch Verzögerungen beim Verbindungsaufbau vermieden werden.

Prost

Eine der besten Antworten, die ich auf diese Frage kenne, stammt vom Benutzer zAy0LfpBZLC8mAC bei Hacker News . Diese Antwort ist so gut, dass ich sie nur so zitieren werde, wie sie ist.

TCP blockiert den Head-of-Queue, da es eine vollständige und ordnungsgemäße Zustellung garantiert. Wenn ein Paket während der Übertragung verloren geht, muss es auf eine erneute Übertragung des fehlenden Pakets warten, während UDP Pakete an die Anwendung übermittelt, sobald sie ankommen , einschließlich Duplikate und ohne jegliche Garantie, dass ein Paket überhaupt ankommt oder in welcher Reihenfolge es ankommt (es handelt sich im Wesentlichen um IP mit Portnummern und einer (optionalen) hinzugefügten Nutzlastprüfsumme), aber das ist zum Beispiel für Telefonie in Ordnung, wo es normalerweise ist Es spielt einfach keine Rolle, wenn ein paar Millisekunden Audio fehlen, aber die Verzögerung ist sehr ärgerlich, sodass Sie sich nicht um erneute Übertragungen kümmern, sondern nur Duplikate ablegen und neu angeordnete Pakete für einige hundert Millisekunden Jitterpuffer in der richtigen Reihenfolge sortieren und wenn Pakete nicht rechtzeitig oder überhaupt nicht angezeigt werden, werden sie einfach übersprungen.möglich interpoliert, wo vom Codec unterstützt.

Ein wesentlicher Teil von TCP ist auch die Flusskontrolle, um sicherzustellen, dass Sie so viel Durchsatz wie möglich erhalten, ohne jedoch das Netzwerk zu überlasten (was irgendwie redundant ist, da ein überlastetes Netzwerk Ihre Pakete verwirft, was bedeutet, dass Sie dies tun müssen Neuübertragungen, was den Durchsatz beeinträchtigt), UDP hat nichts davon - was für Anwendungen wie Telefonie sinnvoll ist, da Telefonie mit einem bestimmten Codec eine bestimmte Bandbreite benötigt, Sie sie nicht "verlangsamen" können und auch zusätzliche Bandbreite macht den Anruf nicht schneller.

Zusätzlich zu Echtzeitanwendungen / Anwendungen mit geringer Latenz ist UDP für sehr kleine Transaktionen wie DNS-Lookups sinnvoll, da es weder hinsichtlich der Latenz noch hinsichtlich der Bandbreitennutzung über den Aufbau und den Abbau von TCP-Verbindungen verfügt. Wenn Ihre Anfrage kleiner als eine typische MTU ist und die Antwort wahrscheinlich auch ist, können Sie in einem Roundtrip durchgeführt werden, ohne dass ein Status auf dem Server beibehalten werden muss, und die Flusskontrolle als Bestellung und all das ist wahrscheinlich nicht besonders nützlich für solche Zwecke entweder.

Und dann können Sie natürlich UDP verwenden, um Ihre eigenen TCP-Ersetzungen zu erstellen, aber ohne ein tiefes Verständnis der Netzwerkdynamik ist dies wahrscheinlich keine gute Idee. Moderne TCP-Algorithmen sind ziemlich ausgefeilt.

Ich denke auch, dass erwähnt werden sollte, dass es mehr als UDP und TCP gibt, wie SCTP und DCCP. Das einzige Problem besteht derzeit darin, dass das (IPv4-) Internet voll von NAT-Gateways ist, die es unmöglich machen, andere Protokolle als UDP und TCP in Endbenutzeranwendungen zu verwenden.

Video-Streaming ist ein perfektes Beispiel für die Verwendung von UDP.

UDP hat einen geringeren Overhead, wie bereits erwähnt, und eignet sich gut zum Streamen von Dingen wie Video und Audio, bei denen es besser ist, nur ein Paket zu verlieren und dann erneut zu senden und aufzuholen.

Es gibt keine Garantie für die TCP-Zustellung. Sie sollten lediglich darüber informiert werden, ob der Socket getrennt wurde oder ob die Daten nicht ankommen werden. Sonst kommt es dort an, wenn es dort ankommt.

Eine große Sache, die die Leute vergessen, ist, dass udp paketbasiert ist und tcp bytestream-basiert ist. Es gibt keine Garantie dafür, dass das von Ihnen gesendete "tcp-Paket" das Paket ist, das am anderen Ende angezeigt wird. Es kann in so viele Pakete zerlegt werden wie es die Router und Stacks wünschen. Ihre Software hat also den zusätzlichen Aufwand, Bytes wieder in nutzbare Datenblöcke zu analysieren, was einen erheblichen Aufwand bedeuten kann. UDP kann außer Betrieb sein, daher müssen Sie Ihre Pakete nummerieren oder einen anderen Mechanismus verwenden, um sie neu zu bestellen, wenn Sie dies möchten. Aber wenn Sie dieses udp-Paket erhalten, kommt es mit denselben Bytes in derselben Reihenfolge an, in der es übrig geblieben ist, ohne Änderungen. Der Begriff udp-Paket ist also sinnvoll, das TCP-Paket jedoch nicht unbedingt. TCP verfügt über einen eigenen Wiederholungs- und Bestellmechanismus, der in Ihrer Anwendung verborgen ist.

UDP ist an beiden Enden viel einfacher zu schreiben, da Sie keine Punkt-zu-Punkt-Verbindungen herstellen und pflegen müssen. Meine Frage ist normalerweise, wo sind die Situationen, in denen Sie den TCP-Overhead wünschen würden? Und wenn Sie Abkürzungen wie die Annahme annehmen, dass ein empfangenes TCP-Paket das vollständige Paket ist, das gesendet wurde, sind Sie besser dran? (Sie werden wahrscheinlich zwei Pakete wegwerfen, wenn Sie sich die Mühe machen, die Länge / den Inhalt zu überprüfen)

Die Netzwerkkommunikation für Videospiele erfolgt fast immer über UDP.

Geschwindigkeit ist von größter Bedeutung und es spielt keine Rolle, ob Updates verpasst werden, da jedes Update den vollständigen aktuellen Status des Spielers enthält.

Die Schlüsselfrage bezog sich auf "welche Art von Situationen wäre UDP die bessere Wahl [über TCP]".

Es gibt viele gute Antworten, aber was fehlt, ist eine formelle, objektive Bewertung der Auswirkungen der Transportunsicherheit auf die TCP-Leistung.

Angesichts des massiven Wachstums mobiler Anwendungen und der damit verbundenen "gelegentlich verbundenen" oder "gelegentlich getrennten" Paradigmen gibt es sicherlich Situationen, in denen der Aufwand für die Versuche von TCP, eine Verbindung aufrechtzuerhalten, wenn Verbindungen schwer zu bekommen sind, zu einer starken führt Fall für UDP und seine "nachrichtenorientierte" Natur.

Jetzt habe ich nicht die Mathematik / Forschung / Zahlen dazu, aber ich habe Apps erstellt, die mit ACK / NAK und Nachrichtennummerierung über UDP zuverlässiger funktionieren als mit TCP, wenn die Konnektivität im Allgemeinen schlecht und das alte TCP schlecht war Ich habe gerade Zeit verbracht und das Geld meines Kunden nur versucht, eine Verbindung herzustellen. Sie erhalten dies in regionalen und ländlichen Gebieten vieler westlicher Länder ....

In einigen Fällen, die andere hervorgehoben haben, ist das garantierte Eintreffen von Paketen nicht wichtig, und daher ist die Verwendung von UDP in Ordnung. In anderen Fällen ist UDP TCP vorzuziehen.

Ein einzigartiger Fall, in dem Sie UDP anstelle von TCP verwenden möchten, ist der Tunnel von TCP über ein anderes Protokoll (z. B. Tunnel, virtuelle Netzwerke usw.). Wenn Sie TCP über TCP tunneln, stören sich die Überlastungskontrollen der einzelnen Systeme gegenseitig. Daher zieht man es im Allgemeinen vor, TCP über UDP (oder ein anderes zustandsloses Protokoll) zu tunneln. Siehe TechRepublic-Artikel: Grundlegendes zu TCP über TCP: Auswirkungen des TCP-Tunnelns auf den End-to-End-Durchsatz und die Latenz .

UDP kann verwendet werden, wenn sich eine App mehr um "Echtzeit" -Daten als um die exakte Datenreplikation kümmert. Beispielsweise kann VOIP UDP verwenden, und die App kümmert sich um die Neuordnung von Paketen. Letztendlich benötigt VOIP jedoch nicht jedes einzelne Paket, sondern vor allem einen kontinuierlichen Fluss vieler Pakete. Vielleicht haben Sie hier einen "Fehler" in der Sprachqualität, aber der Hauptzweck ist, dass Sie die Nachricht erhalten und nicht, dass sie auf der anderen Seite perfekt neu erstellt wird. UDP wird auch in Situationen verwendet, in denen die Kosten für das Herstellen einer Verbindung und das Synchronisieren mit TCP die Nutzlast überwiegen. DNS-Abfragen sind ein perfektes Beispiel. Ein Paket aus, ein Paket zurück pro Abfrage. Bei Verwendung von TCP wäre dies viel intensiver. Wenn Sie die DNS-Antwort nicht zurückerhalten, versuchen Sie es einfach erneut.

UDP, wenn Geschwindigkeit erforderlich ist und die Genauigkeit, wenn die Pakete nicht erforderlich sind, und TCP, wenn Sie Genauigkeit benötigen.

UDP ist oft schwieriger, da Sie Ihr Programm so schreiben müssen, dass es nicht von der Genauigkeit der Pakete abhängt.

Es ist nicht immer eindeutig. Wenn Sie jedoch eine garantierte Zustellung von Paketen ohne Verlust und in der richtigen Reihenfolge benötigen, ist TCP wahrscheinlich das, was Sie wollen.

Andererseits ist UDP zum Übertragen kurzer Informationspakete geeignet, bei denen die Reihenfolge der Informationen weniger wichtig ist oder bei denen die Daten in ein einzelnes Paket passen können.

Dies ist auch angebracht, wenn Sie dieselben Informationen an viele Benutzer senden möchten.

In anderen Fällen ist es angemessen, wenn Sie sequenzierte Daten senden, aber wenn ein Teil davon verloren geht, sind Sie nicht allzu besorgt (z. B. eine VOIP-Anwendung).

Einige Protokolle sind komplexer, da einige (aber nicht alle) Funktionen von TCP benötigt werden, aber mehr als das, was UDP bietet. Hier muss die Anwendungsschicht die zusätzlichen Funktionen implementieren. In diesen Fällen ist auch UDP angemessen (z. B. Internetradio, Reihenfolge ist wichtig, aber nicht jedes Paket muss durchkommen).

Beispiele dafür, wo es verwendet wird / werden könnte 1) Ein Zeitserver, der die richtige Zeit an eine Reihe von Computern in einem LAN sendet. 2) VOIP-Protokolle 3) DNS-Lookups 4) Anfordern von LAN-Diensten, z. B. wo sind Sie? 5) Internetradio 6) und viele andere ...

Unter Unix können Sie grep udp / etc / services eingeben, um eine Liste der heute implementierten UDP-Protokolle zu erhalten. Es gibt Hunderte.

Lesen Sie Abschnitt 22.4 von Stevens Unix-Netzwerkprogrammierung , "Wann UDP anstelle von TCP verwendet werden soll".

Lesen Sie auch diese andere SO-Antwort zu dem Missverständnis, dass UDP immer schneller als TCP ist .

Was Steven sagt, kann wie folgt zusammengefasst werden:

• Verwenden Sie UDP für Broadcast und Multicast, da dies Ihre einzige Option ist (verwenden Sie Multicast für alle neuen Apps).
• Sie können UDP für einfache Anforderungs- / Antwort-Apps verwenden, müssen jedoch Ihre eigenen Bestätigungen, Zeitüberschreitungen und erneuten Übertragungen einbauen
• Verwenden Sie UDP nicht für die Übertragung von Massendaten.

Wir wissen, dass das UDP ein verbindungsloses Protokoll ist

1. Geeignet für Prozesse, die eine einfache Anfrage-Antwort-Kommunikation erfordern.
2. Geeignet für Prozesse mit internem Fluss und Fehlerkontrolle
3. Geeignet für Broadcasting und Multicasting

Spezifische Beispiele:

• in SNMP verwendet
• Wird für einige Routenaktualisierungsprotokolle wie RIP verwendet

Beim Vergleich von TCP mit UDP gewährleisten verbindungslose Protokolle wie UDP die Geschwindigkeit, jedoch nicht die Zuverlässigkeit der Paketübertragung. Beispielsweise benötigen Videospiele normalerweise kein zuverlässiges Netzwerk, aber die Geschwindigkeit ist am wichtigsten, und die Verwendung von UDP für Spiele hat den Vorteil, dass die Netzwerkverzögerung verringert wird.

Sie möchten UDP über TCP verwenden, wenn der Verlust einiger Daten auf dem Weg die übertragenen Daten nicht vollständig ruiniert. Viele seiner Anwendungen finden sich in Echtzeitanwendungen wie Spielen (dh FPS), bei denen Sie nicht immer wissen müssen, wo sich jeder Spieler zu einem bestimmten Zeitpunkt befindet, und wenn Sie unterwegs ein paar Pakete verlieren, neu Daten zeigen Ihnen korrekt an, wo sich die Player befinden) und Echtzeit-Video-Streaming (ein beschädigter Frame wird das Seherlebnis nicht beeinträchtigen).

Wir haben einen Webdienst, der Tausende von Winforms-Clients auf ebenso vielen PCs hat. Die PCs haben keine Verbindung zum DB-Backend, der gesamte Zugriff erfolgt über den Webdienst. Daher haben wir uns entschlossen, einen zentralen Protokollierungsserver zu entwickeln, der einen UDP-Port überwacht und alle Clients ein XML-Fehlerprotokollpaket (unter Verwendung des log4net-UDP-Appenders) senden, das beim Empfang an eine DB-Tabelle ausgegeben wird. Da es uns eigentlich egal ist, ob ein paar Fehlerprotokolle fehlen und bei Tausenden von Clients ist es schnell, wenn ein dedizierter Protokollierungsdienst den Hauptwebdienst nicht lädt.

Ich bin etwas zurückhaltend, UDP vorzuschlagen, wenn TCP möglicherweise funktionieren könnte. Das Problem ist, dass, wenn TCP aus irgendeinem Grund nicht funktioniert, weil die Verbindung zu verzögert oder überlastet ist, das Ändern der Anwendung zur Verwendung von UDP wahrscheinlich nicht hilft. Eine schlechte Verbindung ist auch für UDP schlecht. TCP leistet bereits sehr gute Arbeit bei der Minimierung von Überlastungen.

Der einzige Fall, in dem ich mir vorstellen kann, wo UDP erforderlich ist, sind Broadcast-Protokolle. In Fällen, in denen eine Anwendung zwei bekannte Hosts umfasst, bietet UDP wahrscheinlich nur marginale Leistungsvorteile bei erheblich höheren Kosten für die Codekomplexität.

Verwenden Sie UDP nur, wenn Sie wirklich wissen, was Sie tun. UDP ist heutzutage in äußerst seltenen Fällen anzutreffen, aber die Anzahl der (sogar sehr erfahrenen) Experten, die versuchen würden, es überall zu halten, scheint unverhältnismäßig zu sein. Vielleicht genießen sie es, Fehlerbehandlungs- und Verbindungswartungscode selbst zu implementieren.

Es ist zu erwarten, dass TCP mit modernen Netzwerkschnittstellenkarten aufgrund des sogenannten Prüfsummenabdrucks viel schneller ist . Überraschenderweise wäre das Berechnen einer Prüfsumme bei hohen Verbindungsgeschwindigkeiten (z. B. 1 Gbit / s) eine große Belastung für eine CPU, sodass sie auf NIC-Hardware ausgelagert wird , die TCP-Pakete für den Aufdruck erkennt, und Ihnen nicht denselben Service bietet.

UDP ist perfekt für VoIP-Adressen geeignet, bei denen Datenpakete aufgrund ihrer geringeren Zuverlässigkeit gesendet werden müssen. Video-Chats sind ein Beispiel für UDP (Sie können sie während eines Video-Chats durch Wireshark-Netzwerkerfassung überprüfen). Auch TCP funktioniert nicht DNS- und SNMP-Protokolle. UDP hat keinen Overhead, während TCP viel Overhead hat