5 Transmission Control Protocol TCP l RFC 793

5 Transmission Control Protocol (TCP) l RFC 793. J. Postel. Transmission Control Protocol. 1981. l Transport Protokoll l verbindungsorientiert § Verbindungsaufbau § Datenübertragung § Verbindungsabbau l zuverlässig § Verlust von IP Paketen wird erkannt und durch Übertragungswiederholung korrigiert Martin Mauve Universität Mannheim

TCP l Flußkontrolle (engl. Flow Control) § verhindert, daß der Empfänger von einem Sender schneller Daten erhält, als er engegennehmen kann l 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 l 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

Zuverlässigkeit in TCP l TCP unterteilt den byte stream in Einheiten, die jeweils in einem IP Paket übertragen werden, diese Einheiten heißen Segmente. l Nachdem TCP ein Segment (per IP) losgeschickt hat, wird ein Timer für dieses Paket gestartet. l Wenn keine Bestätigung über den erfolgreichen Empfang dieses Paketes innerhalb der Timer. Laufzeit eintrifft, wird die Übertragung wiederholt. l 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

Zuverlässigkeit in TCP l TCP berechnet eine Checksumme über die versandten Fragmente. Falls diese einen Fehler signalisiert, wird das Fragment nicht bestätigt. l Wenn Segmente außer der Reihe von IP ausgeliefert werden, wird TCP die richtige Reihenfolge wieder herstellen. l Wenn IP-Datagramme im Netz verdoppelt werden, dann sortiert TCP die Duplikate aus. Martin Mauve Universität Mannheim

Sliding Window l TCP verwendet einen sliding window-Mechanismus zur gemeinsamen Fluß- und Überlastkontrolle Sender: sliding window acknowledgements Martin Mauve Universität Mannheim

Sliding Window l Eine maximale Größe für das Schiebefenster wird durch die Flußkontrolle vorgegeben. l 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

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

TCP Header l Port-Nummern: wie für UDP l sequence number: identifiziert das erste Byte im Datenteil des Paketes l acknowledgement number: identifiziert das nächste Byte, das der Sender dieses Paketes vom Empfänger dieses Paketes erwartet l Da Daten in beide Richtungen zwischen den Kommunikationspartnern fließen können, gibt es eine eigene sequence number für jede Richtung l header length: Größe des TCP headers in 32 bit Worten Martin Mauve Universität Mannheim

TCP Header l 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 l 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

TCP Header l checksum: wird über das gesamte Fragment berechnet, incl. TCP Header und pseudo Header wie in UDP l urgent pointer: der urgent pointer identifiziert das letzte Byte im Datenteil, welches mit besonderer Priorität bearbeitet werden sollte l options: werden wir später besprechen l 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

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 Abbau ack 4713 FIN seq 0816 ack 4713 length 0 win 4096 ack 0817 Martin Mauve Universität Mannheim

TCP-Verbindungsaufbau l eine TCP-Verbindung ist definiert durch ein 4 -Tupel: {IP-Adresse 1, Port 1, IP-Adresse 2, Port 2} l „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 l 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

Timeout bei Verbindungsaufbau l 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

Maximum Segment Size Option l 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

Live Demo TCP-Verbindungsaufbau # telnet pi 4 discard Trying 134. 155. 48. 96 Connected to pi 4. Escape character is `^]`. telnet> ^] (=control + ]) telnet> quit Connection closed. Wiederholung bei gezogenem Netzkabel Martin Mauve Universität Mannheim

TCP-Verbindungsabbau l 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 l 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

2 MSL Wait State l 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 2 MSL wait state) § implementiert wird eine MSL als 30 - 120 Sekunden § während 2 MSL Wait State kann daher die Port-Nummer noch nicht wieder für andere TCP-Verbindungen verwendet werden Martin Mauve Universität Mannheim

Live Demo TCP-Verbindungsabbau # telnet pi 4 discard Trying 134. 155. 48. 96 Connected to pi 4. Escape character is `^]`. telnet> ^] (=control + ]) telnet> quit Connection closed. Martin Mauve Universität Mannheim

TCP Reset l 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

TCP Reset l 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) l 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 l bei Java geschieht dies mit: set. So. Linger(int x), dies gibt an, daß der Socket nach x Sekunden mit einem Reset geschlossen werden soll Martin Mauve Universität Mannheim

TCP PUSH Flag (PSH) l 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 l dies sollte z. B. für interaktive Anwendungen verwendet werden l wird inzwischen jedoch standardmäßig (fast) immer gesetzt, da keine Rechenzeit beim Auslesen der Puffer gespart werden muß Martin Mauve Universität Mannheim

TCP - Application Programming Interface l 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

TCP - API Beispiel: Command Client/Server l einfaches Java-Beispiel für einen sequentiell arbeitenden Server l Beobachten mittles tcpdump/ethereal! Martin Mauve Universität Mannheim

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

Delayed Acknowledgements l 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 rlogin client Martin Mauve rlogin server Universität Mannheim

TCP Delayed Acks - Demon l Martin Mauve wir verwenden rlogin und tcpdump, um zu sehen, wie TCP delayed acks verwendet Universität Mannheim

