Martin MauveUniversität Mannheim1 5 Transmission Control Protocol (TCP) RFC 793. J. Postel....

Martin Mauve Universität Mannheim 1

5 Transmission Control Protocol (TCP)

RFC 793. J. Postel. Transmission Control Protocol. 1981.

Transport Protokoll

verbindungsorientiert Verbindungsaufbau Datenübertragung Verbindungsabbau

zuverlässig Verlust von IP Paketen wird erkannt und durch

Übertragungswiederholung korrigiert


TCP

Flußkontrolle (engl. Flow Control) verhindert, daß der Empfänger von einem Sender schneller

Daten erhält, als er engegennehmen kann

Netzwerk-Überlastkontrolle (engl. Congestion Control) verhindert, daß es zu einer Überlastsituation im Netz kommt,

die zum vollständigen Zusammenbruch des Netzes führen könnte (congestion collapse)

bei Erkennen einer Überlastsituation (Paketverlust!) wird vom Sender die Datenrate gedrosselt

transparente Übertragung von byte streams Anwendungen, die TCP benutzen, sollen nicht merken, daß

die Daten in Form von Paketen übertragen werden.


Zuverlässigkeit in TCP

TCP unterteilt den byte stream in Einheiten, die jeweils in einem IP Paket übertragen werden, diese Einheiten heißen Segmente.

Nachdem TCP ein Segment (per IP) losgeschickt hat, wird ein Timer für dieses Paket gestartet.

Wenn keine Bestätigung über den erfolgreichen Empfang dieses Paketes innerhalb der Timer-Laufzeit eintrifft, wird die Übertragung wiederholt.

Wenn TCP ein Paket vom Kommunikationspartner erhält, dann wird eine Bestätigung über den erfolgreichen Empfang an den Sender geschickt.


Zuverlässigkeit in TCP

TCP berechnet eine Checksumme über die versandten Fragmente. Falls diese einen Fehler signalisiert, wird das Fragment nicht bestätigt.

Wenn Segmente außer der Reihe von IP ausgeliefert werden, wird TCP die richtige Reihenfolge wieder herstellen.

Wenn IP-Datagramme im Netz verdoppelt werden, dann sortiert TCP die Duplikate aus.


Sliding Window

TCP verwendet einen sliding window-Mechanismus zur gemeinsamen Fluß- und Überlastkontrolle

Sender:

sliding windowsliding windowsliding window

acknowledgements


Sliding Window

Eine maximale Größe für das Schiebefenster wird durch die Flußkontrolle vorgegeben.

Die Größe des Fensters ändert sich durch die Überlastkontrolle: wenn eine Überlastung vorliegt, wird sie reduziert wenn keine Überlastung vorliegt, wird sie erhöht


TCP Header

TCP checksum

IP Header (20 Byte)

urgent pointer

data

0 7 15 31

source port number destination port number

sequence number

acknowledgement number

window sizehdr size reserved flags

options


TCP Header

Port-Nummern: wie für UDP

sequence number: identifiziert das erste Byte im Datenteil des Paketes

acknowledgement number: identifiziert das nächste Byte, das der Sender dieses Paketes vom Empfänger dieses Paketes erwartet

Da Daten in beide Richtungen zwischen den Kommunikationspartnern fließen können, gibt es eine eigene sequence number für jede Richtung

header length: Größe des TCP headers in 32 bit Worten


TCP Header

Flags: URG: urgent pointer Feld ist gültig ACK: acknowledgement Feld ist gültig PSH: der Empfänger sollte die Daten der Anwendung so

schnell wie möglich zur Verfügung stellen RST: Reset der Verbindung SYN: Synchronisation der initialen Sequenznummern bei

Verbindungsaufbau FIN: der Sender hat das Senden seiner Daten beendet

window size: Anzahl der Bytes, die der Sender dieses Paketes noch entgegennehmen kann, bis sein Puffer voll ist (flow control)


TCP Header

checksum: wird über das gesamte Fragment berechnet, incl. TCP Header und pseudo Header wie in UDP

urgent pointer: der urgent pointer identifiziert das letzte Byte im Datenteil, welches mit besonderer Priorität bearbeitet werden sollte

options: werden wir später besprechen

der Datenteil eines TCP-Paketes ist optional, ein leeres TCP-Paket kann z.B. als reine Bestätigung empfangener Daten gesendet werden, wenn keine Daten in die Rückrichtung gesendet werden sollen


