Modul 5: TCP-Flusskontrolle

Transkript

1 Modul 5: TCP-Flusskontrolle M. Leischner Internetkommunikation Folie 1

2 Prinzip des Sliding-Window: Zuverlässigkeit + Effizienz A B A B A B A B unbestätigtes Senden Stop-and-Wait Sliding-Window Sliding Window (Piggybacking) (bei TCP) unzuverlässig effizient zuverlässig ineffizient zuverlässig effizient zuverlässig effizient M. Leischner Netze, BCS, 2. Semester Folie 2

3 Sliding-Window - detaillierter Anwendung produziert 2 Segmente Diese Segmente liegen im und im Was ist der Unterschied zwischen und Was ist die Aufgabe von und Größe des s: 5 Größe des s: 3 Zeit M. Leischner Netze, BCS, 2. Semester Folie 3

4 Sliding-Window - detaillierter ACK 1 ACK 2 Was passiert jetzt Beide Segmente können gesendet werden Auswirkungen auf den und das Zeit M. Leischner Netze, BCS, 2. Semester Folie 4

5 Sliding-Window - detaillierter ACK 1 ACK 2 ACK 3 Anwendung produziert zwei weitere Segmente Was macht der Zeit M. Leischner Netze, BCS, 2. Semester Folie 5

6 Sliding-Window - detaillierter ACK 1 ACK 2 ACK 3 Anwendung produziert ein weiteres Segment Was passiert Was wäre, wenn sie zwei weitere Segmente produziert Seg 5 Zeit M. Leischner Netze, BCS, 2. Semester Folie 6

7 Sliding-Window - detaillierter ACK 1 ACK 2 ACK 3 ACK 1 kommt nun beim an Was passiert Seg 5 Zeit M. Leischner Netze, BCS, 2. Semester Folie 7

8 Sliding-Window - detaillierter Schieben des Fensters Versenden von Segment 4 Seg 5 ACK 1 ACK 2 ACK 3 ACK 4 Zeit M. Leischner Netze, BCS, 2. Semester Folie 8

9 Sliding-Window - detaillierter ACK 1 ACK 2 ACK 3 Nun kommt ACK 2 Was passiert Seg 5 ACK 4 Zeit M. Leischner Netze, BCS, 2. Semester Folie 9

10 Sliding-Window - detaillierter Schieben des Fensters Versenden von Seg 5 ACK 1 ACK 2 Für Fortgeschrittene: ACK 3 Was passiert, wenn ACK 4 und ACK 5 vor ACK 3 kommen Seg 5 ACK 4 Seg 5 ACK 5 Frage an alle: Wie groß soll das sein Wer legt das fest Zeit M. Leischner Netze, BCS, 2. Semester Folie 10

11 TCP-Sliding-Window Sende- und Empfangspuffer Spezielle Variante des Sliding-Window-Grundalgorithmus dynamische Fluss-Steuerung mittels "Advertised Window" Einbeziehung der verarbeitenden Anwendungen LastByteAcked+1 NextByteToBeSent LastByteSendable LastByteRead NextByteExpected Jetzt alles auf Byte-Niveau! LastByteReceived LastByteAcceptable Vergangenheit gesendet, aber noch nicht bestätigt kann gesendet werden im produzierende Anwendung freier nicht verwendbar abgearbeitet (gesendet und bestätigt) Vergangenheit verbrauchende Anwendung im Empfangspuffer und bereits bestätigt M. Leischner Internetkommunikation Folie 11 Empfangsfenster Empfangspuffer abgearbeitet (empfangen und weitergeleitet), ist wieder frei wird verworfen noch ausstehendes Byte außer der Reihe empfangen akzeptierbar (freies Empfangsfenster)

12 TCP-Flusskontrolle Segmente auf seite zu sendendes Segment Source Port Destination Port Sequence Number Acknowledgement Number Offset Reserved U A P R R CK SH ST G S YN F IN Advertised Window Size Checksum Urgent Pointer Options (variable Länge) Padding Source Port Destination Port Sequence Number Acknowledgement Number Offset Reserved U R G A CK P SH R ST S YN F IN empfangenes Segment Advertised Window Size Checksum Urgent Pointer Options (variable Länge) Padding LastByteAcked+1 Vergangenheit NextByteToBeSent "LastByteSendable" nicht verwendbar Advertised Window Size: Anzahl der Bytes, die der bereit ist, zu empfangen Formel: AdvertisedWinSize <= EmpfPuffer - (LastByteReceived- LastByteRead) produzierende Anwendung M. Leischner Internetkommunikation Folie 12

