TCP (Trans­mis­si­on Control Protocol) – das Trans­port­pro­to­koll im Porträt

Wollen wir uns mit dem Internet verbinden, stellen wir mit einigen, wenigen Hand­grif­fen eine Ver­bin­dung zwischen Router und Computer bzw. Mo­bil­ge­rät her – wahlweise per Kabel oder draht­lo­sem Log-in. Weitere Schritte sind nicht er­for­der­lich, denn die Anmeldung im Netzwerk funk­tio­niert ebenso au­to­ma­tisch wie der Bezug einer in­di­vi­du­el­len In­ter­net­adres­se, die Sie für das Empfangen und Senden von Daten benötigen. Möglich macht dies eine Sammlung ver­schie­de­ner Pro­to­kol­le, die auch als In­ter­net­pro­to­koll­fa­mi­lie be­zeich­net wird. Eines der ältesten und wich­tigs­ten Mit­glie­der ist dabei das Trans­mis­si­on Control Protocol (TCP). Es legt fest, wie die im Netzwerk vereinten Geräte Daten aus­zu­tau­schen haben.

Das Trans­mis­si­on Control Protocol, kurz TCP oder TCP-Protokoll, ist eine stan­dar­di­sier­te Ver­ein­ba­rung zur Da­ten­über­tra­gung zwischen ver­schie­de­nen Teil­neh­mern eines Com­pu­ter­netz­werks. Die Ge­schich­te dieses Pro­to­kolls geht bis in das Jahr 1973 zurück, in dem die beiden In­for­ma­ti­ker Robert E. Kahn und Vinton G. Cerf im Rahmen ihrer For­schungs­ar­beit bereits eine erste Version ver­öf­fent­lich­ten. Bis zur Stan­dar­di­sie­rung von TCP im RFC 793 sollten al­ler­dings noch acht weitere Jahre vergehen. Seitdem gab es eine Reihe von Ver­bes­se­run­gen und Er­wei­te­run­gen, wobei das Protokoll im Kern bis heute un­ver­än­dert geblieben ist. Die aktuelle Version, die im RFC 7323 fest­ge­hal­ten wurde, stammt aus dem Jahr 2014.

Der heutige Ent­wick­lungs­sta­tus des TCP-Pro­to­kolls erlaubt es zwei End­punk­ten in einem ge­mein­sa­men Com­pu­ter­netz, eine Ver­bin­dung auf­zu­bau­en, die eine beid­sei­ti­ge Da­ten­über­tra­gung erlaubt. Dabei werden jegliche Da­ten­ver­lus­te erkannt und au­to­ma­tisch behoben, weshalb man es auch als zu­ver­läs­si­ges Protokoll be­zeich­net. In der In­ter­net­pro­to­koll­fa­mi­lie bildet TCP gemeinsam mit UDP und SCTP die Gruppe der Trans­port­pro­to­kol­le, die nach dem OSI-Modell in der Netzwerk-Ar­chi­tek­tur auf der Trans­port­schicht ein­ge­stuft werden. Da das TCP-Protokoll in fast allen Fällen auf dem Internet Protocol (IP) aufsetzt und diese Ver­bin­dung die Basis für den Großteil aller öf­fent­li­chen und lokalen Netzwerke und Netz­werk­diens­te bildet, ist häufig auch vom TCP/IP-Pro­to­koll­sta­pel die Rede, wenn im ei­gent­li­chen Sinne die In­ter­net­pro­to­koll­fa­mi­lie gemeint ist.

TCP lässt die Über­tra­gung von In­for­ma­tio­nen in beide Rich­tun­gen zu. Com­pu­ter­sys­te­me, die über TCP kom­mu­ni­zie­ren, können also wie bei einem Te­le­fon­ge­spräch zur gleichen Zeit Daten senden und empfangen. Die grund­le­gen­den Über­tra­gungs­ein­hei­ten, auf die das Protokoll dabei zu­rück­greift, sind Segmente (Pakete), die zu­sätz­lich zu den Nutzdaten auch Steue­rungs­in­for­ma­tio­nen enthalten können und auf eine Größe von 1.500 Byte be­schränkt sind. Der Auf- und Abbau der Ver­bin­dun­gen, die sich als Ende-zu-Ende-Ver­bin­dun­gen einstufen lassen, sowie die Da­ten­über­tra­gung selbst werden von TCP-Software im Netz-Pro­to­koll­sta­pel des je­wei­li­gen Be­triebs­sys­tems über­nom­men.

