RFC 793 · · Ersetzt durch RFC 9293
TCP, das Protokoll, das aus Postkarten einen Telefonanruf macht.
Der offizielle Titel lautet "Transmission Control Protocol." Worüber der RFC wirklich entscheidet: wie zwei Maschinen aus den losen, unzuverlässigen Paketen von IP eine Verbindung machen, die sich wie ein Telefonanruf anfühlt, die, auf der fast jede Webseite, jede E-Mail und jedes Login klammheimlich reisen.
Geschrieben von Noel Lang · IT-Trainer
Kurzfassung
RFC 793 ist die ursprüngliche Spezifikation von TCP, dem Protokoll, das aus den unzuverlässigen Paketen von IP eine zuverlässige, geordnete Verbindung macht. Es nummeriert jedes Byte, bestätigt, was ankommt, und sendet neu, was fehlt, und es definiert den Drei-Wege-Handshake (SYN, SYN-ACK, ACK), der eine Verbindung öffnet. 1981 geschrieben, wurde es 2022 durch RFC 9293 ersetzt, den Text, den man heute zitiert. Das Protokoll auf dem Draht hat sich nie geändert: dein Browser spricht noch immer 793er-TCP.
Welches Problem er löst
RFC 791 gibt dir Postkarten. Jedes IP-Paket wird für sich allein ins Netz geworfen, mit einer Adresse vorn und ohne Versprechen: manche kommen in falscher Reihenfolge an, manche doppelt, manche gehen auf dem Postweg verloren und werden nie wieder erwähnt. Das ist wunderbar für das Netz, das einfach und schnell bleibt, und schrecklich für fast jedes Programm, das am einen Ende einen Strom von Bytes schreiben und am anderen genau dieselben Bytes in genau derselben Reihenfolge lesen will.
TCP ist die Schicht, die das leistet, mit nichts als eben diesen unzuverlässigen Postkarten. Es nummeriert jedes gesendete Byte, wartet auf die Bestätigung der Gegenseite, was angekommen ist, und sendet alles neu, was fehlt. Aus einem Stapel ungeordneter Postkarten rekonstruiert es ein sauberes, durchgehendes Gespräch. IP stellt Pakete zu. TCP stellt ein Versprechen zu.
Die Telefonanruf-Analogie
Rohe IP-Pakete zu senden ist wie Postkarten zu verschicken. Du schreibst eine, wirfst sie in den Kasten und hoffst. Keine Bestätigung, keine Reihenfolge, und geht eine verloren, wirst du nie erfahren welche.
Eine TCP-Verbindung ist ein Telefonanruf. Zuerst klingelt es: eine Seite wählt, die andere hebt ab, und beide vergewissern sich, dass sie einander hören, bevor jemand etwas Wichtiges sagt. Dieses Eröffnungsritual ist der Drei-Wege-Handshake. Steht der Anruf, kommen die Worte in der Reihenfolge an, in der du sie sprichst, und knistert die Leitung, sagst du “Entschuldigung, nochmal?” und der Satz wird wiederholt, bis er ankommt. Bist du fertig, sagst du auf Wiederhören, statt den Hörer einfach fallen zu lassen, damit nichts Halbgesagtes verloren geht. Jedes dieser Verhalten ist etwas, das RFC 793 oben auf die Postkarten von IP gesetzt hat.
Die Analogie aus RFC 1918 setzt sich hier fort. Dort war eine Adresse das Gebäude und ein Port das Klingelschild an der Tür. TCP ist das, was diese Klingelschilder tatsächlich benutzt: eine Verbindung wird durch vier Dinge identifiziert, deine Adresse und dein Port plus ihre Adresse und ihr Port. Genau so hält ein Laptop zwanzig Browser-Tabs, ein Mailprogramm und eine ssh-Sitzung auf derselben Adresse auseinander, ohne durcheinanderzubringen, wessen Bytes wessen sind. Die Adresse bringt das Paket zum Gebäude, der Port zum richtigen Gespräch darin.
Was TCP garantiert und was nicht
Das ist das am gründlichsten missverstandene an TCP. Es gibt genau zwei Versprechen und verweigert pointiert zwei andere:
-
Reihenfolge garantiert
Ja. Jedes Byte ist nummeriert. Kommt Paket 5 vor Paket 4 an, hält TCP es zurück und übergibt deinem Programm die Bytes in der Reihenfolge, in der du sie gesendet hast. Das Durcheinander auf dem Draht bekommst du nie zu sehen.
-
Vollständigkeit garantiert
Ja. Der Empfänger bestätigt, was angekommen ist. Alles Unbestätigte wird erneut gesendet, bis es landet. Was du am einen Ende herausliest, ist genau der Byte-Strom, der am anderen hineinging, keine Lücken, keine Doubletten.
-
Latenz nicht garantiert
Nein. TCP verspricht, dass die Bytes ankommen, nie wann. Auf einer schlechten Verbindung wartet und sendet es fröhlich sekundenlang neu. Deshalb ruckelt ein Videoanruf über TCP: du willst lieber ein zu spätes Bild verwerfen, als darauf zu warten.
-
Sicherheit nicht garantiert
Nein. Die Bytes reisen im Klartext. Vertraulichkeit ist die Aufgabe von TLS eine Schicht höher. TCP sorgt dafür, dass deine Nachricht heil ankommt, nicht dafür, dass niemand sonst sie lesen kann.
Reihenfolge und Vollständigkeit: ja. Timing und Geheimhaltung: nicht TCPs Sache. Die letzten beiden gehören deiner Anwendung und TLS.
Der Drei-Wege-Handshake
Bevor ein einziges Byte deiner Anfrage fließt, tauschen die beiden Maschinen drei Pakete aus, um sich zu vergewissern, dass beide da sind, und um Start-Sequenznummern zu wählen. Das ist es, was “eine Verbindung öffnen” wirklich bedeutet, und der Grund, warum es einen Roundtrip kostet.
Was der RFC wirklich sagt
Das Original von 1981 hat rund 85 Seiten, und Abschnitt 3 ist sein ganzes Herzstück. Die Landkarte, falls du an die Quelle willst:
| Abschnitt | In einfachen Worten |
|---|---|
| 1 · Einleitung | Warum überhaupt eine zuverlässige Schicht nötig ist: IP verliert, verdoppelt und vertauscht Pakete, Anwendungen wollen stattdessen einen sauberen Strom. |
| 2 · Philosophie | Die Entwurfsziele: Zuverlässigkeit, Flusssteuerung, Multiplexing über Ports und Verbindungen. Das Denkmodell für alles darunter. |
| 3.1 · Header-Format | Das berühmte Diagramm: Quell- und Zielport, Sequenz- und Bestätigungsnummer, die Flag-Bits (SYN, ACK, FIN, RST) und das Fenster. |
| 3.4 · Verbindungsaufbau | Der Drei-Wege-Handshake, Paket für Paket ausbuchstabiert. Das ist der Teil, den alle zitieren. |
| 3.5 · Verbindungsabbau | Der höfliche Abschied: FIN und ACK von jeder Seite, damit beim Auflegen keine noch fliegenden Daten verloren gehen. |
| 3.7 · Datenübertragung | Sequenznummern, Bestätigungen, Neuübertragung und das gleitende Fenster: die Mechanik, die die Garantien real macht. |
Was Leute falsch verstehen
-
"TCP ist langsam."
Es hat Overhead, das ist nicht dasselbe wie langsam. Der Handshake kostet einen Roundtrip, bevor Daten fließen, und Neuübertragung kostet nur dann Zeit, wenn wirklich Pakete verloren gehen. Auf einer gesunden Verbindung lastet TCP die Leitung voll aus. Langsam fühlt es sich genau dann an, wenn das Netz schlecht ist, denn dann leistet es die Arbeit, dir diese Schlechtigkeit zu verbergen, und genau das ist sein ganzer Zweck.
-
"RFC 9293 ist eine neue Version von TCP."
Es ist kein neues Protokoll, es ist ein neues Dokument. RFC 9293 (2022) führt das ursprüngliche RFC 793 mit dem Stapel an Errata und Update-RFCs, der über 41 Jahre um ihn herum gewachsen ist, zu einem sauberen Text zusammen. Kein einziges Bit hat sich auf dem Draht geändert. Eine moderne Maschine und eine von 1981 würden noch denselben Handshake vollführen. 9293 ist eine bessere Landkarte desselben Geländes.
-
"TCP garantiert, dass meine Daten sicher sind."
Es garantiert Zustellung und Reihenfolge, nie Geheimhaltung. Bytes über nacktes TCP sind für jeden auf dem Weg lesbar. Das Schloss in deinem Browser kommt von TLS, einer eigenen Schicht über TCP. Zuverlässig und verschlüsselt sind zwei verschiedene Versprechen, von zwei verschiedenen Protokollen.
-
"UDP ist immer schneller und besser."
UDP startet schneller und ist leichter, aber es reicht dir rohe, verlustbehaftete, ungeordnete Pakete. Braucht deine Anwendung die Bytes vollständig und in Reihenfolge, nimmst du entweder TCP oder du baust dir die Garantien von TCP selbst oben auf UDP nach. Genau das tut QUIC. Schneller ist nur dann besser, wenn du die Versprechen von vornherein nicht gebraucht hast.
Wo dir TCP begegnet
TCP ist die stille Voreinstellung unter fast allem, was du online tust. Ein Feldführer, um es zu erkennen:
| Du siehst | Du schaust vermutlich auf |
|---|---|
| https:// in deinem Browser | HTTP/1.1 und HTTP/2 laufen beide über eine TCP-Verbindung (dann in TLS verpackt). Jede Seite, die du lädst, öffnet eine. |
| Ein ssh-Login | SSH ist eine TCP-Anwendung, Port 22. Der zuverlässige, geordnete Strom ist der Grund, warum du einen Befehl tippen und darauf vertrauen kannst, dass jedes Zeichen ankommt. |
| Eine Datenbankverbindung | PostgreSQL (5432), MySQL (3306), Redis (6379): alles langlebige TCP-Verbindungen. Ein Byte mitten in der Abfrage zu verlieren ist keine Option. |
| SYN-Flood im Security-Log | Ein Angriff, der nur das erste Handshake-Paket schickt und nie zu Ende führt, um die Tabelle der halboffenen Verbindungen zu erschöpfen. Ein direkter Missbrauch des 793er-Handshakes. |
| HTTP/3 in den Devtools | Die bewusste Ausnahme: HTTP/3 nutzt QUIC über UDP, nicht TCP. Wenn du es siehst, hat jemand entschieden, TCP hinter sich zu lassen (RFC 9000). |
| Connection timed out | TCP hat seinen Handshake oder seine Neuübertragungen versucht und aufgegeben. Die Garantie lautet zustellen-oder-Bescheid-geben, nie stiller Verlust. |
Fragen, die wirklich gestellt werden
Ist RFC 793 noch der aktuelle TCP-Standard? +
Nein. RFC 793 wurde im August 2022 durch RFC 9293 ersetzt. RFC 9293 beschreibt dasselbe Protokoll, faltet aber vier Jahrzehnte an Korrekturen und Aktualisierungen mit ein. Für den maßgeblichen Text zitierst du heute 9293, für den historischen Ursprung 793. Das TCP auf dem Draht ist unverändert, dein Browser spricht also gerade jetzt noch 793er-TCP.
Was ist der TCP-Drei-Wege-Handshake? +
Die drei Pakete, die eine Verbindung öffnen: der Client sendet SYN, der Server antwortet mit SYN-ACK, der Client bestätigt mit ACK. Danach haben sich beide Seiten auf Start-Sequenznummern geeinigt und die Verbindung steht. RFC 793 hat ihn definiert, und genau er ist der Grund, warum eine TCP-Verbindung langsamer startet als ein einzelnes UDP-Paket.
Was ist der Unterschied zwischen TCP und UDP? +
TCP (RFC 793 / 9293) garantiert, dass deine Bytes vollständig und in der richtigen Reihenfolge ankommen, um den Preis eines Handshakes und von Neuübertragungen. UDP (RFC 768) feuert jedes Paket einfach los und vergisst es, ohne Aufbau und ohne Versprechen. TCP für Korrektheit, UDP für Tempo und Echtzeit, wo ein zu spätes Paket ohnehin wertlos ist.
Garantiert TCP Sicherheit oder Verschlüsselung? +
Nein. TCP garantiert Zustellung und Reihenfolge, nichts über Vertraulichkeit. Die Bytes reisen im Klartext, solange nicht eine Schicht darüber Verschlüsselung hinzufügt. Diese Schicht ist TLS, deshalb sitzt das Schloss bei https und nicht bei TCP. Zuverlässig ist nicht dasselbe wie geheim.
Warum ist RFC 9293 keine neue Version von TCP? +
Weil er kein Bit auf dem Draht ändert. RFC 9293 ist eine Neufassung, die RFC 793 mit den Errata und Update-RFCs, die sich um ihn herum angesammelt hatten (1122, 3168, 6093, 6528 und weitere), zu einem sauberen Dokument zusammenführt. Eine bessere Landkarte desselben Geländes, kein neues Protokoll. Beide sind STD 7.
Warum heißt TCP verbindungsorientiert? +
Weil beide Maschinen gemeinsamen Zustand aufbauen (die Sequenznummern, das Fenster, die Verbindung selbst), bevor Daten fließen, und ihn am Ende wieder abbauen. IP darunter kennt so etwas nicht: jedes Paket ist unabhängig. TCP baut die Illusion einer durchgehenden Verbindung oben auf diese unabhängigen Pakete.
Verweise hierher
Andere Erklärseiten auf dieser Website, die auf diesen RFC zurückverweisen:
Wie RFC 793 zusammenhängt
Was vorher kam
-
RFC 791 IP bewegt Pakete und macht keine Versprechen: manche kommen zu spät, doppelt oder nie. TCP sitzt direkt darüber und fügt jede Garantie hinzu, mit nichts als genau diesen Best-Effort-Paketen.
Seine Gegenstücke
-
RFC 9293 · ersetzt durch
Die Konsolidierung von 2022
RFC 9293 fasst die Spec von 1981 plus Jahrzehnte an Errata und Aktualisierungen zu einem aktuellen Dokument zusammen. Dasselbe Protokoll, aktueller Text. Das ist der RFC, den man heute zitiert.
-
RFC 768 · der umgekehrte Handel
UDP, TCP ohne die Versprechen
Das Gegenstück. UDP lässt Handshake, Reihenfolge und Neuübertragung weg und gewinnt dafür Tempo und Einfachheit. TCP und UDP sind die zwei Arten, IP zu benutzen, je Anwendung gewählt.
-
RFC 9000 · die moderne Neuauflage
QUIC, dieselbe Idee neu auf UDP gebaut
HTTP/3 wollte die Zuverlässigkeit von TCP ohne dessen langsamen Start und Head-of-Line-Blocking, also setzt QUIC geordnete, zuverlässige, verschlüsselte Streams stattdessen auf UDP um. Eine bewusste Flucht aus TCP, vierzig Jahre später.
Teil eines geführten Clusters: Die Netzwerk-Grundlagen, erklärt