Rechnernetze und Internettechnologien

Transkript

1 Rechnernetze und Internettechnologien Dr. Harald Sack Institut für Informatik Friedrich-Schiller-Universität Jena Sommersemester

2 n Vorlesung Nr Datentransport Schicht 4 Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 2

3 n 7. Datentransport - Schicht Transportschicht - Aufgaben und Funktionsweise 7.2 Schnittstelle für die Anwendungsschicht 7.3 Transmission Control Protocol - TCP 7.4 Universal Datagram Protocol - UDP Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 3

4 n 7.1 Transportschicht - Aufgaben und Funktionsweise TCP/IP Referenzmodell Verarbeitung (Application Layer) Transport (Transport Layer) Vermittlung (Internet Layer) Sicherung (Data Link Layer) Bitübertragung (Physical Layer) Aufgabe der Transportschicht ist der zuverlässige und sichere Transport von Datenströmen zwischen zwei Endsystemen über eine virtuelle Verbindung Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 4

5 n 7.1 Transportschicht - Aufgaben und Funktionsweise Services des IP-Protokolls Verbindungslos Jedes IP-Datenpaket kann auf unterschiedlichem Weg zum Ziel gelangen Best Effort Es wird nicht garantiert, dass ein gesendetes Datenpaket tatsächlich am Ziel ankommt bzw. wann es dort eintrifft ABER: Bestimmte Aufgaben erfordern Dienstgarantien (Quality of Service) Sichere Übertragung Einhaltung von Zeitschranken Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 5

6 n 7.1 Transportschicht - Aufgaben und Funktionsweise Protokolle der Transportschicht (1/2) Auf dem verbindungslosen Datagrammdienst IP in der Netzwerkschicht setzen die Protokoll der Transportschicht auf Prominentester Vertreter ist TCP Transmission Control Protocol TCP (RFC 793) leistet dabei scheinbar unmögliches: Auf Basis des unzuverlässigen IP-Datagrammdienst bietet es einen zuverlässigen, gesicherten Transportdienst zum Datenaustausch zwischen zwei Endsystemen Idee: TCP gleicht Fehler und Fehlverhalten des IP-Datagrammdienstes aus Erfolg des Internets ist neben IP vor allem dem TCP-Protokoll zu danken TCP/IP-Protokoll Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 6

7 n 7.1 Transportschicht - Aufgaben und Funktionsweise Protokolle der Transportschicht (2/2) Ermöglichen zuverlässigen und verbindungsorientierten Transport über ein an sich unzuverlässiges Netzwerk TCP Transmission Control Protocol (RFC 793) Komplexes Transportprotokoll, das gesicherten, verbindungsorientierten Vollduplex-Datenstrom zwischen zwei Endsystemen realisiert UDP User Datagram Protocol (RFC 768) Einfaches Transportprotokoll, das ungesicherte, verbindungslose Kommunikation zwischen zwei Endsystemen realisiert Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 7

8 n 7.1 Transportschicht - Aufgaben und Funktionsweise Verbindungsorientierte Datenübertragung (1/3) Vor der eigentlichen Datenübertragung wird eine Verbindung zum designierten Empfänger aufgebaut, die nach der Datenübertragung wieder abgebaut wird Von TCP bereitgestellte Verbindung ist virtuelle Verbindung, die TCP- Prozesse auf den Endsystemen täuschen Verbindung Softwaretechnisch vor TCP benutzt IP-Datagrammdienst zur Datenübertragung, jede TCP- Nachricht wird in IP-Datagramm gekapselt über das Internet übertragen IP behandelt TCP-Nachrichten als reine Nutzdaten TCP muss nur in den Endsystemen implementiert sein, nicht in den Zwischensystemen Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 8

9 n 7.1 Transportschicht - Aufgaben und Funktionsweise Verbindungsorientierte Datenübertragung (2/3) Sender Anwendung TCP Virtuelle und zuverlässige Verbindung der Endsysteme Empfänger Anwendung TCP IP Hardware IP Netzwerkschnittstelle Netzwerkschnittstelle Hardware IP Netzwerkschnittstelle Hardware Netz 1 Netz 2 Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 9

