it-swarm.com.de

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

Denn TCP garantiert die Paketzustellung und kann daher als "zuverlässig" angesehen werden, während UDP nichts garantiert und Pakete verloren gehen können. Was wäre der Vorteil einer Datenübertragung mit UDP in einer Anwendung? als über einen TCP stream? In welchen Situationen wäre UDP die bessere Wahl und warum?

Ich gehe davon aus, dass UDP schneller ist, da es nicht den Overhead hat, einen Stream zu erstellen und zu pflegen, aber wäre das nicht irrelevant, wenn einige Daten nie ihr Ziel erreichen?

283
Jeff L

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, ein eigenes Protokoll zu implementieren, um die Zuverlässigkeit zu gewährleisten, oder es erneut zu senden. DNS ist die perfekte Beschreibung dieses Anwendungsfalls. Die Kosten für den Verbindungsaufbau sind viel zu hoch (DNS unterstützt jedoch auch den Modus TCP)).

Ein anderer Fall ist, wenn Sie Daten bereitstellen, die verloren gehen können, da neuere eingehende Daten die vorherigen Daten/den vorherigen Status ersetzen. Man denkt an Wetterdaten, Video-Streaming, einen Börsendienst (der nicht für den tatsächlichen Handel verwendet wird) oder Spieledaten.

Ein anderer Fall ist, wenn Sie eine enorme Menge an Status verwalten und die Verwendung von TCP vermeiden möchten, weil das Betriebssystem nicht so viele Sitzungen verarbeiten kann. Dies ist heute ein seltener Fall. In der Tat gibt es jetzt user-land TCP Stapel, die verwendet werden können, damit der Anwendungsschreiber eine genauere Kontrolle über die für diesen TCP= Status erforderlichen Ressourcen hat. Vor 2003, UDP war wirklich das einzige Spiel in der Stadt.

Ein weiterer Fall betrifft den Multicast-Verkehr. UDP kann auf mehrere Hosts multicasted werden, wohingegen TCP das überhaupt nicht kann.

331
drudru

Wenn ein TCP -Paket verloren geht, wird es erneut gesendet. Dies ist nicht praktisch für Anwendungen, die darauf angewiesen sind, dass Daten in einer bestimmten Reihenfolge in Echtzeit verarbeitet werden.

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

62
Stephan202

Die "Unzuverlässigkeit" von UDP ist ein Formalismus. Die Übertragung ist nicht absolut garantiert. Praktisch kommen sie fast immer durch. Sie werden einfach nicht bestätigt und nach einer Zeitüberschreitung erneut versucht.

Der Aufwand für das Aushandeln eines TCP Sockets und das Handshaken der TCP Pakete ist enorm. Wirklich enorm. Es gibt keinen nennenswerten UDP-Aufwand.

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

UDP ist nützlich für das Senden von Informationen in einer Publish-Subscribe-Anwendung. IIRC, TIBCO nutzt UDP in großem Umfang für die Benachrichtigung über Statusänderungen.

Jede andere Art von "signifikanten Ereignissen" oder "Protokollierungsaktivitäten" in eine Richtung kann mit UDP-Paketen problemlos verarbeitet werden. Sie möchten eine Benachrichtigung senden, ohne einen vollständigen Socket zu erstellen. Sie erwarten keine Antwort von den verschiedenen Zuhörern.

System "Heartbeat" - oder "I'm Alive" -Meldungen sind ebenfalls eine gute Wahl. Fehlende ist keine Krise. Ein halbes Dutzend (in einer Reihe) fehlt.

56
S.Lott

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

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

  1. 1 Eintrag
    • 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 übertragene Gesamtdatenmenge war für IP und TCP ungefähr gleich. Wir haben zusätzlichen Overhead mit der UDP-Kommunikation, da wir einige der gleichen Dinge haben, die Sie mit TCP/IP "kostenlos" erhalten (Prüfsummen, Folgenummern usw.). Zum Beispiel zeigte Wireshark, dass eine Anforderung für den nächsten Satz von Datensätzen 80 Bytes mit UDP und 84 Bytes mit TCP betrug.

