Informations- und Kommunikationssysteme

Transkript

1 Informations- und Kommunikationssysteme Kapitel 2.3 Transportschicht Acknowledgement: Folien angelehnt an J.F. Kurose and K.W. Ross 1 Kapitel 2.3: Transportschicht Unsere Ziele: Prinzipien der Dienste der Transportschicht: Multiplexing / Demultiplexing Verlässlicher Datentransfer Flusskontrolle Staukontrolle Anwendung auf Protokolle der im Internet: UDP: verbindungsloser Transport TCP: verbindungsorientierter Transport 2

2 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 3 Transportdienste und -protokolle Ziel: Bereitstellen einer logischen Kommunikation zwischen Anwendungen auf verschiedenen Hosts Transportschichtprotokolle laufen in Endsystemen Senderseite: Zerlegen von Nachrichten in Segmente, Weitergabe an Netzwerk Empfängerseite: Zusammensetzen der Segmente, Weiterleitung an Anwendung Mehrere Transportnetzprotokolle application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical Internet: i.d.r. TCP und UDP 4

3 Transport vs. Netzwerkschicht Netzwerkschicht: logische Kommunikation zwischen Hosts Transportschicht: logische Kommunikation zwischen Prozessen basiert auf und erweitert Dienste der Netzwerkschicht Analogie zu Haushalten: Kinder einer Familie senden Briefe an andere Familie Prozesse = Kinder Nachrichten= Briefe in Umschlägen Hosts = Häuser Adressen des Transportprotokolls = Annika und Thomas Protokoll der Netzwerkschicht = Postdienst 5 Internet Protokolle der Transportschicht Verlässliche Auslieferung in Reihenfolge: TCP Staukontrolle Flusskontrolle Verbindungsaufbau Unverlässliche Auslieferung: UDP Einfache Erweiterung des best-effort IP application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical Nicht verfügbare Dienste: Latenzgarantien Bandbreitengarantien application transport network data link physical 6

4 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 7 Multiplexing/Demultiplexing Demultiplexing im Empfänger: Ausliefern empfangener Segmente zum richtigen Socket = Socket = Prozess Multiplexing im Sender: Datenempfang von mehren Sockets, Verpacken mit Header (später genutzt für Demultiplexing) application P3 P1 application P2 P4 application transport transport transport network network network link link link physical physical Host 1 Host 2 Host 3 physical 8

5 Funktionsweise des Demultiplexing Host empfängt IP-Pakete Jedes Paket besitzt Quell-IP- Adresse und Ziel-IP-Adresse Jedes Paket enthält 1 Segment für Transportschicht Jedes Segment enthält Quellund Ziel-Port (Port-Nummer sind i.d.r. für Anwendungen festgeschrieben) Host nutzt IP-Adresse & Port- Nummern um Segment an korrekten Socket auszuliefern 32 bits Quell-Port # Ziel-Port # Andere Header-Felder Anwendungsdaten (Nachricht) TCP/UDP Segmentformat 9 Verbindungsloses Demultiplexing UDP-Sockets werden durch Zweitupel identifiziert: (Ziel-IP-Adresse, Ziel-Port-Nummer) Erstellen von Sockets mit bestimmten Port-Nummern: DatagramSocket mysocket1 = new DatagramSocket(9111); DatagramSocket mysocket2 = new DatagramSocket(9222); Host beim Empfang eines UDP- Segmentes: Überprüft Ziel-Port in Segment Leitet weiter an Socket mit der gleichen Nummer Quell-IP-Adresse und Quell- Port-Nummer sind irrelevant für Entscheidung! 10

6 Verbindungsloses Demultiplexing (II) DatagramSocket serversocket = new DatagramSocket(6428); P2 P3 P1 QP: 6428 ZP: 9157 QP: 6428 ZP: 5775 QP: 9157 QP: 5775 Client IP: A ZP: 6428 Server IP: C ZP: 6428 Client IP:B Quell-Port (QP) nur als Teil der Antwortadresse nötig! 11 Verbindungsorientiertes Demultiplexing TCP-Socket identifiziert durch 4-Tupel: Quell-IP-Adresse Quell-Port-Nummer Ziel-IP-Adresse Ziel-Port-Nummer Empfänger nutzt alle vier Werte um Socket zu bestimmen! Server kann mehrere TCP- Sockets simultan verwenden: Jeder Socket verwendet eigenes 4-Tupel Webserver haben Sockets für jeden verbundenen Client Bei nicht-persistentem HTTP sogar für jede Anfrage einen Socket 12