10 n 7.1 Transportschicht - Aufgaben und Funktionsweise Verbindungsorientierte Datenübertragung (3/3) TCP erlaubt ausschließlich eine Datenübertragung zwischen zwei dezidierten Endsystemen (Ende-zu-Ende-Datenübertragung) Verbindung läuft quasi von einer Anwendung beim Sender zu einer Anwendung beim Empfänger Für den Aufbau der virtuellen Verbindung tragen allein die beiden Endsysteme Verantwortung, die zu überbrückenden Netze und Zwischensysteme leiten Nachrichten nur weiter Multicast oder Broadcast ist mit TCP nicht möglich Jeweils ausgestattet mit Eingangspuffern können Sender und Empfänger gleichzeitig senden (bidirektionale Datenübertragung) Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 10

11 n 7.1 Transportschicht - Aufgaben und Funktionsweise Zuverlässige Datenübertragung (1/4) TCP garantiert fehlerfreie Datenübertragung ohne Datenverlust und ohne Vertauschung der Reihenfolge der empfangenen Datenpakete TCP bedient sich dazu der folgenden Techniken Neuübertragung Adaptive Neuübertragung Überlastkontrolle Congestion Control Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 11

12 n 7.1 Transportschicht - Aufgaben und Funktionsweise Zuverlässige Datenübertragung (2/4) Die von TCP im Fehlerfall initiierte Neuübertragung (Retransmission) von Datenpaketen ist Grundtechnik zur Gewährleistung der fehlerfreien und zuverlässigen Übertragung Gesendete TCP-Nachrichten werden nach Empfang vom Empfänger bestätigt (Acknowledgement) Sender startet vor Übertragung eine Uhr (Timer), läuft die vor Eintreffen einer Bestätigung ab, gilt Nachricht als verloren und wird neu übertragen Um Neuübertragung zu erzwingen, sendet Empfänger kein Acknowledgement und wartet auf automatische Neuübertragung nach Ablauf des Timers Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 12

13 n 7.1 Transportschicht - Aufgaben und Funktionsweise Zuverlässige Datenübertragung (3/4) Sender Nachricht 1 senden Nachricht 1 bestätigt Nachricht 2 senden Nachricht 2 verloren Empfänger Nachricht 1 empfangen Bestätigung senden Timer abgelaufen Nachricht 2 erneut senden Nachricht 2 bestätigt Nachricht 2 empfangen Bestätigung senden Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 13

14 n 7.1 Transportschicht - Aufgaben und Funktionsweise Zuverlässige Datenübertragung (4/4) Wahl einer festen Zeitschranke für den Timer kann nie allen Situationen gerecht werden TCP bietet deshalb adaptiven Mechanismus (Adaptive Retransmission) zur Anpassung der Zeitschanke TCP überwacht dazu die Netzlast für jede Verbindung durch Ermittlung der Paketumlaufzeit (Round-Trip-Time), also der Zeitspanne zwischen Aussendung eines Pakets und Empfang von dessen Eingangsbestätigung: Messung wird für jede Sendung ausgeführt und mit vorhergehenden Messungen auf der gleichen Verbindung verglichen über gleitenden Mittelwert (Smoothed Round-Trip-Time) wird Zeitspanne der momentanen Lastsituation angepasst Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 14

15 n 7.1 Transportschicht - Aufgaben und Funktionsweise Flusskontrolle (1/3) TCP regelt Fluss (Flow Control) über eine Verbindung mit Hilfe des Schiebefenster-Protokolls (Sliding Window Protocol) Schiebefenster-Protokoll arbeitet mit adaptiven lastabhängigen Fenstern, wobei Quittierung und Zuweisung eines Fensters voneinander entkoppelt sind Prinzip: Vergabe eines Kredits über die Menge von Bytes die ohne Bestätigung (ACK) gesendet werden dürfen die Fenstergröße wird um die Anzahl der übertragenen Bytes reduziert mit einem ACK wird die neu berechnete Fenstergröße dem Sender übergeben Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 15

