Ü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. TCP (Transmission Control Protocol) - Sliding-Window-Mechanismus - Optimierungen: Algorithmen von Nagle und Clark, Silly Window Syndrom - Staukontrolle - TCP-Timer - TCP-Zustandsautomat 2. UDP (User Data Protocol) - Einordnung und Aufgaben des Protokolls - Der UDP-Header - Datenübertragung Mandl/Bakomenko/Weiß Seite 2

3 Wiederholung: TCP/IP-Referenzmodell Sender Logische Kommunikation Empfänger Verarbeitungsschicht Verarbeitungsprotokoll: Telnet, ftp, SNMP, HTTP Verarbeitungsschicht leer leer leer Transportschicht Transportprotokoll: TCP und UDP leer Transportschicht Internet Hostanbindung ans Netz IP, ARP nicht festgelegt Internet Hostanbindung ans Netz IP, ARP nicht festgelegt Internet Hostanbindung ans Netz Host Router Host Mandl/Bakomenko/Weiß Seite 3

4 Sliding Window Mechanismus Der Sliding Window Mechanismus erlaubt die Übertragung von mehreren TCP-Segmenten, bevor ein ACKnowlegde eintrifft Bei TCP funktioniert Sliding Window auf Basis von Octets (Bytes) Die Octets (Bytes) eines Streams sind sequenziell nummeriert Flusskontrolle wird über das durch den Empfänger veranlasste Ausbremsen der Übertragung erreicht Mandl/Bakomenko/Weiß Seite 4

5 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 5

6 Sliding Window Mechanismus Die TCP-Instanzen reservieren beim Verbindungsaufbau Puffer für abgehende und ankommende Daten Empfänger informiert den Sender über den Füllstand des Empfangspuffers Anwendung TCP-Instanz Belegter Puffer Ankommende Pakete Freier Puffer IP-Instanz Mandl/Bakomenko/Weiß Seite 6

7 Fenstertechnik, Sliding-Window-Mechanismus T-Instanz 1 T-Instanz 2 Anwendung schreibt 2 KB Anwendung schreibt 3 KB SEQ-Nr=0, 2 KB an Daten ACK-Nr=2048, WIN= Leer KB Leer Sender ist blockiert SEQ-Nr=2048, 2 KB an Daten ACK-Nr=4096, WIN=0 ACK-Nr=4096, WIN= Voll Anwendung liest 2 KB Leer 2 KB SEQ-Nr=4096, 1 KB an Daten Noch 1 KB frei Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 7

8 Nachrichtenfluss: Kleine Übung Ports vernachlässigt T-Instanz 1 T-Instanz 2 SYN=1, SEQ-Nr=2000, ACK-Nr=0, WIN=2048 SEQ-Nr? SEQ-Nr? SEQ-Nr? SYN=1, ACK=1, SEQ-Nr=xxxx, ACK-Nr=xxxx, WIN=1024 ACK=1, SEQ-Nr=2001, ACK-Nr=4001, WIN=2048 ACK=0, SEQ-Nr=xxxx, ACK-Nr=4001, WIN=2048, Data ACK=0, SEQ-Nr=xxxx, ACK-Nr=4001, WIN=2048, Data ACK=1, SEQ-Nr=xxxx, ACK-Nr=2021, WIN=xxxx, Data ACK=1, SEQ-Nr=2021, ACK-Nr=4011, WIN=2048 FIN=1, SEQ-Nr=2021, ACK-Nr=4011 FIN=1, ACK=1, SEQ-Nr=4011, ACK-Nr=2022 ACK=1, SEQ-Nr=2022, ACK-Nr=4012 ACK-Nr? SEQ-Nr? Nutzdaten? Window- Größe? Mandl/Bakomenko/Weiß Seite 8

9 Nachrichtenfluss: Lösung Ports vernachlässigt T-Instanz 1 T-Instanz 2 SYN=1, SEQ-Nr=2000, ACK-Nr=0, WIN=2048 SYN=1, ACK=1, SEQ-Nr=4000, ACK-Nr=2001, WIN=1024 ACK=1, SEQ-Nr=2001, ACK-Nr=4001, WIN=2048 ACK=0, SEQ-Nr=2001, ACK-Nr=4001, WIN=2048, Data (10 Bytes) Hat T- Instanz 2 festgelegt ACK=0, SEQ-Nr=2011, ACK-Nr=4001, WIN=2048, Data(10 Bytes) ACK=1, SEQ-Nr=4001, ACK-Nr=2021, WIN=1004, Data ACK=1, SEQ-Nr=2021, ACK-Nr=4011, WIN=2048 FIN=1, SEQ-Nr=2021, ACK-Nr= Bytes beliebig aufgeteilt FIN=1, ACK=1, SEQ-Nr=4011, ACK-Nr=2022 ACK=1, SEQ-Nr=2022, ACK-Nr=4012 Mandl/Bakomenko/Weiß Seite 9

