Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 10te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät Universität Freiburg 2009

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

Lehrstuhl für Kommunikationssysteme - Systeme II3 Letzte Vorlesung 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)

Lehrstuhl für Kommunikationssysteme - Systeme II4 Ende der siebten Vorlesung Transportschicht Bewegen uns einen Schritt nach unten im TCP/IP- Schichtenmodell Die Schicht zwischen IP und den Anwendungen Bietet Applikationen wichtige Dienste an

Lehrstuhl für Kommunikationssysteme - Systeme II5 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

Lehrstuhl für Kommunikationssysteme - Systeme II6 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 connectionless They are similar types of transportation service Why we need two distinct layers?

Lehrstuhl für Kommunikationssysteme - Systeme II7 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.

Lehrstuhl für Kommunikationssysteme - Systeme II8 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

Lehrstuhl für Kommunikationssysteme - Systeme II9 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?

Lehrstuhl für Kommunikationssysteme - Systeme II10 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...

Lehrstuhl für Kommunikationssysteme - Systeme II11 Multiplex in der Transportschicht 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)

Lehrstuhl für Kommunikationssysteme - Systeme II12 Multiplex in der Transportschicht Dabei spielen die ersten 1024 von den 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,...)

Lehrstuhl für Kommunikationssysteme - Systeme II13 Multiplex in der Transportschicht 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

Lehrstuhl für Kommunikationssysteme - Systeme II14 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,...

Lehrstuhl für Kommunikationssysteme - Systeme II15 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

Lehrstuhl für Kommunikationssysteme - Systeme II16 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

Lehrstuhl für Kommunikationssysteme - Systeme II17 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

Lehrstuhl für Kommunikationssysteme - Systeme II18 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

Lehrstuhl für Kommunikationssysteme - Systeme II19 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 Das Internet Transportation Protocol

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

Lehrstuhl für Kommunikationssysteme - Systeme II24 Das Internet Transportation Protocol 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

Lehrstuhl für Kommunikationssysteme - Systeme II25 Das Internet Transportation Protocol TCP ist ein verbindungsorientierter, zuverlässiger Dienst für bidirektionale Byteströme 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

Lehrstuhl für Kommunikationssysteme - Systeme II26 Das Internet Transportation Protocol TCP ist ein verbindungsorientierter, zuverlässiger Dienst für bidirektionale Byteströme 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)

Lehrstuhl für Kommunikationssysteme - Systeme II28 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

Lehrstuhl für Kommunikationssysteme - Systeme II29 TCP-Header Zu Sequenznummer Nummer des ersten Bytes im Segment Jedes Datenbyte ist nummeriert modulo 2 32 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 definiert Diese Information sollte man sich merken, wenn man einen Maskerade-Host (Firewall) für ein größeres Netzwerk aufsetzt Die 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 empfangene Das Header-Length-Feld gibt die Anzahl der 32bit Worte im Header an. (Notwendig durch das Options-Feld mit variabler Länge) TCP Header

Lehrstuhl für Kommunikationssysteme - Systeme II31 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

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 Technik Wenn 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 Verbindung Das Packen von acks und Daten in ein einzelnes Paket wird piggi-backing genannt Das Scheme zur Wiederversendung ist der Schlüssel zum Erfolg von TCP, da es eine Kommunikation über ein beliebiges Internet unterstützt TCP ermöglicht es verschiedenen Anwendungsprogrammen gleichzeitig zu kommunizieren Aber: 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 soll Acks auf einem lokalen LAN kommen nach wenigen ms, eine zu lange Wartezeit würde den Durchsatz senken und das Netzwerk wäre nicht sinnvoll genutzt Eine 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 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

Lehrstuhl für Kommunikationssysteme - Systeme II39 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)

Lehrstuhl für Kommunikationssysteme - Systeme II40 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 ist TCP nutzt ein Synchronisations-Segment, SYN um die Nachrichten im 3-way handshake zu beschreiben Das End-Segment, FIN, wird eingesetzt um ein Paket zu beschreiben, das die Verbindung wieder löst Wie alle anderen Segmente werden SYN und FIN bei Bedarf neu versandt Der 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

Lehrstuhl für Kommunikationssysteme - Systeme II43 Ende der siebten Vorlesung Ende der zehnten Vorlesung Weiter geht es am Montag, den mit einer weiteren praktischen Übung und am Mittwoch, den mit der nächsten Vorlesung Weiter zur Transportschicht und TCP, insbesondere Strategien zur Datenflusssteuerung Alle relevanten Informationen auf der Webseite zur Vorlesung: Vorbereitung: Abschließen des Kapitels 3 im Kurose&Ross und zu Transportschicht in der angegebenen Literatur!