16 n 7.1 Transportschicht - Aufgaben und Funktionsweise Flusskontrolle (2/3) Beispiel: Nachricht der Länge Byte wird per TCP-Verbindung mit Fenstergröße Byte von A nach B übertragen A sendet die ersten Byte B nimmt diese entgegen, schreibt sie in Eingangspuffer, setzt Fenstergröße auf = 500 (F=500) herab und bestätigt Annahme der ersten Byte (ACK=1.000) A überträgt gemäß erlaubter Fenstergröße die nächsten 500 Byte B nimmt diese entgegen, setzt Fenstergröße auf 0 (F=0) und bestätigt Empfang A muss nun warten, bis Anwendung von B aus Eingangspuffer Byte ausgelesen hat, die Fenstergröße wieder auf Byte setzt (F=1.000) und entsprechende Mitteilung schickt (ACK=1.500) A kann nun Rest der Nachricht (1.000 Byte) schicken Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 16

17 n 7.1 Transportschicht - Aufgaben und Funktionsweise Flusskontrolle (3/3) Sendet Sendet Sender Rechner A Empfänger Rechner B ACK bis 1.000, F=500 ACK bis 1.500, F= aus Puffer gelesen ACK bis 1.500, F=1.000 Fenstergröße F=1.500 leer voll Sendet Sendet ACK bis 2.000, F=500 ACK bis 2.500, F= aus Puffer gelesen ACK bis 2.500, F= voll t t 500 aus Puffer gelesen ACK bis 2.500, F=1.500 leer Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 17

18 n 7.1 Transportschicht - Aufgaben und Funktionsweise Überlastkontrolle (1/5) Überlaststeuerung (Congestion Control) ist eines der schwierigsten Problem für TCP, da TCP Überlastsituationen nicht direkt erkennen kann: Datenpakete werden per IP auf unterschiedlichen Wegen durch das Internet befördert, so dass keine direkten Rückschlüsse auf Überlast bestimmter Zwischensystem gezogen werden können verschiedene TCP-Instanzen können nicht miteinander kooperieren Idee: TCP nutzt Zahl der verlorenen (also nicht bestätigten) Segmente als Maß für Überlast und Parameter für Bestimmung des Congestion Windows zur Regelung der Überlast Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 18

19 n 7.1 Transportschicht - Aufgaben und Funktionsweise Überlastkontrolle (2/5) Slow-Start Algorithmus zur schnellen Anpassung des Congestion Windows Verbindungen werden mit kleiner Fenstergröße gestartet, die dann solange exponentiell gesteigert wird, bis Segmente verloren gehen Congestion-Avoidance Algorithmus zum Abbau von Überlastsituationen häuft sich der Segmentverlust d.h. Quittungen erreichen Sender nicht innerhalb der festgesetzten Zeitspanne senkt TCP die Sende-Datenrate um eine Überlastung des Netzwerkes nicht mit ständiger Wiederholung von Sendungen zu verschärfen Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 19

20 n 7.1 Transportschicht - Aufgaben und Funktionsweise Überlastkontrolle (3/5) Nagle Algorithmus Zur Einschränkung des Overheads beim Senden sind TCP-Segmente nur von kurzer Länge, machen Steuer- und Kontrollinformationen im Header den Großteil der zu übertragenden Daten aus Quittierung eines Segmentes wird deshalb solange als möglich verzögert, um dann z.b. mit eigenen Nutzdaten oder anderen ausstehenden Quittungen zu erfolgen der Nagle-Algorithmus sammelt alle Nutzdaten bis zur nächstfälligen Quittung und überträgt diese dann gemeinsam Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 20

21 n 7.1 Transportschicht - Aufgaben und Funktionsweise Überlastkontrolle (4/5) Silly Window Syndrom ohne zusätzliche Vorkehrungen würde sich bei schnellen Verbindungen die Fenstergröße nahe 0 einpegeln und die Übertragungsstrecke nur unzureichend genutzt Empfänger gibt deshalb Rückmeldung über verfügbare Fenstergröße erst dann, wenn wieder mindest 50% der max. Fenstergröße zur Verfügung stehen Sender sorgt dafür, dass verfügbare Fenstergröße nicht vollständig ausgenutzt wird Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 21

22 n 7.1 Transportschicht - Aufgaben und Funktionsweise Überlastkontrolle (5/5) Silly Window Syndrom Empfänger Buffer ist voll Anwendung liest 1 Byte Platz für 1 Byte TCP-Header TCP-Header 1 Byte Nutzdaten Fenster Update Segment gesendet 1 neues Byte kommt an Empfänger Buffer ist voll Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 22

23 n 7.1 Transportschicht - Aufgaben und Funktionsweise Round Trip Time (RTT) (1/3) Orginalimplementierung (Jacobsen, 1988): Für jede Verbindung verwaltet TCP die Variable RTT (= beste Schätzung der Übertragungszeit zum Ziel bis zum Erhalt der Bestätigung) Wird Segment gesendet, wird Timer gestartet Gemessene Zeit vom Senden bis zur Bestätigung: M M wird für jedes gesendete Segment ermittelt und ein gewichtetes Mittel für RTT errechnet: RTT = RTT + (1-) M, Glättungsfaktor = 0,8 Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 23

24 n 7.1 Transportschicht - Aufgaben und Funktionsweise Round Trip Time (RTT) (2/3) Karn/Patrige Algorithmus: Bei Orginalimplementation kann Berechnung unterschätzt werden, da Zeit auch zwischen Neuaussendung eines verlorenen Pakets und verspätet eintreffender Quittierung des verlorenen Segments gemessen werden kann Karn/Patrige Algorithmus basiert RTT-Berechnung nur auf Messungen bei tatsächlich vom Empfänger quittierte Segmente zusätzlich wird Zeitschranke nach jedem erfolgreichen Versand angehoben (verdoppelt) Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 24

25 n 7.1 Transportschicht - Aufgaben und Funktionsweise Round Trip Time (RTT) (3/3) Karel/Jacobsen Algorithmus Verfeinerung von Karn/Patrige Algorithmus durch Gewichtung der Schwankungen der gemessenen Netzumlaufzeit (über Näherungswert der Standardabweichung D) zusätzlich wird Berechnung des Timeouts angepasst D = D + (1-) RTT - M Timeout = RTT + 4D Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 25

27 n 7.2 Schnittstelle für die Anwendungsschicht Adressierung (1/2) Damit eine Anwendung mit einer anderen Anwendung auf einem entfernten Rechner kommunizieren kann, muss der gewünschte Kommunikationspartner exakt angegeben werden können Zielrechner (IP-Adresse) Zielanwendung (Portnummer) TCP/UDP Socket Allgemeine Festlegung von Kommunikationsendpunkten: Transportschicht: Transport Service Access Point (TSAP) Netzwerkschicht: Network Service Access Point (NSAP) Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 27

28 n 7.2 Schnittstelle für die Anwendungsschicht Adressierung (2/2) Transport- Verbindung Source 1208 Dest Verbindung mit TSAP 1522 Listen Dienst Uhrzeit Connect Aufbau Transportverbindung Senden Client Request Uhrzeit Rückgabe Server Uhrzeit Verbindungsabbau Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 28

29 n 7.2 Schnittstelle für die Anwendungsschicht TCP-Ports (1/4) Um Verbindung zwischen zwei Endsystemen einzurichten und aufrecht zu erhalten, müssen auf Sender und Empfänger eindeutig identifizierbare Endpunkte der Kommunikation (Sockets) eingerichtet werden Sender Empfänger Internet Socket Reservierter Speicherplatz als Kommunikationspuffer Socket (IP-Adresse + Portnummer) Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 29

30 n 7.2 Schnittstelle für die Anwendungsschicht TCP-Ports (2/4) Portnummer ist eine 16 bit Adresse Definiert Verbindung zwischen Anwendung und Transportverbindung Reservierte (privilegierte) Ports (TCP/IP) (UNIX) Registrierte Ports (müssen von IANA registriert werden) Private (dynamische) Ports Bsp: HTTP - Port 80 SMTP ( ) - Port 25 POP3 ( ) - Port 110 Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 30