10 Nachrichtenfluss: Noch eine Übung Ports vernachlässigt T-Instanz 1 T-Instanz 2 Verfügbarer Empfangspuffer xxxx Bytes SYN=1, SEQ-Nr=2000, ACK-Nr=0, WIN=2048 SYN=1, ACK=1, SEQ-Nr=5000, ACK-Nr=xxxx, WIN=1024 Verfügbarer Empfangspuffer xxxx Bytes Verfügbarer Empfangspuffer xxxx Bytes ACK=1, SEQ-Nr=2001, ACK-Nr=xxxx, WIN=2048, Data 1000 ACK=1, SEQ-Nr=xxxx, ACK-Nr=xxxx, WIN=xxxx... Verfügbarer Empfangspuffer xxxx Bytes Mandl/Bakomenko/Weiß Seite 10

11 Nachrichtenfluss: Lösung Ports vernachlässigt T-Instanz 1 T-Instanz 2 Verfügbarer Empfangspuffer 2048 Bytes SYN=1, SEQ-Nr=2000, ACK-Nr=0, WIN=2048 SYN=1, ACK=1, SEQ-Nr=5000, ACK-Nr=2001, WIN=1024 Verfügbarer Empfangspuffer 1024 Bytes Verfügbarer Empfangspuffer 2048 Bytes ACK=1, SEQ-Nr=2001, ACK-Nr=5001, WIN=2048, Data 1000 ACK=1, SEQ-Nr=5001, ACK-Nr=3001, WIN=24... Verfügbarer Empfangspuffer 24 Bytes Mandl/Bakomenko/Weiß Seite 11

12 Überblick 1. TCP (Transmission Control Protocol) - Sliding-Window-Mechanismus - Optimierungen: Algorithmen von Nagle und Clark, Silly Window Syndrom - Staukontrolle - TCP-Timer - TCP-Zustandsautomat 2. UDP (User Data Protocol) - Einordnung und Aufgaben des Protokolls - Der UDP-Header - Datenübertragung Mandl/Bakomenko/Weiß Seite 12

13 Algorithmus von Nagle: Optimierung des Sendeverhaltens Problem: Sendeprozess sendet immer kleine Pakete Nagle versuchte aus Optimierungsgründen zu verhindern, dass immer kleine Nachrichten gesendet werden Lösungsansatz: Zuerst wird nur 1 Byte bzw. ein kleines Segment gesendet Danach werden Daten gesammelt, bis MSS erreicht ist, und danach wird erst wieder ein Segment gesendet, außer bei flush()-aufruf! Wenn ACK empfangen wird, wird aktueller Pufferinhalt sofort gesendet Kritik: Schlecht bei X-Windows oder bei telnet oder bei ssh. Warum? Daher: Ausschaltbar über Socket-Option (NO_DELAY), in Java: Socket.setTcpNoDelay(boolean) - Spezifikation siehe RFC 1122 Mandl/Bakomenko/Weiß Seite 13

14 Algorithmus von Nagle Pseudocode If neue Daten zum Senden vorhanden if the window size >= MSS and verfügbare Datenlänge >= MSS else Sende sofort ein komplettes Segment mit Länge = MSS; if es sind noch Daten nicht bestätigt (ACK fehlt) Lege Daten in den Sendepuffer solange bis ein ACK empfangen wird; else Sende Daten sofort; end if end if end if Mandl/Bakomenko/Weiß Seite 14

15 Silly-Window-Syndrom Empfangsprozess sehr langsam Partner 1 TCP- Instanz 1 TCP- Instanz 2 Partner 2 Verbindung steht... Empfangspuffer ist voll! send Puffern im Sendepuffer WIN=1 Ein Byte lesen Empfangspuffer hat wieder Platz für ein Byte receice (1) Ein Byte senden Empfangspuffer ist voll! WIN=1 Ein Byte lesen receice (1) Ein Byte senden... Mandl/Bakomenko/Weiß Seite 15

