Transportprotokolle im TCP/IP- Referenzmodell

Transkript

1 Transportprotokolle im TCP/IP- Referenzmodell HTTP FTP Telnet SMTP DNS SNMP TFTP Internetprotokolle IGMP TCP ICMP UDP RARP IP ARP Schicht 1/2 Ethernet TokenRing Token Bus Wireless Lan TCP (Transmission Control Protocol): Zuverlässig, verbindungsorientiert. UDP (User Datagram Protocol): Datagramm-Prinzip, verbindungslos, ohne Flusskontrolle, reihenfolgerichtige Zustellung eines Paketstroms nicht garantiert. TCP und UDP - Die Transportschicht A Telnet Client IP Network B Telnet Server Transportprotokolle sind als Dienst für die Applikationsschicht verfügbar TCP ist ein verbindungsorientiertes Protokoll TCP bestätigt die Ankunft der Pakete UDP ist ein verbindungsloses und schnelles Protokoll 1

2 Eigenschaften von TCP Verbindungsorientiert Adressierung der Applikation über Portnummern zuverlässig (fehlerfrei, reihenfolgetreu, ohne Duplikate) Fehlerbehandlung, Quittierung Bytestrom, kein Nachrichtenstrom Segmentierung (max. Segmentgröße 64 KByte) stark beschränktes QoS Flußkontrolle (Sliding-Window-Verfahren) "Urgent"-Nachrichten außerhalb der Flusskontrolle TCP als sichere Verbindung verbindungsorientiert Transport Service Access Point (TSAP), Port-Nummer Network Service Access Point (NSAP), IP-Adresse Client baut Verbindung zum Server auf (CONNECT zum TSAP/TCP-Port) Falls Server-TSAP unbekannt, Nutzung eines Prozess-Servers (Initial- Connection-Protocol) Client Transportschicht Applikationsschicht Vermittlungsschicht Sicherungsschicht Bitübertragung Server Server wartet auf mehreren Ports 2

3 TCP als sichere Verbindung Transport Service Access Point (TSAP) Client Applikationsschicht Prozess- Server Server Network Service Access Point (NSAP) Prozess-Server übergibt bestehende Verbindung an den angefragten Server Vermittlungsschicht Transportschicht Sicherungsschicht Bitübertragung Alternative: Namensserver (vergleichbar zur Telefonauskunft) liefert TSAP zurück TCP als sichere Verbindung Erzeugt logische Verbindungen zwischen zwei Sockets: IP-Adresse + 16 Bit Port-Nummer (48 Bit TSAP) Ein Socket kann für mehrere Verbindungen gleichzeitig genutzt werden TCP-Verbindungen sind immer Vollduplex- und Punkt-zu-Punkt-Verbindungen Datenpakete, die zwischen den beiden Kommunikationsstationen ausgetauscht werden, nennt man Segmente Segmente werden ausgetauscht, um o Verbindungsaufbau, o Vereinbarung der Fenstergröße, o Datentransfer, o Verschicken der Bestätigungen, o Verbindungsabbau zu realisieren 3

4 TCP-basierte Applikationen File Transfer Virtual Terminal World Wide Web Routing Information FTP telnet Electronic Mail SMTP http BGP / well-known (TCP) Ports RFC 1700 Portnummer ist 16-Bit-Adresse Ports von 256 bis können von jedem Host selbst festgelegt werden Der TCP-Header 20 Byte Header zzgl. Optionen dann folgen bis zu Datenbytes (40 Bytes für TCPund IP-Header abgezogen) Bit Position HL Source Port Res. Checksum Options Sequence Number 6 Flags Data Destination Port Acknowledgement Number Window Size Urgent Pointer Padding 4

