Überblick. Daten- kommunikation

Transkript

1 Überblick Wintersemester 2014/2015 Prof. Dr. Peter Mandl Daten- kommunikation Aufbau von Kommunikationssystemen Funktionen und Protokolle der unteren Schichten Grundlagen der Transportschicht TCP-Grundlagen Fortgeschrittene TCP-Funktionen und UDP Grundlagen der Vermittlungsschicht Internet und Internet Protocol (IP) Routingverfahren und -protokolle Internet-Steuerprotokolle und IPv6 Anwendungsschicht, Fallstudien Mandl/Bakomenko/Weiß Seite 1

2 Überblick 1. Einordnung und Aufgaben des Protokolls 2. Der TCP-Header 3. Verbindungsauf- und abbau 4. Datenübertragung Robert E. Kahn Vinton G. Cerf Geschichte: TCP wurde von Robert E. Kahn und Vinton G. Cerf ab 1972 entwickelt (mehrere Jahre) Erste Standardisierung von TCP 1981 im RFC 793 Mandl/Bakomenko/Weiß Seite 2

3 TCP/IP-Referenzmodell Host A Anwendung Identische Nachrichten an den Schnittstellen Host B Anwendung Transport Internet Identische Pakete Router Internet Transport Internet Identische Datagramme Identische Datagramme Netzwerk- Interface Identische Frames Netzwerk- Interface Identische Frames Netzwerk- Interface Physikalisches Netzwerk 1 Physikalisches Netzwerk 2 Mandl/Bakomenko/Weiß Seite 3

4 Ende-zu-Ende-Kommunikation TCP ermöglicht eine Ende-zu-Ende Beziehung zwischen kommunizierenden Anwendungsinstanzen Host 1 Host 2 Host 3 Userprozess Userprozess Serverprozess Schicht T-SAP (Port) vgl.: Tanenbaum Mandl/Bakomenko/Weiß Seite 4

5 Erinnerung: TCP/IP-Protokollfamilie FTP TELNET rlogin... DHCP BOOTP NFS Anwendungsschicht SMTP NNTP HTTP RMI HTTPS X.11 BGP IIOP H.323 DNS RPC SNMP RTP... ruptime NIS rwho IMAP rexec LDAP RIP-1/2 OSPFv1/2 TLS TCP RSVP UDP Transportschicht Socket- Schnittstelle Vermittlungsschicht Netzwerkzugang ICMPv4/6 IEEE 802.x (LANs) IGMPv4/6 IPv4/6 ARP RARP FDDI ATM... Schicht-2- Schnittstelle Physikalische Schicht Mandl/Bakomenko/Weiß Seite 5

6 Erinnerung: TCP/IP-Referenzmodell, Protokollkapselung Nachrichten Segmente Nutzdaten Pakete Anwendung Header Nutzdaten Anwendungs- PDU TCP/UDP Header Anwendung Header Nutzdaten Transport- PDU IP Header TCP/UDP Header Anwendung Header Nutzdaten IP-PDU PDU = Protocol Data Unit Mandl/Bakomenko/Weiß Seite 6

7 Allgemeines zu TCP TCP ist weit verbreitet - Hersteller haben TCP/IP als Industrienorm akzeptiert - Genormt in RFC 793, aktualisiert in RFC 1122, 1349, TCP ist offen, nicht proprietär - also nicht an einen Hersteller gebunden TCP ist skalierbar - Ein bestehendes Netz auf TCP/IP-Basis kann relativ einfach um weitere Rechner erweitert werden; die neuen Rechner benötigen nur IP-Adressen TCP/IP ist die Grundlage des Internets - TCP/IP ist Bestandteil von UNIX - Das Internet basiert auf TCP/IP Mandl/Bakomenko/Weiß Seite 7