16 Silly-Window-Syndrom Lösungsansatz: Algorithmus von Clark Problem: Empfängerprozess holt Daten zu langsam ab Optimierung des Bestätigungsverhaltens wegen des Silly Window Syndroms notwendig Clarks Lösung - Verhindert, dass Sende-Instanz ständig kleine Segmente sendet, da Empfängerprozess sehr langsam ausliest - Verzögerung der ACK-PDU oder Senden von ACK-PDU mit Window Size = 0 - Es wird solange verzögert, bis der Empfänger eine halbe Segmentlänge gelesen hat oder der Empfangspuffer halb leer ist Nagle und Clark ergänzen sich in einer TCP- Implementierung Quelle: Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011) Mandl/Bakomenko/Weiß Seite 16

17 Überblick 1. TCP (Transmission Control Protocol) - Sliding-Window-Mechanismus - Optimierungen: Algorithmen von Nagle und Clark, Silly Window Syndrom - Staukontrolle - TCP-Timer - TCP-Zustandsautomat 2. UDP (User Data Protocol) - Einordnung und Aufgaben des Protokolls - Der UDP-Header - Datenübertragung Mandl/Bakomenko/Weiß Seite 17

18 Staukontrolle bzw. Überlastkontrolle Überblick 1986 gab es im Internet massive Stausituationen Seit 1989 ist Staukontrolle ein wichtiger Bestandteil von TCP J. Nagle: Congestion Control in IP/TCP Internetworks, in RFC 896, 1984 Grundüberlegungen IP reagiert nicht auf Überlastsituationen, ausgenommen über neue Ansätze (ECN) Verlust eines TCP-Segmentes wird von TCP als Auswirkung einer Stausituation im Netz interpretiert Annahme: Netze sind prinzipiell stabil, eine fehlende ACK- PDU nach dem Senden einer Nachricht wird als Stau im Netz betrachtet Mandl/Bakomenko/Weiß Seite 18

19 Staukontrolle bzw. Überlastkontrolle Lösungsansatz (1) TCP tastet sich an die maximale Datenübertragungsrate einer Verbindung heran Neben dem Empfangsfenster wird ein neues Fenster eingeführt: Das Staukontrollfenster (bzw. Überlastfenster) Es baut auf dem Erkennen von Datenverlusten auf Die Übertragungsrate wird bei diesem Verfahren im Überlastfall vom Sender massiv gedrosselt, die Datenmengen werden kontrolliert Das verwendete Verfahren ist das reaktive Slow-Start- Verfahren (RFC 1122) TCP-Implementierungen müssen das Slow-Start-Verfahren unterstützen Mandl/Bakomenko/Weiß Seite 19

20 Staukontrolle bzw. Überlastkontrolle Lösungsansatz (2) Quittungen (ACK-PDUs) dienen als Taktgeber für den Sender Jede Verbindungsseite führt ein Überlast- und ein Empfangsfenster für den Partner Es gilt: Sendekredit für eine TCP-Verbindung = min {Überlastfenster des Partners, Empfangsfenster des Partners} Das Slow-Start-Verfahren kennt zwei Phasen: - Slow-Start-Phase - Probing-Phase Mandl/Bakomenko/Weiß Seite 20

21 Überlastungsfenster (KiB) Staukontrolle bzw. Überlastkontrolle Lösungsansatz (3) Initiale TCP-Segmentlänge im Beispiel 1 KiB (MSS wird ausgetauscht beim Verbindungsaufbau) 1. Schwellwert im Beispiel 32 KiB Ein Timeout tritt im Beispiel bei Überlastfenstergröße von 40 KiB ein Schwellwert wird dann auf 20 KiB gesetzt Übertragung beginnt wieder mit einem Segment (TCP- Variante Tahoe) Schwelle Schwelle. Timeout Schwelle Anzahl der Übertragungen bzw. Round Trips Mandl/Bakomenko/Weiß Seite 21

22 Staukontrolle bzw. Überlastkontrolle Lösungsansatz (4) Slow-Start-Phase: - Sender und Empfänger einigen sich auf eine erste sendbare TCP-Segmentlänge (MSS = z.b Bytes) - Sender sendet zunächst ein Segment dieser Länge - Jeweils Verdoppelung des Überlastfensters bei erfolgreicher Übertragung aller Segmente bis zum Empfangsfenster (exponentielle Steigerung) Für jedes bestätigte TCP-Segment wird im nächsten Schritt das Überlastfenster um ein Segment erhöht - Ein Schwellwert (Threshold) wird ermittelt - Bei Erreichen des Schwellwerts geht es in die Probing-Phase über Gar nicht so langsam! Mandl/Bakomenko/Weiß Seite 22

23 Staukontrolle bzw. Überlastkontrolle Lösungsansatz (5) Die Probing-Phase: - Bei jeder empfangenen Quittung wird die Größe des Überlastfensters nur noch um eine Segmentlänge erhöht, wenn alle Segmente aus dem Überlastfenster erfolgreich übertragen wurden - Berechnung des Überlastfenster bei Ankunft der ACK-PDUs für alle übertragenen Segmente innerhalb des Überlastfenster: Neues Überlastungsfenster += 1 Segment Weiterhin gilt: Sendekredit = min {Überlastfenster, Empfangsfenster} - Es tritt kein Problem auf Überlastfenster steigt bis zum Empfangsfenster und bleibt dann konstant Bei Änderung des Empfangsfensters wird Sendekredit angepasst Mandl/Bakomenko/Weiß Seite 23

24 Staukontrolle bzw. Überlastkontrolle Lösungsansatz (6) ACK wird nicht empfangen - Man geht davon aus, dass ein weiterer Sender hinzugekommen ist - Mit diesem neuen Sender muss man die Pfadkapazität teilen - Der Schwellwert wird um die Hälfte der aktuellen Segmentanzahl reduziert - Die Segmentanzahl wird wieder auf das Minimum heruntergesetzt Die Timerlänge ist entscheidend! - Zu lang: Evtl. Leistungsverlust - Zu kurz: Erhöhte Last durch erneutes Senden - Dynamische Berechnung anhand der Umlaufzeit eines Segments (vgl. Zitterbart) Mandl/Bakomenko/Weiß Seite 24

25 Weitere Mechanismus: Fast Recovery nach RFC 2581 (siehe auch implizites NAK) Ergänzendes Verfahren zur Staukontrolle: Fast- Recovery-Algorithmus (TCP Reno als Weiterentwicklung zu TCP Tahoe) Empfang von 4 Quittierungen (drei ACK-Duplikate) für eine TCP-PDU veranlasst sofortige Sendewiederholung Die Sendeleistung wird entsprechend angepasst Der Schwellwert wird auf die Hälfte des aktuellen Staukontrollfensters reduziert Da nur von einem Paketverlust und nicht von einem Stau im Netzwerk ausgegangen wird, wird das Staukontrollfenster auf einen Wert über dem Schwellwert eingestellt (implementierungsabhängig) Mandl/Bakomenko/Weiß Seite 25

26 Überblick 1. TCP (Transmission Control Protocol) - Sliding-Window-Mechanismus - Optimierungen: Algorithmen von Nagle und Clark, Silly Window Syndrom - Staukontrolle - TCP-Timer - TCP-Zustandsautomat 2. UDP (User Data Protocol) - Einordnung und Aufgaben des Protokolls - Der UDP-Header - Datenübertragung Mandl/Bakomenko/Weiß Seite 26

27 TCP-Timer TCP verwendet einige Timer, Beispiele: - Retransmission Timer Zur Überwachung der TCP-Segmente nach Karn-Algorithmus, 1988 adaptives Verfahren Wenn Timer abläuft, wird er verdoppelt und das Segment erneut gesendet (Wiederholung) - Keepalive Timer Partner wird versucht zu erreichen Gelingt es, bleibt Verbindung bestehen - Timed Wait Timer Timer für Verbindungsabbau Läuft über doppelte max. Paketlaufzeit (Default: 120 s) Stellt sicher, dass alle gesendeten Pakete nach einem Disconnect-Request noch ankommen Mandl/Bakomenko/Weiß Seite 27

28 TCP-Timer 0,3 T 0,3 T1 T2 Wahrscheinlichkeit 0,2 0,1 Wahrscheinlichkeit 0,2 0, Rundreise (ms) Rundreise (ms) (a) Optimale Länge des Timers T Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 28 (b) Schlechte Timer T1 (zu kurz) und T2 (zu lang)