7 Verbindungsorientiertes Demultiplexing (II) P1 P4 P5 P6 P2 P1 P3 QP: 5775 ZP: 80 Q-IP: B Z-IP:C QP: 9157 QP: 9157 Client IP: A ZP: 80 Q-IP: A Z-IP: C Server IP: C ZP: 80 Q-IP: B Z-IP: C Client IP:B 13 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 14

8 UDP: User Datagram Protocol [RFC 768] Internet Protokoll ohne Extras Best Effort Dienst, UDP- Segmente können: verloren gehen in falscher Reihenfolge ankommen Verbindungslos: kein Handshake jedes UDP-Segment wird unabhängig von anderen behandelt Wozu gibt es UDP? Kein Verbindungsaufbau (der verzögern kann) Einfach: kein Verbindungszustand in Sender oder Empfänger Kleiner Header Keine Staukontrolle: UDP kann immer beliebig schnell senden Keine Verzögerung durch Neuanfordern verlorener Pakete 15 User Datagram Protocol (II) Oft genutzt für Multimedia- Anwendungen Tolerant gegen Verlust Sensitiv gegen Länge des Ratenänderungen UDP-Segments in Bytes Weitere Anwendungen: (incl. Header) DNS SNMP Verlässlicher Verkehr über UDP muss auf Anwendungsschicht realisiert werden Erlaubt app.-spezifische Korrektur! Quell-Port # Ziel-Port # Länge 32 bits Prüfsumme Anwendungsdaten (Nachricht) UDP Segmentformat 16

9 UDP-Prüfsumme Ziel: Fehlererkennung (e.g., Bitkipper) im Datensegment Sender: Behandelt Segment als Sequenz von 16-Bit Ganzzahlen Prüfsumme: Addition (sog. 1 s complement sum) der Ganzzahlen Sender vermerkt Prüfsumme im UDP Header Empfänger: Berechnet Prüfsumme des empfangenen Segmentes Prüft ob berechnete Prüfsumme der übertragenen entspricht: NEIN Fehler erkannt JA Kein Fehler erkannt. Aber vielleicht trotzdem Fehler? 17 Internet Prüfsumme - Beispiel Notiz Wenn Ganzzahlen addiert werden, wird der Übertrag dem Ergebnis hinzugefügt! Beispiel: Addition zweier 16-Bit Ganzzahlen Übertrag Summe Prüfsumme

10 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 19 Prinzipien des verlässlichen Datentransports Wichtig auf Anwendungs-, Transport- & Datensicherungsschicht Immer wieder auch Forschungsthema! Charakteristik des unverlässlichen Kanals bestimmt Komplexität des Protokolls für den verlässlichen Datentransfers (reliable data transfer protocol, rdt) 20

11 Verlässlicher Datentransport rdt_send(): Aufgerufen von Anwendungsschicht, soll Daten an Anwendung des Empfängers übergeben deliver_data(): Aufgerufen von rdt um Daten an Applikation auszuliefern Senderseite Empfängerseite udt_send(): Aufgerufen von rdt, um Daten über unverlässlichen Kanal zusenden rdt_rcv(): Aufgerufen wenn Paket auf Senderseite ankommt 21 RDT 1: Verlässlicher Transport über verlässlichen Kanal Annahme: Zugrunde liegender Kanal vollständig verlässlich Keine Bitfehler Keine Paketverluste Kein Überholen von Paketen Sender übergibt Daten ohne weitere Maßnahmen an Kanal Empfänger liest Daten vom Kanal rdt_send(data) rdt_rcv(packet) Sender Empfänger 22

12 RDT 2: Kanal mit Bitfehlern Annahme: Zugrunde liegender Kanal kann Bits in Paket kippen und Prüfsumme detektiert alle Fehler Frage: Wie werden Fehler behoben? Acknowledgements (ACKs): Empfänger quittiert den Empfang jedes korrekten Paketes explizit mit OK Negative acknowledgements (NAKs): Empfänger meldet fehlerhaft empfangene Pakete Sender übermittelt Paket bei Empfang eines NAK erneut Neue Mechanismen in RDT2 (im Vergleich zu RDT1): Fehlererkennung Rückmeldung beim Empfänger durch Kontrollnachrichten (ACK, NAK) 23 RDT 2: Beispiel ohne Bitfehler rdt_send(data1) udt_send(data1) rdt_rcv(data1) udt_send(ack) rdt_rcv(ack) mit Bitfehlern rdt_send(data1) rdt_rcv(nack) udt_send(data1) rdt_send(data1) udt_send(data1) rdt_rcv(data1*) udt_send(nack) rdt_rcv(ack) udt_send(ack) Sender Empfänger Sender Empfänger 24