8 Einordnung und Aufgaben TCP ermöglicht die Kommunikation - über vollduplex-fähige, virtuelle Verbindungen zwischen Anwendungen Stream-orientierte Kommunikation im Unterschied zur blockorientierten Übertragung (siehe OSI TP4) - Siehe Socket-Schnittstelle TCP bietet eine zuverlässige Ende-zu-Ende- Verbindung zwischen verteilten Prozessen TCP verwendet IP als Grundlage des Pakettransports Mandl/Bakomenko/Weiß Seite 8

9 Aufgaben im Detail Schaffung einer gesicherten Ende-zu-Ende- Verbindung auf Basis von IP Reihenfolgegarantie Garantierte Auslieferung Staukontrolle Flusskontrolle (Vermeidung von Überschwemmungen langsamer Empfänger) Multiplexing und Demultiplexing der IP-Verbindung Fragmentierung und Defragmentierung der Nachrichten (Segmente!) Mandl/Bakomenko/Weiß Seite 9

10 Sicherung der Übertragung Maßnahmen zur Sicherung der Übertragung: - Drei-Wege-Handshake für Verbindungsmanagement - Prüfsumme - Quittierung (ACK-PDU): Positiv-kumulativ und implizites NAK - Zeitüberwachung für jedes Segment (Timer) und Nachrichtenwiederholung - Go-Back-N für die Nachrichtenwiederholung - Sequenznummern = Folgenummern für die Reihenfolgeüberwachung - Sliding Windows Prinzip zur Flusskontrolle - Slow-Start-Verfahren zur Staukontrolle Mandl/Bakomenko/Weiß Seite 10

11 Dienste, Ports und Adressierung Anwendungsprozess kommuniziert über eine Adresse, die als Socket bezeichnet wird - Tupel der Form (IP-Adresse, TCP-Portnummer) Well-known Ports - 16-Bit-Integer - Es gibt hier eine Reihe von sog. well-known Ports für reservierte Services (Portnr. <= 1024) - Jeder Dienst hat eine eigene Portnummer (siehe Datei /etc/services unter Unix) Ein Anwendungsprozess kann auch mehrere Verbindungen unterhalten Client-Server-Prinzip leicht realisierbar: - Server wartet an einem Port auf Connect-Requests Mandl/Bakomenko/Weiß Seite 11

12 Dienste, Ports und Adressierung Eine Verbindung wird durch ein Paar von Endpunkten identifiziert (Socket Pair) Dadurch ist es möglich, dass ein TCP-Port auf einem Host für viele Verbindungen genutzt werden kann Beispiel: - HTTP-Port 80 wird für viele Verbindungen eines HTTP- Servers verwendet. TCP-Verbindungen aus Sicht des HTTP-Servers sind: (( , 80) ( ,6000)) (( , 80) ( ,6001))... wobei die IP-Adresse des Servers ist. Mandl/Bakomenko/Weiß Seite 12

13 Einschub: Vorgaben für Portnutzung ICANN-Vorgabe für die Ports: - Well Known Ports (0 1023) - Registered Ports ( ) Ports, die Hersteller für Anwendungen reservieren können - Dynamic and/or Private Ports ( ) Private Ports, beliebig vergeben - Siehe Datei Mandl/Bakomenko/Weiß Seite 13

14 Beispiele für Dienste und Ports TCP-Portnummer Protokoll, Service 23 Telnet Remote Login 20,21 ftp File Transfer Protocol 25 SMTP Simple Mail Transfer Protocol 80 HTTP Mandl/Bakomenko/Weiß Seite 14

15 Überblick 1. Einordnung und Aufgaben des Protokolls 2. Der TCP-Header 3. Verbindungsauf- und abbau 4. Datenübertragung Mandl/Bakomenko/Weiß Seite 15

16 TCP-Segmente Host 1 Host 2 Userprozess TCP-Segmente Serverprozess IP-Fragmente Byte-Strom wird in TCP-Segmente gepackt TCP-Segmentierung!= IP-Fragmentierung Mandl/Bakomenko/Weiß Seite 16