5 Der TCP-Header Source- und Destination-Port: TSAP (Port) von Sender bzw. Empfänger Sequence Number/Acknowledgement Number: Segmente haben eine eigene 32 Bit Sequenz- und Bestätigungsnummer für den Fenstermechanismus zur Flußkontrolle (Sliding Window). Sequenz- und Bestätigungsnummer zählen einzelne Bytes! Die Bestätigungsnummer gibt das nächste erwartete Byte an! Sequenznummern fangen nicht bei 0 an! Piggybacking: Quittungen können in Datenpaketen mitgeschickt werden. HL: Wie bei IP verfügt auch der TCP-Header über eine Angabe seiner Länge. Die Angabe erfolgt in 32-Bit-Worten. Res = Reserve. Für spätere Verwendung freigehaltene Bits. Der TCP-Header 6 Flags: URG: URGENT. Bei Benutzung des Urgent-Pointers, z.b. bei Tastatureingaben (Ctrl-C). ACK: Bestätigungsfeld, für den Fall, daß eine Quittung mitgesendet wird. PSH: PUSH. Direkte Weiterleitung der Daten, kein Warten auf weitere Daten. RST: RESET. Rücksetzen einer Verbindung, z.b. bei einem Hostabsturz oder einer Verbindungsabweisung. ("Im allgemeinen entstehen Probleme, wenn ein Segment mit gesetztem RST-Bit empfangen wird.") SYN: Aufbau einer Verbindung FIN: Abbau einer Verbindung Window Size: Fenstergröße für die Flußkontrolle (skalierbar durch verhandelbaren Faktor, Window Scale) Urgent Pointer: gibt an, ab wo wichtige Daten stehen (Byteversatz von der aktuellen Folgenummer). Options: zusätzliche Funktionen: Window Scale, Selective Repeat statt Go- Back-n im Fehlerfall. 5

6 Der TCP-Pseudo-Header Checksum: für den Prüfsummen-Algorithmus. Dient u.a. zur Verifikation, daß das Paket an das richtige Gerät ausgeliefert worden ist. Die Prüfsumme für das Checksum-Feld wird unter Verwendung eines Pseudo- Headers berechnet. Dazu wird dem Segment durch den Sender ein Pseudo- Header vorangestellt und dann die Prüfsumme über den Pseudo-Header und den normalen Header berechnet (das Checksum-Feld ist hierbei mit 0en belegt). Die Prüfsummenberechnung erfolgt durch das 1er-Kompliment der Summe aller 16- Bit-Wörter des Segments samt Pseudo-Header. Die entstehende Prüfsumme wird eingesetzt. Der Empfänger kann durch Voranstellen des Pseudo-Headers den gleichen Algorithmus ausführen und muß auf 0 kommen. Quelladresse (IP) Zieladresse (IP) Protokoll = 6 Länge des TCP-Segments TCP-Verbindungsmanagement: 1. Verbindungsaufbau Client Server SYN, SEQ=100 SYN, SEQ=200, ACK=101 ACK=201, SEQ=101 Three-Way-Handshake Der Server wartet mittels LISTEN und ACCEPT auf ankommende Verbindungen. Der Client führt unter Angabe von IP- Adresse, Portnummer und maximal akzeptabler Segment-Größe eine CONNECT-Operation aus. CONNECT sendet ein SYN. Ist der Destination Port der CONNECT- Anfrage identisch zu der Port-Nummer, auf der der Server sein LISTEN ausführt, wird die Verbindung akzeptiert, andernfalls mit RST abgelehnt. Der Server schickt seinerseits das SYN zum Client und bestätigt zugleich den Erhalt des ersten SYN-Segments. 6

7 TCP-Verbindungsmanagement: ungeregelter Verbindungsaufbau Client / Server Client / Server SYN, SEQ=100 SYN, SEQ=200 SYN, SEQ=100, ACK=201 Möglicherweise versuchen zwei Rechner zur gleichen Zeit, eine Verbindung zwischen den gleichen Sockets aufzubauen. Verbindungen sind durch ihre Endpunkte gekennzeichnet, es wird nur eine Verbindung aufgebaut. SYN, SEQ=200, ACK=101 TCP-Verbindungsmanagement: 2. Datenübertragung Client Server Vollduplex-Betrieb SEQ=101, ACK=201, Data SEQ=201, ACK=102 SEQ=102, ACK=201, Data SEQ=201, ACK=110 Aufteilung eines Bytestroms in Segmente. Übliche Größen sind 1500, 536 oder 512 Byte; dadurch wird IP- Fragmentierung vermieden. Üblicher Quittungsmechanismus: Alle Segmente bis ACK-1 sind bestätigt. Hat der Sender vor dem Empfang eines ACKs einen Timeout, überträgt er erneut. Üblich bei fehlenden Segmenten: Go- Back-N auf dem Übertragungsfenster. Allerdings setzt sich auch immer mehr Selective Repeat durch. 7

