Sie sind hier:  AIB V3 > Netzwerke > TCP/IP > TCP  
TCP - Transmission Control Protocol

Welches übergeordnete Protokoll der Transportschicht das Datenpaket erhält, steht im 'Protokoll'-Feld eines jeden IP-Paketes. Jedes Protokoll der Transportschicht bekommt eine eindeutige Identifikationsnummer zugewiesen, anhand der die IP-Schicht entscheiden kann, wie weiter mit dem Paket zu verfahren ist. Eines der wichtigsten Protokolle der Transportschicht ist TCP.

Die Aufgabe von TCP ist es, die oben geschilderten Defizite von IP zu verbergen. Für den TCP-Benutzer soll es nicht mehr sichtbar sein, daß die darunterliegenden Protokollschichten Datenpakete versenden, sondern es soll der Benutzer mit einem Byte-Strom wie bei einer normalen Datei (oder einem Terminal) arbeiten können. TCP garantiert vor allen Dingen den korrekten Transport der Daten - jedes Paket kommt nur einmal, fehlerfrei und in der richtigen Reihenfolge an. Zusätzlich können bei TCP mehrere Programme die Verbindung zwischen zwei Rechnern quasi-gleichzeitig nutzen. TCP teilt die Verbindung in viele virtuelle Kanäle ("Ports") auf, die zeitmultiplex mit Daten versorgt werden. Nur so ist es möglich, daß beispielsweise mehrere Benutzer eines Rechners zur selben Zeit das Netz in Anspruch nehmen können oder daß man mit einer einzigen Wählverbindung zum Provider gleichzeitig E-Mail empfangen und Dateien per FTP übertragen kann.

Dieses Protokoll implementiert also einen verbindungsorientierten, sicheren Transportdienst als Schicht-4-Protokoll. Die Sicherheit wird durch positive Rückmeldungen (acknowledgements) und Wiederholung fehlerhafter Blöcke erreicht. Fast alle Standardanwendungen vieler Betriebssysteme nutzen TCP und das darunterliegende IP als Transportprotokoll, weshalb man die gesamte Protokollfamilie allgemein unter 'TCP/IP' zusammenfaßt. TCP läßt sich in lokalen und weltweiten Netzen einsetzen, da IP und die darunterliegenden Schichten mit den unterschiedlichsten Netzwerk- und Übertragungssystemen arbeiten können (Ethernet, Funk, serielle Leitungen, ...). Zur Realisierung der Flußkontrolle wird ein Fenstermechanismus (sliding windows) verwendet (variable Fenstergröße). TCP-Verbindungen sind vollduplex. Wie bei allen verbindungsorientierten Diensten muß zunächst eine virtuelle Verbindung aufgebaut und bei Beendigung der Kommunikation wieder abgebaut werden. "Verbindungsaufbau" bedeutet hier eine Vereinbarung beider Stationen über die Modalitäten der Übertragung (z. B. Fenstergröße, Akzeptieren eines bestimmten Dienstes, usw.). Ausgangs- und Endpunkte einer virtuellen Verbindung werden wie bei UDP durch Ports identifiziert. Allgemein verfügbare Dienste werden über 'well known' Ports (--> feste zugeordnete Portnummer) erreichbar. Andere Portnummern werden beim Verbindungsaufbau vereinbart.

Damit die ständige Bestätigung jedes Datensegments den Transport nicht über Gebühr hemmt, werden zwei Tricks verwendet. Zum einen kann die Empfangsbetätigung einem Segment in Gegenrichtung mitgegeben werden - das spart ein separates Quittungssegment. Zweitens muß nicht jedes Byte sofort bestätigt werden, sondern es gibt ein sogenanntes 'Fenster'. Die Fenstergröße gibt an, wieviele Bytes gesendet werden dürfen, bis die Übertragung quittiert werden muß. Erfolgt keine Quittung, werden die Daten nochmals gesendet. Die empfangene Quittung enthält die Nummer des Bytess, das als nächstes vom Empfänger erwartet wird - womit auch alle vorhergehenden Bytes quittiert sind. Die Fenstergröße kann dynamisch mit der Quittung des Empfängers geändert werden. Werden die Ressourcen knapp, wird die Fenstergröße verringert. Beim Extremfall Null wird die Übertragung unterbrochen, bis der Empfänger erneut quittiert. Neben einem verläßlichen Datentransport ist so auch die Flußkontrolle gewährleistet.