17 TCP-Header (PCI, Protocol Control Information) Distanz in Byte 32 Bit 0 Quellport Zielport 4 Folgenummer 8 Bestätigungsnummer 12 Offset 000 Flags (9 Bit) Zeitfenstergröße Prüfsumme Optionen (0 oder mehrere 32-Bit-Wörter) Daten (optional) Urgent-Zeiger Padding Mandl/Bakomenko/Weiß Seite 17

18 TCP-Segmente TCP sieht den Datenstrom als eine Sequenz von Octets (Bytes) und unterteilt diese zur Übertragung in Segmente mit einer maximalen Länge Maximum Segment Size (MSS) kann optional ausgehandelt werden - Ein Segment besteht aus einem mind. 20 Bytes langen TCP-Header - MSS-Option im Header hat 16 Bit zum Aushandeln der MSS für eine Verbindung - Nicht verwechseln mit Window-Größe für Flusskontrolle, verlängerbar über WSOpt-Option, bis 1 GB - Sinnvoll: - MSS TCP-Headerlänge IP-Headerlänge Länge weiterer Header (z.b. 8 Bytes für PPP) <= MTU (Maximum Transfer Unit) Hinweis: IPv6 unterstützt auch Jumbograms mit 32 Bit Längenfeld TCP-Anpassung erforderlich Mandl/Bakomenko/Weiß Seite 18

19 TCP-Header (1) Quell- und Zielport - Portnummer des Anwendungsprogramms des Senders und des Empfängers Folgenummer = Sequenznummer - Nächstes Byte innerhalb des TCP-Streams (mod 2 32 ) Bestätigungsnummer - Gibt das als nächstes erwartete Byte im TCP-Strom an und bestätigt damit den Empfang der vorhergehenden Bytes Offset - Gibt die Länge des TCP-Headers in 32-Bit-Worten an Reserviert - Hat noch keine Verwendung Mandl/Bakomenko/Weiß Seite 19

20 TCP-Header (2): Flags Hier handelt es sich um Kontroll-Bits mit unterschiedlicher Bedeutung Hinweis: Neue TCP-Varianten definieren weitere Flags für die Staukontrolle: ECE-Flag (Explicit Congestion Notification) und CWR-Flag (Congestion Window Reduced) Flag URG ACK PSH RST SYN FIN Urgent-Zeiger-Feld ist gefüllt Bedeutung Bestätigung (z.b. bei Verbindungsaufbau genutzt), d.h. die ACK-Nummer hat einen gültigen Wert Zeigt Push-Daten an, Daten dürfen beim Empfänger nicht zwischengespeichert werden, sondern sind sofort an den Empfängerprozess weiter zu leiten wird bei flush() verwendet, um Segment sofort zu senden Dient zum - Rücksetzen der Verbindung (sinnvoll z.b. bei Absturz eines Hosts) - Abweisen eines Verbindungsaufbauwunsches - Abweisen eines ungültigen Segments Wird genutzt beim Verbindungsaufbau Wird genutzt beim Verbindungsabbau Mandl/Bakomenko/Weiß Seite 20

21 TCP-Header (3) Zeitfenstergröße - Erlaubt dem Empfänger, mit ACK dem Sender den vorhandenen Pufferplatz in Byte zum Empfang der Daten mitzuteilen Urgent-Zeiger - beschreibt die Position (Byteversatz von der aktuellen Folgenummer ab) an der dringliche Daten vorgefunden - Diese Daten werden vorrangig behandelt Mandl/Bakomenko/Weiß Seite 21

22 TCP-Pseudoheader Pseudoheader: - Wird vor der Berechnung der Prüfsumme an das TCP- Segment (vor den TCP-Header) gehängt, aber nicht mit übertragen - Aufbau (96 Bit): Distanz in Bit 32 Bit 0 IP-Quelladresse 32 IP-Zieladresse Protokoll = 6 Länge des TCP-Segments (berechnet) Mandl/Bakomenko/Weiß Seite 22

23 TCP-Pseudoheader und Prüfsumme Prüfsumme - Verifiziert das TCP-Segment (Header + Daten) inkl. eines Pseudoheaders auf Basis eines einfachen - Prüfsummenalgorithmus: Prüfsumme im Header auf Null setzen Nutzdaten ggf. auf gerade Byteanzahl mit einem Nullbyte ergänzen Summe der Einerkomplimente aller 16-Bit-Wörter der ganzen Nachricht inkl. TCP-Header und sog. Pseudo-Header bilden Danach Bildung des Einer-Kompliments aus der Summe ergibt die Prüfsumme Prüfsumme Pseudoheader TCP-Header TCP-Daten Berechnung der Prüfsumme über alle Daten = Prüfsumme Mandl/Bakomenko/Weiß Seite 23

24 TCP-Header Optionen (insgesamt max. 40 Byte) - Haben eine variable Struktur, Rundung auf 32 Bit, - Optionen sind z.b.: MSS: Maximum Segment Size der Verbindung einstellen MSS kann für beide Richtungen unterschiedlich sein Kein Aushandeln 536 Byte als Standardgröße SACKOK: Selektive Wiederholungen anstelle von go back n einstellen WSOPT (Windows-Scale-Option): Maximale Fenstergröße verlängern (2 30 Byte max. möglich) SACK: Selektives ACK: Liste an bestätigten Segmenten wird übertragen 24 Bit 24 Bit... Typ Länge Optionsdaten... Typ = 3 Länge = 3 Skalierung Mandl/Bakomenko/Weiß Seite 24

25 TCP-Header (PCI, Protocol Control Information) Distanz in Byte 32 Bit 0 Quellport Zielport 4 Folgenummer 8 Bestätigungsnummer 12 Offset Reserviert Flags Zeitfenstergröße 16 Prüfsumme Urgent-Zeiger Optionen (0 oder mehrere 32-Bit-Wörter) Daten (optional) Padding Mandl/Bakomenko/Weiß Seite 25

26 Überblick 1. Einordnung und Aufgaben des Protokolls 2. Der TCP-Header 3. Verbindungsauf- und abbau 4. Datenübertragung Mandl/Bakomenko/Weiß Seite 26

27 Verbindungsaufbau: Parameter aushandeln und Drei-Wege-Handshake Beim Verbindungsaufbau werden die MSS und die Sequenznummern und ggf. weitere Einstellungen (Optionen) ausgehandelt Verwendung des Drei-Wege-Handshake- Mechanismus - Initiale Sequenznummern werden berechnet und ausgetauscht Kollision beim Verbindungsaufbau ist möglich: - Zwei Hosts versuchen gleichzeitig eine Verbindung mit gleichen Parametern zueinander aufzubauen - Es wird nur eine TCP-Verbindung aufgebaut Mandl/Bakomenko/Weiß Seite 27

28 Verbindungsaufbau: Protokoll Normaler Ablauf T-Instanz 1 T-Instanz 2 Datenaustausch kann ab den ausgetauschten Sequenznummern beginnen c_isn = Initial Sequence Number des Clients (Instanz 1) s_isn = Initial Sequence Number des Servers (Instanz 2) Mandl/Bakomenko/Weiß Seite 28

29 Verbindungsaufbau Fehlerszenarien TCP muss mehrere Fehlersituationen richtig bearbeiten - Gleichzeitiger Verbindungsaufbauversuch beider Partner darf nur zu einer Verbindung führen - Alte Duplikate von TCP-Segmenten werden beim Verbindungsaufbau empfangen Reset der Verbindung (RST-Bit) und erneuter Aufbau - Halb-offene Verbindung erkennen -... Mit Reset (RST-Bit) abbauen Mandl/Bakomenko/Weiß Seite 29

