| orm@doc-tcpip.org | Erstellt: April 1999 - Letzte Modifikation: Februar 2005 |
Auf der IP Ebene sind zwei Zugangsprotokolle implementiert. Einen direkten Zugang zu den IP-Services stellt das User Datagram Protocol (UDP) zur Verfügung. Für einen zuverlässigen Daten-Transfer von einem Ende der Verbindung zum anderen (Ende-Ende) ist das Transmission Control Protocol (TCP) implementiert.
Dabei handelt es sich um einen simplen IP Datagramm Service, auf den TCP als übergeordneter Kontroll-Struktur aufsetzt. Das TCP sorgt für:
TCP sorgt für eine exakte Kopie der Daten. Dazu besitzt das Protokoll Mechanismen, die feststellen und korrigieren, wenn Segmente aus dem Datenstrom im Netz verschwunden sind. Auch Einflüße wie eine Veränderung der Reihenfolge, Verdoppelung oder Beschädigung der Segmente wird bemerkt und korrigiert. Teilweise ist daher eine Wiederholung der Sendung (Retransmission) nötig. Der Sender muß daher bis zur Quittierung des Empfangs alle Segmente im Speicher halten.
TCP zerlegt den Datenstrom der Applikation in einzelne Segmente. Diese werden mit einem TCP Header versehen, indem die TCP Steuer- und Kontroll-Daten Platz finden. Das ganze wird in einem IP-Frame auf das Netz gelegt. Die Größe der Sequenzen (Pakete) wird durch die physikalischen Eigenschaften des Übertragungsmediums festgelegt (Maximum Transmission Units).
TCP besitzt Mechanismen, die die Sendegeschwindigkeit an die Lastverhältnisse auf dem Netz sowie der Auslastung des Empfängers anpassen. TCP passt sich dabei dynamisch an diese Verhältnisse an.
TCP ist für die Applikation transparent. Die für die Übertragung nötige Paketstruktur sowie die Parameter der ausgehandelten Verbindung (Maximum Transmission Units, Read- and Write-Sizes etc.) sind der Applikation unbekannt. Die Applikation schreibt einen konstanten Datenstrom auf die TCP Schnittstelle bzw. liest den Datenstrom von dort ein. Im Prinzip werden nur Schwankungen in der Geschwindigkeit registriert.
TCP baut über das Netz einen Kanal zwischen zwei lokalen Prozessen auf. Der Kanal ist zuverlässig, Full Duplex und betreibt Streaming der Daten.
Unicast-Protokoll: Der Datenaustausch erfolgt zwischen genau 2 Parteien.
Connection State: TCP ist ein Client-Server orientiertes Protokoll. Beide Parteien handeln die Bedingungen und den Status der Verbindung beim Start aus und halten den Status der Verbindung über die gesamte Lebensdauer syncron (Austausch aller Status-Änderungen).
Full Duplex: Beide Partner können über den Kanal gleichzeitig Senden und Empfangen.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +---------------+---------------+---------------+---------------+ | Sequence Number | +-------------------------------+-------------------------------+ | Acknowledgement Number | +-------------------------------+-------------------------------+ |Offs. | Res. | Flags | Window | +-------------------------------+-------------------------------+ | Optionen | +---------------------------------------------------------------+
Die Felder umfassen im einzelnen:
Nummer des 1. Datenoktetts. TCP nummeriert den Datenstrom pro Oktett. Anhand dieser Nummer werden die Daten sequenziert und in der richtigen Reihenfolge gesendet. Den Mechanismen der Flußkontrolle dient die Sequenznummer zum Abgleich mit der ACK Nummer der Gegenseite. Die Daten gelten als empfangen, wenn die Gegenseite in einem Acknowledgement-Paket eine Oktet-Nummer spezifiziert. Der Sender löscht die Daten dann aus seinem Speicher. Wird eine Verbindung initialisiert, so wird die erste Sequenznummer durch einen Zufallsgenerator ausgegeben. Damit wird verhindert, daß auf dem Netz verzögerte Daten als gültig in einer neuen Verbindung erkannt werden. Eine Reihe von Hacking-Methoden (TCP Number Guessing, Connection Hijacking) beruhen auf dem erraten der Sequenznummern.
Der Empfänger antwortet in regelmäßigen Abständen mit einer Bestätigung (Acknowledge, ACK) der empfangenen Daten. Er sendet dazu die Nummer des letzten empfangenen Oktetts plus 1 - also zeigt der Empfänger dem Sender an, welches Oktett (bzw. Segment) er als nächstes erwartet. Der Sender erfährt so, wo der Empfänger im Datenstrom steht. Bestätigte Daten werden vom Sender aus seinem Speicher gelöscht und gelten als erfolgreich übertragen.
Zeigt den Start der Nutzlast des Paketes an. Es wird der Umfang des TCP Headers in 4-Oktett Stücken angezeigt (4 Oktetts == 32 Bit).
Es gibt eine Reihe Header Flags. Das sind 1 Bit Werte, die eine spezielle Eigenschaft des Paketes oder der Verbindung anzeigen:
Zeigt auf das letzte Oktett der als Dringend markierten Daten. Dieser Offset muß also zur Sequence Number addiert werden. Zusätzlich muß das Urgent Flag gesetzt sein.
Zeigt der Gegenseite den lokal und aktuell nutzbaren Speicher für die Datenübertragung. Daraus kann der Sender leicht die Datenmenge ermitteln, die gesendet werden kann.Diese Menge an Daten kann der Empfänger verarbeiten.
TCP Header Source und Destination IP des IP Headers
Ein Feld variabler Länge, das die möglichen TCP Options zeigt. Dieses Feld gehört nicht mehr zum klassischen TCP Header. Seine Existenz wird durch das Feld Data-Offset angezeigt. Alle Daten (Oktetts) zwischen dem Urgent Pointer und dem Beginn der Nutzlast werden als Optionen ausgelesen.
Eine Auswahl Performance relevanter Optionen:
Maximum Receive Segment Size Option: Wird während des TCP Handshakes (also in SYN Paketen) dem anderen Ende mitgeteilt. Zeigt die maximale Größe der Segmente im Oktetts, die der Host empfangen möchte. Diese Option ist also wichtig einmal für die Größe der Segmente, die gesendet werden sowie für die Berechnung des angesagten TCP-Fensters (Advertized TCP Windows). Diese Größe sollte durch Path MTU Discovery ermittelt werden, den nur so kann sichergestellt werden, daß die ausgehandelte Segment-Größe auch den Gegebenheiten auf dem Netzwerk-Pfad entsprechen. Es könnte Strecken geben, die technisch nicht in der Lage sind, eine bestimme Segment-Größe zu befördern. Fragmentierung wäre die Folge, was die Übertragung verlangsamt.
Window Scale Option:
Im klassischen TCP ist die maximale Größe der Window
Size (also das Fenster oder Empfangs-Fenster) auf 16
Bit beschränkt (65535 byte). Diese Option stellt einen
Faktor zur Verfügung, um den Wert der Window Size binär
rechts zu verschieben. Das entspricht einer Multiplikation
mit 2 pro Bit. Auch diese Option wird in SYN Paketen
während des TCP Handshakes ausgehandelt. Wichtig ist das
für Netze mit hohen Geschwindigkeiten und langen
Verzögerungen. Da das Netz von TCP wie ein Puffer
behandelt wird, reduziert eine kleine Window Size
die Menge an Daten (Segmenten), die im Fluß gehalten
werden können. Trotz hoher Bandbreite ist das Netz
so künstlich gedrosselt, da maximal 65535 Byte pro
Round Trip Time übertragen werden können. Die Option
erweitert diese Menge auf 2^30 Byte.
Leider gibt es keinen Prozess, der analog der
PMTU Discovery, das Produkt von Bandbreite und
Verzögerung bestimmen könnte. Die Größe des Fensters
kann also nur durch Messen angenähert werden.
Kind 3 (1 Byte) Length 3 (1 Byte) Shift Count (1 Byte)
Diese Option gehört zum RFC 1323 und kann in der Regel über das
Betriebssystem eingestellt werden; unter AIX z.B. über den
no-Parameter rfc1323.
SACK Selective Acknowledgement:
Mit dieser Option wird im TCP Handshake (SYN Pakete)
die Benutzung des SACK Mechanismus ausgehandelt.
TCP SACK-Permitted: Kind 4 (1 Byte) Length 2 (1 Byte).
Diese Option darf nur in SYN geflaggten Packeten auftauchen.
TCP SACK: Kind 5 (1 Byte) Length x (1 Byte). Danach folgen
die empfangenen Segmente von 1 bis n:
|Left Edge 1st Block|Right Edge 1st Block| ... |
| ... |Left Edge nst Block|Right Edge nst Block|
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL