Überblick · accept() - Wird bei TCP-Verbindungen verwendet und gibt die ... - T-SAP (Transport Service Access Point) Eine Transport-Instanz unterstützt in der Regel mehrere T-SAPs

Mandl/Bakomenko/Weiß Seite 1 Datenkommunikation

Überblick

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

Wintersemester 2014/2015

Prof. Dr. Peter Mandl

Mandl/Bakomenko/Weiß Datenkommunikation

Überblick

1. Transportzugriff

2. Transportorientierte Dienste

- Überblick

- Verbindungsmanagement

- Zuverlässiger Datentransfer

- Quittierung

- Übertragungswiederholung

- Flusskontrolle

- Staukontrolle

Seite 2


Wiederholung: ISO/OSI-Referenzmodell

Bitübertragung Bitübertragung

Verarbeitungsprotokoll

Sicherung

Vermittlung

Transport

Sitzung

Darstellung

Verarbeitung

Sicherung

Vermittlung

Transport

Sitzung

Darstellung

Verarbeitung

Darstellungsprotokoll

Sitzungsprotokoll

Transportprotokoll

Bitübertragung

Sicherung

Vermittlung

Bitübertragung

Sicherung

Vermittlung

7

6

5

4

3

2

1

Sender Empfänger

Seite 3


Wiederholung: TCP/IP-Referenzmodell

Sender Empfänger

Verarbeitungsschicht

leer

leer

Transportschicht

Internet

Hostanbindung ans

Netz

Verarbeitungsschicht

leer

leer

Transportschicht

Internet

Hostanbindung ans

Netz

Internet

Hostanbindung ans

Netz

Host Router Host

IP, ARP

nicht

festgelegt

IP, ARP

Logische Kommunikation

Verarbeitungsprotokoll:

Telnet, ftp, SNMP, HTTP

Transportprotokoll:

TCP und UDP

nicht

festgelegt

Seite 4


Transportzugriffsschnittstelle

Transportzugriffsschnittstelle ermöglicht den

Anwendungsprozessen eine Ende-zu-Ende-

Kommunikation

Prozess 1 Prozess 2

Transportzugriffs-schnittstelle: z.B. Sockets, TLI, XTI

Transportsystem

Rechnergrenze

Seite 5


Sockets sind eine konkrete Implementierung einer Transportzugriffsschnittstelle

Sockets: Systemeinbettung

TCP/IP-Implementierung

Client Server

Socket Interface

Anwendungsprotokoll

Betriebssystem

Seite 6


Die Socket-Schnittstelle ist eine API, mit der man Kommunikationsanwendungen entwickeln kann

Die Socket-Schnittstelle ist eine Transportzugriffs-schnittstelle

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

Überblick über Sockets (1)

Seite 7


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

Überblick über Sockets (2)

Seite 8


Sockets: Protokollmechanismen

Die TCP-Socket-Schnittstelle ist stream-orientiert: Es wird ein Datenstrom eingerichtet

Die UDP-Socket-Schnittstelle ist nachrichten-orientiert

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)

Seite 9


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 Kommunikations-anwendungen sind heute in C programmiert

Im Folgenden sind einige Ausschnitte aus einfachen Beispielanwendungen skizziert


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


Sockets: Verbindungsorientiert über TCP

Server

socket()

bind()

listen()

accept()

recv()

send()

socket()

connect()

send()

recv()

Client

Blockieren, bis Connect Request kommt

Einrichten der Verbindung

Verbindungsorientierte Kommunikation


Server

socket()

bind()

recvfrom()

sendto()

socket()

bind()

sendto()

recvfrom()

Client

Blockieren, bis Daten vom Client empfangen werden

Daten (Request)

Sockets: Verbindungslos über UDP

Verbindungslose Kommunikation


Überblick

1. Transportzugriff


- Überblick



- Quittierung


- Flusskontrolle

- Staukontrolle

Seite 14


Dienste der Transportschicht

T-SAP T-SAP

(meist) unvollkommener N-Dienst

T-Instanz T-Instanz

N-SDUs N-SDUs

T-SDUs T-SDUs

T-PDUs

Logischer Ende-zu-Ende-Transport

verbindungsorientierte Transportdienste

verbindungslose Transportdienste


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)

Seite 16


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?


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


Protokollfunktionen in Transportprotokollen

Verbindungsmanagement und Adressierung

Zuverlässiger Datentransfer

Flusskontrolle

Staukontrolle

Segmentierung


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)


Verbindungsmanagement und Adressierung T-SAP

Anwendungs-Prozess 1

T-SAP

N-SAP

Bitübertra-

gungsschicht

Sicherungs-

schicht

Vermittlungs-

schicht

Transport-

schicht

Anwendungs-Prozess 2

Bitübertra-

gungsschicht

Sicherungs-

schicht

Vermittlungs-

schicht

Transport-

schicht

Netzverbindung

beginnt hier

Transportverbindung

beginnt hier

T-SAP = Transport Service Access Point

N-SAP = Network Service Access Point

Host 1 Host 2


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

Verbindungsaufbau


Verbindungsaufbau, Drei-Wege-Handshake

Normaler

Protokollverlauf

Instanz A und B suchen eigene Folgenummern x und y (seq)

aus

T-Instanz A T-Instanz B

Connect.Request (seq = x)

Lokale Ermittlung der

Folgenummer y

Seq = Folgenummer

T-Instanz = Transportinstanz

Connect.Response (seq = y, ACK = x)