30 SYN = 1, SEQ-Nr = x SYN = 1, SEQ-Nr = x Verbindungsaufbau Kollisionsfall Normalfall und Kollision (gleichzeitiger Verbindungsaufbau) im Vergleich T-Instanz 1 T-Instanz 2 T-Instanz 1 T-Instanz 2 SYN = 1, ACK = 1, SEQ-Nr = y, ACK-Nr = x + 1 SYN = 1, SEQ-Nr = y SYN = 1, ACK = 1, SEQ-Nr = y, ACK-Nr = x + 1 SYN = 0, ACK = 1, SEQ-Nr = x +1, ACK = y +1 SYN = 0, ACK = 1, SEQ-Nr = x +1, ACK = y +1 Normalfall Kollision Nur eine Verbindung mit den Folgenummern (x,y) Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 30

31 Verbindungsaufbau Kollision der Sequenznummern (1) Sequenznummern-Anzahl bei TCP: 2 32 (32-Bit-Feld) Vergabe mod 2 32 Bei 64 Kbit/s kommt es frühestens nach ca. 6,2 Tagen zu einer Wiederholung Bei 100 Mbit/s kommt es frühestens nach ca. 340 s zu einer Wiederholung Bei 1 Gbit/s kommt es frühestens nach ca. 34 s zu einer Wiederholung Probleme: 2 32 * 8 Bit : Bit/s = 2 35 : 10 9 s ~ 34,35 s - Wrapping der Sequenznummern bei schnellen Netzen - Erneuter, schneller Verbindungsaufbau nach Crash könnte zu Sequenznummern-Kollision führen Ein noch altes TCP-Segment könnte bei neuer Inkarnation der Verbindung (gleiche Adressparameter = gleiches Socket Pair) ankommen und nicht erkannt werden Mandl/Bakomenko/Weiß Seite 31

32 Verbindungsaufbau Kollision der Sequenznummern (2) PAWS = Protect Against Wrapped Sequences Lösung für Wrapping der Sequenznummern - RFC 1323: TCP extensions für high performance - Weitere TCP-Option TSopt: Timestamps werden verwendet, um Sequenznummern-Wrapping in schnellen Netzen zu erkennen Lösung für Verbindungsaufbauproblem - Generierung der ISNs anhand eines (fiktiven) Zeitgebers Ursprünglicher Vorschlag im RFC 793, S. 28: Zyklus des Zeitgebers von 4,55 Stunden, Zeitgeber wird alle 4 ms erhöht - Einsatz des 3-Way-Handshake zum Synchronisieren der Sequenznummern beim Verbindungsaufbau - Max. Segmentlebensdauer (MSL) berücksichtigen: Wurde im RFC 792 auf 2 Minuten festgelegt Diese Zeit muss gewartet werden, bevor nach einem Crash einer Verbindung eine neue ISN zugewiesen wird Zustand TIMED_WAIT Mandl/Bakomenko/Weiß Seite 32

33 Verbindungsabbau Protokoll (1) Verbindungsabbau-Protokoll: - Modifizierter Dreiwege-Handshake-Mechanismus - Jede der beiden Verbindungen der Vollduplex-Verbindung wird abgebaut, d.h. beide Seiten bauen ihre Senderichtung ab Ablauf: - Aktiv abbauender Partner sendet zunächst ein Segment mit FIN=1 - Passiver Partner antwortet zunächst mit einem ACK und informiert die Anwendung (Signalisierung implementierungsabhängig!) - Wenn die Anwendung close aufruft, sendet die Partnerinstanz ebenfalls ein Segment mit FIN=1 - Aktiver Partner sendet abschließend ein Segment mit ACK=1 Mandl/Bakomenko/Weiß Seite 33

34 Verbindungsabbau Protokoll (2) Client baut die Verbindung ab (auch Server kann es) Alle Segmente mit Folgenummer < i bzw. j sind noch zu verarbeiten FIN-Segment zählt Sequenznummer um 1 hoch (zählt als 1 Datenbyte) T-Instanz 1 T-Instanz 2 ESTABLISHED close-aufruf FIN WAIT-1 FIN WAIT-2 ESTABLISHED Anwendung informieren CLOSE WAIT close-aufruf TIMED WAIT Warten... CLOSE LAST ACK CLOSE Mandl/Bakomenko/Weiß Seite 34

