6    Datentransport mit TCP und UDP

TCP und UDP – wie Einschreiben und Normalpost

Der weltweite Datentransport geschieht überwiegend innerhalb von IP-Netzen. Ihre Daten werden hier in Pakete zerlegt und am Zielort wieder zusammengesetzt. Den dabei entstehenden Datenstrom können Sie kontrolliert per TCP übertragen. Damit entlasten Sie die Anwendung, die die Korrektheit und Vollständigkeit überprüfen müsste. Natürlich erkaufen Sie sich diese Sicherheit mit erhöhter Netzlast. Diese senken Sie dadurch, dass Sie UDP zur Datenübertragung einsetzen. In diesem Fall sendet Ihr Rechner auf gut Glück die Datenpakete ins Netz. Die jeweils kommunizierenden Anwendungen kontrollieren den Fluss, die Korrektheit und die Vollständigkeit der Daten selbst – und verursachen sowohl beim Sender als auch beim Empfänger eine höhere Rechnerauslastung.

Die TCP- oder UDP-Datagramme liegen im Datenbereich der IP-Pakete. Egal, welches Transportprotokoll Sie benutzen, Ihre Daten brauchen jeweils einen »Hafen« für den Start und das Ziel ihrer Reise, die Ports.

6.1    Transmission Control Protocol (TCP)

Mit TCP benutzen Sie ein verbindungsorientiertes Übertragungsprotokoll für Ihre Datenpakete. Verbindungen werden förmlich auf- und abgebaut, die Datenübertragung selbst unterliegt einer Flusskontrolle. Durch diese Flusskontrolle gehen keine Daten verloren. Unvollständige oder fehlende Pakete werden von der Gegenstelle bemerkt und erneut angefordert. Der Empfänger-Rechner setzt die Datenpakete in ihrer richtigen Reihenfolge wieder zusammen und übergibt sie der Anwendung.

Die TCP-Verbindung kann von den beiden Hosts gleichberechtigt in jede Richtung genutzt werden. Insoweit wird es für Sie manchmal schwierig sein, mitprotokollierten Netzwerkverkehr richtig zu deuten. Die beim TCP verwendeten Ports bilden zusammen mit der IP-Adresse die Sockets.

6.1.1    Das TCP-Paket

Das TCP-Paket, auch TCP-Datagramm genannt, beinhaltet keine Absender- oder Ziel-IP-Adresse. Vielmehr finden Sie nur die Port-Nummern von Sender und Empfänger vor. Die IP-Adressen der beteiligten Hosts sind bereits im IP-Header angegeben, in dem das Datagramm im Datenteil abgelegt ist.

TCP könnten Sie auch innerhalb anderer Netzwerkprotokolle verwenden. Beim IP-Protokoll gibt Ihnen der Ethernet-Frame einen Nutzlastanteil von 1500 Byte vor. Hiervon müssen Sie aber noch den IP-Header mit 20 Byte und den TCP-Header mit ebenfalls 20 Byte abziehen. Unter Umständen benutzen Sie zusätzlich eine Übertragungsmethode wie PPP oder PPPoE (DSL). In diesem Fall gehen davon nochmals 8 Byte verloren. Es verbleiben 1460 oder nur 1452 Byte für Ihre Daten. Diesen Wert nennt man die Maximum Segment Size (MSS). Auf diesen Wert können sich Sender und Empfänger beim Verbindungsaufbau einigen. Hierzu belegen sie das Optionsfeld mit diesem Parameter. Den Aufbau des TCP-Datagramms finden Sie in Abbildung 6.1.

Aufbau des TCP-Datagramms

Abbildung 6.1     Aufbau des TCP-Datagramms

Die Bedeutung der einzelnen Felder habe ich in Tabelle 6.1 erklärt.

Feld

Inhalt

Größe
(Bits)

Quell-Port

Port-Nummer der sendenden Anwendung

16

Ziel-Port

Port-Nummer der empfangenden Anwendung

16

Sequenznummer

Nummer des Datenpakets innerhalb des Datenstroms. Sie darf während der Verbindung nur einmal vorkommen.

32

Bestätigungsnummer

Bestätigung eines Pakets oder Blocks

32

Header-Länge

Header-Länge, angegeben mit der Zahl der benutzten 32-Bit-Blöcke. Damit wird der Beginn der Nutzdaten beschrieben.

4

reserviert

unbenutzt

6

Flags

1-Bit-Kennzeichen (Werte 1 oder 0) mit folgenden Bedeutungen:

–6

URG: kennzeichnet die Einleitung einer Steueranweisung. Alle Pakete ab diesem Flag werden direkt an die Anwendung weitergereicht und nicht gepuffert. Das Ende einer Steueranweisung setzt der Urgent-Pointer. In der Praxis brechen Sie z. B. damit Datenübertragungen oder Kommandos ab.

1

ACK: Acknowledgement. Das ACK-Flag bestätigt die Gültigkeit der Bestätigungsnummer (ACK-Number). Damit bestätigt TCP den vollständigen und richtigen Empfang eines Pakets (oder eines Blocks mit mehreren Paketen).

1

PSH: So gekennzeichnete Pakete übergehen den Empfangspuffer und gelangen direkt zur Anwendung. Damit vermeiden Sie z. B. »Hänger« bei Fernsitzungen.

1

RST: Abbruch von bestehenden Verbindungen, Abweisen von unerwünschten Verbindungen (z. B. geschlossener Port).
Im Gegensatz zu UDP sendet der Empfänger kein Port-Unreachable-ICMP-Paket an den Absender.

1