31 n 7.2 Schnittstelle für die Anwendungsschicht TCP-Ports (3/4) Auswahl der Portnummern beim Verbindungsaufbau zwischen zwei Anwendungsprogrammen: Zielport: Portnummer der gewünschten Anwendung Quellport: eine nicht reservierte und zur Zeit nicht anders genutzte Portnummer TCP-Verbindung kann anhand der beiden Socket-Nummern über das Tupel (Socket Sender, Socket Empfänger) eindeutig identifiziert werden Empfänger assoziiert über die angegebene Portnummer die zugehörige Anwendung, mit der kommuniziert werden soll Ein Socket kann mehreren Verbindungen gleichzeitig dienen Anwendungsprogramme nutzen Transportservice über sogenannte TCP-Primitives, z.b. Request, Response, Confirm, Read, Write,... Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 31

32 n 7.2 Schnittstelle für die Anwendungsschicht TCP-Ports (4/4) Empfänger überwacht ständig alle Ports auf eingehende Verbindungen Offene Ports können ein Sicherheitsrisiko darstellen können gesperrt werden Sender wahlfreie Zuordnung feste Zuordnung Empfänger HTTP Port x Port 80 HTTP SMTP Port y TCP TCP Port 25 SMTP TELNET Port z Port 23 TELNET TCP-Transport Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 32

34 n 7.3 Transmission Control Protocol Transmission Control Protocol Aufgabe: Bereitstellung eines zuverlässigen Bytestroms von einem Endpunkt zum anderen in einem unzuverlässigen Netzwerkverbund Ursprüngliche Version (RFC 793) wurde mehrfach nachgebessert (RFC 1122/1323) Unterteilt Datenstrom in max. 64 kbyte große Segmente Kommunikationsendpunkte (Sockets) addressieren eindeutig Endanwendung Stellt komplexe Verfahren bereit für Verbindungskontrolle Flusskontrolle Überlastkontrolle Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 34

35 n 7.3 Transmission Control Protocol Verbindungsorientierte Datenübertragung 1. Verbindungsaufbau 2. Datenübertragung 3. Verbindungsabbau Datenstrom von A i i+1 i+x i+x+1 i+x+2 i+z i+z+1 i+z+2 Start der Verbindung von A Start der Verbindung von B Ende der Verbindung von A Ende der Verbindung von B j j+1 j+y j+y+1 j+y+2 j+u j+u+1 j+u+2 Datenstrom von B Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 35

36 n 7.3 Transmission Control Protocol Zuverlässiger Verbindungsaufbau TCP verlangt von Sender und Empfänger eine Vereinbarung über die aufzubauende Verbindung evtl. Duplikatsegmente aus früheren Verbindungen können so ignoriert werden Wollen die Kommunikationspartner eine Verbindung beenden, sorgt TCP vor Abbau der Verbindung dafür, dass alle gesendeten aber noch nicht angekommenen Segmente zugestellt werden Zum Auf- bzw. Abbau von TCP-Verbindungen werden drei bzw. vier Nachrichten ausgetauscht 3-Wege-Handshake (Verbindungsaufbau) 4-Wege-Handshake (Verbindungsabbau) Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 36

37 n 7.3 Transmission Control Protocol 3-Wege Handshake (1/3) 3-Wege-Handshake sorgt dafür, dass beide Seiten zum Datenempfang bereit sind und dass die zur Identifikation der Verbindung wichtigen Sequenznummern ausgetauscht werden 3-Wege Handshake 1. Sender signalisiert Verbindungsaufbau-Wunsch mit Synchronisations-Segment und sendet Sequenznr x zur Identifikation (SYN+Sequenznr x) 2. Empfänger bestätigt Empfang des Synchronisations-Segments (SYN ACK+ Sequenznr x) und sendet eigene Sequenznr y zur Identifikation 3. Sender bestätigt Empfang von SYN ACK und der Sequenznr y Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 37

38 n 7.3 Transmission Control Protocol 3-Wege Handshake (2/3) Sender Sendet SYN, seq=x Empfängt SYN+ACK Sendet ACK y+1 Empfänger Empfängt x Sendet SYN, seq=y, ACK x+1 Empfängt ACK Verbindung eingerichtet Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 38

