Ü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. Transportzugriff 2. Transportorientierte Dienste - Überblick - Verbindungsmanagement - Zuverlässiger Datentransfer - Quittierung - Übertragungswiederholung - Flusskontrolle - Staukontrolle Mandl/Bakomenko/Weiß Seite 2

3 Wiederholung: ISO/OSI-Referenzmodell Sender Empfänger 7 Verarbeitung Verarbeitungsprotokoll Verarbeitung 6 Darstellung Darstellungsprotokoll Darstellung 5 Sitzung Sitzungsprotokoll Sitzung 4 Transport Transportprotokoll Transport 3 Vermittlung Vermittlung Vermittlung Vermittlung 2 Sicherung Sicherung Sicherung Sicherung 1 Bitübertragung Bitübertragung Bitübertragung Bitübertragung Mandl/Bakomenko/Weiß Seite 3

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

5 Transportzugriffsschnittstelle Transportzugriffsschnittstelle ermöglicht den Anwendungsprozessen eine Ende-zu-Ende- Kommunikation Rechnergrenze Prozess 1 Prozess 2 Transportsystem Transportzugriffsschnittstelle: z.b. Sockets, TLI, XTI Mandl/Bakomenko/Weiß Seite 5

6 Sockets: Systemeinbettung Sockets sind eine konkrete Implementierung einer Transportzugriffsschnittstelle Anwendungsprotokoll Client Server Socket Interface TCP/IP-Implementierung Betriebssystem Mandl/Bakomenko/Weiß Seite 6

7 Überblick über Sockets (1) Die Socket-Schnittstelle ist eine API, mit der man Kommunikationsanwendungen entwickeln kann Die Socket-Schnittstelle ist eine Transportzugriffsschnittstelle Sockets wurden in der Universität von Berkeley entwickelt (BSD-Version von UNIX), erste Version 4.1cBSD-System für die VAX aus dem Jahre 1982 Die Originalversion der Socket-Schnittstelle stammt von Mitarbeitern der Firma BBN (ARPA-Projekt, 1981) Sockets sind heute der De-facto-Standard Siehe auch POSIX Standard Mandl/Bakomenko/Weiß Seite 7

8 Überblick über Sockets (2) Die Socket API unterstützt vor allem Client-Server- Anwendungen, was aus dem Programmiermodell hervorgeht: - Aktiver Partner = Client - Passiver Partner = Server Sockets sind Kommunikationsendpunkte innerhalb der Applikationen, die in der Initialisierungsphase miteinander verbunden werden Dabei spielt es keine Rolle, auf welchen Rechnern die miteinander kommunizierenden Prozesse laufen Mandl/Bakomenko/Weiß Seite 8

9 Sockets: Protokollmechanismen Die TCP-Socket-Schnittstelle ist stream-orientiert: Es wird ein Datenstrom eingerichtet Die UDP-Socket-Schnittstelle ist nachrichtenorientiert Es ist verbindungsorientierte (TCP-basierte) und verbindungslose (UDP-basierte) Kommunikation möglich Die Adressierung der Kommunikationspartner erfolgt über die Kommunikationsendpunkte über das Tupel (IP-Adresse, Portnummer) Mandl/Bakomenko/Weiß Seite 9

10 Socket-Programmierung in C C-Socket-Schnittstelle wird in nahezu jedem Betriebssystem in einer Funktionsbibliothek bereitgestellt Mit der Funktionsbibliothek lässt sich relativ aufwändig programmieren Die meisten Socket-basierten Kommunikationsanwendungen sind heute in C programmiert Im Folgenden sind einige Ausschnitte aus einfachen Beispielanwendungen skizziert Mandl/Bakomenko/Weiß Seite 10

11 Sockets: Die wichtigsten C-Funktionen socket() - Initialisiert einen Socket bind() - Ordnet einem Socket eine lokale Adresse zu connect() - Baut eine Verbindung vom Client zum Server auf listen() - Setzt den Socket in einen passiven, d.h. auf ankommenden Verbindungswünsche wartenden Zustand accept() - Wird bei TCP-Verbindungen verwendet und gibt die nächste ankommende, aufgebaute Verbindung aus der Warteschlange zurück close() - Schließt eine Verbindung recv() - Liest Daten aus dem spezifizierten Socket und gibt die Anzahl der tatsächlich gelesenen Byte zurück send() - Sendet Daten über den spezifizierten Socket und gibt die Anzahl der tatsächlich gesendeten Byte zurück Mandl/Bakomenko/Weiß Seite 11

12 Sockets: Verbindungsorientiert über TCP Server socket() bind() Verbindungsorientierte Kommunikation listen() accept() Blockieren, bis Connect Request kommt Einrichten der Verbindung recv() Client socket() connect() send() send() recv() Mandl/Bakomenko/Weiß Seite 12

13 Sockets: Verbindungslos über UDP Server socket() bind() recvfrom() Blockieren, bis Daten vom Client empfangen werden sendto() Verbindungslose Kommunikation Daten (Request) Client socket() bind() sendto() recvfrom() Mandl/Bakomenko/Weiß Seite 13

14 Überblick 1. Transportzugriff 2. Transportorientierte Dienste - Überblick - Verbindungsmanagement - Zuverlässiger Datentransfer - Quittierung - Übertragungswiederholung - Flusskontrolle - Staukontrolle Mandl/Bakomenko/Weiß Seite 14

15 Dienste der Transportschicht Logischer Ende-zu-Ende-Transport verbindungsorientierte Transportdienste verbindungslose Transportdienste T-SDUs T-SDUs T-SAP T-SAP T-Instanz T-PDUs T-Instanz N-SDUs N-SDUs (meist) unvollkommener N-Dienst Mandl/Bakomenko/Weiß Seite 15

16 Pufferung von Nachrichten Puffer für ankommende Nachrichten werden in den Protokollinstanzen (meist im Betriebssystemkern) verwaltet Die Instanzen kopieren die Nachrichten in den Adressraum der empfangenden Anwendungsprozesse Pufferspeicher müssen verwaltet werden ( Overhead) Pufferspeicher benötigen Adressraum (Speicher) Pufferspeicher sind begrenzt ( evtl. Verwerfen von Nachrichten, wenn sie voll sind) Mandl/Bakomenko/Weiß Seite 16

17 Verbindungsorientierte Transportdienste Eine Verbindung wird etabliert Gemeinsamer Kontext wird aufgebaut Geprägt von traditionellen Kommunikationsdiensten wie Telefonieren Hohe Zuverlässigkeit Fehlerfreie und reihenfolgerichtige Auslieferung der Daten beim Empfänger Verbindungsorientierte Protokolle sind komplexer - Warum? Wann braucht man Verbindungen? Mandl/Bakomenko/Weiß Seite 17

18 Verbindungslose Transportdienste Verlust von Datenpaketen wird nicht bemerkt Verfälschung des Nutzdatenteils ist nicht unbedingt nachvollziehbar Reihenfolgezerstörung ist möglich Kein Zusammenhang bei aufeinanderfolgenden Dienstaufrufen T-PDUs enthalten die Adressinformation von Sender und Empfänger Mandl/Bakomenko/Weiß Seite 18

19 Protokollfunktionen in Transportprotokollen Verbindungsmanagement und Adressierung Zuverlässiger Datentransfer Flusskontrolle Staukontrolle Segmentierung Mandl/Bakomenko/Weiß Seite 19

20 Verbindungsmanagement und Adressierung Kommunizierende Anwendungsprozesse müssen sich kennen - Schicht 4: Transportadresse - T-SAP (Transport Service Access Point) Eine Transport-Instanz unterstützt in der Regel mehrere T-SAPs Transportadressen sind oft kryptisch, daher symbolische Adressen notwendig - Directory Service (Naming Service) Mandl/Bakomenko/Weiß Seite 20

21 Verbindungsmanagement und Adressierung T-SAP Host 1 Host 2 Anwendungs- Prozess 1 T-SAP N-SAP Transportschicht Anwendungs- Prozess 2 Vermittlungsschicht Sicherungsschicht Bitübertragungsschicht Transportverbindung beginnt hier Netzverbindung beginnt hier Vermittlungsschicht Transportschicht Sicherungsschicht Bitübertragungsschicht T-SAP = Transport Service Access Point N-SAP = Network Service Access Point Mandl/Bakomenko/Weiß Seite 21

22 Verbindungsaufbau Einrichten von Connection End Points (CEP) - Kontextaufbau auf beiden Seiten Zwei-Wege-Handshake-Protokolle Drei-Wege-Handshake-Protokolle Vorsicht Duplikate! - Diverse Fehlerszenarien möglich - Mechanismus der Folgenummern kombiniert mit einer maximalen Paketlebensdauer - Folgennummern sind einfache Zähler Mandl/Bakomenko/Weiß Seite 22

23 Verbindungsaufbau, Drei-Wege-Handshake Normaler Protokollverlauf Instanz A und B suchen eigene Folgenummern x und y (seq) aus T-Instanz A T-Instanz B Lokale Ermittlung der Folgenummer x Connect.Request (seq = x) Daten senden und Bestätigung von y (Huckepack) Connect.Response (seq = y, ACK = x) Data.Request (seq = x, ACK = y) Lokale Ermittlung der Folgenummer y... Seq = Folgenummer T-Instanz = Transportinstanz Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 23

24 Verbindungsaufbau, Drei-Wege-Handshake Altes CR-Duplikat taucht auf T-Instanz A T-Instanz B Altes Duplikat! Connect.Request (seq = x) Instanz B merkt nichts! Instanz A erkennt das Duplikat und verweigert Verbindungsaufbau Connect.Response (seq = y, ACK = x) Connect.Reject (seq = x, ACK = y) Ende! Seq = Folgenummer T-Instanz = Transportinstanz Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 24

25 Verbindungsaufbau, Drei-Wege-Handshake Duplikat von Connect-Request und Duplikat von ACK tauchen plötzlich auf T-Instanz A T-Instanz B Altes Duplikat! Instanz B merkt nichts! Instanz A erkennt das Duplikat und verweigert Verbindungsaufbau Altes ACK-Duplikat! Bestätigung falsch! Ende! Seq = Folgenummer T-Instanz = Transportinstanz Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 25

26 Verbindungsabbau Anforderung: - Beim Verbindungsabbau dürfen keine Nachrichten verloren gehen Datenverlust kann vorkommen, wenn - eine Seite einen Verbindungsabbau initiiert, - die andere aber vor Erhalt der Disconnect-Request-PDU noch eine Nachricht sendet - Diese Nachricht ist verloren (Datenverlust) Anspruchsvolles Verbindungsabbau-Protokoll notwendig: - Dreiwege-Handshake-Mechanismus wird auch hier genutzt - Beide Seiten bauen ihre Senderichtung ab Mandl/Bakomenko/Weiß Seite 26

27 Verbindungsabbau und das Zwei-Armeen-Problem Die Armee der Weißröcke lagert in einem Tal Auf beiden Anhöhen lagert ein Teil der Armee der Blauröcke Die Blauröcke können nur gemeinsam gewinnen und müssen ihren Angriff synchronisieren Unzuverlässiger Kommunikationskanal: Boten, die zu Fuß durch das Tal rennen müssen B Blaue Armee 1 B Blaue Armee 2 W Weiße Armee Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 27

28 Verbindungsabbau, Timerüberwachung Kein Protokoll ist absolut zuverlässig Es wird immer eine Seite geben, die unsicher ist, ob die letzte Nachricht angekommen ist Übertragen auf den Verbindungsabbau: - Beim Dreiwege-Handshake kann immer ein Disconnect- Request oder eine Bestätigung verloren gehen Praktische Lösung: Timerüberwachung mit begrenzter Anzahl an Nachrichtenwiederholungen Nicht unfehlbar, aber doch ganz zufriedenstellend Mandl/Bakomenko/Weiß Seite 28

29 Timerüberwachung beim Verbindungsabbau Szenario Normaler Ablauf T-Instanz A T-Instanz B Disconnect-Request senden und Timer starten Disconnect-Request bestätigen und Timer starten Verbindung abbauen, ACK senden Verbindung abbauen Timer würde hier ablaufen Timer würde hier ablaufen Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 29

30 Timerüberwachung beim Verbindungsabbau Szenario Timer läuft ab T-Instanz A T-Instanz B Disconnect-Request senden und Timer starten Disconnect-Request bestätigen und Timer starten Verbindung abbauen, ACK senden Timer würde hier ablaufen Timeout, Verbindung trennen Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 30

31 Timerüberwachung beim Verbindungsabbau Szenario Disconnect-Response geht verloren Disconnect-Request senden und Timer starten T-Instanz A Discon.Request T-Instanz B Geht im Netz verloren! Discon.Response Disconnect-Request bestätigen und Timer starten Timeout, erneut senden Discon.Request Discon.Response Verbindung trennen Discon.Response (ACK) Verbindung trennen Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 31

32 Timerüberwachung beim Verbindungsabbau Szenario Zwei Disconnect-PDUs gehen verloren Disconnect-Request senden und Timer starten T-Instanz A Discon.Request T-Instanz B Timeout, erneut senden Geht im Netz verloren! Discon.Request Discon.Response Geht im Netz verloren! Disconnect-Request bestätigen und Timer starten... Timeout, Verbindung trennen Timeout, Verbindung trennen Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011 Mandl/Bakomenko/Weiß Seite 32

33 Zuverlässiger Datentransfer Was heißt hier zuverlässige Datenübertragung? - Garantierte Ausführung? Nein! - Transaktionssicherheit Nein! - Sicherstellen der Übertragung durch Quittierung und Übertragungswiederholung Ja! Quittierungsvarianten - Positiv selektiv - Positiv kumulativ - Negativ selektiv - Kombination der Verfahren möglich Varianten der Übertragungswiederholung - Selektiv - Go-back-N Mandl/Bakomenko/Weiß Seite 33

34 Zuverlässiger Datentransfer Quittierungsvarianten Positiv selektives Quittierungsverfahren Eine Quittung pro gesendeter Nachricht Hoher Zusatzverkehr (viele ACK-PDUs) Im Beispiel unten in Kombination mit Stop-and-Wait Daten-PDU senden Warten auf ACK!... Erst hier kann wieder gesendet werden T-Instanz A Data.Request (Data) Data.Response (ACK) Data.Request (Data) T-Instanz B Daten erhalten, bestätigen Daten erhalten, bestätigen Timer würde hier ablaufen Data.Response (ACK) Mandl/Bakomenko/Weiß Seite 34

35 Zuverlässiger Datentransfer Quittierungsvarianten Positiv kumulatives Quittierungsverfahren Eine Quittung für mehrere Nachrichten Reduzierung der Netzlast Nachteil: Verspätete Information an den Sender über Datenverlust Daten-PDU 1 senden T-Instanz A Data.Request (Data1) T-Instanz B Daten erhalten Daten-PDU 2 senden, Kein Warten auf ACK 1 Data.Request (Data2) Daten erhalten Data.Response (ACK 1+2) Daten bestätigen... Mandl/Bakomenko/Weiß Seite 35

36 Zuverlässiger Datentransfer Quittierungsvarianten Negativ selektives Quittierungsverfahren Weitere Reduzierung der Netzlast Problem: Verlust von Quittungen und dessen Behandlung Daten-PDU 1 senden Daten-PDU 2 senden T-Instanz A Data.Request (Data1) Data.Request (Data2) T-Instanz B Daten erhalten Daten-PDU 3 senden Data.Request (Data3) Kommt nicht an! Daten-PDU 2 erneut senden... Data.Response (NAK 2) Nachricht 3 erhalten, Nachricht 2 wird angefordert Timerüberwachung notwendig! Mandl/Bakomenko/Weiß Seite 36

37 Zuverlässiger Datentransfer Übertragungswiederholung Generell: selektiv Sender muss Nachrichten über einen gewissen Zeitraum zur Übertragungswiederholung bereithalten Man nennt diese Art von Protokollen auch ARQ- Protokolle Automatic Repeat request, = Automatische Wiederholungsanfrage Nur die negativ quittierten Nachrichten werden wiederholt Empfänger puffert die nachfolgenden Nachrichten, bis die fehlende Nachricht da ist Reguläre Übertragung kann während der Wiederholung fortgesetzt werden Nachteil: Große Pufferkapazität beim Empfänger Mandl/Bakomenko/Weiß Seite 37

38 Zuverlässiger Datentransfer Übertragungswiederholung Go-Back-N Übertragungswiederholung der fehlerhaften Nachricht sowie aller nachfolgenden Die reguläre Übertragung wird unterbrochen Vorteil: Geringe Speicherkapazität beim Empfänger. Warum? T-Instanz A T-Instanz B Nachrichten senden Data.Request (Data1) Data.Request (Data2) Data.Request (Data3) Kommt nicht an! NAK (Data2) Nachricht 2 fehlt! Ab Data 2 alles noch mal senden Data.Request (Data2) Data.Request (Data3) Hier in Kombination mit negativ-selektiver Quittung (NAK) Mandl/Bakomenko/Weiß Seite 38

39 Flusskontrolle Steuerung des Datenflusses Vermeidet Überlastung des Empfängers Traditionelle Verfahren sind: - Stop-and-Go (Stop-and-Wait) Einfachstes Verfahren Kopplung von Fluss- und Fehlerkontrolle Nächste Nachricht wird erst nach der Quittierung gesendet - Fensterbasierte Flusskontrolle Empfänger vergibt sog. Sendekredit, also eine max. Menge an Nachrichten oder Bytes, die unquittiert an ihn gesendet werden dürfen Empfänger kann den Sendekredit durch positive Quittungen erhöhen Vorteil: Kontinuierlicher Datenfluss und höherer Durchsatz als bei Stop-and-Go möglich Mandl/Bakomenko/Weiß Seite 39

40 Flusskontrolle Sliding-Window-Protokoll: Vier Intervalle Bestätigung (ACK) führt zum Weiterrücken des Zeigers base und des Fensters base nextseqnum bereits bestätigt gesendet, aber noch nicht bestätigt verwendbar, noch nicht gesendet nicht verwendbar Quelle: Kurose Fenstergröße N Mandl/Bakomenko/Weiß Seite 40

41 Staukontrolle (Überlastkontrolle, Congestion Control) Nicht mit Flusskontrolle verwechseln Durch Staukontrolle sollen Verstopfungen bzw. Überlastungen im Netz vermieden werden Staukontrolle in der Transportschicht durch Endezu-Ende-Steuerung zwischen Endsystemen Staukontrolle ist ein Mechanismus mit netzglobalen Auswirkungen Beispiel später: Slow-Start-Verfahren bei TCP Mandl/Bakomenko/Weiß Seite 41

42 Rückblick 1. Transportzugriff 2. Transportorientierte Dienste - Überblick - Verbindungsmanagement - Zuverlässiger Datentransfer - Quittierung - Übertragungswiederholung - Flusskontrolle - Staukontrolle Mandl/Bakomenko/Weiß Seite 42