5.2 TCP und UDP

Gemeinsame Grundlage, unterschiedlicher Dienst

TCP und UDP arbeiten an den Endsystemen oberhalb von IP. Router müssen für die gewöhnliche Weiterleitung weder eine TCP-Verbindung aufbauen noch UDP-Endpunkte bereitstellen. Firewalls, NAT-Gateways und Lastverteiler können Transportinformationen dennoch auswerten oder verändern.

Beide Protokolle besitzen getrennte 16-Bit-Porträume von 0 bis 65535. Ein TCP-Port und ein UDP-Port mit derselben Nummer sind daher verschiedene Endpunkte. TCP bildet Segmente und UDP Datagramme; beide werden als Nutzlast eines IP-Pakets übertragen.

Ports, Dienste und Sockets

Ein Port bezeichnet eine logische Transportadresse, keine physische Buchse. System- beziehungsweise Well-Known Ports reichen von 0 bis 1023, registrierte Ports von 1024 bis 49151 und dynamische oder private Ports von 49152 bis 65535. Ein Betriebssystem kann für kurzlebige Clientverbindungen einen eigenen Teilbereich verwenden.

Die IANA-Zuordnung beschreibt den vorgesehenen Dienst, beweist aber nicht, dass ein Dienst tatsächlich läuft oder durch eine Firewall erreichbar ist. Anwendungen dürfen außerdem abweichende Ports verwenden. Manche Anwendungsprotokolle nutzen bewusst TCP und UDP.

TCP- und UDP-Header im direkten Vergleich

Der TCP-Header ist wegen seiner zusätzlichen Aufgaben deutlich umfangreicher. Ohne Optionen umfasst er 20 Byte. TCP-Optionen wie Maximum Segment Size, Window Scale, Selective Acknowledgment oder Zeitstempel können den Header erweitern. Der UDP-Header besteht immer aus vier 16-Bit-Feldern und umfasst genau 8 Byte.

Weniger Headerfelder bedeuten nicht automatisch, dass eine UDP-Anwendung insgesamt schneller oder einfacher ist. Muss sie Zuverlässigkeit, Reihenfolge, Sicherheit oder Überlastkontrolle selbst ergänzen, entsteht die Komplexität oberhalb von UDP. QUIC ist ein wichtiges Beispiel dafür.

Die Felder des TCP-Headers

TCP-Steuerbits richtig lesen

Die sechs klassischen Flags aus vielen Lehrdarstellungen werden heute durch ECE und CWR für Explicit Congestion Notification ergänzt. Ein einzelnes Flag erklärt noch nicht den vollständigen Zustand; entscheidend sind Kombination, Verbindungsphase, Sequenz- und Bestätigungsnummern.

TCP-Verbindung aufbauen und geordnet schließen

Der Client beginnt den Three-Way Handshake mit SYN und einer Initial Sequence Number. Der Server antwortet mit SYN und ACK sowie seiner eigenen Initial Sequence Number. Das abschließende ACK bestätigt die Serversequenz. Erst dann besteht auf beiden Seiten ein abgestimmter Verbindungszustand.

TCP ist vollduplex: Beide Seiten können unabhängig Daten senden. Beim geordneten Schließen beendet FIN jeweils nur eine Senderichtung. ACK und FIN können in getrennten oder kombinierten Segmenten auftreten. RST beendet eine Verbindung dagegen abrupt. Der Zustand TIME_WAIT verhindert am aktiv schließenden Endpunkt, dass verspätete Segmente sofort einer neuen Verbindung mit denselben Endpunkten zugeordnet werden.

Sequenznummern, ACK und Retransmission

TCP nummeriert nicht einfach Pakete, sondern Bytes im Datenstrom. Die Bestätigungsnummer nennt das nächste erwartete Byte. Dadurch bestätigt ein kumulatives ACK alle davor lückenlos empfangenen Bytes. Ein Empfänger darf ACKs verzögern oder mehrere Segmente gemeinsam bestätigen; deshalb folgt nicht zwingend auf jedes Segment sofort ein eigenes ACK.

Fehlende Daten können nach Ablauf eines berechneten Retransmission Timeout erneut gesendet werden. Mehrere gleiche ACKs können eine Lücke früher sichtbar machen und eine schnelle Wiederholung auslösen. Mit Selective Acknowledgment kann der Empfänger zusätzlich bereits vorhandene Bereiche oberhalb der Lücke melden.

Die TCP-Prüfsumme erkennt viele Übertragungsfehler, ist aber weder Verschlüsselung noch kryptografischer Manipulationsschutz. Vertraulichkeit, Authentizität und ein stärkerer Integritätsschutz werden beispielsweise durch TLS oberhalb von TCP ergänzt.

Flusssteuerung und Überlastkontrolle sind nicht dasselbe