13 TCP-Flusskontrolle "Zero advertised window size" deadlock AdWin=0 AdWin=4096 dieses Segment geht verloren! Dargestelltes Problem: Wie kommt es zum Deadlock Lösung des Problems: benutzt einen persistenten Timer, um periodisch ein Zero-Window-Probe- Segment zu senden, sobald das fenster geschlossen ist. (Algorithmus: Exponentieller Back-Off-Algorithmus: Startwert 1.5 Sek., Verdopplung nach jedem Ack bis Limit, z.b. 60 s, erreicht. 1, ) Probe-Segment enthält keine Nutzdaten. Spezifikation erlaubt explizit das Senden von Probe Segmenten auch nach geschlossenem fenster. (Beachte: solange das Probe-Segment nicht verarbeiten kann, enthält das ACK die Sequenz-Nummer des letzten angenommen Bytes) M. Leischner Internetkommunikation Folie 13

14 TCP-Flusskontrolle "Small Packet Problem" (Appl.: Telnet) 1 Byte ACK, AdWin=4 ACK, AdWin=5 1 Byte ACK, AdWin=4 ACK, AdWin=5 dargestelltes Problem: Versenden von zwei Byte erzeugt 240 Byte Overhead (2 Datensegmente á 40 Byte, 2 Acknowledgements á 40 Byte, 2 Fensteraktualisierungen á 40 Byte) Lösungen: seitig: delayed Acknowledgement: Verzögerung von Bestätigung und Fensteraktualisierungen um 200 ms (Idee dahinter: Huckepack, Sammeln von ACKs ) seitig: Nagle's Algorithm (RFC 896, 1984): Falls Daten byteweise von Anwendung kommen, sende nur das erste Byte, sammle Bytes auf und sende diese in einem Segment, sobald MSS erreicht oder das erste Byte bestätigt wird. Bei IP über LAN wenig Einfluss, aber bei WAN. Probleme bei interaktiven Anwendungen (Nagle's Algorithmus führt z.b. bei X-Window zu ruckeliger Arbeit). Daher ist Nagle's Alg. über Sockets abschaltbar. M. Leischner Internetkommunikation Folie 14

15 TCP-Flusskontrolle "Silly Window Syndrome (SWS) RFC 813" ACK, AdWin=0 ACK, AdWin=1 1 Byte ACK, AdWin=0 ACK, AdWin=1 dargestelltes Problem: Byteweise Verarbeitung auf seite: Der wird animiert, kleine Segmente zu senden. Lösungen: seitig: (1) Versenden von kleinen Datenmengen vermeiden. (2) Nagle's Algorithm. seitig: Fensteraktualisierungen nur bei größerem Betrag (z.b. wenn 30% vom Empfangspuffer oder 2 MSS frei) 1 Byte M. Leischner Internetkommunikation Folie 15

16 Fast Retransmit (Grundprinzip) Seg 5 Seg 6 Retransmit RTO ACK 1 ACK 2 dack 2 dack 2 dack 2 ACK 6 dargestelltes Problem: Grobe Einstellung des RTO führt zu Wartezeiten bei Paketverlust Lösung: Bei dreifachem duplicate ACK Retransmission des fehlenden Pakets ohne auf Ablaufen des Retransmissiontimers zu warten Neues Problem: Verlorenes Paket ist Zeichen für Überlastung des Netzes. Daher nach Fast Retransmit Reaktion auf Netzüberlast notwendig. > Themenstellung Überlastkontrolle Anmerkung: Fast Recovery: Algorithmus, um nach Fast Retransmit Datenfluss zu erhalten SACK (Selective Acknowledgement, RFC2018): Bestätigung der tatsächlich erhaltenen Segemente M. Leischner Internetkommunikation Folie 16

17 TCP-Acknowledgements (gemäß RFC 1122, 10/89) Ereignis Ankunft eines direkt nachfolgenden Segments, keine Lücke, alle vorhergehenden Segmente sind bereits bestätigt. Ankunft von direkt nachfolgenden Segmenten, keine Lücke Ankunft eines Segments, das ganz oder teilweise eine Lücke füllt (so dass ein Teil des Bytestroms vervollständigt wird). Ankunft eines out-of-order Segments größer als NextByteExpected (es entsteht Lücke). Reaktion TCP- delayed Acknowledgement: Warte bis zu 200 ms, ob neues Segment kommt, wenn bis dahin keines kommt, muss ein ACK gesendet werden. Senden eines kummulativen ACKs: Bestätigen von mehreren Segmenten mit einem Acknowledgement Immediate Acknowledgement: Sofortiges Senden eines ACKs. Senden eines duplicate ACKs: wiederholtes Senden des letzten ACKs (=Beginn der Lücke) M. Leischner Internetkommunikation Folie 17