13 RDT 2: Probleme bei Verlust von Kontrollnachrichten F: Was passiert wenn ACK/NAK fehlerhaft sind? Sender weiß nicht ob der Empfänger das Paket korrekt erhalten hat! Erneute Übermittlung würde zu Duplikaten führen Umgang mit Duplikaten: Sender fügt eine Sequenznummer zu jedem Paket hinzu Sender übermittelt aktuelles Paket wenn ACK/NAK fehlerhaft ist Empfänger verwirft duplizierte Pakete (i.e. übergibt sie nicht erneut an Anwendung) 25 RDT 3: Kanäle mit Fehlern und Verlusten Neue Annahme: Kanal kann auch Pakete verlieren (Daten und ACKs) Prüfsummen, Seq. #, ACKs, Neuübermittlung hilft, reicht aber nicht Stop-and-Wait Sender sendet genau ein Paket und wartet dann auf Antwort des Empfängers Ansatz: Sender wartet angemessene Zeit auf ein ACK Erneute Übermittlung falls kein ACK erhalten wurde Falls Daten (oder ACK) nur verzögert wurden: Erneute Übertragung führt zu Duplikaten, aber Seq. # verwerfen Daten Empfänger muss Seq # des Paketes für das ACK mit angeben Erfordert Countdown Timer 26

14 RDT 3: Beispiele 27 RDT 3: Beispiele 28

15 Performanz von RDT 3 RDT 3 funktioniert, aber schlechte Nutzung der Ressourcen Beispiel: 1 Gbps Link, 15 ms Ausbreitungsverzögerung, 1KB Paket: d Übertragung = L (Paketlänge in Bits) R (Übertragungsrate, bps) = 8 kbit 10 9 bit/s = 8 µs U Sender = L / R RTT + L / R = = ! U Sender : Utilization Auslastung, Anteil der Zeit die für das Senden verwendet wird! 1KB Paket alle 30 ms -> 33KB/s Durchsatz über den 1 Gbps Link! Das Netzwerkprotokoll limitiert Nutzung der Ressourcen! 29 RDT 3: Stop-And-Wait im Einsatz Erstes Paket Bit übermittelt, t = 0 Letztes Bit übermittelt, t = L / R Sender Empfänger RTT Erstes Paket Bit kommt an Letztes Bit kommt an, ACK wird gesendet ACK kommt an, nächstes Paket wird gesendet, t = RTT + L / R U Sender = L / R RTT + L / R = =

16 Lösung: Pipelining Pipelining: Sender erlaubt mehrere Pakete ohne Acknowledgement Zahlenbereich der Sequenznummern muss erhöht werden Puffern von Paketen im Sender und/oder Empfänger notwendig! Zwei verschiedene Unterarten von Protokollen mit Pipelining: Go-Back-N, Selective Repeat 31 Pipelining führt zu besserer Auslastung Erstes Paket Bit übermittelt, t = 0 Letztes Bit übermittelt, t = L / R Sender Empfänger RTT ACK kommt an, nächstes Paket wird gesendet, t = RTT + L / R Erstes Paket Bit kommt an Letztes Bit kommt an, sende ACK 2. Paket vollständig, sende ACK 3. Paket vollständig, sende ACK Auslastung um Faktor 3 gesteigert! U Sender = 3 * L / R RTT + L / R = =

17 Go-Back-N Sender: k-bit Sequenznummer im Paket-Header Window von bis zu N, aufeinanderfolgenden Paketen ohne ACK erlaubt! ACK(n): ACK für alle Pakete bis Seq # n (inklusive) cumulative ACK! u.u. führt dies zu ACK-Duplikaten (siehe Empfänger)! Timer für jedes Paket im Transfer! Timeout(n): Erneute Übermittlung von Paket n und aller Pakete mit höheren Seq # im Fenster 33 Beispiel für Go-Back-N (Window: 4) 34