5.1 TCP-Verbindungsaufbau und -abbau

SYN seq 4711 length 0 win 4096 mss 1024

SYN seq 0815 ack 4712 length 0 win 4096 mss 1024

ack 0816

Aufbau

Abbau

FIN seq 4712 ack 0816 length 0 win 4096

ack 4713

FIN seq 0816 ack 4713 length 0 win 4096

ack 0817


TCP-Verbindungsaufbau

eine TCP-Verbindung ist definiert durch ein 4-Tupel: {IP-Adresse 1, Port 1, IP-Adresse 2, Port 2}

„three way handshake“ SYN Flag zeigt an, daß die Sequence Numbers

SYNchronisiert werden sollen SYN „kostet“ ein Byte bezüglich der

Sequenznummernvergabe reine acknowledgements „kosten“ keine Bytes

derjenige Teilnehmer, der den Verbindungsaufbau initiiert, führt ein „active open“ (i.d.R. der Client) durch, der Kommunikationspartner ein „passive open“ (i.d.R. der Server)


Timeout bei Verbindungsaufbau

Was passiert, wenn der Kommunikationspartner nicht antwortet? die Übertragung des Paketes wird wiederholt, TCP betrachtet

dies als gewöhnlichen Paketverlust nach einer festen Zeit (timeout) wird der Verbindungsversuch

abgebrochen und die Anwendung informiert


Maximum Segment Size Option

mit der Maximum Segment Size (MSS) gibt ein System an, wie groß Segmente sein dürfen, die in einem TCP Paket übertragen werden: Standardwert ist 536 (ergibt 576, wenn minimale IP- und

TCP-Header hinzugerechnet werden) ein größerer Wert kann von einem System angegeben

werden, dieser darf die MTU des angeschlossenen LANs minus minimale IP- und TCP-Header nicht überschreiten

zu IP-Fragmentierung kommt es, wenn ein Netz durchquert wird, welches eine kleinere MTU als die MSS (+header) hat, dann wird path MTU discovery verwendet


Live Demo TCP-Verbindungsaufbau

# telnet pi4 discardTrying 134.155.48.96Connected to pi4.Escape character is `^]`.telnet> ^] (=control + ])telnet> quitConnection closed.

Wiederholung bei gezogenem Netzkabel


TCP-Verbindungsabbau

durch zweimal half-close: da die TCP-Verbindung bidirektional ist, können beide

Richtungen getrennt voneinander beendet werden wer seine Senderolle beenden möchte, setzt das FIN Flag FIN „kostet“ ein Byte und wird daher durch ein

ack(nowledgement) bestätigt der andere Teilnehmer kann weiter senden - jedoch sieht

man fast immer das Verhalten, daß der andere Teilnehmer als Reaktion auch seine Senderolle beendet

derjenige Teilnehmer, der zuerst seine Verbindung beendet, führt ein „active close“ (i.d.R. der Client) durch, der Kommunikationspartner ein „passive close“ (i.d.R. der Server)


2MSL Wait State

derjenige Teilnehmer, der einen active close durchführt, muß nach Senden des acks für das FIN des Kommunikationspartners die Verbindung für eine gewisse Zeit offen halten Grund: das ack könnte verloren gehen und müßte dann

erneut übertragen werden die „gewisse Zeit“ beträgt 2 maximal segment lifetimes

(daher 2MSL wait state) implementiert wird eine MSL als 30 - 120 Sekunden während 2MSL Wait State kann daher die Port-Nummer

noch nicht wieder für andere TCP-Verbindungen verwendet werden


Live Demo TCP-Verbindungsabbau

# telnet pi4 discardTrying 134.155.48.96Connected to pi4.Escape character is `^]`.telnet> ^] (=control + ])telnet> quitConnection closed.


TCP Reset

ein Segment, bei dem das RST (reset) bit im TCP header gesetzt ist, terminiert die Verbindung in Form eines „abortive release“ (im Gegensatz zum „orderly release“ mit FIN): alle Daten, die beim Sender gepuffert waren, werden

verworfen und das reset Segment wird sofort gesendet, die Verbindung ist damit aus Sicht des RST Senders sofort terminiert

es können beim Reset Daten verloren gehen (das passiert beim Verbindungsabbau mit FIN nicht)

der Emfänger eines RST Segmentes meldet dies der Anwendung und terminiert sofort


TCP Reset

