TCP

Kurz: Transmission Control Protocol — ein verbindungsorientiertes Transportprotokoll, das garantiert, dass Datenpakete vollständig, in der richtigen Reihenfolge und ohne Duplikate beim Empfänger ankommen.

Genauer: Vor der eigentlichen Datenübertragung baut TCP über den Three-Way-Handshake (SYN, SYN-ACK, ACK) eine Verbindung auf. Verlorene Pakete werden erkannt und erneut gesendet, was TCP zuverlässig, aber langsamer als UDP macht. Eingesetzt überall dort, wo Vollständigkeit wichtiger ist als Geschwindigkeit — z. B. bei HTTP, FTP oder E-Mail-Protokollen.

Im Detail

Verbindungsaufbau und Segmentierung

Bevor überhaupt ein Byte Nutzdaten fließt, handeln beide Seiten über den Three-Way-Handshake (SYN → SYN-ACK → ACK) Startsequenznummern aus und bestätigen, dass beide Richtungen der Verbindung tatsächlich erreichbar sind. Die zu sendenden Daten werden dabei in Segmente zerlegt, deren Größe von der “Maximum Segment Size” (MSS) begrenzt wird — typischerweise so gewählt, dass ein Segment inklusive aller Header in ein einzelnes Ethernet-Frame (1500 Byte MTU) passt, damit auf IP-Ebene keine zusätzliche Fragmentierung nötig wird. Jedes Segment bekommt eine fortlaufende Sequenznummer (gezählt in Byte, nicht in Segmenten), sodass der Empfänger sie in der richtigen Reihenfolge zusammensetzen kann, selbst wenn sie über unterschiedliche Netzwerkpfade in falscher Reihenfolge ankommen.

Zuverlässigkeit: ACKs, Neuübertragung, Prüfsummen

Jedes empfangene Segment wird mit einem ACK quittiert, das die nächste erwartete Sequenznummer nennt (“kumulatives ACK”) — bleibt eine Bestätigung innerhalb eines dynamisch berechneten Timeouts (Retransmission Timeout, RTO) aus, sendet TCP das entsprechende Segment automatisch erneut. Eine Prüfsumme im Header erkennt auf dem Weg beschädigte Daten; ein Segment mit falscher Prüfsumme wird stillschweigend verworfen und muss ebenfalls neu angefordert werden. Moderne TCP-Implementierungen nutzen zusätzlich “Selective ACK” (SACK), bei dem der Empfänger dem Sender mitteilen kann, welche einzelnen Lücken in der Sequenz fehlen, statt bei jedem Verlust den kompletten nachfolgenden Datenstrom neu zu übertragen.

Flow Control und Congestion Control

Zwei unterschiedliche Mechanismen regeln, wie viele Daten “unterwegs” sein dürfen. Flow Control (“Empfänger-Bremse”) verhindert, dass ein schneller Sender einen langsameren Empfänger mit mehr Daten überflutet, als dessen Empfangspuffer verarbeiten kann — der Empfänger meldet dafür laufend sein verfügbares “Receive Window”. Congestion Control (“Netzwerk-Bremse”) ist unabhängig davon: TCP startet vorsichtig mit einer kleinen Datenmenge (“Slow Start”) und steigert die Sendemenge schrittweise, bis ein Paketverlust auf eine überlastete Verbindung hindeutet — dann wird die Sendemenge drastisch reduziert und der Anstieg beginnt erneut, langsamer. Dieses Wechselspiel aus Beschleunigen und Bremsen sorgt dafür, dass viele gleichzeitige TCP-Verbindungen sich eine begrenzte Leitung fair teilen, statt sie einzeln zu überfluten.

Verbindungsabbau

Anders als der dreiseitige Aufbau läuft der geordnete Abbau typischerweise über einen “Four-Way Handshake” (FIN/ACK von beiden Seiten unabhängig, da eine TCP-Verbindung aus zwei getrennten Datenrichtungen besteht, die jede für sich beendet werden muss). Eine Seite kann so bereits “fertig mit Senden” sein, während sie noch Daten von der anderen Seite empfängt (Half-Close). Ein abrupter Abbruch per RST-Flag umgeht diesen geordneten Ablauf komplett und wird meist bei Fehlern eingesetzt, etwa wenn ein Port gar nicht erst geöffnet ist.

Abwägung gegenüber UDP

Diese Zuverlässigkeit hat ihren Preis: Der Handshake kostet vor der eigentlichen Datenübertragung bereits eine komplette Hin-und-Her-Runde (Latenz), und jede Bestätigung/Neuübertragung braucht zusätzliche Zeit. Für Anwendungen, bei denen ein einzelnes verlorenes Paket verschmerzbar ist, aber Aktualität zählt (Video-Streaming, VoIP, Online-Gaming), ist deshalb oft UDP die bessere Wahl — TCP optimiert konsequent auf Vollständigkeit, UDP auf Geschwindigkeit. Praktisch zeigt sich dieser Unterschied z. B. beim traceroute-Befehl, der standardmäßig UDP-Pakete verschickt, weil ein Verlust dort egal ist, während HTTP, FTP und E-Mail-Protokolle konsequent auf TCP setzen, weil eine unvollständige Webseite oder Datei nutzlos wäre.

Siehe auch: UDP, Three-Way-Handshake, SYN