18 Selective Repeat Empfänger sendet individuelle ACKs für alle korrekt erhaltenen Pakete Puffern von Paketen nach Bedarf bis zur korrekten Auslieferung an höhere Schicht Sender überträgt nur Pakete ohne ACK erneut Timer für jedes Paket ohne ACK Window des Senders N aufeinanderfolgende Seq # (Auch hier) Zahlenraum der Seq # limitiert die Anzahl der zu sendenden Pakete ohne ACK 35 Selective Repeat: Windows von Sender & Empfänger 36

19 Beispiel für Selective Repeat 37 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 38

20 TCP: Überblick (RFCs: 793, 1122, 1323, 2018, 2581) socket door Punkt-zu-Punkt: ein Sender, ein Empfänger Verlässlicher, geordneter Byte-Strom: keine Nachrichtengrenzen Pipelined: TCP-Stau- und Flusskontrolle bestimmen Window-Größe Sende- & Empfangspuffer application writes data TCP send buffer segment application reads data TCP receive buffer Vollduplex-Übertragung: Bidirektionaler Datenfluss über gleiche Verbindung MSS: Maximum Segment Size Verbindungsorientiert: Handshaking initialisiert vom Sender, erzeugt Zustand im Empfänger vor Datenaustausch Flusskontrolle: Sender überlastet Empfänger nicht socket door 39 TCP: Segmentstruktur URG: eilige Daten (kaum benutzt) ACK: ACK # gültig PSH: pushed Auslieferung (kaum benutzt) RST, SYN, FIN: Kontrollpakete (Verb.-aufbau, Abbau Kommandos) Internet Prüfsumme (wie in UDP) 32 bits Quell-Port # Ziel-Port # head len res. Sequenznummer Prüfsumme ACK-Nummer U A P R S F Window Urg data pointer Optionen (variable Länge) Anwendungsdaten (variable Länge) Zähler in Bytes (nicht Segmente!) # Bytes die Empfänger akzeptiert 40

21 TCP: Sequenznummern und ACKs Seq. # s: Byte-Strom Zähler des ersten Bytes im Segment ACKs: Seq # des nächsten Bytes das erwartet wird Cumulative-ACKs F: Wie soll Empfänger mit Paketen in falscher Reihenfolge umgehen? User tippt C Host sendet ACK für C -Echo Host A Host B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 Host sendet ACK für C, und gibt C -Echo im Fenster aus A: In TCP nicht standardisiert Freie Entscheidung des Implementierers Ein einfaches Telnet-Szenario Zeit 41 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 42

22 TCP: Verlässlicher Datentransfer TCP stellt rdt auf Basis vom unverlässlichen IP-Dienst bereit Pipelining von Segmenten Cumulative ACKs TCP nutzt einzelnen Timer zur Neuübermittlung Neuübermittlung durch: Timeout-Ereignisse Duplizierte ACKs Beispiel an einem vereinfachten TCP-Sender: Ignoriert ACK-Duplikate Ignoriert Fluss- und Staukontrolle 43 TCP: Round Trip Time und Timeout F: Wie setzt TCP den Timeout-Wert? Etwas länger als RTT Aber: RTT variiert Zu kurz: vorzeitiger Timeout Unnötige Neuübertragungen Zu lang: Langsame Reaktion auf Verluste F: Wie kann RTT geschätzt werden? SampleRTT: gemessene Zeit von der Segmentübermittlung bis zum Empfang des korrespondierenden ACK Neuübertragungen werden ignoriert! SampleRTT variiert, geschätzte RTT muss geglättet werden Durchschnitt über mehrere Messungen, nicht nur aktuelle SampleRTT 44

23 TCP: Round Trip Time und Timeout EstimatedRTT = (1-α) * EstimatedRTT + α * SampleRTT! Exponential Weighted Moving Average! Einfluss alter Messungen nimmt exponentiell ab! Typischer Wert: α = TCP: Beispiel einer RTT-Schätzung RTT: gaia.cs.umass.edu to fantasia.eurecom.fr RTT (milliseconds) time (seconnds) SampleRTT Estimated RTT 46

