martin mauveuniversität mannheim1 5 transmission control protocol (tcp) rfc 793. j. postel....
Post on 05-Apr-2015
104 Views
Preview:
TRANSCRIPT
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
Martin Mauve Universität Mannheim 2
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 3
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.
Martin Mauve Universität Mannheim 4
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 5
Sliding Window
TCP verwendet einen sliding window-Mechanismus zur gemeinsamen Fluß- und Überlastkontrolle
Sender:
sliding windowsliding windowsliding window
acknowledgements
Martin Mauve Universität Mannheim 6
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 7
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
Martin Mauve Universität Mannheim 8
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 9
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)
Martin Mauve Universität Mannheim 10
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 11
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
Martin Mauve Universität Mannheim 12
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)
Martin Mauve Universität Mannheim 13
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 14
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 15
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
Martin Mauve Universität Mannheim 16
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)
Martin Mauve Universität Mannheim 17
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
Martin Mauve Universität Mannheim 18
Live Demo TCP-Verbindungsabbau
# telnet pi4 discardTrying 134.155.48.96Connected to pi4.Escape character is `^]`.telnet> ^] (=control + ])telnet> quitConnection closed.
Martin Mauve Universität Mannheim 19
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 20
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 21
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ß
Martin Mauve Universität Mannheim 22
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
Martin Mauve Universität Mannheim 23
TCP - API Beispiel: Command Client/Server
einfaches Java-Beispiel für einen sequentiell arbeitenden Server
Beobachten mittles tcpdump/ethereal!
Martin Mauve Universität Mannheim 24
5.2 TCP Interactive Data Flow
Buchstabe
ack für Buchstabe
Darstellung des Buchstabens
ack für Darstellung des Buchstaben
rlogin client rlogin server
Martin Mauve Universität Mannheim 25
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
Martin Mauve Universität Mannheim 26
TCP Delayed Acks - Demon
wir verwenden rlogin und tcpdump, um zu sehen, wie TCP delayed acks verwendet
Martin Mauve Universität Mannheim 27
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
Martin Mauve Universität Mannheim 28
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 29
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)
Martin Mauve Universität Mannheim 30
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 31
Schneller Sender und langsamer Empfänger
sequ 1, length 1024, ack 1, win 4096
ack 2049, win 2048
ftp server ftp client
sequ 1025, length 1024, ack 1, win 4096
sequ 2049, length 1024, ack 1, win 4096
sequ 3073, length 1024, ack 1, win 4096
ack 4097, win 0
ack 4097, win 4096
Martin Mauve Universität Mannheim 32
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
Martin Mauve Universität Mannheim 33
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)!
Martin Mauve Universität Mannheim 34
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
Martin Mauve Universität Mannheim 35
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 36
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
Martin Mauve Universität Mannheim 37
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 38
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 39
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
Martin Mauve Universität Mannheim 40
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)
Martin Mauve Universität Mannheim 41
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
Martin Mauve Universität Mannheim 42
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 43
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 44
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
Martin Mauve Universität Mannheim 45
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 46
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 47
Slowstart & Congestion Avoidance -ohne Verluste
Martin Mauve Universität Mannheim 48
Slowstart & Congestion Avoidance - mit Verlusten
Martin Mauve Universität Mannheim 49
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)
top related