29
Mark Wilkins

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 es keine Überlastungskontrolle einsetzt . Überlastungskontrolle in TCP ist sehr sehr wichtig. Es steuert die Rate und den Durchsatz von die Verbindung, um die Überlastung des Netzwerks zu minimieren, indem versucht wird, die aktuelle Kapazität der Verbindung zu schätzen. Selbst wenn Pakete über sehr zuverlässige Verbindungen wie im Kernnetzwerk gesendet werden, haben Router Puffer mit begrenzter Größe. Diese Puffer füllen sich mit ihrer Kapazität und Pakete werden dann verworfen, und TCP bemerkt diesen Abfall durch das Fehlen einer empfangenen Bestätigung und drosselt die Geschwindigkeit der Verbindung zur Schätzung der Kapazität. TCP verwendet auch etwas, das als langsamer Start bezeichnet wird, aber den Durchsatz (tatsächlich das Überlastungsfenster ) wird langsam erhöht, bis Pakete verworfen werden, und wird dann gesenkt und langsam wieder erhöht, bis Pakete verworfen werden usw. Dies bewirkt, dass der TCP Durchsatz schwankt. Dies wird deutlich, wenn Sie a herunterladen große Datei.

Da UDP keine Überlastungskontrolle verwendet, kann es sowohl schneller sein als auch eine geringere Verzögerung erfahren, da es nicht versucht, die Puffer bis zum Abwurfpunkt zu maximieren, d. H. UDP-Pakete verbringen weniger Zeit in Puffern und gelangen mit geringerer Verzögerung schneller dorthin. Da UDP keine Überlastungskontrolle verwendet, dies jedoch bei TCP) der Fall ist, kann es TCP) Kapazität entziehen, die für UDP-Flows erbracht wird.

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

Das Ergebnis ist, dass UDP:

  • Erzielen Sie einen höheren Durchsatz als TCP), solange sich die Netzwerkausfallrate innerhalb der von der Anwendung möglichen Grenzen befindet.
  • Liefern Sie Pakete schneller als TCP mit weniger Verzögerung.
  • Richten Sie die Verbindungen schneller ein, da kein erster Handshake zum Einrichten der Verbindung erforderlich ist
  • Übertragen Sie Multicast-Pakete, wobei TCP mehrere Verbindungen verwenden müssen.
  • Übertragen Sie Pakete mit fester Größe, während TCP Daten in Segmenten übertragen. Wenn Sie ein UDP-Paket mit 300 Bytes übertragen, erhalten Sie am anderen Ende 300 Bytes. Mit TCP können Sie den Sende-Socket speisen 300 Bytes, aber der Empfänger liest nur 100 Bytes und Sie müssen irgendwie herausfinden, dass 200 Bytes mehr auf dem Weg sind. Dies ist wichtig, wenn Ihre Anwendung Nachrichten mit fester Größe statt eines Bytestroms überträgt.

Zusammenfassend kann UDP für jede Art von Anwendung verwendet werden, die TCP) kann, sofern Sie auch einen ordnungsgemäßen Neuübertragungsmechanismus implementieren. UDP kann sehr schnell sein und ist mit geringer Verzögerung davon nicht betroffen Überlastung auf Verbindungsbasis, überträgt Datagramme mit fester Größe und kann für Multicasting verwendet werden.

15
Andy

UDP ist ein verbindungsloses Protokoll und wird in Anwendungen wie SNMP (Simple Network Management Protocol) und DNS (Domain Name System) verwendet, bei denen Datenpakete nicht ordnungsgemäß eingehen, unzuverlässig und nicht von Belang sind und ein sofortiges Durchsenden der Datenpakete wichtig ist.

Da UDP keinen Verbindungsaufbau beinhaltet, werden Anwendungen wie DNS, bei denen Verzögerungen beim Verbindungsaufbau vermieden werden müssen, UDP gegenüber TCP bevorzugt.