Delayed Acknowledgements l ein ack wird bei delayed acknowledgements i. d. R. um maximal 200 ms verzögert l während dieser Zeit können Daten, die gesendet werden, das ack „Huckepack“ (engl. piggiyback) mitnehmen, dies spart die Übertragung eines reinen ack Segmentes l werden innerhalb dieser Zeit keine Daten gesendet, so wird ein reines ack Segment übertragen l der 200 ms Timer wird nicht für jedes Paket aufgezogen, sondern läuft global, d. h. alle 200 ms werden alle acks verschickt, die noch offen sind Martin Mauve Universität Mannheim

Nagle Algorithm l wenn Segmente übertragen werden, die sehr klein sind, dann fällt viel Overhead in Form von Headern an l z. B. bei rlogin 40 Byte Header für 1 Daten Byte! l insbesondere in WANs (wide area networks) kann dies problematisch sein l zur Vermeidung dieses Problems wird der Nagle Algorithmus verwendet Martin Mauve Universität Mannheim

Nagle Algorithm l RFC 896 l ein Sender darf nur ein ausstehendes Segment haben, welches kleiner als die MSS ist l Idee: solange acks schnell zurückkommen behindert dies den Sender nicht, wenn acks langsam zurückkommen, dann ist es wichtig, daß möglichst wenige „tinygrams“ gesendet werden l Problem: manchmal möchte man dieses Verhalten nicht (z. B. bei X Window sollen Maus-Bewegungen ohne Verzögerung übertragen werden) l Lösung: man kann den Nagle Algorithmus abschalten, z. B. in Java: set. Tcp. No. Delay(boolean) Martin Mauve Universität Mannheim

5. 3 TCP Bulk Data Flow l was passiert, wenn man große Datenmengen per TCP überträgt? l wir schauen uns eine Dateiübertragung mittels ftp an (ethereal) l Frage: wann wird ein ack gesendet? § bisher: delayed ack nach 200 ms § das würde zu viele unbestätigten Paketen verursachen, wenn die Datenrate hoch ist (bulk data flow) § daher wird i. d. R. jedes 2 te Segment sofort bestätigt, auch wenn der 200 ms delayed ack timer noch nicht abgelaufen ist Martin Mauve Universität Mannheim

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

Schneller Sender und langsamer Empfänger l der Sender überträgt die Daten schneller, als sie der Empfänger aus dem Puffer lesen kann l 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) l 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

Congestion l 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

Congestion Window l um Congestion zu verhindern, wird beim Sender ein zusätzliches Congestion Window (cwnd) mitgeführt l cwnd wird wie das vom Empfänger mitgeteilte flow control window in Bytes geführt l ein Sender darf nur das MINIMUM aus (cwnd, Emfänger Window) an Daten senden Martin Mauve Universität Mannheim

Slow Start l das cwnd wird zu Beginn einer Verbindung mit einer MSS (wie vom Kommunikationspartner angekündigt) initialisiert l 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

Slow Start l mittels slow start soll schnell der Wert bestimmt werden, den man senden kann, ohne Paketverlust hervorzurufen l 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

Slow Start l slow start terminiert, wenn die ersten Paketverluste auftreten, dann kommt es zu congestion avoidance (wird erklärt, wenn wir Verlusterkennung und Übertragungswiederholung besprechen) l ideal wäre es, wenn man einfach den durch slow start bestimmten Wert für die ganze Lebenszeit der Verbindung verwenden könnte l 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

5. 4 Zuverlässigkeit in TCP l generell wird Zuverlässigkeit in TCP durch acknowledgements gewährleistet l wenn der Sender kein acknowledgement für ein Segment erhält, wird dieses nach Ablauf eines Timers erneut übertragen l wenn nötig, wird dies wiederholt, bis eine Bestätigung vorliegt l damit dies funktioniert, benötigt man Wissen über die Netzwerkverzögerung zwischen Sender und Empfänger (round trip delay) Martin Mauve Universität Mannheim

Round Trip Delay-Messung l l 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

Round Trip Delay-Messung l die erste Idee hat nur bedingt funktioniert, da sie nicht resistent genug gegen plötzliche Schwankungen des round trip delays war l Idee: die Varianz muß 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

Karn‘s Algorithmus l 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 l 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

Fast Retransmit l Problem: was tun, wenn einzelnes Segment verloren gegangen ist, und die nachfolgenden Segmente vom Empfänger korrekt empfangen werden? l 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

Fast Retransmit l erhält der Sender ein duplicate ack, so kann: § entweder die Reihenfolge der Pakete im Netz verändert worden sein, § oder ein Paketverlust vorliegen l 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 l 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

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

Slowstart & Congestion Avoidance l l l 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!) l 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

Slowstart & Congestion Avoidance l 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 l 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) l l 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

Slowstart & Congestion Avoidance ohne Verluste Martin Mauve Universität Mannheim

Slowstart & Congestion Avoidance mit Verlusten Martin Mauve Universität Mannheim

TCP-Zusammenfassung l TCP bietet eine gesicherte, verbindungsorientierte Übertragung von Byte-Stömen l Verbindungsaufbau / -abbau l Zuverlässigkeit durch acks / timeout / fast retransmit l flow control durch Empfänger-Fenster l congestion control durch cwnd (AIMD) Martin Mauve Universität Mannheim