29 Überblick 1. TCP (Transmission Control Protocol) - Sliding-Window-Mechanismus - Optimierungen: Algorithmen von Nagle und Clark, Silly Window Syndrom - Staukontrolle - TCP-Timer - TCP-Zustandsautomat 2. UDP (User Data Protocol) - Einordnung und Aufgaben des Protokolls - Der UDP-Header - Datenübertragung Mandl/Bakomenko/Weiß Seite 29

30 Exkurs: Endliche Zustandsautomaten (1) Finite State Machine (FSM) - Deterministischer endlicher Automat mit Ausgabe (siehe Mealy-Automat): Zustandsveränderung hängt vom aktuellen Zustand und vom Input ab - Verwendet man gerne zur groben Beschreibung des Verhaltens von Protokollinstanzen - Ein endlicher Zustandsautomat lässt sich als Quintupel <S, I, O, T, s o > beschreiben: S - endliche, nicht leere Menge von Zuständen I - endliche, nicht leere Menge von Eingaben O - endliche, nicht leere Menge von Ausgaben T S x (I {t}) x O x S eine Zustandsüberführungsfunktion t bezeichnet eine leere Eingabe s o S Initialzustand des Automaten Mandl/Bakomenko/Weiß Seite 30

31 Exkurs: Endliche Zustandsautomaten (2) Eine Transition (Zustandsübergang) t T ist definiert durch das Quadrupel <s, i, o, s > wobei - s S der aktuelle Zustand, - i I eine Eingabe, - o O eine zugehörige Ausgabe und - s S der Folgezustand ist Grafische Darstellung eines Zustandsübergangs i / o s s i / o,... s s Erweitert: mehrere Ausgaben Mandl/Bakomenko/Weiß Seite 31

32 Exkurs: Endliche Zustandsautomaten (3) Nachteil von FSM: Keine weiteren Zustandsinformationen z.b. in Variable modellierbar Daher in der Praxis oft Nutzung erweiterter endlicher Automaten (EFSM) für die Detailspezifikation, um Zustandskontexte noch besser zu beschreiben nutzt weitere Variable neben Zustandsvariable Modellierung z.b. in der Sprache SDL (Spezification and Description Language) Beispiel: ACK Aktion1 S1 t Aktion2 DR ACK Kontrollflüsse Variablen Aktionen.. S2 -- S3 Mandl/Bakomenko/Weiß Seite 32

33 Zustandsautomat allgemein Client- Anwendung Server- Anwendung [Socket-Interface] TCP-Instanz (Client) [TCP-Protokoll] TCP-Instanz (Server) Je ein Zustandsautomat pro Transportverbindung wird in jeder beteiligten TCP-Instanz verwaltet Mandl/Bakomenko/Weiß Seite 33

34 Zustände im TCP-Zustandsautomat (nur Verbindungsmanagement) Zustand CLOSED LISTEN SYN_RCVD SYN_SENT ESTABLISHED FIN_WAIT_1 FIN_WAIT_2 TIME_WAIT CLOSING CLOSE_WAIT LAST_ACK Beschreibung Keine Verbindung aktiv oder anstehend Der Server wartet auf eine ankommende Verbindung Ankunft einer Verbindungsanfrage und Warten auf Bestätigung Die Anwendung hat begonnen, eine Verbindung zu öffnen Zustand der normalen Datenübertragung Die Anwendung möchte die Übertragung beenden, Close-Aufruf wurde bereits abgesetzt Die andere Seite ist einverstanden, die Verbindung abzubauen, Bestätigung (ACK) gesendet Warten, bis keine Segmente mehr kommen Beide Seiten haben versucht, gleichzeitig zu beenden Die Gegenseite hat den Abbau eingeleitet, warten auf Close- Aufruf der lokalen Anwendung Warten, bis letzte Bestätigung (ACK) für Verbindungsabbau angekommen ist Mandl/Bakomenko/Weiß Seite 34

35 TCP als FSM Ein TCP-Zustandsautomat für das TCP-Verbindungsmanagement lässt sich als Quintupel <S, I, O, T, s o > beschreiben: S = {CLOSED, LISTEN, SYN_RCVD,...} I = {connect, send, close, SYN, ACK, FIN,...} O = {SYN, ACK, FIN,...} s o = CLOSED S Hinweis: Wir beschreiben im Weiteren nur die Transitionen des Verbindungsauf- und abbaus Beispiel einer Transition: Aufruf an der Socket- Schnittstelle Gesendetes TCP-Segment mit SYN-Flag CLOSED connect / SYN SYN_SENT Mandl/Bakomenko/Weiß Seite 35