39 n 7.3 Transmission Control Protocol 3-Wege Handshake - verzögerte Duplikate (3/3) Verzögerter Connection Request (CR) Verzögerter CR + Acknowledgement (Ack) Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 39

40 n 7.3 Transmission Control Protocol 4-Wege Handshake - Verbindungsabbau (1/2) Partei möchte Verbindung beenden, muss aber darauf achten, dass alle abgesendeten Daten auch zugestellt werden, bevor die Verbindung beendet wird 1. Anwendung sendet ENDE-Segment (FIN) mit Sequenznr. x 2. Gegenseite bestätigt Empfang von FIN, nimmt keine weiteren Segmente mehr entgegen und benachrichtigt zuständiges Anwendungsprogramm Verbindung in Richtung SenderEmpfänger ist abgeschlossen 3. Anwendung auf Gegenseite beendet Verbindung und sendet eigenes FIN mit Sequenznr. y 4. Bestätigung des Empfangs des FIN-Segments Sobald Gegenseite die Bestätigung erhält, gilt die Verbindung als beendet Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 40

41 n 7.3 Transmission Control Protocol 4-Wege Handshake - Verbindungsabbau (2/2) Anwendung beendet Verbindung Sender Empfänger Sendet FIN, seq=x Empfängt FIN+ACK Empfängt FIN, x Sendet ACK x+1, Informiert Anwendung Anwendung beendet Verbindung Empfängt FIN+ACK Sendet ACK y+1 Sendet FIN, seq=y, ACK=x+1 Empfängt ACK Verbindung beendet Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 41

42 n 7.3 Transmission Control Protocol TCP - Zustandsübergangsdiagramm Activ Open SYN senden Closed Passiv Open SYN gesendet Close Close Listen SYN empfangen Close FIN senden FIN Wait FIN empfangen Established Closed SYN empfangen SYN gesendet FIN empfangen Close Wait Close FIN senden Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 42

43 n 7.3 Transmission Control Protocol TCP-Segmente TCP überträgt Nachrichten in Form von einzelnen Datenblöcken (Segmente) Bei Aufteilung einer Nachricht in Segmente (Segmentierung) wird jedes Segment mit einem TCP-Header versehen, der alle notwendigen Steuer- und Kontrollinformationen enthält Zum Transport werden TCP-Segmente in IP-Datagrammen fragmentiert und gekapselt Geht IP-Datagramm mit TCP-Segment verloren, wird das TCP- Segment nicht bestätigt und nach Timeout neu übertragen IP-Header TCP-Header IP-Nutzdaten TCP-Segment Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 43

44 n 7.3 Transmission Control Protocol TCP-Header (1/3) Source Port (16 Bit) Quell-Port, der mit Anwendungsprozess assoziiert ist, der die Verbindung gestartet hat Destination Port (16 Bit) Ziel-Port, ist mit Anwendungsprozess assoziiert, der die übertragenen Daten entgegennimmt Sequenznummer (32 Bit) zur Durchnumerierung der in Senderichtung übermittelten Segmente initialer Wert wird beim Verbindungsaufbau ausgetauscht Erhöhung erfolgt jeweils um Anzahl der bereits gesendeten Bytes Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 44

45 n 7.3 Transmission Control Protocol TCP-Header (2/3) Bestätigungsnummer (32 Bit) dient auf Empfängerseite zur Bestätigung empfangener Segment Header Length (4 Bit) Länge des TCP-Headers in 32-Bit Worten Code Bits (6 Bit) zeigen an, welche Felder im Header gültig sind Sendefenster Window (16 Bit) Zahl der Bytes, die Empfänger in seinen Eingabepuffer aufnehmen kann Prüfsumme (16 Bit) berechnet sich aus TCP-Header, TCP- Nutzdaten und einem Pseudo-Header, der aus TCP- und IP-Daten berechnet wird Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 45

