Warum ist TCP langsamer als UDP?
Ich finde einfach nix im Internet... die Daten werden doch glaube ich überprüft ob sie falsch sind oder evt neu gesendet, wie heisst das Verfahren?
7 Antworten
Wenn ich mich noch richtig daran erinnere liegt es an der Verbindung der Protokolle TCP/UDP :
Der Vorteil von UDP liegt in einer schnellen Übertragung mit geringem Verwaltungsaufwand.
Ein Nachteil ist, dass UDP keine Garantie für die Datenzustellung bietet. Es ist keine zuverlässige Methode, um wichtige Informationen zu senden, da es keine Datenwiederherstellung oder erneute Übertragungen für verlorene Pakete gibt.
Der Nachteil von TCP ist, dass die Verbindungen langsamer sind, weil ständig Datenpakete hin- und hergeschickt werden müssen, um sie zu synchronisieren und zu bestätigen.
Ergänzend zu den Antworten hier kann man noch sagen, dass der Overhead bei TCP größer ist. Ein UDP-Header besteht aus 8 Byte und ein TCP-Header besteht aus mindestens 20 Byte.
Bei TCP wird erst mal eine Verbindung aufgebaut. Dazu braucht es schon mal drei Pakete. Anschließend werden Daten ausgetauscht, abschließend wird die Verbindung wieder mit drei bis vier Paketen abgebaut. Dazu kommt eine Flusskontrolle. Wenn ein Paket verloren geht, drosselt TCP die Übertragungsrate.
die Daten werden doch glaube ich überprüft ob sie falsch sind oder evt neu gesendet, wie heisst das Verfahren?
Innerhalb von TCP wird die Vollständigkeit der Daten anhand der Sequence Number und der Acknowledgement Number überprüft. Verloren gegangene Pakete werden erneut gesendet, man spricht von Retransmission. Es gibt ein Receive Window, das eine bestimmte Datenmenge angibt, die vom Sender gesendet werden darf. Spätestens nach dieser Datenmenge muss der Sender eine Bestätigung (Acknowledgement) vom Empfänger abwarten.
Bei UDP findet kein Verbindungsaufbau statt, ebenso gibt es keine Flusskontrolle. Wenn etwas verloren geht, ist es weg.
Langsamer ist erstmal der falsche Begriff.
TCP gibt ständig eine Antwort zurück und kontrolliert den Datenfluss.
UDP ist eher ein Fire-and-Forget. Wenn da ein Paket nicht ankommt, ist das halt so.
Deshalb wird bei der Datenübertragung TCP genutzt, weil man alle Daten benötigt.
Bei Voice Chat nutzt man UDP, weil man nicht unbedingt jeden Ton benötigt und auch keine Stotter braucht, wenn mal etwas verloren geht.
LG
Ah, dann ist mein Stand veraltet.
Ich schätze mal, das liegt daran, dass wir recht gut in der Lage sind kaputte Pakete zu reparieren?
Nein, repariert werden kann da nichts. Bei DHCP und DNS wird einfach noch einmal gefragt, wenn keine Antwort kommt. Bei Syslog ist es Pech, alternativ kann man Syslog auch per TCP machen. Bei SNMP werden Requests noch einmal geschickt, für die Traps gibt es die Informs. Das sind Traps, auf die eine Bestätigung erwartet wird. Bei HTTP/3 wird das Thema von QUIC erledigt.
Überspitzt dargestellt:
TCP- A: Hallo, ich will Dir ein Paket schicken.
- B: OK
- A: Hier ist Paket 1
- B: OK
- A: Hier Paket 2
- B. OK
- A: Hier Paket 3.
- B: OK
- A: Super, dann können wir die Verbindung beenden.
- B: OK
- A: Hier, das Paket 3.
- A: Hier, das Paket 1.
- A: Hier, das Paket 2.
Meines Wissens ist es UDP dann übrigens egal, wenn der Empfänger eines der Pakete nicht verarbeiten konnte, weil es derzeit mit anderen Dingen überlastet war. Die Reihenfolge wird auch nicht eingehalten, das 3-1-2 war dementsprechend Absicht.
Na ja, so pauschal ist das auch nicht richtig und in Zukunft wird es noch weniger richtig sein. TFTP z. B. läuft über UDP. DNS ebenfalls in den meisten Fällen, ebenso wie DHCP. Auch Syslog und SNMP werden in der Regel per UDP abgewickelt. In Zukunft werden Webseiten zunehmend per HTTP/3 übermittelt, das ist HTTP over QUIC, wobei QUIC über UDP läuft.