Kein Folientitel - pi4

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
Martin Mauve
Universität Mannheim
1
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
Martin Mauve
Universität Mannheim
2
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 TimerLaufzeit 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.
Martin Mauve
Universität Mannheim
3
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.
Martin Mauve
Universität Mannheim
4
Sliding Window

TCP verwendet einen sliding window-Mechanismus
zur gemeinsamen Fluß- und Überlastkontrolle
Sender:
sliding window
sliding window
acknowledgements
Martin Mauve
Universität Mannheim
5
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
Martin Mauve
Universität Mannheim
6
TCP Header
0
15
7
31
IP Header (20 Byte)
source port number
destination port number
sequence number
acknowledgement number
hdr size
reserved
flags
window size
TCP checksum
urgent pointer
options
data
Martin Mauve
Universität Mannheim
7
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
Martin Mauve
Universität Mannheim
8
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

Martin Mauve
window size: Anzahl der Bytes, die der Sender
dieses Paketes noch entgegennehmen kann, bis
sein Puffer voll ist (flow control)
Universität Mannheim
9
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
Martin Mauve
Universität Mannheim
10
5.1 TCP-Verbindungsaufbau und -abbau
SYN seq 4711 length 0 win 4096 mss 1024
Aufbau
SYN seq 0815 ack 4712 length 0 win 4096 mss 1024
ack 0816
FIN seq 4712 ack 0816 length 0 win 4096
ack 4713
Abbau
FIN seq 0816 ack 4713 length 0 win 4096
ack 0817
Martin Mauve
Universität Mannheim
11
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

Martin Mauve
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)
Universität Mannheim
12
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
Martin Mauve
Universität Mannheim
13
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
Martin Mauve
Universität Mannheim
14
Live Demo TCP-Verbindungsaufbau
# telnet pi4 discard
Trying 134.155.48.96
Connected to pi4.
Escape character is `^]`.
telnet> ^] (=control + ])
telnet> quit
Connection closed.
Martin Mauve
Universität Mannheim
15
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

Martin Mauve
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)
Universität Mannheim
16
2MSL Wait State

derjenige Teilnehmer, der einen active close
durchführt, muss 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üsste 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
Martin Mauve
Universität Mannheim
17
Live Demo TCP-Verbindungsabbau
# telnet pi4 discard
Trying 134.155.48.96
Connected to pi4.
Escape character is `^]`.
telnet> ^] (=control + ])
telnet> quit
Connection closed.
Martin Mauve
Universität Mannheim
18
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
Martin Mauve
Universität Mannheim
19
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
Martin Mauve
Universität Mannheim
20
TCP PUSH Flag (PSH)

die ursprüngliche Aufgabe des PSH Flags war es,
dass der Sender eines Segmentes den Empfänger
auffordert, dieses (und alle vorangegangenen) sofort
bei der jeweiligen Anwendung auszuliefern, ohne
dass 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 muss
Martin Mauve
Universität Mannheim
21
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/Prozess anlegen, so dass
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
Martin Mauve
Universität Mannheim
22
TCP - API Beispiel: Command Client/Server

einfaches Java-Beispiel für einen sequentiell
arbeitenden Server

Beobachten mittles tcpdump/ethereal!
Martin Mauve
Universität Mannheim
23
5.2 TCP Interactive Data Flow
Buchstabe
ack für Buchstabe
Darstellung des Buchstabens
ack für Darstellung des Buchstaben
rlogin client
Martin Mauve
rlogin server
Universität Mannheim
24
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
ack für Buchstabe und Darstellung des Buchstabens
delayed ack
delayed ack
ack für Darstellung des Buchstaben
rlogin client
Martin Mauve
rlogin server
Universität Mannheim
25
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. piggyback)
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
Martin Mauve
Universität Mannheim
26
TCP Delayed Acks - Demon

Martin Mauve
wir verwenden rlogin und tcpdump, um zu sehen,
wie TCP delayed acks verwendet
Universität Mannheim
27
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
Martin Mauve
Universität Mannheim
28
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ückkommen, dann ist es wichtig, dass 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)
Martin Mauve
Universität Mannheim
29
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
Martin Mauve
Universität Mannheim
30
Schneller Sender und langsamer Empfänger
sequ 1, length 1024, ack 1, win 4096
sequ 1025, length 1024, ack 1, win 4096
ack 2049, win 2048
sequ 2049, length 1024, ack 1, win 4096
sequ 3073, length 1024, ack 1, win 4096
ack 4097, win 0
ack 4097, win 4096
ftp server
Martin Mauve
ftp client
Universität Mannheim
31
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

das so genutzte Fenster ist das Empfänger Fenster
(eines pro Kommunikationspartner)
Martin Mauve
Universität Mannheim
32
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
Sender B
Martin Mauve
Empfänger C
wenn alle Verbindungen die gleiche
Bandbreite haben und sowohl A als
auch B mit der Bandbreite der Verbindung
senden, dann kommt es hier zur Netzwerküberlastung (congestion)!
Universität Mannheim
Empfänger D
33
Congestion Window

um auf Congestion zu reagieren, wird beim Sender
ein zusätzliches Congestion Window (cwnd)
mitgeführt

cwnd wird wie das vom Empfänger mitgeteilte
Empfänger Fenster in Byte geführt

ein Sender darf nur das MINIMUM aus (cwnd,
Empfänger Fenster) an Daten senden
Martin Mauve
Universität Mannheim
34
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
Martin Mauve
Universität Mannheim
35
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,
dass die Verbindung zum Empfänger mit Paketen
gefüllt bleibt:
Sender
Empfänger
optimales cwnd = bandbreite * round-trip Verzögerung
Martin Mauve
Universität Mannheim
36
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)
Martin Mauve
Universität Mannheim
37
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)
Martin Mauve
Universität Mannheim
38
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, muss
diese Änderung erfaßt werden
erste Idee (exponentielle Glättung):




Martin Mauve
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
Universität Mannheim
39
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 muss in die Berechnung einbezogen
werden:





Martin Mauve
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)
Universität Mannheim
40
Karn‘s Algorithmus

Problem: wenn eine Segmentübertragung wiederholt
wurde (z.B. wegen eines Timeouts) 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

Martin Mauve
nach Karn dürfen daher acks von Segmenten, die
wiederholt übertragen wurden, nicht bei der
Berechnung des round trip delays berücksichtigt
werden
Universität Mannheim
41
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
Martin Mauve
Universität Mannheim
42
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
Martin Mauve
Universität Mannheim
43
Fast Retransmit-Beispiel
sequ 1, geht verloren
ack 1
sequ 1025
ack 1
sequ 2049
ack 1
sequ 3073
ack 1
triple duplicate ack:
retransmit sequ 1
ack 4097
sequ 4097
ftp server
Martin Mauve
ftp client
Universität Mannheim
44
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)
Martin Mauve
Universität Mannheim
45
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!)
Martin Mauve
Universität Mannheim
46
Slowstart & Congestion Avoidance ohne Verluste
Martin Mauve
Universität Mannheim
47
Slowstart & Congestion Avoidance mit Verlusten
Martin Mauve
Universität Mannheim
48
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 Mauve
Universität Mannheim
49