Data.Request (seq = x, ACK = y)

Lokale Ermittlung der

Folgenummer x

...

Daten senden und

Bestätigung von y

(Huckepack)

Nach Tanenbaum, A.: et al.: Computer Networks,

5. Auflage, Pearson Studium, 2011



Altes CR-Duplikat

taucht auf


Connect.Request (seq = x)

Instanz B merkt nichts!

Seq = Folgenummer


Connect.Response (seq = y, ACK = x)

Connect.Reject (seq = x, ACK = y)

Altes Duplikat!

Ende!

Instanz A erkennt das

Duplikat und verweigert

Verbindungsaufbau

Nach Tanenbaum, A.: et al.: Computer Networks, 5. Auflage, Pearson Studium, 2011



Duplikat von Connect-Request und Duplikat von ACK tauchen plötzlich auf


Instanz B merkt nichts!

Seq = Folgenummer


Altes Duplikat!

Ende!

Instanz A erkennt das

Duplikat und verweigert

VerbindungsaufbauAltes ACK-Duplikat!

Bestätigung falsch!

Nach Tanenbaum, A.: et al.: Computer Networks,

5. Auflage, Pearson Studium, 2011


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


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

BB

Blaue

Armee 1

Weiße

Armee

Blaue

Armee 2

W



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


Timerüberwachung beim Verbindungsabbau Szenario „Normaler Ablauf“


Timer würde hier

ablaufen

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überwachung beim Verbindungsabbau Szenario „Timer läuft ab“


Timer würde hier

ablaufen

Disconnect-Request


Disconnect-Request


starten

Verbindung abbauen, ACK

senden

Timeout,

Verbindung trennen



Timerüberwachung beim Verbindungsabbau Szenario „Disconnect-Response geht verloren“


Discon.Request

Discon.Response

Discon.Request

Disconnect-Request


Disconnect-Request


starten

Timeout, erneut

senden

Geht im Netz verloren!

Discon.Response

Discon.Response (ACK)

Verbindung trennen

Verbindung trennen



Timerüberwachung beim Verbindungsabbau Szenario „Zwei Disconnect-PDUs gehen verloren“


Discon.Request

Discon.Response

Discon.Request

Disconnect-Request


Disconnect-Request


startenGeht im Netz verloren!

Timeout, Verbindung

trennenTimeout, Verbindung

trennen

Geht im Netz verloren!

Timeout, erneut

senden

...



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


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 erhalten, bestätigen


Data.Request (Data)

Data.Response (ACK)

Daten-PDU senden

Timer würde hier

ablaufen Data.Response (ACK)

Data.Request (Data)

Erst hier kann

wieder gesendet

werden

Warten auf ACK!

...

Daten erhalten, bestätigen



Positiv kumulatives Quittierungsverfahren Eine Quittung für mehrere Nachrichten

Reduzierung der Netzlast

Nachteil: Verspätete Information an den Sender über Datenverlust

Daten erhalten


Data.Request (Data1)

Daten-PDU 1 senden

...

Data.Response (ACK 1+2)


Daten 1 + 2 bestätigen

Daten erhalten

Daten-PDU 2 senden,

Kein Warten auf ACK 1



Negativ selektives Quittierungsverfahren Weitere Reduzierung der Netzlast

Problem: Verlust von Quittungen und dessen Behandlung

Daten erhalten


Data.Request (Data1)Daten-PDU 1 senden

...

Data.Response (NAK 2)


Nachricht 3 erhalten,

Nachricht 2 wird

angefordert

Timerüberwachung

notwendig!

Kommt nicht an!


Daten-PDU 2 senden

Daten-PDU 3 senden

Daten-PDU 2 erneut

senden


Zuverlässiger Datentransfer Übertragungswiederholung

Generell:

Sender muss Nachrichten über einen gewissen Zeitraum zur Übertragungswiederholung bereithalten

Man nennt diese Art von Protokollen auch ARQ-Protokolle

• Automatic Repeat reQuest, = Automatische Wiederholungsanfrage

selektiv

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


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?


Data.Request (Data1)Nachrichten senden

Nachricht 2 fehlt!

Ab Data 2 alles

noch mal senden


Data.Request (Data3)Kommt nicht an!

NAK (Data2)



Hier in Kombination mit negativ-selektiver Quittung (NAK)


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


Flusskontrolle

nextseqnumbase

Fenstergröße N

bereits

bestätigtgesendet, aber noch

nicht bestätigt

verwendbar, noch

nicht gesendetnicht verwendbar

Quelle: Kurose

Sliding-Window-Protokoll: Vier Intervalle

Bestätigung (ACK) führt zum Weiterrücken des Zeigers base und des Fensters


Staukontrolle (Überlastkontrolle, Congestion Control)

Nicht mit Flusskontrolle verwechseln

Durch Staukontrolle sollen Verstopfungen bzw. Überlastungen im Netz vermieden werden

Staukontrolle in der Transportschicht durch Ende-zu-Ende-Steuerung zwischen Endsystemen

Staukontrolle ist ein Mechanismus mit netzglobalen Auswirkungen

Beispiel später: Slow-Start-Verfahren bei TCP


Rückblick

1. Transportzugriff


- Überblick



- Quittierung


- Flusskontrolle

- Staukontrolle

Documents

Überblick · accept() - Wird bei TCP-Verbindungen verwendet und gibt die ... - T-SAP (Transport Service Access Point) Eine Transport-Instanz unterstützt in der Regel mehrere T-SAPs