Die TCP-Software wird von den ver­schie­de­nen Netz­werk­an­wen­dun­gen wie Web­brow­sern oder Servern über spe­zi­fi­sche Schnitt­stel­len an­ge­steu­ert, wobei jede Ver­bin­dung immer durch zwei klar de­fi­nier­te Endpunkte (Client und Server) iden­ti­fi­ziert werden muss. Welche Seite die Client- und welche die Ser­ver­rol­le übernimmt, spielt dabei keine Rolle – wichtig ist, dass die TCP-Software pro Endpunkt ein ein­deu­ti­ges, ge­ord­ne­tes Paar aus IP-Adresse und Port (auch als „2-Tupel“ oder „Socket“ be­zeich­net) zur Verfügung stehen hat.

Die Vor­aus­set­zun­gen für den Aufbau einer gültigen TCP-Ver­bin­dung: Beide in­vol­vier­ten Endpunkte müssen bereits über eine ein­deu­ti­ge IP-Adresse (IPv4 oder IPv6) verfügen und den ge­wünsch­ten Port für die Da­ten­über­tra­gung de­kla­riert und frei­ge­ge­ben haben. Während erstere als Iden­ti­fi­ka­ti­ons­merk­mal fungiert, ist letzterer für die Zuordnung der Ver­bin­dun­gen zu den konkreten Client- und Ser­ver­an­wen­dun­gen durch das Be­triebs­sys­tem relevant.

Da der Ver­bin­dungs­auf­bau via Trans­mis­si­on Control Protocol also insgesamt drei Schritte umfasst, hat sich für diesen Prozess der Name „Drei-Wege-Handshake“ etabliert.

Für die Partei, die das letzte ACK-Segment gesendet hat (in unserem Fall: der Client), ist die Ver­bin­dung al­ler­dings noch nicht sofort beendet. Da es keine Garantie dafür gibt, dass das zuletzt ge­schick­te Paket auch tat­säch­lich an­ge­kom­men ist, verweilt der jeweilige Kom­mu­ni­ka­ti­ons­part­ner zunächst in einem War­te­mo­dus (auch „Time-Wait-Zustand“), bis die maximalen Lauf­zei­ten des ACK- und eines eventuell neu ver­schick­ten FIN-Segments ab­ge­lau­fen sind (nach RFC 793 jeweils zwei Minuten).

Pro­to­koll­ty­pisch befinden sich die ent­schei­den­den Daten, die für den Ver­bin­dungs­au­bau und die Da­ten­über­tra­gung mit dem Trans­mis­si­on Control Protocol benötigt werden, im Header eines TCP-Pakets. Diese Kopfdaten (auch Steu­er­in­for­ma­tio­nen) stehen der zu über­tra­gen­den Nutzlast (Payload) voran und haben ty­pi­scher­wei­se eine Größe von 20 Byte (160 Bit), gefolgt von bis zu 40 Byte (320 Bit) Zu­satz­in­for­ma­tio­nen, die optional sind und nicht in allen Paketen Ver­wen­dung finden.

Die einzelnen Kom­po­nen­ten bzw. Felder der Kopfzeile des TCP-Pro­to­kolls haben dabei folgende Bedeutung:

Quell-Port (16 Bit): Gibt die Port­num­mer des Senders an.

Ziel-Port (16 Bit): Gibt die Port­num­mer des Emp­fän­gers an.

Se­quenz­num­mer (32 Bit): Die Se­quenz­num­mer gibt wahlweise das erste Byte der an­ge­häng­ten Nutzdaten an oder wird im Rahmen des Ver­bin­dungs­auf­baus bzw. -abbaus mit­ge­schickt. Sie dient glei­cher­ma­ßen der Va­li­die­rung und Sor­tie­rung (im Anschluss an die Über­tra­gung) der Segmente.