36 Finite-State-Machine-Modell für das TCP-Verbindungsmanagement (1) fette Linie: normaler Pfad des Clients fette gestrichelte Linie: normaler Pfad des Servers feine Linie: ungewöhnliche Ereignisse (Start) CLOSED CONNECT/SYN CLOSE/- LISTEN/- CLOSE/- SYN/SYN +ACK LISTEN SYN RCVD RST/- SYN/SYN + ACK SEND/SYN (gleichzeitig geöffnet) SYN SENT CLOSE/FIN zu FIN WAIT 1 ACK/- (Datenübertragung) ESTABLISHED SYN + ACK/ACK (Schritt 3 des Dreiwege-Handshakes) Mandl/Bakomenko/Weiß Seite 36

37 Finite-State-Machine-Modell für das TCP-Verbindungsmanagement (2) von SYN RCVD ESTABLISHED SYN + ACK/ACK (Schritt 3 des Dreiwege-Handshakes) CLOSE/FIN FIN/ACK (ClOSE aktiv) (CLOSE passiv) FIN WAIT 1 FIN/ACK CLOSING CLOSE WAIT ACK/- ACK/- CLOSE/FIN FIN WAIT 2 FIN + ACK/ACK FIN/ACK TIME WAIT LAST ACK (Timeout/-) CLOSED ACK/- (Zurück zum Anfang) Es gibt vier Möglichkeiten, die Verbindung abzubauen. Welche? 1) Close Aktiv 2) Close passiv 3) Beide gleichzeitig (FIN_WAIT_1 CLOSING TIME_ WAIT CLOSED) 4) Selten: Close auf passiver Seite bei FIN schon da Mandl/Bakomenko/Weiß Seite 37

38 Finite-State-Machine-Modell Aktiver Partner (vereinfacht) s (konfigurierbar) CLOSED CONNECT / SYN (Start) TIME_WAIT SYN_SENT FIN / ACK SYN+ACK / ACK FIN_WAIT_2 ESTABLISHED ACK / - FIN_WAIT_1 CLOSE / FIN Mandl/Bakomenko/Weiß Seite 38

39 Finite-State-Machine-Modell Passiver Partner (vereinfacht) ACK / - CLOSED LISTEN / - LAST_ ACK LISTEN CLOSE / FIN SYN / SYN+ACK CLOSE_ WAIT SYN_ RCVD FIN / ACK ESTABLISHED ACK / - Mandl/Bakomenko/Weiß Seite 39

40 Verbindungsaufbau 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 40

41 Verbindungsabbau Client baut die Verbindung ab (auch Server kann es) Alle Segmente mit Folgenummer < i bzw. j sind noch zu verarbeiten T-Instanz 1 T-Instanz 2 ESTABLISHED close-aufruf FIN_WAIT_1 FIN_WAIT_2 ESTABLISHED Anwendung informieren CLOSE_WAIT close-aufruf TIME_WAIT Warten... CLOSE LAST_ACK CLOSE Zustände im TCP-Zustandsautomat: ESTABLISHED, FIN_WAIT_1, FIN _WAIT_2, TIME_WAIT, CLOSE, CLOSE_WAIT, LAST_ACK Mandl/Bakomenko/Weiß Seite 41

42 Übung Wozu dienen folgende Stati des TCP- Zustandsautomaten: - SYN_RECVD - SYN_SENT - TIME_WAIT - CLOSE_WAIT Betrachten Sie mit dem Kommando netstat die Zustände diverser TCP-Verbindungen, die auf Ihrem Rechner laufen - Web-Browser - Chat-Anwendung -... Mandl/Bakomenko/Weiß Seite 42