Wird in SNMP als Netzwerkverwaltung verwendet, muss dies häufig in einem belasteten Netzwerk erfolgen, d. H. Wenn eine zuverlässige, überlastungsgesteuerte Datenübertragung schwierig zu erreichen ist.

prost

15
Arnkrishn

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

13
Dana Holt

Eine der besten mir bekannten Antworten auf diese Frage kommt von Benutzer zAy0LfpBZLC8mAC bei Hacker News . Diese Antwort ist so gut, dass ich sie nur so zitiere, wie sie ist.

TCP hat eine Head-of-Queue-Blockierung, 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 bei ihrer Ankunft an die Anwendung übermittelt , einschließlich Duplikate und ohne Gewähr dafür, 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 gut für Telefonie, wo es normalerweise der Fall ist Es spielt einfach keine Rolle, wann ein paar Millisekunden Audio fehlen, aber die Verzögerung ist sehr ärgerlich, sodass Sie sich nicht um erneute Übertragungen kümmern müssen. Sie müssen nur alle Duplikate löschen und neu geordnete Pakete für ein paar hundert Millisekunden Jitterpuffer in der richtigen Reihenfolge sortieren Wenn Pakete nicht rechtzeitig oder überhaupt nicht angezeigt werden, werden sie einfach übersprungen und möglicherweise interpoliert, sofern dies vom Codec unterstützt wird.

Außerdem besteht ein Großteil von TCP in der Flusskontrolle, um sicherzustellen, dass Sie so viel Durchsatz wie möglich erzielen, ohne das Netzwerk zu überlasten (was ein bisschen redundant ist, da ein überlastetes Netzwerk Ihre Pakete fallen lässt, was bedeutet, dass Sie d müssen Retransmits machen, was den Durchsatz beeinträchtigt), UDP hat nichts davon - was für Anwendungen wie Telefonie Sinn macht, da Telefonie mit einem bestimmten Codec eine gewisse Bandbreite benötigt, kann man es nicht "verlangsamen", und zusätzliche Bandbreite beschleunigt den Anruf ebenfalls nicht.

Neben Echtzeitanwendungen und Anwendungen mit geringer Latenz ist UDP auch für sehr kleine Transaktionen wie DNS-Lookups sinnvoll, da es weder hinsichtlich der Latenz noch hinsichtlich des Zeitaufwands einen TCP -Verbindungsauf- und -abbaus aufweist Bandbreitennutzung. Wenn Ihre Anfrage kleiner als eine typische MTU ist und die Antwort wahrscheinlich auch ist, können Sie in einem Durchgang ausgeführt werden, ohne dass ein Status auf dem Server gespeichert werden muss, und die Flusskontrolle als Bestellung und all das ist wahrscheinlich nicht besonders nützlich auch für solche Zwecke.

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.

Außerdem sollte erwähnt werden, dass es nicht nur UDP und TCP gibt, sondern auch SCTP und DCCP. Das einzige Problem besteht derzeit darin, dass das (IPv4-) Internet mit NAT Gateways gefüllt ist, die es unmöglich machen, andere Protokolle als UDP und TCP in Endbenutzeranwendungen zu verwenden.

12
Shital Shah

UDP hat einen geringeren Overhead, da dies bereits für das Streamen von Dingen wie Video und Audio geeignet ist, bei denen es besser ist, nur ein Paket zu verlieren, als erneut zu senden und aufzuholen.

Es gibt keine Garantien für TCP Lieferung, Sie sollen lediglich informiert werden, wenn die Verbindung zum Socket unterbrochen wurde oder wenn die Daten nicht ankommen. Andernfalls gelangen sie dorthin, wenn sie dort ankommen.

