5 Transmission Control Protocol (TCP)

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

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 sliding window sliding window acknowledgements Sliding Window • TCP verwendet einen sliding window-Mechanismus zur gemeinsamen Fluß- und Überlastkontrolle Sender:

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. 0 15 31 7 TCP Header IP Header (20 Byte) source port number destination port number sequence number acknowledgement number hdrsize 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. SYN seq 4711 length 0 win 4096 mss 1024 SYN seq 0815 ack 4712 length 0 win 4096 mss 1024 ack 0816 FIN seq 4712 ack 0816 length 0 win 4096 ack 4713 FIN seq 0816 ack 4713 length 0 win 4096 ack 0817 5.1 TCP-Verbindungsaufbau und -abbau Aufbau Abbau

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 discardTrying 134.155.48.96Connected to pi4.Escape character is `^]`.telnet> ^] (=control + ])telnet> quitConnection 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 30 - 120 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 discardTrying 134.155.48.96Connected to pi4.Escape character is `^]`.telnet> ^] (=control + ])telnet> quitConnection 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. Buchstabe ack für Buchstabe Darstellung des Buchstabens ack für Darstellung des Buchstaben 5.2 TCP Interactive Data Flow rlogin client rlogin server

25. Buchstabe ack für Buchstabe und Darstellung des Buchstabens delayed ack ack für Darstellung des Buchstaben delayed ack 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: 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. sequ 1025, length 1024, ack 1, win 4096 sequ 2049, length 1024, ack 1, win 4096 sequ 3073, length 1024, ack 1, win 4096 sequ 1, length 1024, ack 1, win 4096 ack 2049, win 2048 ack 4097, win 0 ack 4097, win 4096 Schneller Sender und langsamer Empfänger 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. sequ 1, geht verloren sequ 1025 sequ 3073 sequ 2049 sequ 4097 ack 1 ack 1 ack 1 ack 1 ack 4097 triple duplicate ack: retransmit sequ 1 Fast Retransmit-Beispiel ftp server ftp client

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)

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)