43 Einschub für Interessierte: Zustandsautomaten implementieren Wie implementiert man einen Zustandsautomaten? - Welches Prozess-/Threadmodell verwendet man? Ein bekanntes Modell: Server-Modell - Auftretende Ereignisse (Nachrichten, Timeouts, Dienstaufrufe) müssen verarbeitet werden und führen zu Zustandsänderungen und Aktionen Mehrere Varianten - Bei jedem Ereignis über Switch-Case-Konstruktionen prüfen, welche Aktion ausgeführt werden soll und ob das Ereignis zulässig ist - Nutzung des State Patterns zur Vermeidung von ewigen Switch-Case- Konstruktionen State Pattern (Objektorientierter Ansatz) - Jeder Zustand wird als eigene Objektklasse implementiert, die von einer Basisobjektklasse erbt Mandl/Bakomenko/Weiß Seite 43

44 Einschub für Interessierte: Zustandsautomaten implementieren - Server-Modell (1) Das Server-Modell - Protokollinstanz wird als zyklisch arbeitender sequentieller Prozess/Thread umgesetzt - Eingabewarteschlange für auftretende Ereignisse wird an einem Ereigniswartepunkt abgearbeitet - Ereignisse werden zyklisch in einer Endlosschleife abgearbeitet: - Grober Algorithmus: Ereignis aus der Warteschlange lesen Analyse des eingehenden Ereignisses (Nachricht) Aktion auf Basis des aktuellen Zustandes auswählen Ggf. Fehleranalyse und Fehlerreaktion Aktion ausführen, Transition durchführen (in Zustand gehen) und Ausgabe erzeugen Und dann wieder von vorne: Nächstes Ereignis aus der Warteschlange lesen Mandl/Bakomenko/Weiß Seite 44

45 Einschub für Interessierte: Zustandsautomaten implementieren - Server-Modell (2) Dienstaufruf Eingabewarteschlange (receive) Ankommende PDU Timeout Timerbaustein Zentraler Wartepunkt Ereignis lesen Transition ermitteln Zustand 1 Zustand n Ereignis 1 Ereignis n Ereignis 1 Ereignis n Aktion für Ereignis 1 Aktion für Ereignis n Aktion für Ereignis 1 Aktion für Ereignis n Ausgabe (send) Protokollinstanz König, H.: Protocol Engineering, Teubner, 2003 Mandl/Bakomenko/Weiß Seite 45

46 Einschub für Interessierte: Zustandsautomaten implementieren - Server-Modell (3) Eingabewarteschlange (receive) Programmierte Auswahl Zentraler Wartepunkt Ereignis lesen Transition ermitteln switch (zustand) { case (Closed) if (ereignis == ConnectReqPDU) {... } else if... case (Connecting) if (ereignis == Timeout) {... } else if } Ausgabe (send) Protokollinstanz König, H.: Protocol Engineering, Teubner, 2003 Mandl/Bakomenko/Weiß Seite 46

47 Einschub für Interessierte: Zustandsautomaten implementieren - Server-Modell (4) Eingabewarteschlange (receive) Tabellengesteuerte Auswahl Zentraler Wartepunkt Ereignis lesen Ereignis / Zustand Connect Req Connect Rsp Data ReqPDU Closed Aktion_1 Transition ermitteln Ausgabe (send) Connecting -- Accepting Aktion_n Established Aktion_k Sending --- Testing Protokollinstanz König, H.: Protocol Engineering, Teubner, 2003 Mandl/Bakomenko/Weiß Seite 47

48 Einschub für Interessierte: Zustandsautomaten implementieren - Server-Modell (5) Kritik am Server-Modell - Positiv - Negativ Einfacher Entwurf, da Zustandsautomat direkt abgebildet wird Einfach zu implementieren Bei vielen Zuständen unübersichtlich, da viele Switch-Case und If- Konstruktionen zur Ermittlung der nächsten Transition notwendig sind Evtl. nicht so leistungsfähig, da alles in einem Prozess/Thread erledigt wird Verbesserung durch Ausführen einer Aktion in einem eigenen Thread Mandl/Bakomenko/Weiß Seite 48

49 Überblick 1. TCP (Transmission Control Protocol) - Sliding-Window-Mechanismus - Optimierungen: Algorithmen von Nagle und Clark, Silly Window Syndrom - Staukontrolle - TCP-Timer - TCP-Zustandsautomat 2. UDP (User Data Protocol) - Einordnung und Aufgaben des Protokolls - Der UDP-Header - Datenübertragung Mandl/Bakomenko/Weiß Seite 49