Be­stä­ti­gungs­num­mer (32 Bit): In diesem Feld wird die Be­stä­ti­gungs­num­mer angegeben, die der Absender als nächstes erwartet. Vor­aus­set­zung für die Gül­tig­keit ist ein gesetztes ACK-Flag (im Feld „Flags“).

Offset (4 Bit): Das Feld „Offset“ weist die Länge des TCP-Headers in 32-Bit-Blöcken aus, um den Start­punkt der Nutzdaten her­vor­zu­he­ben. Dieser ist aufgrund des variablen Op­ti­ons­felds von Segment zu Segment ver­schie­den.

Re­ser­viert (6 Bit): RFC 793 ent­spre­chend für künftige Nutzung re­ser­viert, bis dato nicht verwendet. Dieses Feld muss immer den Wert „0“ haben.

Flags (6 Bit): Über die sechs möglichen Einzel-Bits im Flags-Feld lassen sich ver­schie­de­ne TCP-Aktionen ak­ti­vie­ren, um die Kom­mu­ni­ka­ti­on und Da­ten­ver­ar­bei­tung zu or­ga­ni­sie­ren. Bei den Flags, die hierfür entweder gesetzt oder nicht gesetzt werden, handelt es sich um folgende:

• URG: Das „Urgent“-Flag (dt. „dringend“) si­gna­li­siert der TCP-Anwendung, dass die Nutzdaten bis zum gesetzten Urgent-Pointer (s. u.) sofort zu ver­ar­bei­ten sind.
• ACK: In Kom­bi­na­ti­on mit der Be­stä­ti­gungs­num­mer hat das ACK-Flag die Funktion, den Empfang von TCP-Paketen zu quit­tie­ren. Ist das Flag nicht gesetzt, ist au­to­ma­tisch auch die Be­stä­ti­gungs­num­mer ungültig.
• PSH: Das „Push“-Flag sorgt dafür, dass ein TCP-Segment sofort be­reit­ge­stellt wird, ohne zunächst im Puffer von Sender und Empfänger zu landen.
• RST: Ist bei der Über­tra­gung ein Fehler auf­ge­tre­ten, lässt sich die Ver­wen­dung durch ein TCP-Paket mit gesetztem RST-Flag („Reset“) zu­rück­set­zen.
• SYN: Nach­rich­ten mit gesetztem SYN-Flag stellen den ersten Schritt des Drei-Wege-Hand­shakes dar – in­iti­ie­ren also den Ver­bin­dungs­auf­bau.
• FIN: Das „Finish“-Flag si­gna­li­siert dem Gegenüber, dass ein Kom­mu­ni­ka­ti­ons­part­ner die Über­tra­gung beendet.

Fens­ter­grö­ße (16 Bit): In diesem Feld wird dem Kom­mu­ni­ka­ti­ons­part­ner die Anzahl an Bytes über­mit­telt, die der Sender bereit ist zu empfangen.

Prüfsumme (16 Bit): Das Trans­mis­si­on Control Protocol kann Über­tra­gungs­feh­ler zu­ver­läs­sig erkennen. Hierfür wird die Prüfsumme her­an­ge­zo­gen, die aus dem Header, den Nutzdaten und dem so­ge­nann­ten Pseudo-Header berechnet wird.

Urgent-Pointer (16 Bit): Der Urgent-Pointer („Dringend“-Anzeiger) gibt die Position des ersten Bytes nach den dringlich zu be­han­deln­den Nutzdaten an. Folglich ist dieses Feld nur gültig und relevant, wenn das URG-Flag gesetzt ist.

Optionen (0–320 Bit): Sollen TCP-Funk­tio­nen be­reit­ge­stellt werden, die nicht in den ge­ne­rel­len Header gehören, geschieht dies über das Op­ti­ons­feld – ein mögliches Beispiel ist die De­fi­ni­ti­on der maximalen Seg­ment­grö­ße. Die Optionen müssen immer eine Länge des Viel­fa­chen von 32 Bit haben, an­dern­falls ist die Auf­fül­lung mit Null-Bits (Padding) er­for­der­lich.