24 TCP: Round Trip Time und Timeout Setzen des Timeouts EstimtedRTT plus Sicherheit Große Variation der EstimatedRTT -> Größerer Sicherheitswert Erste Schätzung: Abweichung der SampleRTT von der EstimatedRTT: DevRTT = (1-β)*DevRTT + β* SampleRTT-EstimatedRTT (typischerweise, β = 0.25) Setzen des Timeout-Intervalls: TimeoutInterval = EstimatedRTT + 4*DevRTT 47 TCP: Ereignisse auf Senderseite Daten von Anwendung empfangen: Erstellen eines Segmentes mit aktueller Seq # Ausliefern des Segmentes an untere Schicht Starten des Timers, falls dieser nicht bereits läuft Timer verantwortlich für das jeweils älteste Segment ohne ACK Ablaufinterval: TimeOutInterval Timeout: Erneute Übermittlung des Segments das für Timeout verantwortlich war Timer neustarten ACK empfangen: Falls neues Acknowledgement Aktualisieren der bekannten korrekt empfangenen Pakete Starten des Timers falls weitere ACKs ausstehen 48

25 Seq=92, 8 bytes data TCP: Szenarien der Neuübermittlung Host A Host B Host A Host B Timeout Seq=92, 8 bytes data X Verlust ACK=100 Seq=92 Timeout Seq=92, 8 bytes data Seq=100, 20 bytes data SendBase = 100 Zeit Seq=92, 8 bytes data ACK=100 Verlorenes ACK Sendbase = 100 SendBase = 120 SendBase = 120 Seq=92 Timeout Zeit Seq=92, 8 bytes data Zu kurzes Timeout 49 TCP: Szenarien der Neuübermittlung (II) Host A Host B Timeout Seq=100, 20 bytes data X Verlust ACK=100 SendBase = 120 ACK=120 Zeit Kumulatives ACK 50

26 TCP: Fast Retransmit Timeout-Intervall oft vergleichsweise lang: Große Verzögerung bevor verlorene Pakete erneut übertragen werden Detektion verlorener Segmente über duplizierte ACKs: Sender schickt oft viele Segmente direkt hintereinander Falls Segmente verloren gehen werden sehr wahrscheinlich duplizierte ACKs auftreten Falls Sender drei ACKs für die selben Daten erhalten, wird angenommen, dass das folgende Segment verloren gegangen ist Fast Retransmit: Erneute Übertragung von Segmente bevor Timer abläuft 51 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 52

27 TCP: Flusskontrolle Empfängerseite von TCP besitzt Datenpuffer Aber: Anwendungsprozess liest u.u. Daten nur langsam ein Flusskontrolle Sender überlastet Puffer des Empfängers nicht durch zu schnelles Senden Im Prinzip Geschwindigkeitsabgleich: Senderate wird automatisch an Empfangsbereitschaft angepasst 53 TCP: Arbeitsweise der Flusskontrolle (Annahme TCP-Empfänger verwirft Segmente in falscher Reihenfolge) Freier Platz im Puffer = RcvWindow = RcvBuffer -[LastByteRcvd - LastByteRead] Empfänger übermittelt freien Platz indem RcvWindow in Segmenten übertragen wird Sender limitiert # der Pakete ohne ACK auf RcvWindow Garantiert Einhalten der Puffergröße 54

28 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 55 TCP: Verbindungs-Management Erinnerung: TCP-Sender & Empfänger bauen vor Datenaustausch eine Verbindung auf Initialisiert TCP-Variablen: Sequenznummern Puffer, Flusskontrollinformationen (e.g. RcvWindow) Three-Way-Handshake: Schritt 1: Client sendet TCP-SYN-Segment an Server Schritt 2: legt initiale Sequenz-# fest keine Daten Server empfängt SYN, antwortet mit SYNACK-Segment Schritt 3: Server reserviert Puffer Enthält Sequenz-# des Servers Client empfängt SYNACK, antwortet mit ACK, welches Daten enthalten darf 56

29 TCP: Verbindungs-Management (II) Schließen einer Verbindung Client schließt Socket: Step 1: Client Host sendet TCP FIN Kontrollsegment an Server schließen Client FIN Server Step 2: Server empfängt FIN, antwortet mit ACK. Schließt Verbindung und sendet ebenfalls FIN. timed wait ACK FIN ACK schließen geschlossen 57 TCP: Verbindungs-Management (III) Schritt 3: Client empfängt FIN, antwortet mit ACK. Client Server Beginnt mit Timed Wait - Zustand und antwortet mit ACK auf empfangene FINs schließen FIN Schritt 4: Server empfängt ACK. Verbindung geschlossen. ACK FIN schließen Anmerkung: Kleine Änderungen nötig um auf gleichzeitige FINs zu reagieren. Timed Wait geschlossen ACK geschlossen 58

