Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 10te Vorlesung Lehrstuhl für...

Lehrstuhl für Kommunikationssysteme - Systeme II 1

Systeme II – 10te Vorlesung

Lehrstuhl für KommunikationssystemeInstitut für Informatik / Technische Fakultät

Universität Freiburg2009


Letzte Vorlesung

‣Email eine der ältesten Anwendungen des Internets überhaupt, erste Spezifikation (RFC) Anfang der 80er Jahre•Email-Systeme umfassen mehrere Komponenten, die für verschiedene (Teil-)Aufgaben zuständig sind


Letzte Vorlesung

‣Email selbst folgt einem bestimmten, festgelegten Aufbau, im Laufe der Zeit durch weitere RFCs erweitert, wie beispiels-weise durch MIME (siehe Header Content Types)‣Verschiedene Protokolle, die alle Message-orientiert mit Status-Codes arbeiten•SMTP zum Verschicken von Mail

•POP3 und das komfortablere IMAP für das Abholen von Mail vom Server (in den eigenen Mail-Client)


Ende der siebten VorlesungTransportschicht

Bewegen uns einen Schritt “nach unten” im TCP/IP-SchichtenmodellDie Schicht zwischen IP und den AnwendungenBietet Applikationen wichtige Dienste an


Dienste der Transportschicht

‣Verbindungslos oder Verbindungsorientert•Beachte: Sitzungsschicht im ISO/OSI-Protokoll

‣Verlässlich oder Unverlässlich

•Best effort oder Quality of Service

•Fehlerkontrolle

‣Mit oder ohne Congestion Control

‣Möglichkeit verschiedener Punkt-zu-Punktverbindungen

•Stichwort: Demultiplexen

‣Interaktionsmodelle

•Byte-Strom, Nachrichten, „Remote Procedure Call“


Motivation einer Transportschicht

‣In Hard- or software providing transportation layer services is called transport entity‣Transport entity can be implemented in the operation system kernel (Linux, BSD, other Unixes), in a separate user process (VM on S390), in a library package bound into network applications‣As they are two types of networks: connection orientated and connectionlessThey are similar types of transportation serviceWhy we need two distinct layers?


Motivation einer Transportschicht

‣Betrachte die folgenden Fragen:Wenn das Netzwerk verbindungsorientiert betrieben wird:

Was passiert, wenn Router regelmäßig abstürzen?

Oder Pakete häufig verloren gehen?

Solche Probleme tauchen auf und sind meist nicht lösbar.Das Netzwerk ist auch selten unter der Kontrolle eines einzelnen Operators. Ohne die Kontrolle über zumindest einige der Subnetze haben die Nutzer keine Möglichkeit die Zuverlässigkeit der Netzwerkschicht zu verbessern.


Möglichkeiten der Transportschicht

‣Existenz der Transportschicht ermöglicht es dem Transportdienst zuverlässiger zu sein, als der darunterliegende Netzwerkdienst‣Verlorene Pakete und fehlerhafte Daten können in der Transportschicht erkannt und kompensiert werden‣Transportdienstroutinen können so angelegt sein, dass sie unabhängig von den Netzwerkdienstroutinen funktionieren (man denke hierbei an den Übergang von IP v4 zu IP v6)‣Die Transportschicht erfüllt die Schlüsselfunktion bei der Isolierung der oberen Schichten von der jeweiligen Technologie, der Gestaltung und Fehler des Subnetzes


Dienste der Transportschicht

‣Zentrales Problem von Multifunktions-Netzwerksystemen – Wie können verschiedene Dienste gleichzeitig auf einem System angeboten werden (IP-Services), bzw. mehrere Client-Applikationen gleichzeitig Verbindungen über das IP Netz unterhalten?


Multiplex in der Transportschicht

‣Zentrale Aufgabe – Multiplexing (Mischen, Entmischen des Datenstroms der Vermittlungsschicht)‣Die Netzwerkschicht leitet Daten an die Transportschicht unkontrolliert weiter‣Die Transportschicht muss sie den verschiedenen Anwendungen zuordnen:•z.B. WWW, SMTP, POP3, IMAP4, FTP, SSH, DNS, DHCP, ...