Die Flusssteuerung richtet sich nach dem Empfänger. Er meldet mit dem Receive Window, kurz rwnd, wie viele weitere Bytes er aufnehmen kann. Ein Fenster von null stoppt neue Nutzdaten vorübergehend; Window-Probes helfen zu erkennen, wann wieder Platz vorhanden ist.

Die Überlastkontrolle richtet sich nach dem Netzpfad. Der Sender verwaltet dafür ein Congestion Window, kurz cwnd, und reagiert abhängig vom eingesetzten Algorithmus auf ACK-Verhalten, Verlust, Laufzeit und gegebenenfalls ECN. Die praktisch sendbare Datenmenge wird unter anderem durch den kleineren Wert aus rwnd und cwnd begrenzt. Die ältere Pauschalaussage, bei jedem Verlust werde die Zahl aller Pakete einfach halbiert, ist deshalb zu ungenau.

Sockets verbinden Anwendung und Transport

Ein Socket ist eine vom Betriebssystem bereitgestellte Kommunikationsschnittstelle. Anwendungen erzeugen einen Socket, binden ihn bei Bedarf an eine lokale Adresse und einen Port und lesen oder schreiben darüber Daten. Server binden typischerweise einen bekannten Port, lauschen und nehmen Verbindungen an; Clients verwenden häufig einen dynamisch vergebenen Quellport.

Diese Rollen sind ein häufiges Anwendungsmuster, aber keine allgemeine technische Pflicht jedes Sockets. Peer-to-Peer-Anwendungen können beide Rollen übernehmen. Stream-Sockets werden üblicherweise mit TCP verwendet, Datagram-Sockets mit UDP. Eine TCP-Verbindung wird durch Transportprotokoll, Quell-IP, Quellport, Ziel-IP und Zielport unterschieden.

UDP-Header und Prüfsumme

Der UDP-Header enthält Quellport, Zielport, Länge und Prüfsumme. Das Längenfeld umfasst Header und Nutzdaten. Der kleinste Wert ist deshalb 8 Byte. Das theoretische Maximum eines gewöhnlichen UDP-Datagramms wird durch das 16-Bit-Längenfeld bestimmt; praktisch begrenzen Pfad-MTU, IP-Header und Anwendungsprotokoll die sinnvolle Größe.

Bei IPv4 darf eine UDP-Prüfsumme als null übertragen werden und ist dann deaktiviert. Bei gewöhnlichem UDP über IPv6 ist die Prüfsumme erforderlich. Sie deckt UDP-Header, Nutzdaten und einen IP-Pseudoheader ab, erkennt aber keinen Verlust eines vollständigen Datagramms und erzeugt keine Wiederholung.

MTU, MSS und Fragmentierung

Die häufige Ethernet-MTU von 1500 Byte beschreibt die maximale Größe des IP-Pakets im Ethernet-Frame, nicht die maximale Größe eines TCP-Segments. Ohne IP- oder TCP-Optionen bleiben bei IPv4 typischerweise 1460 Byte und bei IPv6 1440 Byte TCP-Nutzdaten. Die Maximum Segment Size, kurz MSS, bezieht sich auf die TCP-Nutzdaten und wird beim Verbindungsaufbau angekündigt.

UDP besitzt keine MSS-Aushandlung. Eine Anwendung sollte Datagramme an die zulässige Größe des Pfades anpassen. Zu große IP-Pakete können bei IPv4 fragmentiert werden; bei IPv6 fragmentieren Router nicht. Fragmentverlust macht das gesamte ursprüngliche Datagramm unbrauchbar. Die historische 512-Byte-Grenze betrifft klassische DNS-Antworten ohne EDNS und ist keine allgemeine UDP-Grenze.

Welches Protokoll passt zur Anwendung?

TCP eignet sich, wenn ein geordneter zuverlässiger Bytestrom gewünscht ist und die Anwendung diese Funktionen nicht selbst implementieren soll. UDP eignet sich für kompakte Anfrage-Antwort-Protokolle, Broadcast oder Multicast und Anwendungen, die Aktualität höher bewerten als die Wiederholung veralteter Daten. Echtzeitverkehr kann Paketverluste tolerieren, benötigt aber weiterhin eine kontrollierte Senderate.

QUIC zeigt, dass UDP auch als Träger für ein komplexes Transportprotokoll dienen kann. QUIC ergänzt unter anderem sichere Verbindungen, zuverlässige Streams, Verlustbehandlung und Überlastkontrolle und bildet die Transportbasis von HTTP/3. Die Aussage „UDP ist immer schneller“ ist daher fachlich nicht haltbar; entscheidend sind Aufbau, Datenmenge, Netzbedingungen und Protokollfunktionen der gesamten Anwendung.

TCP und UDP bei der Fehlersuche