Das Prinzip des Fenstermechanismus ist eigentlich ganz einfach. Wenn man das Bild betrachtet, ergibt sich folgende Sachverhalt:

  • Die Fenster größe im Beispiel beträgt drei Bytes.
  • Byte 1 wurde von der Datenquelle gesendet und vom Empfänger quittiert.
  • Die Quelle hat die Bytes 2, 3 und 4 gesendet, sie wurden aber vom Empfänger noch nicht quittiert (Quittung eventuell noch unterwegs).
  • Byte 5 wurde von der Quelle noch nicht gesendet. Er geht erst dann auf die Reise, wenn die Quittung für Byte 2 (oder höher) eingetroffen ist.

Das TCP-Paket wird oft auch als 'Segment' bezeichnet. Jedem TCP-Block ist ein Header vorangestellt, der aber wesentlich umfangreicher als die bisherigen ist:

Source Port
Identifiziert den sendenden Prozeß.
Destination Port
Identifiziert den Prozeß des Zielknotens.
Sequence Number
TCP betrachtet die zu übertragenden Daten als numerierten Bytestrom, wobei die Nummer des ersten Bytes beim Verbindungsaufbau festgelegt wird. Dieser Bytestrom wird bei der Übertragung in Blöcke (TCP-Segmente) aufgeteilt. Die 'Sequence Number' ist die Nummer des ersten Datenbytes im jeweiligen Segment (--> richtige Reihenfolge über verschiedene Verbindungen eintreffender Segmente wiederherstellbar).
Acknowledgement Number
Hiermit werden Daten von der Empfängerstation bestätigt, wobei gleichzeitig Daten in Gegenrichtung gesendet werden. Die Bestätigung wird also den Daten "aufgesattelt" (Piggyback). Die Nummer bezieht sich auf eine Sequence-Nummer der empfangenen Daten; alle Daten bis zu dieser Nummer (ausschließlich) sind damit bestätigt --> Nummer des nächsten erwarteten Bytes. Die Gültigkeit der Nummer wird durch das ACK-Feld (--> Code) bestätigt.
Data Offset
Da der Segment-Header ähnlich dem IP-Header Optionen enthalten kann, wird hier die Länge des Headers in 32-Bit-Worten angegeben.
Res.
Reserviert für spätere Nutzung
Code
Angabe der Funktion des Segments:
  • URG Urgent-Pointer (siehe unten)
  • ACK Quittungs-Segment (Acknowledgement-Nummer gültig)
  • PSH Auf Senderseite sofortiges Senden der Daten (bevor Sendepuffer gefüllt ist) und auf Empfangsseite sofortige Weitergabe an die Applikation (bevor Empfangspuffer gefüllt ist) z. B. für interaktive Programme.
  • RST Reset, Verbindung abbauen
  • SYN Das 'Sequence Number'-Feld enthält die initiale Byte-Nummer (ISN) --> Numerierung beginnt mit ISN + 1. In der Bestätigung übergibt die Zielstation ihre ISN (Verbindungsaufbau).
  • FIN Verbindung abbauen (Sender hat alle Daten gesendet), sobald der Empfänger alles korrekt empfangen hat und selbst keine Daten mehr loswerden will.
Window
Spezifiziert die Fenstergröße, die der Empfänger bereit ist anzunehmen - kann dynamisch geändert werden.
Checksum
16-Bit Längsparität über Header und Daten.
Urgent Pointer
Markierung eines Teils des Datenteils als dringend. Dieser wird unabhängig von der Reihenfolge im Datenstrom sofort an das Anwenderprogramm weitergegeben (URG-Code muß gesetzt sein). Der Wert des Urgent-Pointers markiert das letzte abzuliefernde Byte; es hat die Nummer <Sequence Number> + <Urgent Pointer>.
Options
Dieses Feld dient dem Informationsaustausch zwischen beiden Stationen auf der TCP-Ebene, z. B. die Segmentgröße (die Ihrerseits von der Größe des IP-Datagramms abhängen sollte, um den Durchsatz im Netz optimal zu gestalten).

Ablauf einer TCP-Session

Im Gegensatz zu IP ist TCP verbindungsorientiert. Das muß so sein, denn TCP-Verbindungen sollen ja für den Benutzer prinzipiell wie Dateien zu handhaben sein. Das bedeutet, eine TCP-Verbindung wird wie eine Datei geöffnet und geschlossen, und man kann ihre Position innerhalb des Datenstroms bestimmen, genau wie man bei einer Datei die Position der Lese- oder Schreibposition angeben kann. TCP sendet die Daten auch in größeren Einheiten, um den Verwaltungsaufwand durch Header- und Kontrollinformationen klein zu halten. Im Gegensatz zu den IP-Paketen bezeichnet man die Einheiten der Transportschicht als "Segmente". Jedes gesendete TCP-Segment hat eine eindeutige Folgenummer, welche die Position seines ersten Bytes im Byte-Strom der Verbindung angibt. Anhand dieser Nummer kann die Reihenfolge der Segmente korrigiert und doppelt angekommene Segmente können aussortiert werden. Da die Länge des Segments aus dem IP-Header bekannt ist, können auch Lücken im Datenstrom entdeckt werden, und der Empfänger kann verlorengegangene Segmente neu anfordern.