35 Verbindungsabbau Signalisierung beim passiven Partner Laut Zustandsautomat gibt es mehrere Varianten (genau 4) des Verbindungsabbaus - Es geht auch mit drei Segmenten (FIN=1 + ACK=1) Die Signalisierung des Verbindungsabbaus an die Anwendung ist der Implementierung überlassen und im RFC nicht genau beschrieben - Es kann eine Weile dauern, bis die Anwendung auf das close-ereignis reagiert - Anwendung kann evtl. sogar eine Benutzereingabe erfordern - Dies hängt vom Programm ab Auch abnormale Beendigung einer Verbindung ist möglich - Segment mit RST-Bit=1 wird gesendet und der Empfänger bricht die Verbindung sofort ab Mandl/Bakomenko/Weiß Seite 35

36 Überblick 1. Einordnung und Aufgaben des Protokolls 2. Der TCP-Header 3. Verbindungsauf- und abbau 4. Datenübertragung Tool zum Mitschneiden und Analysieren des Nachrichtenverkehrs Wireshark-Sniffer Mandl/Bakomenko/Weiß Seite 36

37 Sequenznummern und Quittierung Einsatz von Sequenznummern, die auf einzelnen Bytes, nicht auf TCP-Segmenten basieren Die Sequenznummer enthält die Nummer des nächsten erwarteten Bytes Alle gesendeten Bytes werden vom Empfänger im Feld Bestätigungsnummer kumulativ quittiert Selektive, positive Quittierung auch möglich: Vorschlag in einem eigenen RFC Die Bestätigung muss von der empfangenden TCP-Instanz nicht unbedingt sofort gesendet werden, wenn noch Platz im Puffer ist - Hier besteht Implementierungsfreiheit für die Hersteller von TCP/IP-Stacks Mandl/Bakomenko/Weiß Seite 37

38 Szenario: Erfolgreiche Übertragung Sende-Instanz zieht Timer auf Timer wird nach ACK gelöscht T-Instanz 1 T-Instanz 2 Timer aufziehen Timeout-Zeit Timer löschen Geplanter Timeout Timer aufziehen Timeout-Zeit Timer löschen Geplanter Timeout Mandl/Bakomenko/Weiß Seite 38

39 Szenario: Bestätigung geht verloren Sende-Instanz zieht Timer auf Timer läuft bei verlorengegangener Quittung ab Timer aufziehen T-Instanz 1 T-Instanz 2 TCP-Segment wird erneut gesendet Timeout-Zeit Nachricht kommt nicht an! Geplanter Timeout Timeout-Zeit Timer löschen Geplanter Timeout Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 39

40 Szenario: Implizites NAK bewirkt Sendewiederholung Im Beispiel wird das 1. ACK drei mal vom Empfänger wiederholt Sender erkennt Problem und sendet erneut Problem wird vor dem Timerablauf erkannt T-Instanz 1 T-Instanz 2 1. Bestätigung Wird als implizites NAK bezeichnet! X 2. Bestätigung 3. Bestätigung 4. Bestätigung NAK erkannt! Erneut senden Mandl/Bakomenko/Weiß Seite 40

41 Szenario: Kumulative Quittung verhindert erneutes Senden Verlust eines Segments bleibt ohne Folgen T-Instanz 1 T-Instanz 2 Timer aufziehen für SeqNr = 92 Timeout- Zeit Timer aufziehen für SeqNr = 100 X Verlust bleibt ohne Folgen! Alle Timeouts löschen Kumulative Quittung! Geplanter Timeout 1 Geplanter Timeout 2 Mandl/Bakomenko/Weiß Seite 41

42 Rückblick 1. Einordnung und Aufgaben des Protokolls 2. Der TCP-Header 3. Verbindungsauf- und abbau 4. Datenübertragung Mandl/Bakomenko/Weiß Seite 42