Daten per UDP austauschen. So funktioniert es.
Patrick Boekhoven
https://www.youtube.com/watch?v=hd4e1fGIPJg

Transkript (automatisch erstellt)

0:00 wenn ihr Daten über das Internet verschickt dann könnte UDP also das User datagram protocol eventuell die richtige Wahl sein zumindest wenn ihr ein verbindungsloses und nicht zuverlässiges
0:10 Protokoll wählt klingt jetzt auf den ersten Blick nicht so erstrbenswert aber warum UDP trotzdem seine Daseinsberechtigung hat das gucken wir uns jetzt an also nehmen wir jetzt mal an wir haben
0:19 ja zwei PCs einmal den PC von lutka SIEBERT und einmal den PC von Hanna Wolf und lutkas PC möchte Daten zu hannwols PC schicken und nutzt dafür UDP dann benötigt ist keine extra Verbindung das heißt
0:31 es muss kein Handshake oder ähnliches passieren sondern lutkas PC erstellt sein Datenpaket und sendet es ohne vorherigen Verbindungsaufbau direkt an hanwolfs PC im UDP Header findet sich dann
0:42 wieder von welchem quellport das Paket gesendet wurde und natürlich der Zielport und das ist die Aufgabe von lutgar PC hier die richtigen Ports einzutragen also das heißt hann Wolfs PC überwacht
0:53 jetzt den Netzwerkverkehr auf dem angegebenen Port und nimmt das Paket entgegen sofern es dann angekommen ist und es gibt keine Bestätigung kein Empfang oder ähnliches also das heißt das
1:03 holt sich die Nutzerdaten aus dem UDP Paket und verarbeitet dann dann die Daten dementsprechend bzw übergibt sie an die Anwendung und in dem Fall stand jetzt drin dass das Paket für den Port 3478
1:15 bestimmt war und den krallz sich dann Skype zumindest wenn es darum geht eine Verbindung zu initiieren deswegen an der Stelle klar ist oh das Paket muss direkt an die Anwendung Skype
1:24 weitergeleitet werden und es gibt überhaupt gar keine Mechanismen zur Überprüfung an dieser Stelle ob die Pakete richtig angekommen sind oder nicht bzw wenn irgendein Paket nicht angekommen ist dann
1:35 gibt's auch kein Mechanismus zur Wiederherstellung Sprich, ist ein Paket verloren gegangen, dann ist das Paket auch verloren gegangen, und das wird auch nicht ankommen. Und natürlich
1:43 kommt es manchmal vor, dass ein Datenpaket zu groß ist, um in einem einzigen Netzwerkrahmen transportiert zu werden, und dann wird dieses Paket fragmentiert. Und diese Fragmentierung, die
1:54 erfolgt auf der Ebene des IP, also das Internet Protocols. Da UDP selbst keine Mechanismen für die Aufteilung und Wiederherstellung von großen Datenpaketen anbietet, das heißt
2:04 grundlegend passiert folgendes: Wenn der PC von Lutka jetzt ein Datenpaket an den PC von Hanna senden möchte und dieses Paket deutlich zu groß ist, um es einzeln zu versenden, dann
2:14 werden daraus einzelne Fragmente gebildet. Also, das heißt, wir haben einen großen Datenblock, den wir nachher wieder zusammensetzen müssen, und das passiert anhand von sogenannten
2:23 Identifikationsnummern und dem sogenannten Offset. Also, ihr seht, jedes dieser einzelnen Fragmente hat die gleiche Identifikationsnummer. Also, diese Identifikationsnummer gibt dann an,
2:34 zu welchem Originaldatenpaket dieses Fragment gehört, und dazu kommt dann der Offset, und der gibt dann jedes Mal an, an welcher Position im ursprünglichen Datenpaket sich dieses Fragment
2:44 befindet. Also, wenn ihr Identifikationsnummer und den Offset habt, dann könnt ihr am Ende diese Fragmente wieder zu einem kompletten Datenpaket zusammensetzen. Und diese ganzen Fragmente,
2:53 die werden dann separat, also wirklich einzeln, über eventuell auch verschiedene Wege vom Sender zum Empfänger transportiert, und beim Empfänger selber, also bei Hannawolfs PC,
3:04 wenn die Daten dann empfangen bzw. diese einzelnen IP-Fragmente und reassembliert werden, also mit anderen Worten wieder richtig zusammengebaut, und jetzt fragt ihr euch vielleicht, Folge richtig,
3:14 was passiert denn, wenn jetzt ein Fragment weg ist, denn es gibt ja keine Mechanismen zur Kontrolle bzw. die Sachen werden ja nicht normal geschickt, dann kann das tatsächlich passieren,
3:22 dass das gesamte Datenpaket verloren geht, denn dieses Fragment, was dann verloren geht, das lässt sich logischerweise nicht mehr rekonstruieren. Und jetzt stellt ihr euch vielleicht die Frage, warum
3:31 überhaupt UDP? Und dafür gibt's einige Gründe, und UDP, das ist verbindungslos, also das heißt, das erfordert kein Handshake oder irgendwelche Bestätigungen, und da ist es in der Regel deutlich
3:42 schneller und bietet auch eine geringe Latenz. Das heißt, bei Anwendungen, wo es nur darum geht, Daten schnell zu übertragen und das wichtiger ist als Zuverlässigkeit, wie die Echtzeittelefonie,
3:53 über die wir gerade gesprochen haben, da ist UDP wirklich absolut sinnvoll, und deswegen hat UDP seine Daseinsberechtigung. Und die Effizienz ist ein ganz wichtiges Thema, denn UDP, das hat einen
4:05 geringen Overhead, bzw. einen deutlich geringeren Overhead als TCP selber, das keine Mechanismen zur Gewährleistung der Datenintegrität und Reihenfolge der Übertragung bietet, und das kann tatsächlich
4:16 auch ein Vorteil sein, denn in Anwendungen, bei denen diese Aspekte weniger kritisch sind, da ist UDP natürlich deutlich effizienter. Und natürlich benötigt ihr hier eine Anwendung, bei der der
4:25 Verlust von Datenpaketen durchaus tolerierbar ist, denn wenn ich eine Anwendung habe, wo wirklich jedes Paket gesichert ankommen muss, ist UDP natürlich die falsche Wahl. Und ein gutes Beispiel
4:36 ist DNS, also das Domain Name System, und hier hinter verbirgt sich ein Protokoll zur Umsetzung von menschenlesbaren Domainnamen in IP-Adressen, und damit kommen wir alleine beim Surfen schon
4:47 sehr häufig in Berührung. Denn wir geben ja nicht die IP-Adresse vom Google Server an, sondern wir geben immer google.de an, und google.de wird dann in die entsprechende IP-Adresse aufgelöst werden,
4:58 das heißt, wir geben beispielsweise einen Domainnamen an und erhalten dafür eine IP-Adresse, und DNS-Anfragen sind in der Regel recht klein, und UDP, das haben wir jetzt besprochen, hat einen
5:08 geringen Overhead, was natürlich bei kleinen Datenmengen deutlich effizienter ist. Also, hier eignet sich UDP super, und wir haben gerade von der Latenz gesprochen. DNS
5:18 erfordert oft eine schnelle Auflösung von Domainnamen, Webseiten etc., aufzurufen, und auch hier kommen wir wieder bei diesem geringen Overhead raus. Denn dadurch,
5:26 dass wir einfach so einen geringen Overhead haben, bietet natürlich eine geringe Latenz. Außerdem ist hier der Verlust von einzelnen Paketen absolut tolerierbar, denn DNS-Anfragen sind oft einfach,
5:38 und es ist okay, dass gelegentlich mal ein Paket verloren geht. Wenn eine DNS-Anfrage dann wirklich mal verloren geht, dann kann sie normalerweise ohne Probleme wiederholt werden
5:47 bzw. erneut gesendet werden. Also, da DNS in der Regel mit kleinen Anfragen und Antworten arbeitet, ist die Zuverlässigkeit der Datenübertragung nicht ganz so kritisch. Die Geschwindigkeit und
5:58 die Effizienz bei der Auflösung der Domainnamen sind deutlich wichtiger, und daher eignet sich UDP deutlich besser. Und zum Schluss gucken wir uns noch mal einige Fakten an, und da beginnen wir
6:08 erstmal damit, dass wir bei UDP eine ganz einfache Headerstruktur vorfinden. Das heißt, dieser UDP-Header, der ist vergleichsweise einfach. Der besteht aus einem Quellport und einem Zielport,
6:18 der Länge des Datensegments, einer Prüfsumme, etc., und mehr kommt da nicht hinzu. Und genau diese einfache Struktur, die trägt tatsächlich zu diesem geringen Overhead und zur Latenz von
6:29 UDP bei. Außerdem ist das Senden von Broadcast- und Multicast-Nachrichten möglich, was bedeutet, dass Datenpakete an mehrere Empfänger gleichzeitig gesendet werden können. Und das ist nützlich in
6:39 Anwendungen, bei denen Daten an eine bestimmte Gruppe von Empfängern übertragen werden müssen, wie z.B. Multimedia-Streaming oder verschiedene Netzwerkspiele. Und das ist ein ganz großer
6:48 Unterschied zu TCP. Außerdem ist UDP und seine Einfachheit und Verbindungslosigkeit oft einfacher zu implementieren als TCP, und das erleichtert die Entwicklung von Anwendungen. Allerdings,
6:58 was man auch dazu sagen muss, es existiert keine Flusskontrolle. Denn im Gegensatz zu TCP wie UDP diese nicht an. Das bedeutet, dass es keine Mechanismen gibt,
7:08 um die Geschwindigkeit bei der Datenübertragung zwischen Sender und Empfänger zu steuern, und es gibt auch keine Überlastungskontrolle. Das heißt, es gibt keinerlei Mechanismen, die sicherstellen,
7:18 dass das Netzwerk nicht überlastet wird und die Datenübertragung mit einer für das Netzwerk angemessenen Rate erfolgt. Das heißt, bei UDP, da werden die Daten ohne Rücksicht darauf,
7:27 ob das Netzwerk überlastet ist, gesendet, und das ist auch völlig egal, ob der Empfänger wirklich Schritt halten kann. Und das kann dazu führen, dass Daten natürlich auch verloren gehen. Also,
7:36 ihr merkt, wir haben einen bunten Mix an Vorteilen, aber auch an Nachteilen, und das gibt Situationen, da ist UDP wirklich geeignet, und man muss tatsächlich sagen, es gibt Situationen,
7:46 dass UDP überhaupt nicht geeignet ist. Aber das müsst ihr natürlich von Situation zu Situation selber beurteilen. So, damit sind wir auch durch. Hier links habe ich mein Video zu TCP verlinkt,
7:57 und der rechts, da findet ihr mein Video zu RA-Systemen, also wie ihr Speichersysteme effizient organisieren könnt. Und ich freue mich natürlich jedes Mal über ein Like oder
8:04 ein Abo. Also, wenn euch das ganze gefallen hat, wenn euch das ganze einen Mehrwert geboten hat, dann würde ich mich sehr über euren Support freuen. Alles Gute und bis zum nächsten Mal.