es gibt prinzipiell zwei unterschiedliche Situationen, wann ein RST gesendet wird: wenn ein Port nicht belegt ist (connection refused) wenn eine bestehende Verbindung abgebrochen wird

(connection reset by peer) i.d.R. kann man als socket Option angeben, ob ein

normales TCP close erwünscht ist (mit FIN) oder ob ein Abbruch erwünscht ist

bei Java geschieht dies mit: setSoLinger(int x), dies gibt an, daß der Socket nach x Sekunden mit einem Reset geschlossen werden soll


TCP PUSH Flag (PSH)

die ursprüngliche Aufgabe des PSH Flags war es, daß der Sender eines Segmentes den Empfänger auffordert, dieses (und alle vorangegangenen) sofort bei der jeweiligen Anwendung auszuliefern, ohne daß es lange gepuffert wird

dies sollte z.B. für interaktive Anwendungen verwendet werden

wird inzwischen jedoch standardmäßig (fast) immer gesetzt, da keine Rechenzeit beim Auslesen der Puffer gespart werden muß


TCP - Application Programming Interface

Client/Server mit Sockets: der Server wartet auf einem wohldefinierten Port auf

Verbindungswünsche von Clients ein Client verbindet sich mit dem Server nachdem die Verbindung hergestellt ist, kann der Server für

diese Verbindung einen Thread/Prozeß anlegen, so daß er auf weiterhin eingehende Verbindungswünsche reagieren kann

wenn er dies nicht tut, werden die Verbindungswünsche sequentiell bearbeitet (selten)

Client und Server kommunizieren über byte streams


TCP - API Beispiel: Command Client/Server

einfaches Java-Beispiel für einen sequentiell arbeitenden Server

Beobachten mittles tcpdump/ethereal!


5.2 TCP Interactive Data Flow

Buchstabe

ack für Buchstabe

Darstellung des Buchstabens

ack für Darstellung des Buchstaben

rlogin client rlogin server


Delayed Acknowledgements

um zu verhindern, daß überflüssige TCP-Segmente gesendet werden, die nur ein ack beinhalten, wird das Senden von acks i.d.R. verzögert:

Buchstabe

rlogin client rlogin server

ack für Buchstabe und Darstellung des Buchstabens delayed ack

ack für Darstellung des Buchstaben

delayed ack


TCP Delayed Acks - Demon

wir verwenden rlogin und tcpdump, um zu sehen, wie TCP delayed acks verwendet


Delayed Acknowledgements

ein ack wird bei delayed acknowledgements i.d.R. um maximal 200 ms verzögert

während dieser Zeit können Daten, die gesendet werden, das ack „Huckepack“ (engl. piggiyback) mitnehmen, dies spart die Übertragung eines reinen ack Segmentes

werden innerhalb dieser Zeit keine Daten gesendet, so wird ein reines ack Segment übertragen

der 200ms Timer wird nicht für jedes Paket aufgezogen, sondern läuft global, d.h. alle 200ms werden alle acks verschickt, die noch offen sind


Nagle Algorithm

wenn Segmente übertragen werden, die sehr klein sind, dann fällt viel Overhead in Form von Headern an

z.B. bei rlogin 40 Byte Header für 1 Daten Byte!

insbesondere in WANs (wide area networks) kann dies problematisch sein

zur Vermeidung dieses Problems wird der Nagle Algorithmus verwendet


Nagle Algorithm

RFC 896 ein Sender darf nur ein ausstehendes Segment

haben, welches kleiner als die MSS ist Idee: solange acks schnell zurückkommen behindert

dies den Sender nicht, wenn acks langsam zurück-kommen, dann ist es wichtig, daß möglichst wenige „tinygrams“ gesendet werden

Problem: manchmal möchte man dieses Verhalten nicht (z.B. bei X Window sollen Maus-Bewegungen ohne Verzögerung übertragen werden)

Lösung: man kann den Nagle Algorithmus abschalten, z.B. in Java: setTcpNoDelay(boolean)


5.3 TCP Bulk Data Flow

was passiert, wenn man große Datenmengen per TCP überträgt?

wir schauen uns eine Dateiübertragung mittels ftp an (ethereal)

Frage: wann wird ein ack gesendet? bisher: delayed ack nach 200ms das würde zu viele unbestätigten Paketen verursachen,

wenn die Datenrate hoch ist (bulk data flow) daher wird i.d.R. jedes 2te Segment sofort bestätigt, auch