•In TCP/UDP durch Port-Nummern

•z.B. Port TCP/80 für Web-Server

•TCP/22 für SSH-Server

•TCP/25 für SMTP ...



‣Theoretisch könnten auf gleichen Portnummern in UDP und TCP komplett verschiedene Dienste laufen

•Typischerweise nur für UDP oder für TCP implementiert

•Siehe auch /etc/services in der praktischen Übung für “wellknown ports” (Aus-schnitt neben-stehend)



‣Dabei spielen die ersten 1024 von den 65535 eine privilegierte Rolle (Client-Verbindungen starten daher erst danach)•Kann man sich bspw. mit netstat ansehen (praktische Übung)

‣Service-Port-Zuordnungen freiwillige Vereinbarung, wie bspw. in UDP (RFC768) und TCP (RFC793) festgelegt – muss sich aber keiner dran halten‣Eher selten, das Dienst verschiedene Transportschicht-protokolle nutzt:-UDP/53 DNS (Client-Anfragen)

-TCP/53 Datenaustausch (z.B. Zone-Transfes zwischen primärem und sekundärem DNS-Server, ...)



‣In speziellen Fällen auch mehrere Ports für ein Protokoll•DHCP arbeitet mit Broadcasts im Subnetz, deshalb zur Unterscheidung

-UDP/67 für Server-Antworten

-UDP/68 für Client-Anfragen

•TCP/20 für FTP-Data

•TCP/21 für FTP-Control-Connection

‣Port-Duplizierungen auch an anderer Stelle‣So lange Zeit Trennung für (un)verschlüsselte Verbindungen•TCP/80 für HTTP, TCP/110 für POP3 ohne SSL

•TCP/443 für HTTPS, TCP/995 für POP3S mit TLS/SSL

•Viele Applikationen können das inzwischen aber auch dynamisch aushandeln


Datenkapselung

‣Für ihre Aufgaben fügt Transportschicht eigene Header ein•Damit korrekte Zuordnung erfolgt – Information im IP Header für Next Header (Protocol Feld)

•Siehe /etc/protocols (z.B. in praktischer Übung)

‣ICMP – 1, TCP – 6, UDP – 17, ...


Transportschichtprotokolle des TCP/IP

‣In TCP (transmission control protocol)•Erzeugt zuverlässigen Datenfluß zwischen zwei Rechnern

•Unterteilt Datenströme aus Anwendungsschicht in Pakete

•Gegenseite schickt Empfangsbestätigungen (Acknowledgments)

‣UDP (user datagram protocol)

•Einfacher unzuverlässiger Dienst zum Versand von einzelnen Päckchen

•Wandelt Eingabe in ein Datagramm um

•Anwendungsschicht bestimmt Paketgröße

‣Versand der Segmente durch Netzwerkschicht

‣Kein Routing: End-to-End-Protokolle


Portnummern in UDP und TCP

‣Zwei kommunizierende Rechner (Prozesse) müssen sich auf entsprechende Portnummern einigen‣Zwei Möglichkeiten, Port-Nummern zu vergeben•Zentrale Vergabe der Portnummern (universal assignment, well-known port assignment)

•Dynamisches Zuordnen (dynamic binding)

‣TCP und UDP implementieren Hybridlösung:•einige Port-Nummern a priori (generelle Anwendungs-programme als laufende Server)

-TCP/80 Webserver, TCP/25 Mailserver

•Restliche Port-Nummern stehen zur freien Verfügung


Eigenschaften von UDP

‣UDP – User Datagram Protocol ist ein unzuverlässiges, verbindungsloses Transportprotokoll für Pakete‣Demultiplexing von Paketen aus der Vermittlungsschicht – UDP verwirklicht das Protokoll-Port-Konzept für IP‣UDP bietet denselben unzuverlässigen, verbindungslosen Übertragungs-Service wie das IP‣Zusätzlich (optional – muss nicht jede Applikation nutzen):•Checksum aus UDP Header + Daten

‣UDP-Pakete können•Verloren gehen

•In falscher Reihenfolge ankommen

•Zu schnell beim Empfänger ankommen


Eigenschaften von UDP