46 n 7.3 Transmission Control Protocol TCP-Header (3/3) Urgent Pointer (16 Bit) zeigt an, dass neben den Nutzdaten dringliche Out-of-Band Daten, z.b. Interrupts, übertragen werden, die so schnell als möglich, z.b. ohne Ablage im Eingangspuffer, an Anwendungsprozess übermittelt werden sollen Optionen zur Einbeziehung zusätzlicher Funktionalität, z.b. Maximum Segment Size MSS, Window Scale WSopt, Timestamps Option TSopt, Selective Acknowledgement, Conection Count CC Füllbits füllen Länge des TCP-Segment-Headers auf Wortgrenze von 32 Bit auf Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 46

47 n 7.3 Transmission Control Protocol TCP-Segment Source Port Sequenznummer Destination Port Bestätigungsnummer HLEN reserviert Code Bits Fenstergröße Prüfsumme Urgent Pointer Optionen Füllbits Nutzdaten Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 47

48 n 7.3 Transmission Control Protocol TCP/IP Datenübertragung Datei Daten Daten Daten TCP-Segmente TCP-Header Daten IP-Pakete IP-Header TCP-Header Daten Frames Frame- Header LLC-Header IP-Header TCP-Header Daten Frame-Trailer Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 48

50 n 7.3 Universal Datagram Protocol UDP Protocol (1/2) TCP stellt zuverlässigen, verbindungsorientierten Transportdienst zur Verfügung Implementierung und Abarbeitung des TCP-Protokolls erfordern erheblichen Aufwand (z.b. Verbindungauf- und -abbau) Als Alternative z.b. zum Versand kurzer Nachrichten ohne vorherigem Verbindungsaufbau bietet UDP User Datagram Protocol einen verbindungslosen, unzuverlässigen Transportdienst UDP (RFC 768) setzt direkt auf IP auf und bietet als zusätzliche Funktionalität lediglich die Bereitstellung von Kommunikationsports UDP-Ports zur Verknüpfung der kommunizierenden Anwendungen Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 50

51 n 7.3 Universal Datagram Protocol UDP Protocol (1/2) UDP bietet keine Flusskontrolle, keine gesicherte Übertragung und keine verbindungsorientierte Übertragung UDP wird von verschiedenen Protokollen der Anwendungsschicht genutzt, die sich auf einfach Frage/Antwort-Interaktionen beschränken, z.b. 69 TFTP, 53 DNS, 123 NTP, 111 RPC, 389 LADP, UDP nimmt Daten von Anwendung über deren Ports entgegen und gibt sie als UDP-Datagramme gekapselt an IP zur Übertragung weiter Portmultiplexing Für TCP und UDP festgelegte Portnummern können sich unterscheiden, sie müssen übereinstimmen, wenn sie von beiden Protokollen genutzt werden Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, 51

52 n 7.3 Universal Datagram Protocol UDP-Datagramm (1/2) Source Port (16 Bit) Portnummer des Absenders Destination Port (16 Bit) Portnummer des Empfängers Länge (16 Bit) Länge des UDP-Datagrams in Byte, Minimum 8 Byte (Headerlänge) Prüfsumme (16 Bit) über UDP-Header, UDP-Nutzdaten und Pseudoheader mit bei IP verwendetem Algorithmus (Berechnung ist optional) Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 52

53 n 7.3 Universal Datagram Protocol UDP-Datagramm (2/2) UDP Source Port UDP Datagramm Länge UDP Destination Port UDP Prüfsumme UDP Nutzdaten Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 53

54 n 7.3 Universal Datagram Protocol RTP - Real Time Transport Protocol Transportprotokoll für Echtzeitdaten (RFC 1889) Benutzer- Bereich Betriebsystemkern Multimedia-Anwendung MUX RTP Socket-Schnittstelle UDP IP Ethernet keine Flusskontrolle keine Fehlerbehandlung keine Bestätigungen durchgehende Paketnummern Zeitstempel Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 54

56 n 7. Datentransport - Schicht 4 Literatur Ch. Meinel, H. Sack: WWW Kommunikation, Internetworking, Web-Technologien, Springer, A. Tanenbaum: Computer Networks, 4th ed., Pearson, Dr.rer.nat. Harald Sack, Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Universität Potsdam, harald.sack@hpi.uni-potsdam.de 56