wenn der 200ms delayed ack timer noch nicht abgelaufen ist


Schneller Sender und langsamer Empfänger

sequ 1, length 1024, ack 1, win 4096

ack 2049, win 2048

ftp server ftp client




ack 4097, win 0

ack 4097, win 4096


Schneller Sender und langsamer Empfänger

der Sender überträgt die Daten schneller, als sie der Empfänger aus dem Puffer lesen kann

der Puffer des Empfängers läuft voll, er signalisiert dies mit der Fenstergröße (dies ist eine Erweiterung zum sliding window-Mechanismus, welche es erlaubt, Pakete zu bestätigen, ohne dem Sender das Recht zu geben, weitere Pakete zu senden)

erst wenn der Puffer vom Empfänger wieder freien Platz enthält, wird dieser freie Platz in einem weitern ack dem Sender mitgeteilt


Congestion

Problem: wenn alle Sender im Netz immer so viele Pakete losschicken, wie bei den Empfängern in den Puffer passen, dann kann es zur Überlast (congestion) im Netz kommen, da nicht auf die momentane Situation im Netz Rücksicht genommen wird

Sender A Empfänger C

Sender B Empfänger Dwenn alle Verbindungen die gleiche Bandbreite haben und sowohl A alsauch B mit der Bandbreite der Verbindungsenden, dann kommt es hier zur Netzwerk-überlastung (congestion)!


Congestion Window

um Congestion zu verhindern, wird beim Sender ein zusätzliches Congestion Window (cwnd) mitgeführt

cwnd wird wie das vom Empfänger mitgeteilte flow control window in Bytes geführt

ein Sender darf nur das MINIMUM aus (cwnd, Emfänger Window) an Daten senden


Slow Start

das cwnd wird zu Beginn einer Verbindung mit einer MSS (wie vom Kommunikationspartner angekündigt) initialisiert

solange kein Verlust auftritt, wird das cwnd jeweils um eine MSS erhöht, wenn ein Segment bestätigt wurde: d.h. wenn das erste Segment bestätigt wurde, dürfen zwei

volle Segmente gesendet werden, sofern dies weniger als die von Empfänger angegebene (flow control) Fenstergröße ist: das cwnd wird auf 2 erhöht und es stehen keine unbestätigten Segmente mehr aus


Slow Start

mittels slow start soll schnell der Wert bestimmt werden, den man senden kann, ohne Paketverlust hervorzurufen

dieser Wert ist erreicht, wenn das cwnd so groß ist, daß die Verbindung zum Empfänger mit Paketen gefüllt bleibt:

Sender Empfänger

optimales cwnd = bandbreite * round-trip Verzögerung


Slow Start

slow start terminiert, wenn die ersten Paketverluste auftreten, dann kommt es zu congestion avoidance (wird erklärt, wenn wir Verlusterkennung und Übertragungswiederholung besprechen)

ideal wäre es, wenn man einfach den durch slow start bestimmten Wert für die ganze Lebenszeit der Verbindung verwenden könnte

dies ist leider nicht möglich, da sich die verfügbare Bandbreite während einer Verbindung ändern kann (dies kann sehr häufig in kurzen Abständen passieren)


5.4 Zuverlässigkeit in TCP

generell wird Zuverlässigkeit in TCP durch acknowledgements gewährleistet

wenn der Sender kein acknowledgement für ein Segment erhält, wird dieses nach Ablauf eines Timers erneut übertragen

wenn nötig, wird dies wiederholt, bis eine Bestätigung vorliegt

damit dies funktioniert, benötigt man Wissen über die Netzwerkverzögerung zwischen Sender und Empfänger (round trip delay)


Round Trip Delay-Messung

beim Sender wird beim Eintreffen eines acks das round trip delay für das erste Segmente bestimmt, welches durch das ack bestätigt wurde

d.h. wenn 2 Segmente durch ein ack bestätigt werden, wird nur das round trip delay für das erste Segment bestimmt

da sich das round trip delay mit der Zeit ändern kann, muß diese Änderung erfaßt werden

erste Idee (exponentielle Glättung): RTT a*RTT + (1-a)*M RTT= round trip time estimator, a=0.9, M=aktuelle Messung nach RTO=2*RTT wird die Übertragung eines Paketes

wiederholt 2*RTT um bei spontane Variationen des round trip delays

nicht sofort überflüssige Übertragungen zu erzeugen


Round Trip Delay-Messung