8 TCP-Verbindungsmanagement: 3. Verbindungsabbau Client Server SEQ=110, ACK= 201, DATA=logout SEQ=201, ACK=116, DATA=logout SEQ=116, ACK=207 Es besteht die Möglichkeit, daß sich die Kommunikationspartner vor dem Verbindungsabbau darauf einigen, daß die Verbindung wirklich beendet wird. logout im Datenteil. TCP-Verbindungsmanagement: 4. Verbindungsende Client Server FIN, SEQ=207, ACK=116 FIN, SEQ=116, ACK=208 Abbau als zwei Simplex-Verbindungen Senden eines FIN-Segments Wird das FIN-Segment bestätigt, wird die Richtung 'abgeschaltet'. Die Gegenrichtung bleibt aber noch offen, hier kann noch weiter gesendet werden. Verwendung von Timern zum Schutz vor Paketverlust. SEQ=208, ACK=117 8

9 Die gesamte TCP-Verbindung Normaler Pfad des Clients Normaler Pfad des Servers ungewöhnliche Ereignisse Ereignis/Aktion-Paar Ereignis: Systemaufruf durch Benutzer, Segmentankunft, Timeout Aktion: Senden eines Steuersegments Flußkontrolle - Der Fenstermechanismus Flow Control (Sliding Window) Sender sendet entsprechend der Fenstergröße (Bytes) Fenster wird um n Bytes versetzt, sobald ein ACK für n Bytes eingetroffen ist Ausnahme: Dringende Daten (URGENT-Flag) werden sofort gesendet Initial window Segment 1, 2 und 3 acknowledged Window slides

10 Der Fenstermechanismus - Beispiel Anwendung schreibt 2 KB Sender 2K SEQ = 0 Empfänger Empfänger-Puffer 0 4K Leer 2K ACK=2048 WIN=2048 Anwendung schreibt 2 KB 2K SEQ = 2048 Voll Sender ist blockiert ACK=4096 WIN=0 Anwendung liest 2 KB Sender kann bis zu 2 KB übertragen ACK=4096 WIN=2048 1K SEQ = K 1K 2K "Silly Window"-Syndrom Empfängerpuffer ist voll Anwendung liest 1 Byte Header Platz für noch 1 Byte Segment zur Fensteraktualisierung übertragen Header Neues Byte kommt an Empfängerpuffer ist voll 1 Byte Lösungsansatz von Clark: Der Empfänger muß mit der nächsten Fensteraktualisierung warten, bis der Empfängerpuffer wieder halbwegs leer ist 10

11 Flußkontrolle - Überlast durch Netzengpässe Annahme: Paketverlust liegt selten an Übertragungsfehlern, eher an Überlast-Situationen. Kapazität des Empfängers: Empfangsfenster Kapazität des Netzes: Überlastungsfenster Nötig: Congestion Control Überlastungsalgorithmus im Internet Jeder Sender pflegt zwei Fenster zur Anzahl der zu sendenden Bytes: Empfänger-Fenster: Maximal vom Empfänger gewährte Anzahl Überlastfenster (Congestion Window): Maximal vom Übertragungsnetz gewährte Anzahl Minimum aus beiden Fenstern ist die maximal zu sendende Anzahl von Bytes Bei Aufbau der Verbindung initialisiert der Sender das Überlastfenster auf die Größe des maximalen Segments Maximales Segment wird gesendet Falls Bestätigung vor Ablauf eines Timers eintritt, erfolgt Verdopplung des Überlastfensters (Slow Start-Algorithmus), ansonsten ein Rücksetzen auf den Startwert Vergrößerung stoppt bei Erreichen des Empfängerfensters Verfeinerung durch Einführung eines Schwellenwerts (anfangs 64 Kbyte): - Steigerung erfolgt nur noch linear - Bei einem Timeout wird der Schwellenwert auf die Hälfte des vorher erreichten Werts zurückgesetzt 11

12 Überlastungsalgorithmus im Internet Timer-Management bei TCP TCP benutzt mehrere Timer: Retransmission Timer (zur Wiederholung einer Übertragung) Aber: wie soll man den Timer wählen? Wahrscheinlichkeitsdichte für die Zeit, bis eine Bestätigung eintrifft T T 1 T 2 Wahrscheinlichkeit Wahrscheinlichkeit Problem auf der Transportschicht: T1 ist zu klein: zu viele Neuübertragungen Roundtrip-Time [ms] Sicherungsschicht Roundtrip-Time [ms] Transportschicht T2 ist zu groß: ineffizient bei tatsächlichem Paketverlust 12