30 TCP: Verbindungs-Management (IV) TCP-Client Lebenszyklus 59 TCP: Verbindungs-Management (V) TCP-Server Lebenszyklus 60

31 Kapitel 2.3 Roadmap 3.1 Dienste der Transportschicht 3.2 Multiplexing und Demultiplexing 3.3 Verbindungsloser Transport: UDP 3.4 Prinzipien des verlässlichen Datentransfers 3.5 Verbindungsorientierter Transport: TCP Segmentstruktur Verlässlicher Datentransfer Flusskontrolle Verbindungs-Management TCP-Staukontrolle 61 TCP: Prinzipien der Staukontrolle Überlast, Stau: Informell: zu viele Quellen senden für das Netzwerk zu viele Daten in zu kurzer Zeit Unterscheidet sich signifikant von Flusskontrolle! Erscheinungen in diesem Kontext: Verlorene Pakete (Pufferüberläufe in Routern) Lange Verzögerungen (Warteschlangen in Routern) 62

32 TCP: Staukontrolle Ende-zu-Ende-Mechanismus (keine Netzwerkunterstützung) Sender limitiert gesendete Pakete: LastByteSent - LastByteAcked CongWin Es gilt in etwa, Rate = CongWin RTT CongWin ist dynamisch hängt von angenommener Netzauslastung ab Bytes/s Wie beobachtet ein Sender Stau? Paketverlust = Timeout oder 3 duplizierte ACKs TCP-Sender reduziert Rate (CongWin) nach jedem Verlust Drei Mechanismen: AIMD Slow-Start Konservativ nach Timeout 63 TCP: Staukontrolle - AIMD Additive Increase: Erhöhen des CongWin um 1 MSS pro RTT ohne Verlust: probing congestion window Multiplicative Decrease: halbiere CongWin bei jedem Verlust 24 Kbytes 16 Kbytes 8 Kbytes time AIMD in langlebiger TCP-Verbindung 64

33 TCP: Staukontrolle Slow Start Nach Verbindungsaufbar CongWin = 1 MSS Beispiel: MSS = 500 Bytes & RTT = 200 ms Initiale Senderate = 20 kbps Verfügbare Bandbreite kann sehr viel größer als MSS/RTT sein Gewünscht: Schnelles Hochregeln zu geeigneter Rate Nach Verbindungsaufbau: Exponentielles Erhöhen der Rate bis zum ersten Verlust F: Wie passt der Name Slow Start zum exponentiellen Wachstum? 65 TCP: Staukontrolle Slow Start (II) Nach Verbindungsaufbau: Exponentielles Erhöhen der Rate bis zum ersten Verlust: Verdoppeln des CongWin nach jeder RTT CongWin wird bei jedem empfangenen ACK um 1 erhöht RTT Host A Host B ein Segment zwei Segmente Zusammenfassung: Initiale Rate ist langsam, aber wächst sehr schnell vier Segmente Zeit 66

34 TCP: Staukontrolle Mehr Details Nach 3 duplizierten ACKs: CongWin wird halbiert Window wächst dann linear Aber nach Timeout: CongWin wird auf 1 MSS gesetzt Window wächst exponentiell nach Schwellwert lineares Wachstum Grundannahme:! 3 duplizierte ACKs zeigen, dass das Netz wenigstens einige Nachrichten korrekt transportiert! Timeout ist wesentlich alarmierender 67 TCP: Staukontrolle Mehr Details (II) F: Wann wird zwischen exponentiellem und linearen Wachstum umgeschaltet? A: Wenn CongWin bei der Hälfte des vorherigen Wertes ist Implementierung: Variabler Schwellwert Bei Verlust wird Schwellwert, auf 1/2 des CongWin gesetzt, bevor dessen Wert reduziert wird 68

35 TCP: Fairness, Gerechtigkeit Fairness : Wenn k TCP-Verbindungen über den gleichen Engpass (Flaschenhals, bottleneck) mit Bandbreite R geleitet werden, sollte jede eine durchschnittliche Rate von R/k haben TCP Verbindung 1 TCP Verbindung 2 Flaschenhals Router mit Kapazität R 69 Zusammenfassung: TCP Staukontrolle Wenn CongWin kleiner als ist Threshold, befindet sich der Sender in der Slow-Start-Phase Window wächst exponentiell. Wenn CongWin größer als Threshold, befindet sich der Sender in der Congestion-Avoidance-Phase Window wächst linear. Wenn 3 duplizierte ACKs auftreten: Threshold wird auf CongWin/2 gesetzt und CongWin auf Threshold. Wenn ein Timeout auftritt: Threshold wird auf CongWin/2 gesetzt und CongWin auf 1 MSS. 70