Eine große Sache, die die Leute vergessen, ist, dass udp paketbasiert ist und tcp bytestream-basiert. 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 sich die router und stacks wünschen. Ihre Software hat also den zusätzlichen Aufwand, Bytes wieder in verwendbare Datenblöcke zu zerlegen, was einen erheblichen Mehraufwand bedeuten kann. UDP ist möglicherweise nicht in Ordnung, daher müssen Sie Ihre Pakete nummerieren oder einen anderen Mechanismus verwenden, um sie neu zu ordnen, wenn Sie dies möchten. Aber wenn Sie dieses udp-Paket erhalten, kommt es mit allen gleichen Bytes in der gleichen Reihenfolge an, wie es verlassen hat, keine Änderungen. Der Begriff "udp-Paket" ist also sinnvoll, "tcp-Paket" jedoch nicht. TCP hat einen eigenen Wiederholungs- und Ordnungsmechanismus, der von Ihrer Anwendung verborgen wird. Sie können diesen mit UDP neu erfinden, um ihn an Ihre Bedürfnisse anzupassen.

UDP ist viel einfacher, Code für beide Seiten zu schreiben, da Sie die Punkt-zu-Punkt-Verbindungen nicht herstellen und warten müssen. Meine Frage ist normalerweise, wo die Situationen sind, in denen Sie den TCP Overhead wünschen würden? Und wenn Sie Verknüpfungen annehmen, dass ein empfangenes TCP- "Paket" das vollständige Paket ist, das gesendet wurde, sind Sie besser dran (Sie werden wahrscheinlich zwei Päckchen wegwerfen, wenn Sie sich die Mühe machen, die Länge/den Inhalt zu überprüfen)

8
old_timer

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

7
Daniel A. White

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

Geschwindigkeit ist von äußerster Wichtigkeit und es spielt keine Rolle, ob Updates verpasst werden, da jedes Update den vollständigen aktuellen Status dessen enthält, was der Spieler sehen kann.

5
17 of 26

In einigen Fällen, die andere hervorgehoben haben, ist die garantierte Ankunft 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, in dem Sie TCP über ein anderes Protokoll tunneln (z. B. Tunnel, virtuelle Netzwerke usw.) Wenn Sie TCP über TCP tunneln, stören sich die Überlastungskontrollen gegenseitig. Daher zieht man es im Allgemeinen vor, TCP über UDP (oder ein anderes) zu tunneln zustandsloses Protokoll). Siehe TechRepublic-Artikel: Grundlegendes zu TCP Über TCP: Auswirkungen von TCP Tunneling auf End-to-End-Durchsatz und -Latenz =.

3
Brian M. Hunt

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

Es gibt viele gute Antworten, aber es fehlt eine formelle, objektive Bewertung der Auswirkungen von Transportunsicherheiten auf die Leistung von TCP.

Angesichts des massiven Wachstums mobiler Anwendungen und der damit einhergehenden "gelegentlich verbundenen" oder "gelegentlich getrennten" Paradigmen gibt es sicherlich Situationen, in denen der Overhead der TCP-Versuche, eine Verbindung aufrechtzuerhalten, wenn es schwierig ist, Verbindungen herzustellen, zu einem starken Anstieg führt Argumente für UDP und seine "nachrichtenorientierte" Natur.

Jetzt habe ich keine Mathematik/Forschung/Zahlen, aber ich habe Apps entwickelt, die zuverlässiger mit ACK/NAK und Nachrichtennummerierung über UDP arbeiten als mit TCP, wenn die Konnektivität im Allgemeinen schlecht war und der arme, alte TCP verbrachte gerade seine Zeit und das Geld meines Kunden versuchte nur, eine Verbindung herzustellen. Sie erhalten dies in regionalen und ländlichen Gebieten vieler westlicher Länder ....

3

Es ist nicht immer eindeutig. Wenn Sie jedoch eine verlustfreie und garantierte Zustellung von Paketen in der richtigen Reihenfolge benötigen, ist TCP wahrscheinlich das Richtige für Sie.

Auf der anderen Seite ist UDP für die Übertragung kurzer Informationspakete geeignet, bei denen die Reihenfolge der Information weniger wichtig ist oder bei denen die Daten in ein einzelnes Paket passen können.

Dies ist auch dann sinnvoll, wenn Sie die gleichen Informationen an viele Benutzer senden möchten.

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

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