die erste Idee hat nur bedingt funktioniert, da sie nicht resistent genug gegen plötzliche Schwankungen des round trip delays war

Idee: die Varianz muß in die Berechnung einbezogen werden: Err = M -A A A+g*Err D D + h*(|Err| -D) RTO = A+4*D mit A=geglättetes durchschnittliches round trip delay,

D=geglättete Standardabweichung, Err=Abweichung des aktuellen Testwertes M, g=Anpassungsfaktor für A (0.125), h=Anpassungsfaktor für D (0.25)


Karn‘s Algorithmus

Problem: wenn eine Segmentübertragung wiederholt wurde (z.B. wegen eines Timouts) und dann bestätigt wird, weis man nicht, ob: die Bestätigung für die erste Übertragung gemeint war und

im Netz zu lange verzögert wurde, oder die Bestätigung tatsächlich für die wiederholte Übertragung

des Segmentes gilt

nach Karn dürfen daher acks von Segmenten, die wiederholt übertragen wurden, nicht bei der Berechnung des round trip delays berücksichtigt werden


Fast Retransmit

Problem: was tun, wenn ein einzelnes Segment verloren gegangen ist, und die nachfolgenden Segmente vom Empfänger korrekt empfangen werden?

der Empfänger schickt duplicate acks, d.h. er bestätigt das letzte Paket vor der „Lücke“ erneut, wenn er Segmente erhält, die nicht in der richtigen Reihenfolge ankommen


Fast Retransmit

erhält der Sender ein duplicate ack, so kann: entweder die Reihenfolge der Pakete im Netz verändert

worden sein, oder ein Paketverlust vorliegen

wenn wenige duplicate acks in Folge ankommen, ist der erste Fall wahrscheinlich und der Sender ignoriert dies; treten mehr als 2 duplicate acks auf, wird vom Sender ein Paketverlust angenommen und das betroffene Segment erneut übertragen

wenn ein kontinuierlicher Datenstrom vom Sender gesendet wird, dann werden einzelne Paketverlust so deutlich schneller erkannt und repariert, daher der Name: fast retransmit


Fast Retransmit-Beispiel

sequ 1, geht verlorenack 1

ftp server ftp client

sequ 1025

sequ 2049 ack 1

sequ 3073 ack 1

ack 1 triple duplicate ack:

retransmit sequ 1

ack 4097sequ 4097


Slowstart & Congestion Avoidance

cwnd wird mit der MSS des Empfängers initialisiert slow start threshold (ssthresh) wird mit 65353 initialisiert solange ssthresh>cwnd und keine Verluste auftreten:

slow start: erhöhe cwnd um MSS für jedes empfangene ACK (dies ist exponentiell!)

wenn keine Verluste und ssthresh<=cwnd: congestion avoidance: erhöhe cwnd um 1/cwnd (hier cwnd

gemessen in Vielfachen von MSS), wenn eine ACK empfangen wird (dies ist linear)


Slowstart & Congestion Avoidance

wenn triple duplicate ack: setzte ssthresh und cwnd auf die Hälfte von min(cwnd,

Empfänger Fenster), runde auf ganze Vielfache von MSS ab danach congestion avoidance

wenn timeout: setzt ssthresh auf die Hälfte von min(cwnd, Empfänger Fenster),

runde auf ganze Vielfache von MSS ab setzte cwnd auf MSS (slow start)

für Übertragung immer: min(cwnd, Empfänger Fenster), dabei wird cwnd auf ganze Vielfache von MSS abgerundet

dieses Vorgehen bezeichnet man als additive increase multiplicative decrease (AIMD): die Senderate wird additiv während congestion avoidance erhöht und multiplikativ bei Paketverlust verringert (halbiert!)


Slowstart & Congestion Avoidance -ohne Verluste


Slowstart & Congestion Avoidance - mit Verlusten


TCP-Zusammenfassung

TCP bietet eine gesicherte, verbindungsorientierte Übertragung von Byte-Stömen

Verbindungsaufbau / -abbau

Zuverlässigkeit durch acks / timeout / fast retransmit

flow control durch Empfänger-Fenster

congestion control durch cwnd (AIMD)

Martin MauveUniversität Mannheim1 5 Transmission Control Protocol (TCP) RFC 793. J. Postel....

Documents

Transcript of Martin MauveUniversität Mannheim1 5 Transmission Control Protocol (TCP) RFC 793. J. Postel....