50 Einordnung und Aufgaben Unzuverlässiges, verbindungsloses Transportprotokoll - Keine Empfangsbestätigung für Pakete - UDP-Nachrichten können ohne Kontrolle verloren gehen - Eingehende Pakete werden nicht in einer Reihenfolge sortiert - Maßnahmen zur Erhöhung der Zuverlässigkeit müssen im Anwendungsprotokoll ergriffen werden, z.b. ACK und Warten mit Timeout Wiederholtes Senden bei fehlendem ACK Vorteile von UDP gegenüber TCP - Bessere Leistung möglich, aber nur, wenn TCP nicht nachgebaut werden muss - Multicast- und Broadcast wird unterstützt Mandl/Bakomenko/Weiß Seite 50

51 Einordnung und Aufgaben Bei UDP ist keine explizite Verbindungsaufbau- Phase erforderlich und entsprechend auch kein Verbindungsabbau Userprozess erzeugt ein UDP-Socket und kann Nachrichten senden und empfangen Nachrichten werden bei UDP als Datagramme bezeichnet In den Datagrammen wird die T-SAP-Adresse des Senders und des Empfängers gesendet (UDP-Ports) Mandl/Bakomenko/Weiß Seite 51

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

53 UDP-Header (PCI) Distanz in Byte 32 Bit 0 4 UDP-Quellportnummer Länge UDP-Zielportnummer Prüfsumme (optional) 8 Daten (optional) Mandl/Bakomenko/Weiß Seite 53

54 UDP-Header UDP-Ziel-Portnummer Nummer des empfangenden Ports UDP-Quell-Portnummer Nummer des sendenden Ports Länge Größe des UDP-Segments inkl. Header in Byte Prüfsumme (optional) Prüft das Gesamtsegment (Daten + Header) einschließlich eines Pseudoheaders Daten Nettodaten der Nachricht Mandl/Bakomenko/Weiß Seite 54

55 Pseudoheader (1) Die Prüfsumme ist die einzige Möglichkeit, die intakte Übertragung beim Empfänger zu verifizieren Vor dem Berechnen der Prüfsumme wird Pseudoheader ergänzt Das Segment wird auf eine durch 16 Bit teilbare Größe aufgefüllt (gerade Anzahl an Bytes) Berechnung auch wie bei TCP über Addition der Einerkomplemente der 16-Bit-Wörter und Bildung des Einerkompliments der Summe (RFC 1071) 32 Bit IP-Adresse des Senders IP-Adresse des Empfängers Zero Protokoll (17) UDP-Länge (ohne Pseudo Header) Mandl/Bakomenko/Weiß Seite 55

56 Pseudoheader (2) Der Empfänger muss bei Empfang einer UDP- Nachricht folgendes unternehmen: - die IP-Adressen aus dem ankommenden IP-Paket lesen - Der Pseudoheader muss zusammengebaut werden - Die Prüfsumme muss ebenfalls berechnet werden (vorher Prüfsumme aus UDP-Datagramm entfernen) - Die mit gesendete Prüfsumme mit der berechneten vergleichen Wenn die beiden Prüfsummen identisch sind, dann muss das Datagramm seinen Zielrechner und auch den richtigen UDP-Port erreicht haben - Ziel des Pseudoheaders ist es somit, beim Empfänger herauszufinden, ob das Paket den richtigen Empfänger gefunden hat Mandl/Bakomenko/Weiß Seite 56

57 Einige well-known UDP-Portnummern UDP- Portnummer Protokoll, Service 53 DNS Domain Name Service 520 RIP Routing Information Protocol 161 SNMP Simple Network Management Protocol 69 TFTP Trivial File Transfer Protocol Mandl/Bakomenko/Weiß Seite 57

58 Begrenzte Nachrichtenlänge bei UDP Die Länge eines UDP-Segments ist minimal 8 Byte und maximal = Byte Nettodatenlänge = = Byte Darüber hinaus ist es sinnvoll, die UDP-Segmente nicht länger als in der möglichen IP-Paketlänge zu versenden, da sonst fragmentiert werden muss Mandl/Bakomenko/Weiß Seite 58

59 Rückblick 1. TCP (Transmission Control Protocol) - Sliding-Window-Mechanismus - Optimierungen: Algorithmen von Nagle und Clark, Silly Window Syndrom - Staukontrolle - TCP-Timer - TCP-Zustandsautomat 2. UDP (User Data Protocol) - Einordnung und Aufgaben des Protokolls - Der UDP-Header - Datenübertragung Mandl/Bakomenko/Weiß Seite 59