Beim Öffnen einer TCP-Verbindung tauschen beide Kommunikationspartner Kontrollinformationen aus, die sicherstellen, daß der jeweilige Partner existiert und Daten annehmen kann. Dazu schickt die Station A ein Segment mit der Aufforderung, die Folgenummern zu synchronisieren.
Das einleitende Paket mit gesetztem SYN-Bit ("Synchronise-" oder "Open"-Request) gibt die Anfangs-"Sequence Number" des Client bekannt. Diese Anfangs-"Sequence Number wird zufällig bestimmt. Bei allen nachfolgenden Paketen ist das ACK-Bit ("Acknowledge", "Quittung") gesetzt. Der Server antwortet mit ACK, SYN und der Client bestätigt mit ACK. Das sieht dann so aus:

Die Station B weiß jetzt, daß der Sender eine Verbindung öffnen möchte und an welcher Position im Datenstrom der Sender anfangen wird zu zählen. Sie bestätigt den Empfang der Nachricht und legt ihrerseits eine Folgenummer für Übertragungen in Gegenrichtung fest.

Station A bestätigt nun den Empfang der Folgenummer von B und beginnt dann mit der Übertragung von Daten.

Diese Art des Austausches von Kontrollinformationen, bei der jede Seite die Aktionen der Gegenseite bestätigen muß, ehe sie wirksam werden können, heißt "Dreiwege-Handshake". Auch beim Abbau einer Verbindung wird auf diese Weise sichergestellt, daß beide Seiten alle Daten korrekt und vollständig empfangen haben. Im zeitlichen Zusammenhang stellt sich eine TCP/IP-Verbindung folgendermaßen dar:

Das folgende Beispiel zeigt die Arbeitsweise des TCP/IP - Protokolls. Es wird eine Nachricht von einem Rechner im grünen Netz zu einem Rechner im orangen Netz gesendet.

Die Nachricht wird in mehrere Pakete aufgeteilt und auf der besten Route auf die Reise geschickt. Das verbindungslose IP-Protokoll sorgt zusammen mit den Routern für den Weg.
Da eine Strecke überlastet ist, werden die Pakete 3, 4 und 5 auf einer anderen Strecke weiter transportiert. Dieser Transport erfolgt zufälligerweise schneller als jener der Pakete 1 und 2.
Die Pakete wandern ihrem Bestimmungsnetz entgegen. Das erste Paket ist bereits angekommen. Paket 3 kommt vor Paket 2 am Ziel an.
Die Pakete 1, 2 und 3 sind - in falscher Reihenfolge - am Zielrechner angekommen. Auf der Strecke, auf der Pakete 4 und 5 transportiert werden, tritt eine Störung auf.
Paket 4 ist bei der Störung verloren gegangen. Paket 5 wird auf einer anderen Route zum Zielnetz geschickt (wären die Routen statisch am Router eingetragen, ginge auch Paket 5 verloren).
Alle überlebenden Pakete sind am Zielrechner angekommen. Das TCP-Protokoll setzt die Pakete wieder in der richtigen Reihenfolge zusammen und fordert das fehlende Paket 4 nochmals beim Sender an. Für den Empfänger ergibt sich ein kontinuierlicher Datenstrom.

TCP-Zustandsübergangsdiagramm

Den gesamte Lebenszyklus einer TCP-Verbindung beschreibt die folgende Grafik in einer relativ groben Darstellung.

Erklärung der Zustände:

  • LISTEN: Warten auf ein Connection Request.
  • SYN-SENT: Warten auf ein passendes Connection Request, nachdem ein SYN gesendet wurde.
  • SYN-RECEIVED: Warten auf Bestätigung des Connection Request Acknowledgement, nachdem beide Teilnehmer ein Connection Request empfangen und gesendet haben.
  • ESTABLISHED: Offene Verbindung.
  • FIN-WAIT-1: Warten auf ein Connection Termination Request des Kommunikationspartners oder auf eine Bestätigung des Connection Termination, das vorher gesendet wurde.
  • FIN-WAIT-2: Warten auf ein Connection Termination Request des Kommunikationspartners.
  • CLOSE-WAIT: Warten auf ein Connection Termination Request (CLOSE) der darüberliegenden Schicht.
  • CLOSING: Warten auf ein Connection Termination Request des Kommunikationspartners. LAST-ACK: Warten auf die Bestätigung des Connection Termination Request, das zuvor an den Kommunikationspartner gesendet wurde.