36 TCP: Durchsatz Wie hoch ist der durchschnittliche Durchsatz von TCP in Bezug auf Window-Größe und RTT? Annahme: kein Slow-Start, Flusskontrolle nicht limitierend W = Window-Größe wenn Verlust auftritt. Durchsatz ist dann W / RTT Nach jedem Verlust: Window sinkt auf W/2, Durchsatz W / 2 / RTT. Durchschnittlicher Durchsatz: 0.75 W/RTT (da linearer Anstieg) 71 TCP Modellierung von Verzögerungszeiten F: Wie lang dauert die Übertragung eines Objektes von einem Webserver nach Absenden der Anfrage? Annahme kein Stau Verzögerung beeinflusst durch: TCP-Verbindungsaufbau Datenübertragungsverzögerung Slow-Start Notation, Annahmen: Zwischen Client und Server ein Link mit Rate R S: MSS (max. segment size, Bits) O: Objektgröße (Bits) keine Neuübertragung (kein Verlust, keine Bitfehler) Window-Größe: Zunächst: festes Congestion Window mit W Segmenten Anschließend: Dynamisches Window & Slow Start 72

37 TCP Latenz bei festem Congestion Window (I) Erster Fall: WS/R >= RTT + S/R: ACKs erreichen Server bevor durch Window vorgegebener Kredit erschöpft ist Verzögerung = 2 RTT + O/R 73 TCP Latenz bei festem Congestion Window (II) Zweiter Fall: WS/R < RTT + S/R: Warten auf ACKs nach Nutzen des vollen Kontingents Verzögerung = 2 RTT + O/R + (K-1)[S/R + RTT - WS/R] 74

38 TCP Latenz: Slow Start (I) Neue Annahme: Latenz wächst wie bei Slow-Start-Algorithmus Wir zeigen, dass die Latenz für ein Objekt den folgenden Wert hat: Latenz = 2RTT + O R + P! RTT + S $ " # R% & (2P 1) S R wobei P die Anzahl der Zyklen ist, die TCP im Server wartet: P = min{ Q, K 1} - wobei Q die Anzahl der Wartezyklen ist, wenn das Objekt unendliche Größe hätte. - K ist Anzahl der Windows die für das Objekt gebraucht werden. 75 TCP Latenz: Slow Start (II) Komponenten Latenz:! 2 RTT für Verb.- aufbau und Request! O/R zum Senden des Objektes! Wartezeit durch Slow- Start! Server wartet: P = min{k-1,q} mal initiate TCP connection request object RTT first window = S/R second window = 2S/R third window = 4S/R Beispiel:! O/S = 15 Segmente! K = 4 Windows! Q = 2! P = min{k-1,q} = 2! Server wartet P=2 mal object delivered time at client time at server fourth window = 8S/R complete transmission 76

39 Modellierung der HTTP-Antwortzeit Annahme Webseite besteht aus: einer HTML-Seite (der Größe O Bits) M Bildern (jeweils O Bits) Nicht-persistentes HTTP: M+1 aufeinander folgende TCP-Verbindungen Antwortzeit = (M+1)O/R + (M+1)2RTT + Summe der Wartezeiten Persistentes HTTP (mit Pipelining): 2 RTT um eine HTML-Datei anzufragen und zu erhalten 1 RTT um M Bilder anzufragen und zu erhalten Antwortzeit = (M+1)O/R + 3RTT + Summe der Wartezeiten Nicht-persistentes HTTP mit x Parallelverbindungen Annahme: M/x ganzzahlig. 1 TCP Verbindung für HTML-Datei M/x Folgen von x parallelen Verbindungen für die Bilder. Antwortzeit = (M+1)O/R + (M/x+1)2RTT + Summe der Wartezeiten 77 Kapitel 2.3: Zusammenfassung Grundlegende Prinzipien von Diensten der Transportschicht: Multiplexing, Demultiplexing Verlässlicher Datentransfer Flusskontrolle Staukontrolle Verwendung und Implementierung im Internet: UDP TCP Anschließend: Verlassen der Network Edge (Anwendungs- & Transportschicht) Behandlung des Network Core 78