Beispiele, wo es verwendet wird/werden könnte 1) Ein Zeitserver, der die richtige Zeit an eine Reihe von Maschinen in einem LAN sendet. 2) VOIP-Protokolle 3) DNS-Lookups 4) Anfordern von LAN-Diensten, z. 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 abzurufen. Es gibt Hunderte.

2
Matt

UDP, wenn Geschwindigkeit erforderlich ist, und die Genauigkeit, wenn die Pakete nicht erforderlich sind, und TCP, wenn Genauigkeit erforderlich ist.

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

2
bgw

UDP kann verwendet werden, wenn sich eine App mehr um Echtzeitdaten als um die exakte Datenreplikation kümmert. Beispielsweise kann VOIP UDP verwenden, und die App wird sich Gedanken über die Neuordnung von Paketen machen. 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 nachgebildet wird. UDP wird auch in Situationen verwendet, in denen die Kosten für das Herstellen einer Verbindung und das Synchronisieren mit TCP) die Nutzdaten überwiegen. DNS-Abfragen sind ein perfektes Beispiel. Ein Paket heraus, ein Paket zurück pro Abfrage TCP das wäre viel intensiver. Wenn Sie die DNS-Antwort nicht zurückbekommen, versuchen Sie es einfach noch einmal.

2
RC.

Wir wissen, dass 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
2
vikki

Lesen Sie Abschnitt 22.4 von Steven's nix Network Programming , "Wann UDP anstelle von TCP verwendet wird".

Siehe auch diese andere SO Antwort über die falsche Annahme, 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 Neuübertragungen einbauen
  • Verwenden Sie UDP nicht für die Übertragung von Massendaten.
2

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

enter image description here

2
Jorgesys

Wir haben einen Webservice mit Tausenden von WinForms-Clients auf so vielen PCs. Die PCs haben keine Verbindung zum DB-Backend, der Zugriff erfolgt ausschließlich über den Webservice. Aus diesem Grund haben wir uns für die Entwicklung eines zentralen Protokollierungsservers entschieden, der einen UDP-Port überwacht und von allen Clients ein XML-Fehlerprotokollpaket (mit dem UDP-Appender von log4net) sendet, das beim Empfang in eine DB-Tabelle geschrieben wird. Da es uns eigentlich egal ist, ob ein paar Fehlerprotokolle fehlen, und bei Tausenden von Clients ist dies schnell, da ein dedizierter Protokollierungsdienst den Hauptwebdienst nicht lädt.

1
softveda

Sie möchten UDP über TCP in den Fällen verwenden, in denen der Verlust einiger Daten auf dem Weg die übertragenen Daten nicht vollständig ruiniert. Ein Großteil der Verwendung erfolgt in Echtzeitanwendungen, z als Gaming (dh FPS, bei dem Sie nicht immer wissen müssen, wo sich jeder Spieler zu einem bestimmten Zeitpunkt befindet, und wenn Sie auf dem Weg ein paar Pakete verlieren, zeigen Ihnen neue Daten auf jeden Fall korrekt an, wo sich die Spieler befinden) und Echtzeit-Video-Streaming (ein fehlerhafter Frame kann das Seherlebnis nicht beeinträchtigen).

1
Zachary Murray

Ich zögere ein bisschen, UDP vorzuschlagen, wenn TCP könnte möglicherweise funktionieren. Das Problem ist, dass wenn TCP aus irgendeinem Grund nicht funktioniert, weil die Verbindung Wenn die Anwendung zu spät oder zu überlastet ist, hilft es wahrscheinlich nicht, die Anwendung auf UDP umzustellen. Eine schlechte Verbindung ist auch für UDP schlecht. TCP) minimiert bereits sehr gut die Überlastung.

Der einzige Fall, an den ich denken kann, wo UDP erforderlich ist, ist für Broadcast-Protokolle. In Fällen, in denen eine Anwendung zwei bekannte Hosts umfasst, bietet UDP wahrscheinlich nur marginale Leistungsvorteile für wesentlich höhere Kosten für die Codekomplexität.