Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

5 Transmission Control Protocol (TCP)

Ähnliche Präsentationen


Präsentation zum Thema: "5 Transmission Control Protocol (TCP)"—  Präsentation transkript:

1 5 Transmission Control Protocol (TCP)
RFC 793. J. Postel. Transmission Control Protocol Transport Protokoll verbindungsorientiert Verbindungsaufbau Datenübertragung Verbindungsabbau zuverlässig Verlust von IP Paketen wird erkannt und durch Übertragungswiederholung korrigiert

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.

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.

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.

5 Sliding Window TCP verwendet einen sliding window-Mechanismus zur gemeinsamen Fluß- und Überlastkontrolle Sender: sliding window sliding window acknowledgements

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

7 TCP Header 7 15 31 IP Header (20 Byte) source port number
7 15 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

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

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)

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

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 Aufbau 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

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)

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

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

15 Live Demo TCP-Verbindungsaufbau
# telnet pi4 discard Trying Connected to pi4. Escape character is `^]`. telnet> ^] (=control + ]) telnet> quit Connection closed. Wiederholung bei gezogenem Netzkabel

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)

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 Sekunden während 2MSL Wait State kann daher die Port-Nummer noch nicht wieder für andere TCP-Verbindungen verwendet werden

18 Live Demo TCP-Verbindungsabbau
# telnet pi4 discard Trying Connected to pi4. Escape character is `^]`. telnet> ^] (=control + ]) telnet> quit Connection closed.

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

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

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ß

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

23 TCP - API Beispiel: Command Client/Server
einfaches Java-Beispiel für einen sequentiell arbeitenden Server Beobachten mittles tcpdump/ethereal!

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

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 ack für Buchstabe und Darstellung des Buchstabens delayed ack ack für Darstellung des Buchstaben delayed ack rlogin client rlogin server

26 TCP Delayed Acks - Demon
wir verwenden rlogin und tcpdump, um zu sehen, wie TCP delayed acks verwendet

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

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

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)

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

31 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 ftp client

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

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 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)! Sender B Empfänger D

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

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

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

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)

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)

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

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)

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

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

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

44 Fast Retransmit-Beispiel
sequ 1, geht verloren ack 1 sequ 1025 sequ 2049 ack 1 ack 1 sequ 3073 ack 1 triple duplicate ack: retransmit sequ 1 ack 4097 sequ 4097 ftp server ftp client

45 Slowstart & Congestion Avoidance
cwnd wird mit der MSS des Empfängers initialisiert slow start threshold (ssthresh) wird mit 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)

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!)

47 Slowstart & Congestion Avoidance - ohne Verluste

48 Slowstart & Congestion Avoidance - mit Verlusten

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)


Herunterladen ppt "5 Transmission Control Protocol (TCP)"

Ähnliche Präsentationen


Google-Anzeigen