SYN: Anzeigen des Verbindungsaufbaus und damit verbunden Synchronisieren der Sequenznummer. Der Empfänger bestätigt den Verbindungsaufbau mit SYN + ACK. Er kann den Verbindungsaufbau mit RST ablehnen.

1

FIN: Schlusszeichen einer Übermittlung. Der Sender zeigt das Ende der Daten an und gibt die Verbindung frei.

1

Window-Size

Anzahl der Bytes, die der Sender übermitteln darf, ohne ein Überlaufen des Empfangspuffers hervorzurufen.

16

Prüfsumme
(Checksum)

Quersumme zum Prüfen der Unversehrtheit der Pakete

16

Urgent-Pointer

Angabe der Position des letzten Bytes der Urgent-Daten (Flag URG) im Datenstrom. Das Flag URG muss gleichfalls gesetzt sein, damit diese Anweisung gültig ist.

16

Optionen/Padding

Übergabe von Optionen. Damit dieser Bereich immer 32 Bit Länge aufweist, wird der ungenutzte Platz mit »0« aufgefüllt (Padding).

32

Daten

die Nutzdaten für die empfangende Anwendung

Tabelle 6.1     TCP-Header

Weitere vertiefende Informationen finden Sie in den RFCs 793, 1122, 2474, 3168, 4301, 5884, 6040, 6093, 6298, 6528, 6633, 6864, 7619, 7726, 8029, 8311 und 9041.

6.1.2    TCP: Verbindungsaufbau

Zunächst sendet Host 1 ein Anfragepaket an Host 2 (SYN). Im Beispiel der Abbildung 6.2 nimmt er die Anfrage an und sendet seine Zustimmung als SYN ACK-Paket zurück. Host 1 bestätigt wiederum mit einem ACK den Erhalt und beginnt mit der Übermittlung der Datenpakete. Schon beim Verbindungsaufbau kommen beidseitig Sequenznummern zum Einsatz.

Diese Sequenznummern bildet jeder Host für sich (SEQ = X, SEQ = Y). Bei der ersten Antwort sendet Host 2 die um den Wert 1 erhöhte Sequenznummer als Bestätigungsnummer (ACK, ACK-Nummer) zusammen mit seiner eigenen Sequenznummer zurück. Host 1 bestätigt den Erhalt, indem er mit ACK und der um 1 erhöhten Sequenznummer des Hosts 2 als Bestätigungsnummer antwortet. Gleichzeitig erhöht er den Wert seiner eigenen Sequenznummer und übermittelt diese ebenfalls. Die Verbindung ist aufgebaut.

TCP: Verbindungsaufbau

Abbildung 6.2     TCP: Verbindungsaufbau

Einen Verbindungswunsch kann ein Host durch Senden eines Pakets mit dem RST-Flag ablehnen.

6.1.3    TCP: Transportkontrolle

Das Datenvolumen kann größer sein als der für die Nutzlast bemessene Speicherplatz. Der sendende Host teilt die Daten paketweise auf (Segmentierung). Jedes Segment bekommt einen eigenen TCP-Header und wird an den Empfänger übermittelt. Dieser setzt aus den einzelnen Paketen die Daten in der Reihenfolge der Sequenznummern wieder zusammen. Anschließend übergibt TCP die kompletten Daten der anfordernden Anwendung.

Nach dem erfolgreichen Verbindungsaufbau sendet Host 1 seine Daten an Host 2 (Abbildung 6.3). Für jedes erfolgreich übermittelte Paket antwortet Host 2 mit einem ACK-Paket, das auch die Bestätigungsnummer (= Sequenznummer des erhaltenen Pakets) beinhaltet.

Im Beispiel aus Abbildung 6.3 sehen Sie zunächst den Ablauf der Einzelquittierung. Bei der reinen Datenübermittlung kommt diese kaum zum Einsatz, da sie das Netz zusätzlich belastet. Die gebräuchliche Blockquittierung erlaubt es dem Sender, mehrere Pakete zu übermitteln, wenn diese miteinander zusammenhängen. Der Empfänger gibt in seinem ACK-Paket als Bestätigungsnummer die letzte empfangene Sequenz zurück. Tritt bei der Übermittlung ein Fehler auf, erkennt der Sender nach Ablauf eines Timers das Fehlen von unbestätigten Sequenzen (Retransmission Timer). Er sendet diese Pakete nochmals ab.

Mit der Prüfsumme werden Unregelmäßigkeiten innerhalb der Pakete erkannt. Für die Berechnung der Prüfsumme zieht TCP nur folgende Daten heran:

TCP: Datenübertragung

Abbildung 6.3     TCP: Datenübertragung

6.1.4    TCP: Verbindungsabbau

Liegen keine zu übermittelnden Daten mehr vor, baut der Sender die TCP-Verbindung wieder ab. Auch dies unterliegt einem eigenen Formalismus. Der sendende Host 1 sendet ein Paket mit dem FIN-Flag, das der Empfänger-Host 2 bestätigt. Dieser (Host 2) erklärt daraufhin seinerseits mittels eines FIN-Pakets die Verbindung für beendet. Host 1 bestätigt den Erhalt mittels ACK. Die TCP-Verbindung zwischen den beiden Rechnern ist damit aufgehoben (Abbildung 6.4).

TCP: Aufhebung der Verbindung

Abbildung 6.4     TCP: Aufhebung der Verbindung

Es ist notwendig, dass sich beide Hosts das Verbindungsende gegenseitig erklären. TCP-Verbindungen sind bidirektional.

Eine weitere Darstellung einer TCP-Verbindung im Zusammenhang mit einem Sitzungsprotokoll (HTTP) finden Sie in Abschnitt 7.3.1, »Grundlagen des HTTP-Protokolls«.