13 Retransmission-Timer Einzig sinnvolle Lösung: dynamischer Algorithmus, der den Timer durch laufende Messungen der Netzleistung an aktuelle Gegebenheiten anpassen kann. Algorithmus von Jacobson (1988): TCP verwaltet für jede Verbindung eine Variable RTT (Round-Trip-Time) RTT ist momentan beste Schätzung der Rundreisezeit zum Zielrechner Bei Senden eines Segments wird ein Timer gestartet, der mißt, wie lange die Bestätigung braucht und löst bei Bedarf eine Neuübertragung aus. Kommt die Bestätigung vor Ablauf des Timers an (nach einer Zeiteinheit t), wird RTT aktualisiert: RTT = α RTT + (1 - α) t α ist ein Glättungsfaktor, typischerweise Die Wahl des Timeouts basiert auf RTT: Timeout = βrtt Zu Beginn war β immer 2, aber dies war zu unflexibel Retransmission-Timer Verbesserung (Jacobsson): wähle β proportional zur Standardabweichung der Ankunftszeit von Bestätigungen Berechnung von β: β = α β + (1 - α) RTT - t dabei muß α nicht unbedingt genauso groß sein wie bei der RTT-Berechnung Standard-Timeout-Intervall: Timeout = RTT + 4 β Faktor 4 wurde durch einerseits durch Ausprobieren ermittelt, andererseits soll der Timeout möglichst schnell und einfach berechnet werden können. Alternativer, sehr einfacher Vorschlag, der in den meisten TCP-Implementeriungen angewendet wird: Verdopple den Timeout so lange jedes Mal, bis die Segmente das erste Mal durchkommen. 13

14 Weitere Timer Persistence Timer Verhindert einen Deadlock bei einem Verlust der Puffer-Freigabe für den Sender Bei Ablauf des Timers überträgt der Sender probeweise ein Segment. Die Antwort auf diese Übertragung liefert dem Sender die verwendbare Fenstergröße. Ist diese noch Null, wird der Timer wieder gestartet. Keepalive Timer Ist eine Verbindung längere Zeit inaktiv, wird nach Ablauf des Timers geprüft, ob die andere Seite noch da ist. Kommt keine Antwort, wird die Verbindung beendet. Umstrittene Funktion, nicht oft implementiert.? Timer Während der Beendigung einer Verbindung läuft der Timer für die doppelte Paketlebensdauer, um sicherzustellen, daß keine weiteren Pakete mehr eintreffen. Vergleich von TCP mit dem OSI- Transportprotokoll TCP OSI-TP(Klasse 4) Anzahl PDUs 1 10 Länge des Headers 20 Bytes 5 Bytes QoS-Parameter kaum ausbaufähig Datenstrom Einzeln numerierte Bytes Nachrichten wichtige Nachrichten / Daten URGENT-FLAG (+Zeiger) expedited data Quittierung Piggybacking ACK-PDU Flusskontrolle Verbindungsabbau Sliding Window (Window Size dynamisch verändert) schonend (kein Datenverlust) auch: Kreditverfahren abrupt (Gefahr eines Datenverlustes) höhere Schichten Anwendungsprotokoll Schichten

15 Das User Data Protocol (UDP) Prinzip: Keep it simple! 8 Byte Header verbindungslos keine Bestätigung der Pakete auf der UDP-Schicht, fehlerhafte Pakete werden schlicht und einfach verworfen. Weiterhin sind Duplikation, Reihenfolgevertauschung, Paketverlust möglich. die Checksumme bietet die einzige Möglichkeit, die Pakete auf Übertragungsfehler zu testen geringe Zuverlässigkeit, aber schneller Austausch von Informationen Möglich: ACKs und Neuübertragungen werden von der Anwendung selbst übernommen. UDP-Header Bit Positon Source Port Message Length Destination Port Checksum Data Adressierung der Applikationen über Portnummern Message-Length gibt die Gesamtlänge (Header + Daten) in 32 Bit Worten an Checksum (optional!). Ablauf wie bei TCP Daten werden bei Bedarf auf eine gerade Bytezahl aufgefüllt (da Message Length in 32 Bit Worten angegeben wird) 15

16 UDP-basierte Applikationen Routing-Information Automatic Address Assignment Management Name Service File Transfer DNS BOOTP TFTP SNMP RIP / / well-known (UDP) Ports 16