Die Hauptmerkmale von TCP

  • verbindungsorientierter Dienst
  • vollduplexfähig
  • hohe Zuverlässigkeit
  • Sicherung der Datenübertragung durch Prüfsumme und Quittierung mit Zeitüberwachung
  • Sliding Window Verfahren
  • Möglichkeit von Vorrangdaten
  • Adressierung der Ende-zu-Ende-Verbindung durch Portnummern in Verbindung mit IP-Adressen

Normalerweise stützen sich Programme auf Anwendungseben auf mehrere der Protokolle (ICMP, UDP, TCP).

Ports für jeden Dienst

Server-Prozesse lauschen bei UDP und TCP auf bestimmten Portnummern. Per Übereinkunft werden dazu Ports niedriger Nummern verwendet. Für die Standarddienste sind diese Portnummern in den RFCs festgeschrieben. Ein Port im "listen"-Modus ist gewissermaßen eine halboffene Verbindung. Nur Quell-IP und Quellport sind bekannt. Der Serverprozeß kann vom Betriebssystem dupliziert werden, so daß weitere Anfragen auf diesem Port behandelt werden können.

  • Die Portnummern werden auf dem Host-System konfiguriert und haben zwei Funktionen:
    • Allgemein verfügbare Dienste werden über 'well known' Ports (--> feste, per RFC zugeordnete Portnummer) erreichbar. Sie stehen also für ein Protokoll, das über die Nummer direkt angesprochen wird
    • oder sie werden beim Verbindungsaufbau vereinbart und einem Server-Programm zugewiesen
  • Die Portangabe ist nötig, wenn mehrere Serverprogramme auf dem adressierten Rechner laufen.
  • Die Portnummer steht im TCP-Header und 16 Bit groß. Theoretisch können also bis zu 65535 TCP-Verbindungen auf einem Rechner mit einer einzigen IP-Adresse aufgebaut werden.
  • Portnummern werden oft auch bei der Konfiguration von Internet-Clients als Parameter gefordert.
  • Die Client-Prozesse verwenden normalerweise freie Portnummern, die vom lokalen Betriebssystem zugewiesen werden (Portnummer > 1024).

Die "well known" Portnummern (0 bis 1023), die weltweit eindeutig adressiert werden müssen, werden durch die IANA (Internet Assigned Numbers Authority) vergeben. Einige Beispiele für TCP-Ports (UDP verwendet eine andere Zuordnung):

Portnummer Protokoll
20 FTP (Daten)
21 FTP (Befehle)
22 Secure Shell
23 Telnet
25 SMTP
53 DNS-Server
70 Gopher
79 Finger
80 HTTP (Proxy-Server)
110 POP3
119 NNTP
143 IMAP
194 IRC
210 WAIS
256 - 1023 UNIX-spezifische Services
540 UUCP
1024 - 49151 Registered Ports
49152 - 65535 Dynamic / Private Ports

Eine vollständige Portliste erhält man bei http://www.isi.edu/in-notes/iana/assignments/port-numbers.

IP-Adresse und Portnummer definieren einen Kommunikationsendpunkt, der in der TCP/IP-Welt "Socket" genannt wird. Die Grenze zwischen der Anwendungsschicht und der Transportschicht ist in den meisten Implementierungen zugleich die Grenze zwischen dem Betriebssystem und den Anwendungsprogrammen. Im OSI-Modell ist diese Grenze in etwa die Grenze zwischen den Schichten 4 und 5. Daher ordnet man IP meist ungefähr in die Ebene 3 und TCP ungefähr in Ebene 4 des OSI-Modells ein. Da TCP/IP jedoch älter und einfacher als das OSI-Modell ist, kann diese Einordnung nicht genau passen.

Spam-Server "Grum" abgeschaltet

Für alle die sich schon immer über zuviel Spam im Postfach geärgert haben gibt es eine gute...

TYPO3 Version 4.7 verfügbar

Die finalen Version des TYPO3 CMS Version 4.7 ist veröffentlicht worden. In TYPO3 4.7 wurde...

Schleusingen jetzt mit UTMS versorgt

In Schleusingen ab sofort mit bis zu 42,2 Megabit pro Sekunde im Internet surfen....

neuer RC TYPO3 4.7 veröffentlicht

Der neue Release-Kandidat 2 von TYPO3 4.7 wartet mit einer Vielzahl neuer Funktionen auf, außerdem...

TYPO3 4.4.12, 4.5.8 und 4.6.1 sind online

Heute wurde bekannt gegeben, dass ab sofort TYPO3 4.4.12, 4.5.8 und 4.6.1 zur Verfügung stehen. Es...

Das Hennebergische Gymnasium Schleusingen hat eine neue Website !

Nach langen Wochen der Erstellung und Redaktionsschulung ist die neue Website www.gym-schleusingen...