Noch bevor die ersten Daten über­tra­gen werden, einigen sich Sender und Empfänger ty­pi­scher­wei­se zunächst auf die maximale Größe der zu ver­sen­den­den TCP-Segmente (Maximum Segment Size – MSS). Stan­dard­mä­ßig sind dabei bis zu 1.500 Byte pro Segment möglich, wobei min­des­tens 20 Byte für den TCP-Header und weitere 20 Byte für den IP-Header ein­zu­pla­nen sind, sodass 1.460 Byte für Nutzdaten üb­rig­blei­ben. Ist eine in­di­vi­du­el­le Größe gewünscht, muss dies wie oben be­schrie­ben über das Op­ti­ons­feld spe­zi­fi­ziert werden, wodurch weitere Abstriche für den Nutz­da­ten­teil zu machen sind.

Rechnet man mit der maximalen Seg­ment­grö­ße abzüglich der Header, bedeutet das also, dass ein TCP-Paket lediglich Daten mit einer Größe von 1,46 Kilobyte bzw. 0,00146 Megabyte über­tra­gen kann. Damit nun Web­in­hal­te wie Bilder, die auch mal mehrere Hunderte Kilobyte groß sind, über das TCP-Protokoll aus­ge­tauscht werden können, kommt die Seg­men­tie­rung zum Einsatz, bei der die An­wen­dungs­da­ten vor dem Transport in mehrere Da­ten­blö­cke auf­ge­teilt, num­me­riert und dann in zu­fäl­li­ger Abfolge versendet werden. Da der Empfänger den Erhalt jedes einzelnen Segments quit­tie­ren muss und die tat­säch­li­che Rei­hen­fol­ge anhand der Se­quenz­num­mern re­kon­stru­ie­ren kann, kann er die er­hal­te­nen Nutzdaten im Anschluss an die TCP-Über­tra­gung pro­blem­los und voll­stän­dig wieder zu­sam­men­set­zen.

Rund ein halbes Jahr­hun­dert lang hat das TCP-Protokoll die Ge­schich­te und Ent­wick­lung von Com­pu­ter­netz­wer­ken bereits geprägt. Das liegt ei­ner­seits an der guten Kom­bi­nier­bar­keit mit dem ebenfalls ge­schichts­träch­ti­gen In­ter­net­pro­to­koll (IP), an­de­rer­seits an den vor­wie­gend vor­teil­haf­ten Ei­gen­schaf­ten, durch die sich TCP von Al­ter­na­ti­ven wie UDP und SCTP abhebt. Die wich­tigs­ten Merkmale lassen sich dabei wie folgt zu­sam­men­fas­sen:

• TCP ist ver­bin­dungs­ori­en­tiert und er­mög­licht eine wech­sel­sei­ti­ge Kom­mu­ni­ka­ti­on zwischen zwei End­punk­ten nach dem so­ge­nann­ten Drei-Wege-Handshake.
• TCP ist zu­ver­läs­sig, denn das Protokoll stellt sicher, dass alle Daten voll­stän­dig über­tra­gen werden und vom Empfänger in der richtigen Rei­hen­fol­ge zu­sam­men­ge­setzt werden können.
• TCP sieht den Versand der Daten in einzelnen Segmenten vor, die eine maximale Größe von 1.500 Bytes (inklusive Header) haben können.
• TCP wird – im OSI-Modell – auf der Trans­port­schicht (Layer 4) ein­ge­stuft.
• TCP setzt in den meisten Fällen auf dem In­ter­net­pro­to­koll (IP) auf, weshalb häufig auch vom TCP/IP-Pro­to­koll­sta­pel ge­spro­chen wird.
• Der TCP-Header hat eine Stan­dard­grö­ße von 20 Byte – es können bis zu 40 Byte an Zu­satz­op­tio­nen hin­zu­kom­men.