‣Applikationen müssen sich bei UDP selbst um Strom-steuerung, Retransmit etc. kümmern‣Deshalb bei entweder sehr einfachen, schnellen Protokollen ohne großen Overhead (DHCP, DNS) oder bei echtzeit-kritischen Anwendungen ohne Retransmit im Einsatz (Multi-media-Datenströme)‣Aufbau des UDP-Headers


Motivation für TCP

‣UDP nur dünne Zwischenschicht über IP, Header gerade mal 8 Byte (Octets) groß•Damit nur das IP-Sent&Forget

•Keine Fluss-Steuerung

•Keine Zusicherung auf Zustellung, keine Kontrolle, ob Pakete ankamen

•Applikation muss bi-direktionalen Datenverkehr selbst organisieren, muss also viel über Netzwerk wissen, was eigentlich nicht in oberen Schichten vorliegt

‣Entwicklung von TCP – Applikationen werden von Netzwerk-aufgaben entlastet

Einführung in TCP

Die Flusskontrolle in einem paketporientierten Netzwerk hat einige Probleme:IP ist unzuverlässig (aus guten Gründen!)

Viele Arten möglicher physikalischer Netzwerke

Dynamisches Routing mit verschiedenen Metriken

Unterschiedliche Paketgrößen und Fragmentation

Staukontrolle mit Hilfe von ICMP (source quench) ist veraltet – es ist nicht besonders schlau noch mehr Pakete in einem überlasteten Netzwerk zu senden, um vor der Überlastung zu warnen.

Internetworks unterscheiden sich von einzelnen Netzwerken weil die einzelnen Teile sehr unterschiedliche Bandbreiten, Verzögerungen, Paketgrößen oder Topologien haben können.Das transmission control protocol (TCP) wurde entwickelt, um sich dynamisch an die Eigenschaften des Internetworks anzupassen und robust auf viele Fehlerarten reagieren zu können. Die TCP Entität erhält Datenströme von lokalen Prozessen, teilt sie in Stücke von nicht mehr als 64Kbyte und sendet jedes Stück als einzelnes IP Datagram.TCP muss die MTU-Größe des benutzten Netzwerks kenne, um den Datenstrom in passende Stücke zu teilen. (normalerweise 1500Byte)

Das Internet Transportation Protocol

Ankommende IP-Datagramme, die TCP-Daten beinhalten, werden an die TCP Entität weitergegeben, die dann die ursprünglichen Bytefolge rekonstruiert


Die IP-Schicht garantiert nicht, dass Datagramme korrekt geliefert werden, so dass es die Aufgabe von TCP ist, nach einer bestimmten Zeit neu zu sendenDatagramme können in der falschen Reihenfolge ankommen. TCP muss sie dann in die richtige Reihenfolge bringen und zusammensetzenTCP liefert die Zuverlässigkeit, die die Anwendungsschicht benötigt und die IP nicht erfüllen kannSpäterer Screenshot zeigt ein IP Packt mit einem TCP SegmentAlle Teile des Pakets können einfach ausgelesen werden, da dies notwendig für manche Aufgaben beim Routing ist




‣TCP ist ein verbindungsorientierter, zuverlässiger Dienst für bidirektionale Byteströme

‣TCP ist ein Dienst für bidirektionale Byteströme•Daten sind zwei gegenläufige Folgen aus einzelnen Bytes (=8 Bits)

•Inhalt wird nicht interpretiert

•Zeitverhalten der Datenfolgen kann verändert werden

•Versucht zeitnahe Auslieferung jedes einzelnen Datenbytes

•Versucht Übertragungsmedium effizient zu nutzen = wenig Pakete




‣TCP ist verbindungsorientiert•Zwei Parteien identifiziert durch Socket: IP-Adresse und Port(TCP-Verbindung eindeutig identifiziert durch Socketpaar)

•Damit kein Broadcast oder Multicast (spätere Vorlesung) möglich

•Verbindungsaufbau und Ende notwendig

•Solange Verbindung nicht (ordentlich) beendet, ist Verbindung noch aktiv




‣TCP ist zuverlässig•Jedes Datenpaket wird bestätigt (acknowledgment)

•Erneutes Senden von unbestätigten Datenpakete

