Vorlesung: Netzwerke (TK) WS 2009/10 Kapitel 5 Ende-zu-Ende-Protokolle Session 15 Prof. Dr. Michael Massoth [Stand: 07.01.2009] 15-1
15-2 ACHTUNG: Testat_3 am Mittwoch, den 13.01.2010 Referenzmodelle (OSI, Hybrid, TCP/IP) Hardware-Bausteine bzw. Kopplungselemente Strukturierte Verkabelung Ethernet (inkl. CSMA/CD) und WLAN Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN) Internetworking (inkl. IPv4-Adressierung und Subnetting, IPv6) Ende-zu-Ende-Protokolle (UDP + TCP) 15-2
15-3 ACHTUNG: Testat_4 am Mittwoch, den 20.01.2009 Referenzmodelle (OSI, Hybrid, TCP/IP) Hardware-Bausteine bzw. Kopplungselemente Strukturierte Verkabelung Ethernet (inkl. CSMA/CD) und WLAN Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN) Internetworking (inkl. IPv4-Adressierung und Subnetting, IPv6) Ende-zu-Ende-Protokolle (UDP + TCP) 15-3
15-4 ACHTUNG: Testat_5 am Donnerstag, den 21.01.2009 Referenzmodelle (OSI, Hybrid, TCP/IP) Hardware-Bausteine bzw. Kopplungselemente Strukturierte Verkabelung Ethernet (inkl. CSMA/CD) und WLAN Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN) Internetworking (inkl. IPv4-Adressierung und Subnetting, IPv6) Ende-zu-Ende-Protokolle (UDP + TCP) 15-4
15-9 Lernziele heute: Transmission Control Protocol (TCP) Teil 2 Lernziele im Detail: TCP als zuverlässiges Byte-Strom-Protokoll verstehen, erklären und anwenden können TCP Verbindungsaufbau und -abbau verstehen und erklären können TCP Zustandsübergangsdiagramm (wenn vorgegeben!!!) verstehen, interpretieren und erklären können 15-9
15-10 TCP [Transmission Control Protocol ] TCP-Segmentstruktur Verbindungsorientierter Transport (1): Verbindungsaufbau Verbindungsorientierter Transport (2): Verbindungsabbau TCP-Verbindungsmanagement 15-10
TCP-Multiplexmechanismus 15-11 Bedeutung: Macht Koexistenz vieler höherer Protokolle und Anwendungsprozesse in einem Rechner möglich Prozessmultiplexing Zudem kann TCP von vielen Anwendungsprozessen eines höheren Protokolls genutzt werden Ansatz: Zur Identifikation der verschiedenen Datenströme vergibt TCP in jedem Rechner Port-Nummern. Über diese Port-Nummern erfolgt der gesamte Datenaustausch zwischen den Anwendungsprozessen und dem TCP Vergabe der Port-Nummern in einem Rechner erfolgt dynamisch und wahlfrei Für häufig genutzte Anwendungsprozesse sind feste Port-Nummern vergeben z.b. FTP=20, Telnet=23, SMTP=25, HTTP=80, Rlogin=513 15-11
TCP-Verbindungsmanagement (1) 15-12 Fette Linie = normaler Pfad des Clients Fette gestrichelte Linie = normaler Pfad des Servers Feine Linie = ungewöhnliche Ereignisse Jeder Übergang wird durch das Ereignis bezeichnet, das ihn verursacht, sowie durch die daraus resultierenden Aktionen (getrennt durch einen Schrägstrich / ) Ereignis/Aktionen 15-12
TCP-Verbindungsmanagement (2) 15-13 Zustand CLOSED LISTEN SYN RCVD SYN SENT ESTABLISHED FIN WAIT 1 FIN WAIT 2 TIMED WAIT CLOSING CLOSE WAIT LAST ACK Beschreibung Keine Verbindung aktiv oder anstehend Der Server wartet auf eine ankommende Verbindungsanfrage Eine Verbindungsanfrage ist angekommen. Warten auf Bestätigung. Die Anwendung hat begonnen, eine Verbindung zu öffnen. Zustand der normalen Datenübertragung Die Anwendung möchte die Übertragung beenden. Die andere Seite ist einverstanden, die Verbindung abzubauen. Warten bis keine TCP-Segmente mehr kommen. Beide Seiten haben gleichzeitig versucht, zu beenden. Die Gegenseite hat die Verbindungsfreigabe eingeleitet. Warten, bis keine TCP-Segmente mehr kommen. 15-13
TCP Client Lifecycle 15-14 TCP Client 15-14
TCP Client Lebenszyklus 15-15 Typische Abfolge von TCP-Zuständen eines TCP Clients [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.39] 15-15
TCP Server Lifecycle 15-16 TCP Server 15-16
TCP Server Lebenszyklus 15-17 Typische Abfolge von TCP-Zuständen, die ein serverseitiges TCP durchläuft [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.40] 15-17
TCP State Diagram: Connection Setup 15-18 Server passive OPEN create TCB CLOSED Client CLOSE delete TCB active OPEN create TCB Snd SYN LISTEN CLOSE delete TCB SYN RCVD rcv SYN snd SYN ACK rcv ACK of SYN rcv SYN snd ACK SEND snd SYN Rcv SYN, ACK Snd ACK SYN SENT CLOSE Send FIN ESTAB 15-18
TCP State Diagram: Connection Teardown 15-19 CLOSE send FIN FIN WAIT-1 ACK FIN WAIT-2 Active Close ESTAB CLOSE send FIN rcv FIN snd ACK rcv FIN+ACK snd ACK CLOSING rcv FIN send ACK Passive Close CLOSE WAIT CLOSE snd FIN LAST-ACK rcv ACK of FIN rcv ACK of FIN rcv FIN snd ACK TIME WAIT Timeout=2msl delete TCB CLOSED 15-19
TCP Connection Teardown 15-20 Auf beiden Seiten gibt es drei mögliche Kombinationen von Übergängen, um eine Verbindung vom ESTABLISHED- in den CLOSED-Zustand zu versetzen: Die eine Seite schließt zuerst: ESTABLISHED FIN_WAIT_1 FIN_WAIT_2 TIME_WAIT CLOSED Die andere Seite schließt zuerst: ESTABLISHED CLOSE_WAIT LAST_ACK CLOSED Beide Seiten schließen gleichzeitig: ESTABLISHED FIN_WAIT_1 CLOSING TIME_WAIT CLOSED 15-20
TCP Zustandsübergangsdiagramm 15-21 CLOSED Passive open Close Close LISTEN SYN/SYN + ACK Send /SYN SYN/SYN + ACK SYN_RCVD ACK SYN + ACK/ACK Close/FIN ESTABLISHED Close/FIN FIN/ACK FIN_WAIT_1 FIN/ACK ACK Active open /SYN SYN_SENT CLOSE_WAIT Close/FIN Erklärung: Jede Box bezeichnet einen Zustand, in dem sich ein Ende einer TCP-Verbindung befinden kann Alle Verbindungen beginnen mit dem Zustand CLOSED Jeder Pfeil ist mit einer Bezeichnung in der Form Ereignis/Aktion beschriftet ACK + FIN/ACK FIN_WAIT_2 FIN/ACK CLOSING ACK TIME_WAIT Timeout after two segment lifetimes LAST_ACK ACK CLOSED 15-21
TCP for Client-Server Communication 15-22 TCP is a connection-oriented protocol for client-server communication: Main Thread of Server Process Client Process Three-way handshake Internet Server socket New Thread of Server Process Client socket Data New socket 15-22
Adressierung 15-23 Portnummer ID Transportprotokoll IP-Adresse MAC-Adresse Application Sockets Transport Network Treiber Data Link Physical 80 für HTTP, 25 für SMTP 6 für TCP, 17 für UDP 172.17.5.xx Labor-PC 00:03:6C:1C:56:96 15-23
Sockets 15-24 Ein Socket ist die Kombination von einer IP-Adresse und einem Port Computer A Computer B Requests to Destination Port 23 Source Port = 2500 Destination Port = 2500 Source Port = 23 Austausch der Quell- und Ziel-Sockets 15-24
Port, Socket und eindeutige TCP-Verbindung 15-25 Port: Eindeutige Zuordnung der TCP-Pakete zur nächsthöheren Schicht bzw. zum Anwendungsprozess) Socket: Eindeutige Adresse einer TCP-Verbindung, zusammengesetzt aus IP-Adresse und Port-Nummer Eindeutige TCP-Verbindung: 4-Tupel aus [Sender IP-Adresse, Sender Port-Nummer, Empfänger IP-Adresse, Empfänger Port-Nummer] oder mit anderen Worten {Sender-Socket, Empfänger-Socket} 15-25
15-26 TCP [Transmission Control Protocol ] TCP Sequenz- und Bestätigungsnummern Zuverlässiger Datentransfer TCP-Flusskontrolle Pipelining und Sliding-Window TCP-Überlastkontrolle 15-26
TCP ist ein Byte-orientiertes Protokoll 15-27 Application process TCP Send buffer Write bytes Segment Segment Segment Transmit segments Application process TCP Receive buffer Read bytes Der Sender schreibt Bytes in eine TCP-Verbindung, der Empfänger liest sie aus TCP puffert am Quell-Host ausreichend Bytes vom sendenden Prozess, bis ein Paket (=Segment) einer angemessenen Größe zusammenkommt Dann sendet TCP dieses Segment an seinen Partner auf dem Ziel-Host Merke: TCP ist ein zuverlässiges Byte-orientiertes Protokoll. Kein nachrichtenorientiertes Protokoll Anfrage/Antwort- Anwendungen (Client/Server, Request/Response) tauschen immer Nachrichten aus! 15-27
Sequenznummer eines TCP-Segments (1) 15-28 Merke: Die Sequenznummer eines TCP-Segments ist die Bytestromnummer des ersten Bytes im Segment. [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.29] 15-28
Sequenznummer eines TCP-Segments (2) 15-29 Beispiel für die Aufteilung der Daten einer Datei in TCP-Segemente: Annahme: Datei mit 500.000 Byte, MSS = 1.000 Byte, Start-Seqnum = 0 Aufteilung der TCP-Segmente: Dem ersten TCP-Segment wird die Seqnum = 0, dem zweiten TCP-Segment die Seqnum = 1.000, dem dritten TCP-Segment die Seqnum = 2.000, usw. zugewiesen. [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.29] 15-29
TCP Sequenznummern (1) 15-30 TCP Sequenznummern: Jedes gesendete TCP-Byte hat eine Sequenzfolgenummer (kurz: Sequenznummer). Merke: Sequenz- und Quittungsnummern beziehen sich auf Bytes! Die Start-Sequenznummer (ISN) wird beim Verbindungsaufbau durch das Betriebssystem bestimmt (Three Way Handshake) 15-30
TCP Sequenznummern (2) 15-31 TCP Sequenznummern: Merke: Die Sequenznummer eines TCP-Segments ist die Bytestromnummer des ersten Bytes im Segment. Mit anderen Worten: Als Sequenznummer im TCP-Header wird das erste Daten-Byte in diesem Segment gesetzt. Falls SYN = 1 gesetzt ist, dann handelt es sich um die ISN (engl. Initial Sequenz Number), das erste Datenbyte hat dann die Nummer ISN + 1 Das erste Daten-Byte, gleich hinter dem TCP-Header, hat die niedrigste Sequenznummer innerhalb des TCP-Segments. Alle nachfolgenden Daten-Bytes werden konsekutiv durchnummeriert. 15-31
Telnet: Eine Fallstudie 15-32 Telnet: Eine Fallstudie für Sequenzund Bestätigungsnummern [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.30] 15-32
TCP Bestätigungsnummern (1) 15-33 TCP Bestätigungsnummern: Merke: Die Bestätigungsnummer, die Host B in sein Segment einfügt, ist die Sequenznummer des nächsten Bytes, das Host B von Host A erwartet. Als Quittungsnummer im TCP-Header wird gesetzt: ACK-Nummer (von Host B) = fehlerfrei empfangene Seq-Nummer (von Host A) + Größe der Nutzdaten in Byte TCP arbeitet mit positiven Quittungen, die Summenquittungen darstellen (für die Menge erfolgreich übertragener Bytes) 15-33
TCP Bestätigungsnummern (2) 15-34 TCP Bestätigungsnummern: TCP arbeitet (i.d.r.) mit positiven Quittungen, die Summenquittungen darstellen (für die Menge erfolgreich übertragener Bytes) Da TCP Bytes nur bis zum ersten fehlenden bzw. erwarteten Byte im Datenstrom bestätigt, sagt man, dass TCP kumulative Bestätigungen verwendet. Bestätigungen für fehlerfrei empfangene Daten im Datentransfer von Host A (Client) Host B (Server), werden im Datenstrom von Host B Host A mitbefördert. Dies nennt man auch Huckepack (engl. Piggyback) 15-34
Erzeugung von Quittungen 15-35 TCP-Empfehlungen für die ACK-Erzeugung [RFC 1122, RFC 2581] Ereignis Ankunft eines fehlerfreien TCP-Segments in der richtigen Reihenfolge mit der erwarteten Sequenznummer. Alle Daten bis zu dieser erwarteten Sequenznummer sind bereits bestätigt. Keine Lücke in den empfangenen Daten. Ankunft eines fehlerfreien TCP-Segments in der richtigen Reihenfolge mit der erwarteten Sequenznummer. Ein weiteres vorher empfangenes fehlerfreies Segment in der richtigen Reihenfolge wurde noch nicht bestätigt. Keine Lücke in den empfangenen Daten. Ankunft eines fehlerfreien TCP-Segments außer der Reihe mit einer höheren als der erwarteten Sequenznummer. Lücke erkannt. Ankunft eines fehlerfreien TCP-Segments, das die Lücke in den empfangenen Daten teilweise oder vollständig füllt. Aktion des TCP-Empfängers Verzögertes ACK; maximal 500 ms auf Ankunft eines weiteren Segments in der richtigen Reihenfolge warten. ACK senden, falls das nächste erwartete Segment innerhalb dieses Zeitintervalls nicht ankommt. Sofort ein einzelnes kumulatives ACK senden, um beide Segmente mit der richtigen Reihenfolge zu bestätigen. Sofort ein Duplikat-ACK mit Angabe der Sequenznummer des nächsten erwarteten Bytes senden. Sofort ein ACK senden, sofern dieses Segment mit dem unteren Ende der Lücke beginnt. 15-35
Einige interessante Szenarien (1) 15-36 Neuübertragung aufgrund einer verlorenen Bestätigung (ACK) [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.32] 15-36
Einige interessante Szenarien (2) 15-37 TCP-Segment wird nicht erneut übertragen, weil seine Bestätigung vor dem Timeout ankommt. [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.33] 15-37
Einige interessante Szenarien (3) 15-38 Durch eine kumulative Bestätigung wird die Neuübertragung des ersten TCP-Segments vermieden. [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.34] 15-38
15-39 TCP [Transmission Control Protocol ] TCP Sequenz- und Bestätigungsnummern Zuverlässiger Datentransfer TCP-Flusskontrolle Pipelining und Sliding-Window TCP-Überlastkontrolle 15-39
15-40 Lernziele heute : Zuverlässige Zustellung: Stop-and-Wait-Algorithmus und Sliding Window (Grundlagen) Lernziele im Detail: Zuverlässige Zustellung verstehen und anwenden können Sliding-Window-Algorithmus für Sender und Empfänger mit Variablenverwaltung verstehen und anwenden können 15-40
Zwei Probleme aus der Praxis 15-41 Problem 1: Fehlererkennung Weil TCP-Segmente während der Übertragung manchmal beschädigt werden, müssen diese Fehler erkannt werden können. Problem 2: Zuverlässige Zustellung Da einige beim Zielknoten ankommende TCP-Segmente Fehler enthalten können und daher verworfen werden, lautet die nächste Aufgabe, wie solche Fehler behoben werden können. Das Ziel ist dabei, die Verbindungsleitung für höhere Schichten und Anwendungen als zuverlässig erscheinen zu lassen. 15-41
Zuverlässige Zustellung 15-43 Frage: Wie können Pakete (oder genauer TCP-Segmente) zuverlässig zugestellt werden? Welche prinzipiellen Methoden können dabei eingesetzt werden? [Frage ans Auditorium, Ideen an Tafel sammeln] Antworten: Quittungen positive und/oder negative Bestätigungen, Acknowledgements (ACKs) Zeitüberwachung Timer, Timeout Sequenznummern 15-43
Implizite Übertragungswiederholung 15-44 Um verlorengegangene Pakete/Quittungen behandeln zu können, die sonst einen weiteren Datenaustausch unterbinden würden, muss vom Sender eine Zeitüberwachung durchgeführt werden (Time-out), nach der eine erneute Übertragung erfolgt. DL-Data.Req(p1) Sender P1,0 Empfänger Zeitüberwachung P1,0 ACK DL-Data.Ind(p1) Legende: Daten,Folgenummer DL-Data.Req(p2) Zeitüberwachung P2,1 ACK P2,1 ACK 15-44 DL-Data.Ind(p2) Als Duplikat erkannt! Zeit 1
Fehlerbehandlung: Go-back-N 15-45 DL-Data.Req(p1) DL-Data.Req(p2) DL-Data.Req(p3) DL-Data.Req(p4) DL-Data.Req(p5) DL-Data.Req(p6) p1 p2 p3 p4 p5 p6 DL-Data.Ind(p1) p2 p3 p4 p5 p6 DL-Data.Ind(p2) DL-Data.Ind(p3) DL-Data.Ind(p4) DL-Data.Ind(p5) DL-Data.Ind(p6) 15-45 1
TCP Flusskontrolle und Fenstergröße 15-48 Merke: TCP setzt einen zuverlässigen bytestromorientierten Datentransferdienst auf den unzuverlässigen Best-Effort- Dienst von IP auf. 15-48
15-49 TCP [Transmission Control Protocol ] TCP Sequenz- und Bestätigungsnummern Zuverlässiger Datentransfer TCP-Flusskontrolle Pipelining und Sliding-Window TCP-Überlastkontrolle 15-49
TCP Receiver Window und Buffer 15-50 Zusammenhang zwischen TCP Receiver Window und Receiver Buffer [Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.35] 15-50
TCP Window Flow Control: Send Side 15-51 TCP Sendepuffer window Sent and acked Sent but not acked Not yet sent Next to be sent 15-51
TCP Window Flow Control: Receive Side 15-52 TCP-Empfangspuffer What should receiver do? New Receive buffer Acked but not delivered to user Not yet acked window 15-52
TCP Window Flow Control: Send Side 15-53 Packet Sent Source Port Dest. Port Sequence Number Acknowledgment HL/Flags Window D. Checksum Urgent Pointer Options Packet Received Source Port Dest. Port Sequence Number Acknowledgment HL/Flags Window D. Checksum Urgent Pointer Options... App write acknowledged sent to be sent outside window 15-53
TCP Flusskontrolle und Fenstergröße (1) 15-54 Merke: Das 16-Bit-Feld Empfänger-Fenster (Window) dient der Flusskontrolle. Es wird dazu benutzt, um die Anzahl von Bytes anzugeben, die ein Empfänger anzunehmen bereit ist. Die Empfänger-Fenstergröße bildet eine absolute obere Schranke für den Sender und darf nicht überschritten werden. 15-54
TCP Flusskontrolle und Fenstergröße (2) 15-55 Mit anderen Worten: TCP stellt Flusskontrolle dadurch bereit, dass es den Sender eine Variable verwalten lässt, die man als Empfagsfenster (ReceiveWindow) bezeichnet. Das Empfangsfenster ist dynamisch, d. h. es ändert sich im Verlauf einer Verbindung. In einer Vollduplex-Verbindung verwaltet der Sender auf jeder Seite der Verbindung ein eigenes Empfangsfenster. 15-55
Fensterverwaltung und Flusskontrolle in TCP 15-56 Beispiel: Empfänger hat eine Empfangsfenstergröße (Puffer) von nur 4.096 Byte. Merke: Flusskontrolle erfolgt über das WINDOW -Feld im TCP-Header. 15-56
15-57 Vielen Dank für Ihre Aufmerksamkeit! Noch Fragen? Fragen und Diskussion 15-57