Datennetze Teil 3: Transportschicht Sommersemester 2004 Prof. Dr. Thomas Wieland (C) U. Stein
Übersicht Teil 3 3.1 Einführung 3.2 Struktur von TCP/IP 3.3 Einfache IP-Protokolle 3.4 Sender/Empfänger-Koordination 3.5 Transmission Control Protocol (TCP) 3.6 Überlastkontrolle 2
3.1 Einführung
Entstehungsgeschichte des Internet Mythos: Internet wurde für militärische Zwecke entwickelt Tatsache: Ein Mitarbeiter der ARPA (Advanced Research Projects Agency) ärgerte sich, dass für die Verbindung mit drei Unis drei verschiedene Terminals nötig waren Näheres in "ARPA Kadabra" von K. Hafner und M. Lyon 4
Pionierzeit 1967: ARPA des DoD vergibt Auftrag Projektstudie ausfalltolerantes Paketnetz an SRI (Stanford Research Institute) 1969: Erstes Internet aus 4 Knoten: University of California at Los Angeles (UCLA), Stanford Research Institute (SRI), University of California at Santa Barbara (UCSB), University of Utah Entscheidung für paketvermittelndes Netz nach Store-And- Forward-Prinzip Paket wird von Vermittlungsstation komplett entgegengenommen Weiterleitung erst nach vollständigem Empfang 1971: Betriebsaufnahme des ARPANet 1972: Erste öffentliche Demonstration 1974: Neue Protokollsuite: TCP/IP 5
Verbreitung und Kommerzialisierung 1980: Integration der TCP/IP-Protokolle in UNIX 1986: NSFNet (National Science Foundation) als zweiter Backbone 1988: IP-Verbindung zum Internet aus Deutschland 1991: WWW wird entwickelt 1995: Kommerzielle Provider für Internetzugänge von Privatleuten 1999: Mehr als 200 Mio. Internet-Nutzer weltweit 6
3.2 Struktur von TCP/IP
Struktur von TCP/IP Application Layer Layer anwendungsnahe Protokolle, z.b. TELNET, FTP, SMTP, DNS korrekte Zustellung von Paketen Definition von Paketformaten Protokoll: IP Zugang zum physikalischen Übertragungsmedium Host-to-Host Transport Layer Layer Internet Layer Layer Network Access Layer Layer Ende-zu-Ende- Verbindung zwischen Hosts Protokolle: TCP und UDP 8
Internet-Architektur Definiert von der Internet Engineering Task Force (IETF) "Doppelkegel"-Design Anwendung vs. Anwendungsprotokoll (FTP, HTTP) FTP HTTP NV TFTP TCP UDP IP NET 1 NET 2 NET n 9
Network Access Layer Definiert, wie zugrunde liegendes Netz zur Übertragung von Daten der höheren Schichten genutzt wird Anpassung an das Datenformat des Netzes Abbildung von logischen Adressen auf physikalische Adressen des Netzwerks Umfasst etwa Bitübertragungs- und Sicherungsschicht aus ISO/OSI-Modell Protokolle spezifisch für zugrunde liegende Netzvariante 10
Internet Protocol (IP) Protokoll auf Internet Layer verantwortlich für Übermittlung von Daten zwischen Stationen Stationen sind entweder Hosts (Endstationen) oder Gateways (Transitstationen) Entspricht etwa Vermittlungsschicht bei ISO/OSI Erledigt auch Netzüberwachung Identifikation und Weitermeldung nicht erreichbarer Empfangsstationen IP: ungesichertes, verbindungsloses Protokoll Fehlerbehandlung erfolgt durch andere Schichten Sorgt für Routing der Pakete Suche geeigneter Übermittlungspfade von Sender zum Empfänger "Best effort": Pakete können u.u. verloren gehen oder verfälscht ankommen 11
Dienstmodell bei IP IP: ungesichertes, verbindungsloses Protokoll Fehlerbehandlung erfolgt durch andere Schichten Dienstmodell "Best effort" Pakete können verloren gehen Pakete können in anderer Reihenfolge eintreffen als gesendet Duplikate von Paketen können eintreffen Pakete können lange verzögert werden D.h.: Übertragung nicht garantiert, Zeit bis zu Auslieferung nicht garantiert Ungeeignet für Echtzeitanforderungen! 12
User Datagram Protocol (UDP) Unzuverlässiges verbindungsloses Protokoll ungesichert hinsichtlich Paketverlust broadcast- und multicastfähig Arbeitet im Host-to-Host Transport Layer Zuständig für Ende-zu-Ende- Übertragung Entspricht der Transportschicht Merkmale: Vermeidung von Overhead zugunsten möglichst schneller Übermittlung, vor allem für kleine Datenmengen geeignet Flusskontrolle, Fehlererkennung und -behandlung muss anderweitig gewährleistet werden Im Wesentlichen Hinzufügen von Port-Nummern ( Transportadressen ) zu IP Ports können von (den Prozessen) einer Anwendung benutzt werden 13
Transmission Control Protocol (TCP) Alternatives Protokoll im Hostto-Host Transport Layer Aufwändiger als UDP zuverlässiges verbindungsorientiertes Protokoll Segmentierung des eingehenden bzw. Erzeugung des ausgehenden Bytestroms Merkmale: Stellt Aspekte der Flusssteuerung bereit Verwendet Sendewiederholung und positiver Bestätigung Sequenznummern und acknowledge / retransmit Timeouts und Fenstergrössen werden dynamisch angepasst Ebenfalls Ports (16-Bit-Nummern) als Kommunikationsendpunkte Verbindung besteht aus Sendeportnummer, Sende-IP- Nummer, Empfangsportnummer, Empfangs-IP- Nummer 14
Datenstrukturen in TCP/IP Application Layer Bytestrom Nachricht Transport Layer Segment Paket Internet Layer Datagramm Datagramm Network Access Layer Rahmen Rahmen TCP UDP 15
Fragmentierung und Wiederherstellung Jedes Netz hat eine maximale Übertragungseinheit Entspricht z.b. maximaler Paketgröße Auch MTU (maximum transmission unit) genannt Strategie: Spalte auf wenn nötig (falls MTU < Datagramm) Versuche Fragmentierung bei Quellstation zu vermeiden Refragmentierung (erneute Aufspaltung in andere Einheiten) ist möglich Fragmente sind in sich abgeschlosse Datagramme Verwende CS-PDU (keine Zeillen) bei ATM Stelle die Nachricht erst auf der Zielstation wieder her Versuche nicht, verlorene Fragmente wieder zu bekommen 16
Beispiel Start of header Ident= x 0 Offset= 0 Rest of header 1400 data bytes Start of header H1 R1 R2 R3 H8 Ident= x 1 Offset= 0 Rest of header 512 data bytes ETH IP (1400) FDDI IP (1400) PPP IP (512) PPP IP (512) PPP IP (376) ETH IP (512) ETH IP (512) ETH IP (376) Start of header Ident= x 1 Offset= 512 Rest of header 512 data bytes Start of header Ident= x 0 Offset= 1024 Rest of header 376 data bytes 17 Quelle: Peterson/Davie, "Computernetze"
3.3 Einfache IP- Protokolle
Internet Control Message Protocol (ICMP) Hilfsprotokoll auf IP-Ebene "Partnerprotokoll" Wird bei Fehlern an Quell-Host zurückgeschickt Unterstützt Statusanfragen zur Kontrolle und Fehlersuche ICMP nutzt IP als Transportdienst Meldet aber keine Fehler über ICMP-Pakete Verschiedene Meldungen definiert, z.b. Destination unreachable Time exceeded Source quench (Transitstation überlastet, fordert Absender zur Absenkung der Datenrate auf) Redirect (Router informiert Station über bessere Route) 19
Statusanfragen mit ICMP Echo und Echoantwort (echo request and echo reply) Zur Überprüfung der Aktivität von Kommunikationssystemen Empfänger einer Anfrage sendet in Antwort die erhaltenen Daten zurück Zeitstempel und Zeitstempelantwort (timestamp request and timestamp reply) Zur Bestimmung von Paketumlaufzeiten Meldungen umfassen mehrere Felder zur Aufnahme von Zeitstempeln, Damit können Paketbearbeitungszeiten beim Empfänger und die Verzögerung im Netz bestimmt werden 20
Beispiel ping Hilfsprogramm zur Bestimmung von RTTs und Paketverlusten Verwendet ICMP-Echo Erster Test beim Aufbau von Netzverbindungen! E:\>ping anna.fh-coburg.de Ping anna.fh-coburg.de [192.129.26.52] mit 32 Bytes Daten: Antwort von 192.129.26.52: Bytes=32 Zeit=76ms TTL=118 Antwort von 192.129.26.52: Bytes=32 Zeit=76ms TTL=118 Antwort von 192.129.26.52: Bytes=32 Zeit=75ms TTL=118 Antwort von 192.129.26.52: Bytes=32 Zeit=75ms TTL=118 Ping-Statistik für 192.129.26.52: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 75ms, Maximum = 76ms, Mittelwert = 75ms 21
Beispiel traceroute Bestimmt die Route eines IP-Pakets Verfahren: Absenden von UDP Testpaketen mit kleiner Lebensdauer (time to live, TTL) Warten auf eine ICMP-Nachricht "Time exceeded" von einem Router Beginnt mit einer TTL von 1 und erhöht dann immer um 1 Drei Testpakete werden mit jeder TTL gesendet Ausgabe: TTL, Adresse des Routers, RTT 22
Der schnellste Weg zu Yahoo! e:\fh>tracert www.yahoo.de Routenverfolgung zu www2.vip.lng.yahoo.com [217.12.3.11] über maximal 30 Abschnitte: 1 2 ms 3 ms 2 ms back26.fh-coburg.de [192.129.26.1] 2 10 ms 6 ms 4 ms Wingate.fh-coburg.de [192.129.26.231] 3 15 ms 8 ms 14 ms ar-ilmenau2.g-win.dfn.de [188.1.35.197] 4 7 ms 6 ms 7 ms ar-ilmenau1-ge4-0.g-win.dfn.de [188.1.69.129] 5 12 ms 11 ms 10 ms cr-leipzig1-po5-1.g-win.dfn.de [188.1.70.45] 6 15 ms 15 ms 14 ms cr-frankfurt1-po10-0.g-win.dfn.de [188.1.18.189] 7 15 ms 16 ms 14 ms so-6-0-0.ar2.fra2.gblx.net [208.48.23.141] 8 16 ms 16 ms 15 ms pos5-0-2488m.cr2.fra2.gblx.net [62.16.32.77] 9 33 ms 32 ms 31 ms pos0-0-2488m.cr1.lon3.gblx.net [67.17.64.34] 10 36 ms 31 ms 32 ms so6-0-0-2488m.ar2.lon3.gblx.net [64.212.107.146] 11 31 ms 33 ms 31 ms Level-3public-peering.ge-5-0-0.ar2.LON3.gblx.net [208.51.239.162] 12 32 ms 33 ms 32 ms ae0-16.mp2.london1.level3.net [212.187.131.146] 13 31 ms 34 ms 37 ms so-3-0-0.mp1.london2.level3.net [212.187.128.46] 14 33 ms 32 ms 37 ms gige11-0.ipcolo1.london2.level3.net [212.187.129.167] 15 32 ms 32 ms 32 ms unknown.level3.net [212.113.10.210] 16 32 ms 32 ms 32 ms www2.vip.lng.yahoo.com [217.12.3.11] Ablaufverfolgung beendet. 23
RSVP (Resource Reservation Protocol) Protokoll zur Reservierung von Ressourcen z.b. Vereinbarung bestimmter Dienstqualität zwischen Hosts Arbeitsweise: Hosts vereinbaren regelmäßig bestimmte Dienstqualität Reservierung von Empfängern initiiert unterschiedliche Anforderungen bei Multicast entsprechende Datagramme lösen auf betroffenen Routern Reservierung von Ressourcen aus Rückmeldung, falls erforderliche Ressourcen nicht vorhanden Reservierung verfällt nach gewisser Zeit Anpassung an geändertes Routing 24
TCP/IP und benachbarte Protokolle MIME MIME BGP BGP FTP FTP HTTP HTTP SMTP SMTP Telnet Telnet SNMP SNMP TCP TCP UDP UDP ICMP ICMP IGMP IGMP OSPF OSPF RSVP RSVP IP IP 25
3.4 Sender/Empfänger- Koordination
Simplex-Protokoll (1) Senderseite empfangevonvermittlungsschicht(paket) bereit bereit bilderahmen(paket, rahmen) sendeanbitüschicht(rahmen) Empfängerseite empfangevonbitüschicht(rahmen) bereit bereit extrahierepaket(rahmen, paket) sendeanvermittlungsschicht(paket) 27
Simplex-Protokoll (2) Annahmen und Voraussetzungen Wertung nur zwei beteiligte Stationen mit fester Rollenverteilung Sender bleibt immer Sender, Empfänger immer Empfänger unidirektionale Datenübertragung Protokoll versagt bei Übertragungsfehlern bei Überlastung des Empfängers idealer Übertragungskanal keine Rahmenverluste Einsatz damit kaum empfehlenswert keine Beschädigung der Daten keine Berücksichtigung von Verarbeitungszeiten Empfänger kann Rahmen beliebig schnell aufnehmen 28
Stop-and-Wait-Protokoll (1) Verbesserung gegenüber Simplex-Protokoll keine Überlastung des Empfängers durch Rückmeldemechanismus Empfänger signalisiert Aufnahmefähigkeit für neue Nachricht Sender wartet mit nächster Nachricht bis zum Empfang der Rückmeldung strenges Alternieren zwischen Übertragung von Nutzdaten und Quittungen Einsatz erfordert zumindest Halbduplexkanal Limitierung funktioniert nur bei idealem Übertragungskanal keine Rahmenverluste keine Beschädigung der Daten Protokoll versagt bei Übertragungsfehlern 29
Stop-and-Wait-Protokoll (2) empfangevonvermittlungsschicht(paket) Senderseite bilderahmen(paket, rahmen) sendeanbitüschicht(rahmen) bereit bereit empfangequittung(quittung) warte warte auf auf Quittung Quittung Empfängerseite empfangevonbitüschicht(rahmen) bereit bereit extrahierepaket(rahmen, paket) sendeanvermittlungsschicht(paket) sendequittung(quittung) 30
Stop-and-Wait-Protokoll bei störanfälliger Leitung (1) weitere Verbesserung: Mechanismus zur Behandlung von Übertragungsfehlern Rahmenverlust Verfälschung der Rahmeninhalte Idee: Empfänger quittiert erhaltenen Rahmen Sender wiederholt Übertragung bei Ausbleiben von Quittungen PAR - Positive Acknowledgement with Retransmission ARQ - Automatic Repeat Request fehlererkennende Codierung zur Überwachung der Datenintegrität Unterscheidung von Rahmen durch Folgenummer 31
Stop-and-Wait-Protokoll bei störanfälliger Leitung (2) Senderseite empfangevonvermittlungsschicht(paket) berechneprüfsumme(psumme) setzefolgenummer(fnr) bilderahmen(paket, psumme, fnr, rahmen) sendeanbitüschicht(rahmen) startetimer(timer) bereit bereit warte warte auf auf Quittuntung Quit- empfangequittung(quittung) istabgelaufen(timer) sendeanbitüschicht(rahmen) startetimer(timer) stoppetimer(timer) 32
Stop-and-Wait-Protokoll bei störanfälliger Leitung (3) Empfängerseite empfangevonbitüschicht(rahmen) UND istkorrekt(psumme) bereit bereit istwiederholung(fnr) sendequittung(quittung) Wiederholunholung Wieder-? NICHT istwiederholung(fnr) extrahierepaket(rahmen, paket) sendeanvermittlungsschicht(paket) sendequittung(quittung) setzefolgenummer(fnr) 33
Wertung des Stop-and and-wait Wait-Protokoll bei störanfälliger Leitung Protokoll versagt bei Übertragungsfehlern, die verwendeter Code nicht erkennt fehlerhafte Rahmen werden akzeptiert zu knappe Dimensionierung der Wartezeit (Laufzeit des Timers) Sender schickt Nachrichten häufig doppelt, weil Rückmeldungen erst eintreffen, wenn bereits erneut gesendet wurde Quittung wird eventuell auf falschen Rahmen bezogen Lösungsmöglichkeit: Einfügen der Folgenummer in Quittung zur Kennzeichnung, worauf sie sich bezieht Dimensionierung der Timerlaufzeit, so dass Timerlaufzeit > Übertragungszeit_Rahmen + Verarbeitungszeit_Rahmen + Übertragungszeit_Quittung bei Quittungsverlust können sich Folgenummern von Sender und Empfänger unterscheiden 34
Stop-and-Wait-Protokoll im Duplexmodus jede Station gleichzeitig Sender und Empfänger Erhöhung der Kanalauslastung verzögerte Bestätigung empfangener Rahmen möglichst an ausgehenden Datenrahmen angehängt, sonst separater Quittungsrahmen Implementierungsskizze: Zusammenfassen der Zustandsdiagramme für Sender und Empfänger Empfang einer Nachricht sowohl aus Zustand bereit als auch aus warte auf Quittung heraus möglich zwei Folgenummern erforderlich eine für nächsten zu sendenden Rahmen (nächstegesendet) eine für als nächsten erwarteten Rahmen (nächsteerwartet) 35
Pipelining Problem schlechte Performanz bei langen Laufzeiten von Nachrichten Lösungsansatz: Pipelining Versendung mehrerer Rahmen ohne Abwarten der Quittungen Verwaltung mehrerer Listen von Rahmen gesendete Rahmen mit noch ausstehender Quittung Rahmen, die noch gesendet werden können, bis Quittung zwingend erforderlich ist Schiebefenster Puffer für Rahmen beim Sender und Empfänger bei Erhalt von Quittungen rückt Fenster weiter 36
Schiebefensterprotokolle (1) "Sliding window protocol" Protokollfamilie der Schicht 2 für Flusssteuerung Größe des Sendefensters variabel, aber begrenzt Aktuelle Größe entspricht der Zahl der unbestätigten gesendeten Rahmen Maximale Größe durch Puffergröße bestimmt Größe des Empfangsfensters i.a. fest Entspricht Zahl der Rahmen, die außer der Reihe ankommen dürfen Bestimmt Wertebereich für Sequenznummern 37
Schiebefensterprotokolle (2) Sender-Variablen 0 1 2 3 4 5 6 7 NAE LFS bestätigte Rahmen =2 unbestätigte Rahmen =4 freie Pufferplätze MAX =6 NAE: Next Acknowledgement Expected LFS: Last Frame Sent Aktuelle Fenstergröße: LFS-NAE+1 Maximale Fenstergröße: MAX-NAE+1 Senden: LFS++, solange LFS MAX ACK für NAE kommt an: NAE++, MAX++ Es kann auch ein ACK(k) kommen mit NAE < k LFS ACK(k) wird oft als ACK(k-1), ACK(k-2) etc. verwendet 38
Schiebefensterprotokolle (3) Empfänger-Variablen 0 1 2 3 4 5 empfangene Rahmen NFE =2 Rahmen 2 fehlerhaft, 3 korrekt empfangen, 4 ausstehend LFA =4 NFE: Next Frame Expected LFA: Last Acceptable Frame Seqnr < NFE: Frame verwerfen (aber ACK senden!) Seqnr > LFA: Frame verwerfen Alle Rahmen mit Seqnr innerhalb des Fenster werden akzeptiert und quittiert Empfang von Rahmen Nr. NFE: NFE++, LFA++ (ggf. mehr als einmal, falls Rahmen zwischendrin schon da) 39
Schiebefensterprotokolle (4) Strategien zur Behandlung von Übertragungsfehlern: Rücksetzen kein Puffer für korrekte Rahmen außer der Reihe auf Empfängerseite erneute Übertragung des fehlerhaften und aller danach bereits gesendeten Rahmen Größe des Empfängerfensters = 1 schlechter Datendurchsatz, falls Fehlerrate hoch selektive Wiederholung Puffer für korrekte, aber außer der Reihe empfangene Rahmen auf Empfängerseite erneute Übertragung ausschließlich für fehlerhafte Rahmen Erweiterung: negative Quittierung Empfänger fordert aktiv und gezielt fehlerhafte oder fehlende Rahmen nach 40
Schiebefensterprotokolle (5) - Rücksetzen Sender Timout-Intervall 0 1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 Empfänger Fehler von Sicherungsschicht verworfen 41
Schiebefensterprotokolle (6) - Selektive Wiederholung Timer-Intervall Sender 0 1 2 3 4 5 6 7 8 2 9 10 11 12... Empfänger 0 1 3 4 5 6 7 8 2 9 10 11 12 ack 0 ack 1 Fehler auf Sicherungsschicht gepuffert ack 8 ack 9 ack 10 ack 11 ack 12 42
Schiebefensterprotokolle (7) - Sequenznummern Wertebereich für Sequenznummern begrenzt Werden als Bits codiert, daher Nummernbereich i.a. Potenz von 2 (z.b. 4, 8 oder 16) Spart Platz in den Rahmen und ACK "<" und ">" müssen dann zyklisch (d.h. mod 2 i ) interpretiert werden (z.b. bei NAE < k LFS) Nummernbereich dürfen sich beim Verschieben nicht überlappen Bei Empfängerfenstergröße RWS = 1 genügt Sendefenstergröße MaxSeqNr SWS +1 Bei größeren RWS genügt dies nicht mehr! Bei SWS = RWS benötigt man MaxSeqNr 2 SWS 43
Schiebefensterprotokolle (8) - Effizienz Effizienz E hängt von Durchsatz und Kapazität ab, genauer von Ausbreitungsverzögerung Entfernung * Bandbreite a = = Übertragungsverzögerung Signalgeschwindigkeit * Rahmengröße Für Fenstergröße N gilt: E = 1 falls N > 2a+1 N/(2a+1) sonst 1 f1(x) f7(x) f16(x) f128(x) 0.8 0.6 0.4 0.2 0 0.1 1 10 100 1000 44
3.5 Transmission Control Protocol (TCP)
Ende-zu-Ende-Protokolle Das Netz arbeitet nur "best effort" Verlust von Nachrichten Umordnung von Nachrichten Verdopplung von Nachrichten Begrenzung der Nachrichtengröße Verzögerung von Nachrichten Ende-zu-Ende-Dienste: Garantieren die Nachrichtenauslieferung Liefern Nachrichten in der gesendeten Reihenfolge aus Liefern genau ein Exemplar jeder Nachricht Unterstützen beliebig lange Nachrichten Erlauben dem Empfänger, auf den Nachrichtenfluss einzuwirken Unterstützen mehrere Anwendungsprozesse auf jeder Station 46
Transmission Control Protocol (TCP) Protokoll des Transport Layer Aufgaben verbindungsorientierte zuverlässige Übermittlung eines Bytestroms Aufbau logischer Ende-zu-Ende-Verbindung zwischen Quellund Zielhost Zerlegung bzw. Wiederzusammensetzen eines Bytestroms in/aus IP-Paketen positive Bestätigungen mit Neuübertragung Flusssteuerung: Sender soll Empfänger nicht überfordern Überlaufkontrolle: Sender soll Netz nicht überfordern Multiplexen von Übertragungen innerhalb einer Verbindung bei Vollduplexbetrieb ursprüngliche Definition von TCP im RFC 793 Klarstellungen und Fehlerkorrekturen im RFC 1122 Erweiterungen in RFCs 1323, 2018 und 2581 47
TCP Overview Anwendungsprozess Anwendungsprozess Schreibe Bytes Lies Bytes TCP Sendepuffer TCP Empfangspuffer Segment Segment Segment Übertrage Segmente 48
Sockets und Ports Sockets als sender- und empfängerseitige Kommunikationsendpunkte Socket kann mehrere (ungerichtete) Verbindungen gleichzeitig bedienen Kennung einer Verbindung durch Paar beteiligter Sockets Socketadresse ergibt sich aus IP-Adresse des Hosts und Portnummer Ports als Dienstzugriffspunkte standardisierte Belegung von Portnummern für Standarddienste, z.b. Port 21 für FTP, 23 für TELNET, 80 für HTTP... Segmente als zwischen Sender und Empfänger ausgetauschte Dateneinheiten ggf. unterwegs Zerlegung von Segmenten durch Router in kleinere Fragmente maximale Länge von IP-Paketen definiert Obergrenze für Segmentlänge 49
Verbindungsaufbau auf TCP- Ebene Dreiweg-Handshake Host 1 Host 2 SYN(x) Angestoßen durch CONNECT ACK(y+1), Daten SYN(y), ACK(x+1) SYN : Anfrage Verbindungsaufbau SYN + ACK : Annahme Verbindung plus Synchronisation über Folgenummern x, y... 50
Verbindungsabbau auf TCP- Ebene symmetrischer Abbau jede Richtung der Verbindung wird separat beendet nach Abbau der einen Richtung können in der anderen weiterhin Daten übertragen werden erst nach Abbau beider Verbindungsrichtungen wird Verbindung insgesamt gelöst Angestoßen durch CLOSE Host 1 Host 2 FIN(x) ACK(y+1) ACK(x+1) FIN(y) Angestoßen durch CLOSE FIN : (gerichteter) Verbindungsabbau ACK : Bestätigung Verbindungsabbau plus Synchronisation über Folgenummern x, y... 51
TCP-Zustände eines Client 52
TCP-Zustände eines Servers 53
Segmentheader 32 bit Quellport Zielport Länge reserviert Flags Prüfsumme Folgenummer Bestätigungsnummer Optionen (beliebig viele 32 Bit-Worte) Daten (optional) Fenstergröße Urgent-Zeiger Quellport / Zielport Endpunkte der Verbindung zusammen mit IP-Adressen von Sender und Empfänger (aus IP-Header) Identifikation der Sockets und damit der Verbindung Portnummer > 255 beliebig belegbar, kleinere Portnummern standardisiert 54
Segmentheader (2) 32 bit Quellport Zielport Folgenummer Bestätigungsnummer Länge reserviert Flags Fenstergröße Prüfsumme Urgent-Zeiger Optionen (beliebig viele 32 Bit-Worte) Daten (optional) Folgenummer Bytes eines TCP-Datenstroms fortlaufend numeriert Segment-Folgenummer ist Nummer des ersten Datenbytes Bestätigungsnummer Nummer des als nächstes erwarteten Datenbytes 55
Segmentheader (3) 32 bit Quellport Zielport Folgenummer Bestätigungsnummer Länge reserviert Flags Fenstergröße Länge Zahl der 32-Bit-Worte im Header Fenstergröße Prüfsumme Optionen (beliebig viele 32 Bit-Worte) Daten (optional) Urgent-Zeiger Zahl der Datenbytes ab der Bestätigungsnummer (einschließlich), die im nächsten Segment der Gegenseite gesendet werden dürfen 56
Segmentheader (4) Flags: 6 Flags von jeweils 1 Bit Länge URG: Kennzeichnung, ob Urgent-Zeiger benutzt wird oder nicht ACK: Kennzeichnung, ob Bestätigungsnummer gültig ist oder nicht PSH: Kennzeichnung von PUSH-Daten Sendepuffer durch Segment mit gesetztem PSH-Flag geleert RST: Signal zum Rücksetzen einer Verbindung Verwendung z.b. nach Absturz eines Kommunikationspartners oder zum Ab-weisen einer Verbindungsanfrage oder eines ungültigen Segments SYN: Verbindungsaufbau entweder Verbindungsanfrage oder Verbindungsbestätigung (in Abhängigkeit vom ACK-Flag) FIN: Verbindungsabbau 57
Segmentheader (5) 32 bit Quellport Zielport Folgenummer Bestätigungsnummer Länge reserviert Flags Fenstergröße Prüfsumme Urgent-Zeiger Optionen (beliebig viele 32 Bit-Worte) Daten (optional) Prüfsumme Summe der Komplemente aller 16-Bit-Halbworte des Segments einschließlich IP-Pseudoheader (Quell-, Zieladresse, Protokoll, Datenlänge) Urgent-Zeiger Nummer des ersten Bytes nicht dringlicher Daten innerhalb des Segment davor liegende Bytes damit implizit als dringend gekennzeichnet Datennetze, Sommersemester 2003 58
Segmentheader (6) 32 bit Quellport Zielport Folgenummer Bestätigungsnummer Länge reserviert Flags Fenstergröße Prüfsumme Urgent-Zeiger Optionen (beliebig viele 32 Bit-Worte) Daten (optional) Optionen u.a. Einigung der Hosts auf maximale Segmentlänge (Voreinstellung: 536 Byte) Skalierungsfaktor für Fenstergröße Negative Bestätigung einzelner Segmente 59
Nochmals Schiebefensterprotokolle Sendende Anwend. Empfang. Anwendung TCP TCP LastByteWritten LastByteRead LastByteAcked LastByteSent NextByteExpected LastByteRcvd Senderseite LastByteAcked < = LastByteSent LastByteSent < = LastByteWritten Pufferbytes zwischen LastByteAcked und LastByteWritten Empfängerseite LastByteRead < NextByteExpected NextByteExpected < = LastByteRcvd +1 Pufferbytes zwischen LastByteRead und LastByteRcvd 60
Flusskontrolle Größe des Senderpuffers: MaxSendBuffer Größe des Empfängerpuffers: MaxRcvBuffer Empfängerseite LastByteRcvd - LastByteRead < = MaxRcvBuffer AdvertisedWindow = MaxRcvBuffer -(NextByteExpected - LastByteRead) Senderseite LastByteSent - LastByteAcked < = AdvertisedWindow EffectiveWindow = AdvertisedWindow -(LastByteSent - LastByteAcked) LastByteWritten - LastByteAcked < = MaxSendBuffer Stoppe Sender falls (LastByteWritten - LastByteAcked) + y > MaxSenderBuffer Sende immer ACK als Antwort auf eintreffendes Segment 61
Schutz vor Überlauf der Sequenznummern 32-bit Sequenznummern Bandbreite T1 (1.5 Mbps) Ethernet (10 Mbps) T3 (45 Mbps) FDDI (100 Mbps) STS-3 (155 Mbps) STS-12 (622 Mbps) STS-24 (1.2 Gbps) Zeit bis zum Überlauf 6.4 Stunden 57 Minuten 13 Minuten 6 Minuten 4 Minuten 55 Sekunden 28 Sekunden 62
TCP-Erweiterungen Implementiert als Header-Optionen Hinterlege Zeitstempel in ausgehende Segmente Erweitere den Sequenznummernraum mit einem 32-Bit-Zeitstempel (PAWS) Verschiebe (skaliere) das "advertised window" 63
Adaptive Neuübertragung (Originalalgorithmus) Miss SampleRTT für jedes Paar aus Segment und ACK Berechne das gewichtete Mittel der RTT EstRTT = α x EstRTT + β x SampleRTT wobei α + β = 1 α zwischen 0.8 und 0.9 β zwischen 0.1 und 0.2 Bestimme Timeout auf Basis der EstRTT TimeOut = 2 x EstRTT 64
Karn/Partridge Algorithm Sender Receiver Sender Receiver Original transmission SampleR TT Retransmission ACK SampleR TT Original transmission ACK Retransmission Berechne RTT nicht bei Neuübertragung Verdopple den Timeout nach jeder Neuübertragung 65
Jacobson/Karels-Algorithmus Neue Berechnungsmethode für die durchschnittliche RTT Diff = SampleRTT - EstRTT EstRTT = EstRTT + (δ x Diff) Dev = Dev + δ( Diff - Dev) wobei δ ein Faktor zwischen 0 und 1 ist Betrachten die Varianz beim Setzen des Timeout-Wertes TimeOut = µ x EstRTT + φ x Dev wobei µ = 1 und φ = 4 Bemerkungen Der Algorithmus ist nur so gut wie die Granularität der Uhr (500ms auf Unix) Genaue Timeout-Mechanismen wichtig für Überlastkontrolle 66
User Datagram Protocol (UDP) 32 bit Quellport Gesamtlänge Zielport Prüfsumme Quellport / Zielport Dienstzugriffspunkte auf Quell- und Zielhost wie bei TCP Länge Länge der Daten plus 8 Byte für den Header Prüfsumme Addition der Komplemente aller 16-Bit-Halbworte wie bei TCP damit Möglichkeit zur verbindungslosen Übertragung roher IP-Datagramme zwischen Anwendungen z.b. Client/Server-Anwendungen 67
3.6 Überlaststeuerung
Netzüberlastung Mögliche Gründe hohes Nachrichtenaufkommen auf bestimmten Teilstrecken hohe Belastung von (langsamen) Routern Aufgaben bei der Überlastungssteuerung 1. Überwachung des Systems auf mögliche Überlastungen 2. Weiterleitung an Stellen mit Eingriffsmöglichkeit 3. steuernder Eingriff prinzipielle Handlungsmöglichkeiten: präventiv korrektiv 69
Präventive Maßnahmen (1) Grundidee: Auslegung des Netzbetriebs so, dass es von vornherein nicht zu Überlastungen kommt Möglichkeiten auf der Vermittlungsschicht: virtuelle Verbindungen anstelle von Datagramm-Diensten Dimensionierung von Warteschlangen auf Routern Abarbeitungsstrategie für Pakete (Round-Robin, prioritätsgesteuert,...) Routing über Alternativpfade Festlegung der Paket-Lebenszeit Möglichkeiten auf Sicherungs- bzw. Transportschicht Festlegung der Timeout-Intervalle Bestätigungsmechanismus (Einzel- oder Huckepack-Bestätigung) Flusssteuerung mit Zwischenspeichern von Paketen 70
Präventive Maßnahmen (2) Traffic Shaping Idee: Festlegung einer zulässigen Rate zur Datenübertragung und entsprechende Überwachung (Policing) Hauptziel: Vermeidung von Verkehrsspitzen zugunsten möglichst gleichmäßiger Belastung vor allem für virtuelle Verbindungen geeignet ähnlicher Ansatz wie in Schiebefensterprotokollen Parameter aber nicht Zahl der Pakete, sondern Datenmenge pro Zeit verbreitete Verfahren: Leaky-Bucket-Algorithmus Token-Bucket-Algorithmus 71
Flusskontrolle: Leaky-Bucket unregulierter Paketfluss Leck konstanter Wasserabfluss Schnittstelle mit rinnendem Eimer Netz regulierter Paketfluss 72
Prinzip des "Leaky Bucket" rinnender Eimer entspricht endlicher Warteschlange neu ankommende Pakete werden bei voller Warteschlange einfach verworfen pro Zeittakt entweder Entnahme eines Pakets aus der Warteschlange oder geeignet, falls alle Pakete gleich lang Entnahme einer festen Anzahl von Bytes ggf. verteilt auf mehrere Pakete geeignet, falls Pakete unterschiedlich lang Leaky-Bucket ebnet Spitzenbelastungen ABER: für Huckepack-Bestätigungen ggf. Versenden mehrerer Pakete en bloc wünschenswert Token-Bucket 73
Flusskontrolle: Token-Bucket rinnender Eimer mit Tokens Netz Netz Eimer sammelt Tokens, nicht Pakete neue Tokens werden zu festen Taktzeitpunkten erzeugt Verwerfen von Tokens bei Überschreitung der Eimerkapazität Weiterleitung eines Pakets nur bei Verbrauch eines Tokens 74
Zugangskontrolle (Admission Control) bei sich abzeichnender Überlastung keine Zulassung weiterer virtueller Verbindungen geeignet für verbindungsorientierten Betrieb häufig zusätzlich Spezifikation des Verkehrsmusters bei Aufbau virtueller Verbindungen explizit oder implizit gültig entweder für komplette Dauer der Verbindung oder erst bei Überlastung Parameter z.b. Obergrenze für Datenrate durchschnittliche Übertragungsrate Toleranz für Verkehrsspitzen Laufzeitvarianz Wird bei ATM eingesetzt (Asynchronous Transfer Mode) Reservierung von Ressourcen im Netz zur Gewährleistung des Verkehrsmusters 75
Überlastkontrolle bei TCP Idee Gehe von einem "Best-effort"-Netz aus (FIFO oder FQ Router) Jede Quelle bestimmt selbst die Netzkapazität Verwendung von implizitem Feedback Temporegelung durch ACKs (selbsttaktend) Herausforderung Zunächst Feststellung der verfügbaren Kapazität Dynamische Anpassung an Kapazitätsveränderungen 76
Additive Zunahme/ Multiplikative Abnahme Ziel: Anpassung an Veränderungen der verfügbaren Kapazität Neue Zustandsvariable für jede Verbindung: CongestionWindow Begrenzt die Datenmenge, die die Quelle überträgt AdvertisedWindow = MaxRcvBuffer (LastByteRcvd LastByteRead) MaxWin = MIN(CongestionWindow, AdvertisedWindow) EffWin = MaxWin - (LastByteSent - LastByteAcked) Idee: Vergrößere CongestionWindow, wenn Überlast zurückgeht Verkleinere CongestionWindow, wenn Überlast steigt Additive Increase/Multiplicative Decrease-Verfahren (AIMD) 77
AIMD-Algorithmus Erhöhe CongestionWindow um ein Paket pro RTT (linear increase) Quelle Ziel Halbiere CongestionWindow bei jedem Timeout (multiplicative decrease) In der Praxis: Erhöhe bei jedem ACK ein wenig Increment = (MSS * MSS)/CongestionWindow CongestionWindow += Increment 79
Ablauf des AIMD Sägezahnmuster 70 60 50 40 KB 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 Zeit (Sekunden) 80 Quelle: Peterson/Davie: Computernetze
Slow-Start Ziel: Bestimme am Anfang die verfügbare Kapazität Idee: Beginne mit CongestionWindow = 1 Paket Verdopple CongestionWindow pro RTT (entspricht einer Erhöhung um 1 Paket für jedes ACK) Quelle Ziel 81
Ablauf des Slow-Start- Verfahrens Exponentielles Wachstum, aber langsamer als alle Pakete auf einmal Wird verwendet Beim ersten Start einer Verbindung Wenn eine Verbindung abstirbt, während sie auf ein Timeout wartet Verlauf KB 70 60 50 40 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 Problem: Pakete im Umfang bis zur Hälfte des CongestionWindow gehen verloren 82 Quelle: Peterson/Davie: Computernetze
Fast-Retransmit und Fast- Recovery Problem: grobgranulare Implementierung von TCP-Timeouts führen zu langen ungenutzten Perioden Fast-Retransmit- Mechanismus: Verwende Duplikat-ACKs, um eine Neuübertragung anzustoßen Paket 1 Paket 2 Paket 3 Paket 4 Paket 5 Paket 6 Retransmit Pakket 3 Sender Empfänger ACK 1 ACK 2 ACK 2 ACK 2 ACK 2 ACK 6 83
Ergebnis KB 70 60 50 40 30 20 10 Fast-Recovery-Mechanismus 1.0 2.0 3.0 4.0 5.0 6.0 7.0 Falls Fast-Retransmit eine Überlast signalisiert Übergehen der Slow-Start-Phase Verwende ACKs in der Pipeline, um Paketübertragung zu takten Nimm direkt die Hälfte des letzten CongestionWindow 84 Quelle: Peterson/Davie: Computernetze
Überlastvermeidung Strategie bei TCP Bringe Überlast bei Auftreten unter Kontrolle Schrittweises Erhöhen der Last, um den Überlastbeginn zu bestimmen, dann Drosseln Alternative Strategie Vorhersage, wann Überlast auftreten könnte Absenkung der Senderate, bevor Pakete verworfen werden Überlastvermeidung (im Ggs. zu Überlastkontrolle) Zwei Möglichkeiten Routerzentriert: DECbit und RED Gateways Hostzentriert: TCP Vegas 85
DECbit Einfügen eines Überlastbit in den Paket-Header Router Bestimmt die durchschnittliche Warteschlangenlänge über den letzten belegten + ungenutzten Zyklus Warteschlangenlänge Aktuelle Zeit Vorheriger Aktueller Zyklus Zyklus Durchschnitt über Zeitintervall Setzt das Überlastbit, falls die durchschnittliche Warteschlangenlänge größer als 1 Kompromiss zwischen Datendurchsatz und Verzögerung Zeit 86 Quelle: Peterson/Davie: Computernetze
End-Stationen bei DECBit Ziel schickt das Bit zurück an die Quelle Quelle zeichnet auf, wieviele ihrer Pakete zum Setzen des Bit geführt haben Wurde es weniger als 50% der Pakete des letzten Fensters gesetzt, wird CongestionWindow um 1 Paket erhöht Wurde es in über 50% aller Pakete gesetzt, wird CongestionWindow um den Faktor 0.875 verkleinert 87
Random Early Detection (RED) Benachrichtigung ist implizit Eines der Pakete wird verworfen (führt zu einem Timeout) Könnte man durch Markieren des Pakets explizit machen "Early Random Drop"-Konzept Statt darauf zu Warten, dass die Warteschlange voll wird, wird jedes eintreffende Paket mit einer gewissen Wahrscheinlichkeit verworfen Verfahren wird aktiv, wenn die Warteschlangenlänge eine Schwelle überschreitet 88
Details des RED Berechnung der durchschnittlichen Warteschlangenlänge AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0 < Weight < 1 (typischerweise 0.002) SampleLen: Länge der Warteschlage zum Zeitpunkt der Stichprobenmessung MaxThreshold MinThreshold AvgLen 89
Weitere Details des RED Zwei Schwellen für die Warteschlangen if AvgLen <= MinThreshold then stelle Paket in Warteschlange if MinThreshold < AvgLen < MaxThreshold then berechne Wahrscheinlichkeit P verwerfe eintreffendes Paket mit Wahrscheinlichkeit P if ManThreshold <= AvgLen then verwerfe eintreffende Pakete 90
Wahrscheinlichkeit für Paketverwerfen bei RED Berechnung der Wahrscheinlichkeit P TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) Kurve der Wahrscheinlichkeit für Verwerfen P(drop) 1.0 MaxP AvgLen MinThresh MaxThresh 91 Quelle: Peterson/Davie: Computernetze
Feinjustierung des RED Wahrscheinlichkeit des Verwerfens eines Pakets eines bestimmten Datenflusses ist ungefähr proportial zum Anteil an Bandbreite, den dieser Fluss gerade an diesem Router erhält Typischer Wert: MaxP = 0.02 Durchschn. Warteschlangenlänge zwischen beiden Grenzwerten Etwa eines von 50 Paketen wird verworfen Kommt Verkehr oft in Bündeln => MinThreshold muss genügend groß sein Damit die Leistungsauslastung auf akzetabel hohem Niveau bleibt Unterschied zwischen zwei Grenzwerten > typische Erhöhung der berechneten durchschnittlichen Warteschlangenlänge innerhalb einer RTT Faustregel im heutigen Internet: MaxThreshold = 2 MinThreshold 92
Quellenbasierte Überlastvermeidung Idee: Quelle achtet auf Anzeichen für Füllung der Warteschlange und drohende Überlast, z.b. RTT steigt Senderate flacht ab Algorithmus "TCP Vegas" KB Sending KBps Queue size in router 70 60 50 40 30 20 10 1100 900 700 500 300 100 10 5 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 Time (seconds) 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 Time (seconds) 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 Time (seconds) 93 Quelle: Peterson/Davie: Computernetze
Algorithmus BaseRTT: Minimum aller gemessenen RTTs Üblicherweise die RTT des ersten Pakets Wenn keine Überlast entsteht, gilt: ExpectRate = CongestionWindow/BaseRTT Quelle berechnet die Senderate (ActualRate) einmal pro RTT Quelle vergleicht ActualRate mit ExpectRate Diff = ExpectedRate - ActualRate if Diff < a vergrößere CongestionWindow linear else if Diff > b verkleinere CongestionWindow linear else lasse CongestionWindow unverändert 94