•Checksum für TCP-Header und Daten

•TCP nummeriert Pakete und sortiert beim Empfänger

•Löscht duplizierte Pakete

TCP Segment Beispiel (wireshark)


TCP-Header

‣Zu sehen ist der Aufbau des TCP-Headers, der deutlich umfangreicher als der UDP-Header ausfällt‣Wie schon bekannt: Soure- und Destination-Ports


TCP-Header

‣Zu Sequenznummer•Nummer des ersten Bytes im Segment•Jedes Datenbyte ist nummeriert modulo 232

‣Bestätigungsnummer•Aktiviert durch ACK-Flag•Nummer des nächsten noch nicht bearbeiteten Datenbytes = letzte Sequenznummer + letzte Datenmenge‣Weitere Header-Elemente

•Headerlänge -data offset•Prüfsumme-Für Header und Daten

Ein Port und seine Host IP bilden eine eindeutige, 48 Bit lange Adresse für den Transportdienst – dadurch ist die maximale Anzahl ausgehender Verbindungen definiertDiese Information sollte man sich merken, wenn man einen Maskerade-Host (Firewall) für ein größeres Netzwerk aufsetztDie Sequence- und ack-Nummer führen die Funktionen aus, die früher erwähnt wurden. Achtung: Die ack-Nummer bezeichnet das nächste erwartete Byte und nicht das zuletzt korrekt empfangeneDas Header-Length-Feld gibt die Anzahl der 32bit Worte im Header an. (Notwendig durch das Options-Feld mit variabler Länge)

TCP Header


TCP-Header

Das nächste 6bit Feld ist leer (freier Platz für mögliche Erweiterungen des Protokolls)Sechs Bit-Flags für die Verbindungskontrolle folgen

URG Set to 1 if urgent pointer is usedACK Set to 1 indicates that ack number is validPSH Pushed data for immediate deliveryRST Reset connection because of confusion or crashSYN Establish connectionsFIN Releasing connection

Für die Flusskontrolle wird ein Sendefenster mit variabler Größe eingesetzt (wird später erklärt)Die Prüfsumme erhöht die Zuverlässigkeit. Kontrolliert wird der Header, die Daten und ein pseudo-Header, der die Quell- und Ziel-IP, die Protokollnummer für TCP (6) und die Segmentlänge enthällt. Der Einsatz von IP Informationen hilft dabei, falsche Pakete zu erkennen, verstößt aber gegen die Schichtung des Protokoll-Stacks.Das Option-Feld liefert zusätzliche Funktionen, die nicht von den normalen Header-Felder abgedeckt sind.

TCP Header

Um die nötige Zuverlässigkeit zu erreichen, ist das Wiederversenden von Paketen eine zentrale TechnikWenn TCP Daten verschickt, werden verlorene Pakete nach folgendem Schema erneut versandt:Wenn der Sender ein Segment verschickt, startet er einen Countdown.

Sobald das Segment auf der anderen Seite angekommen ist, sendet der Empfänger ein Segment mit einer ack-Nummer die der nächsten erwarteten Sequenznummer entspricht

Läuft der Countdown ab, bevor das ack ankommt, wird das Segment neu gesendet

TCP - Zuverlässigkeit

Das Antwortpaket enthält Daten, falls welche vorliegen, ansonsten nicht. Diese Technik ermöglich einen vollen Duplex-Einsatz auf einer TCP VerbindungDas Packen von acks und Daten in ein einzelnes Paket wird “piggi-backing” genanntDas Scheme zur Wiederversendung ist der Schlüssel zum Erfolg von TCP, da es eine Kommunikation über ein beliebiges Internet unterstütztTCP ermöglicht es verschiedenen Anwendungsprogrammen gleichzeitig zu kommunizierenAber: Eine Anwendung könnte mit einer Anderen im gleichen lokalen Subnetz und einer Weiteren auf einem anderen Kontinent kommunizieren

TCP Zuverlässigkeit

TCP muss in beide Richtungen verlorene Pakete erneut senden. Die Frage ist nun, wie lang TCP warten sollAcks auf einem lokalen LAN kommen nach wenigen ms, eine zu lange Wartezeit würde den Durchsatz senken und das Netzwerk wäre nicht sinnvoll genutztEine Wartezeit von wenigen ms wäre aber bei langen Verbindungen mit einem langen Verzögerung nicht sinnvoll – unnötiger Verkehr würde hier teure Bandbreite verbrauchen

TCP Zuverlässigkeit

Quell- und Zielport beschreiben die Endpunkte der Verbindung. Port management:An welchen Port sollte ein Client senden, um einen Server (oder einen bestimmten Dienst) zu erreichen?

An welchen Port sollte sich ein startender Server binden?

Für Standard-Dienste sind die well-known-Ports eine mögliche Antwort, z.B. FTP auf 21, SSH auf 22, TELNET auf 23, SMTP auf 25 (vgl. /etc/services)

Port Management

Meist bleibt man bei dem Standard-Port, wie 80 für einen WebDienst, da sich sonst niemand mit diesem Dienst verbinden wird, da die Suche nach einem offenen http-Port bei 65535 möglichen Ports eher aufwändig ist. Anders sieht es aus, wenn man keinen Standard-Dienst (etwas illegales, …) anbietet. ( wobei man dann immer noch entdeckt werden kann )

Oder man wählt Port 1139 um den SMP FileService auf dem Bürorechner zu nutzen weil der Standardport (139) durch eine Firewall blockiert wird.

Port Management

Servers können die PortNummer des Clients erkennen, und können damit direkt an einen bestimmten Client-Prozess senden. Flüchtige Ports werden an das OS zurückgegeben, nachdem die entsprechende Anwendung geschlossen wurde. Die Nummer bei der flüchtige Ports starten, hängt vom eingesetzten OS ab. Häufig sind die Firewall-Regeln portbasiert.Um zu garantieren, dass Verbindungen zuverlässig aufgebaut sind, verwendet TCP den three-way-handshake.

Port Management


TCP Verbindungsaufbau

‣In der Regel Client-Server-Verbindungen•Dann Aufbau mit drei TCP-Pakete (=Segmente)•Mit ersten SYN-Segment auch Übermittlung der MSS (maximum segment size)


TCP Verbindungsende

‣Sog. Half-Close•Sender kündigt Ende mit FIN-Segment an und wartet auf Bestätigung•In Gegenrichtung kann weitergesendet werden

2 Half-Close beenden TCP-Verbindung

Es wurde gezeigt, dass der 3-way handshake für eine eindeutige Absprache trotz Paketverlust/duplikation und Verzögerung notwendig und hinreichend istTCP nutzt ein Synchronisations-Segment, SYN um die Nachrichten im 3-way handshake zu beschreibenDas End-Segment, FIN, wird eingesetzt um ein Paket zu beschreiben, das die Verbindung wieder löstWie alle anderen Segmente werden SYN und FIN bei Bedarf neu versandtDer Handshake garantiert, dass TCP keine Verbindung öffnet oder schließt, bevor beide Seiten interagiert haben

Verbindungsaufbau

42

„Das“ Seq.nr. 154

„ist“ Seq.nr. 157

„es“ Seq.nr. 160

ACK: 162

„World“ Seq.nr. 23

„bla bla“ Seq.nr. 91

ACK: 91+7=98

„Hello!“ Seq.nr. 17

ACK: 17+6=23

Bestätigungen

‣Huckepack-Technik•Bestätigungen „reiten“ auf den Datenpaket der Gegenrichtung‣Eine Bestätigungssegment kann viele Segmente bestätigen•Liegen keine Daten an, werden Acks verzögert


Ende der siebten VorlesungEnde der zehnten Vorlesung

Weiter geht es am Montag, den 15.6. mit einer weiteren praktischen Übung und am Mittwoch, den 17.6. mit der nächsten VorlesungWeiter zur Transportschicht und TCP, insbesondere Strategien zur DatenflusssteuerungAlle relevanten Informationen auf der Webseite zur Vorlesung: http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28Vorbereitung: Abschließen des Kapitels 3 im Kurose&Ross und zu Transportschicht in der angegebenen Literatur!

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 10te Vorlesung Lehrstuhl für...

Documents

Transcript of Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 10te Vorlesung Lehrstuhl für...