TCP/UDP OSI Transportschicht (Transportlayer)

TCP/UDP OSI Transportschicht (Transportlayer) Lernziele Wenn wir die Unterlagen durch gearbeitet haben, sollten wir in der Lage sein, die folgenden Fragen zu beantworten: Warum ist die Transportschicht überhaupt notwendig? Welche Rolle spielt die Transportschicht bei der Ende zu Ende Übertragung von Daten zwischen Anwendungen? Welche Rolle spielen die beiden TCP/IP Protokolle der Transportschicht TCP und UDP? Wie funktionieren die Schlüsselfunktionen eines Transportschichtprotokolls: Zuverlässigkeit, Port Adressierung und Segmentierung? Wie realisieren TCP und UDP ihre Hauptfunktionen? Wann sollte TCP und wann UDP eingesetzt werden? Was sind Beispiele für Anwendungen, die TCP bzw.udp verwenden? Schlüsselbegriffe Wir lernen die folgenden Schlüsselbegriffe. Die entsprechenden Definitionen findet man auch im Internet. Flusskontrolle Steuerdaten IANA Well known Ports registrierte Ports dynamische/private Ports URG ACK PSH RST SYN FIN Bestätigung Fenstergröße 1

Die 0SI Transportschicht Datennetze und das Internet unterstützen das menschliche Netzwerk, indem sie eine nahtlose und zuverlässige zwischenmenschliche Kommunikation ermöglichen sowohl lokal als auch über den gesamten Globus. Auf einem einzelnen Gerät können Benutzer diverse Dienste wie E Mail, das Web und Instant Messaging zum Versand von Nachrichten oder zum Abrufen von Daten einsetzen. Anwendungen wie Mailclients, Webbrowser und Instant Messaging Clients ermöglichen es Benutzern, mithilfe von Computern und Netzwerken Nachrichten zu senden und Informationen zu suchen. Die Daten aller dieser Anwendungen werden gepackt, transportiert und an den passenden Server Daemon oder die Anwendung auf dem Zielgerät ausgeliefert. Die in der 0SI Transportschicht beschriebenen Protokolle nehmen Daten von der Anwendungsschicht entgegen und bereiten diese für die Adressierung In der Vermittlungsschicht vor. Die Transportschicht ist für den gesamten Ende zu Ende Transfer von Anwendungsdaten zuständig (siehe Abbildung 1.1 unten). Als Daemon oder Dämon (auch häufig in der Schreibweise Demon) bezeichnet man unter Unix oder unixartigen Systemen ein Programm, das im Hintergrund abläuft und bestimmte Dienste zur Verfügung stellt. Benutzerinteraktionen finden hierbei nur auf indirektem Weg statt, zum Beispiel über Signale, Pipes und vor allem (Netzwerk )Sockets. Bei Microsoft Windows heißen die entsprechenden Programme services oder Systemdienste. Abb.1.1 OSI Transportschicht Abb. 1.2 Funktion der Transportschicht 2

Abb. 3.1 OSI Modell (englische Begriffe) Jetzt untersuchen wir die Rolle der Transportschicht bei der Kapselung von Anwendungsdaten für die Vermittlungsschicht. Die Transportschicht erfüllt außerdem die folgenden Funktionen: Sie ermöglicht mehreren Anwendungen auf demselben Gerät die gleichzeitige Kommunikation über das Netzwerk. Sie gewährleistet, dass, sofern erforderlich, alle Daten zuverlässig und in der richtigen Reihenfolge von der passenden Anwendung empfangen werden. Sie setzt Mechanismen zur Fehlerbehandlung ein. 1.1 Funktionen der Transportschicht Die Transportschicht ermöglicht eine transparente Übertragung von Daten zwischen Endbenutzern und stellt dabei den übergeordneten Schichten zuverlässige Datenübertragungsdienste zur Verfügung. Die Transportschicht steuert die Zuverlässigkeit einer gegebenen Leitung mithilfe von Flusskontrolle, Segmentierung/Desegmentierung und Fehlerkontrolle. Einige Protokolle sind zustands und verbindungsorientiert, das heißt, die Transportschicht kann Segmente nachverfolgen und alle jene neu übertragen, deren Versand fehlgeschlagen ist. 1.1.1 Zweck der Transportschicht Die folgenden Aufgaben fallen im Wesentlichen in die Zuständigkeit der Transportschicht: Nachverfolgen der einzelnen Kommunikationsvorgänge zwischen Anwendungen auf den Absender und Zielhosts Segmentieren der Daten und Verwalten jeder Dateneinheit Neuzusammensetzen der Segmente zu Anwendungsdatenströmen Erkennungen der verschiedenen Anwendungen Flusskontrolle zwischen Endbenutzern Wiederherstellen im Fehlerfall Initiieren einer Sitzung Die Transportschicht ermöglicht Anwendungen auf Geräten die Kommunikation (siehe Abbildung 2.1). 3

Abb 2.1 Kommunikation zwischen verschiedenen Anwendungen 4

Der nächste Abschnitt beschreibt die verschiedenen Rollen der Transportschicht und die Anforderungen der Transportschichtprotokolle an Daten. Einzelne Kommunikationsvorgänge nachverfolgen Auf jedem Host können stets mehrere Anwendungen ausgeführt werden, die über das Netzwerk kommunizieren. Alle diese Anwendungen kommunizieren dabei mit einer oder mehreren Anwendungen auf entfernten Hosts. Die Transportschicht ist dafür zuständig, die verschiedenen Kommunikationsströme zwischen diesen Anwendungen aufrechtzuerhalten. Betrachten Sie einen Computer, der an ein Netzwerk angeschlossen ist und auf dem gleichzeitig E Mail und Instant Messaging Nachrichten gesendet und empfangen und Webseiten angezeigt werden und zudem ein VoIP Anruf durchgeführt wird (vgl. Abbildung 3.1 ). Jede dieser Anwendungen sendet und empfängt zur selben Zeit Daten über das Netzwerk. Allerdings werden Daten des Telefongesprächs weder an den Webbrowser weitergeleitet, noch erscheint der Text der Instant Messaging Nachricht in einer E Mail. Abb.3.1 Kommunikationsvorgänge zuordnen 5

Daten segmentieren Die Anwendungsschicht übergibt große Datenmengen an die Transportschicht. Die Transportschicht muss die Daten dann in kleinere Einheiten unterteilen, die für die Übertragung besser geeignet sind. Diese Einheiten heißen Segmente. Bestandteil dieses Vorgangs ist die Kapselung aller Dateneinheiten. Jede Anwendungsdateneinheit benötigt Header, in denen angegeben wird, zu welcher Anwendung sie gehört. Diese Header werden in der Transportschicht hinzugefügt. Die Segmentierung der Daten entsprechend den Transportschichtprotokollen ermöglicht es, Daten mehrerer verschiedener Anwendungen, die gleichzeitig auf dem Computer ausgeführt werden, zu senden und zu empfangen (siehe Abbildung 4.1). Ohne eine Segmentierung könnte nur eine einzige Anwendung beispielsweise der Videostream Daten empfangen. Wir könnten dann weder E Mails empfangen noch im Instant Messenger chatten oder Webseiten ansehen, solange das Video läuft. Abb. 4.1 Segmentierung Segmente wieder zusammensetzen Da Netzwerke mehrere Routen mit jeweils unterschiedlicher Übertragungsdauer anbieten können, ist es durchaus möglich, dass Daten in der falschen Reihenfolge eintreffen. Durch Nummerierung und Sequenzierung der Segmente kann die Transportschicht sicherstellen, dass diese Segmente wieder in der korrekten Reihenfolge zusammengesetzt werden. Beim Empfängerhost müssen alle Segmente wieder zusammengesetzt und an die passende Anwendung weitergeleitet werden. Die Protokolle der Transportschicht beschreiben, wie die Header Daten der Transportschicht beim Zusammensetzen der Dateneinheiten zum Originaldatenstrom verwendet werden, der dann an die Anwendungsschicht übergeben wird. Anwendungen ermitteln Damit die Datenströme an die passenden Anwendungen übergeben werden, muss die Transportschicht die Zielanwendung ermitteln können. Zu diesem Zweck weist die Transportschicht einer Anwendung eine Kennung zu. Bei den TCP/IP Protokollen heißt diese Kennung Port Nummer. Jedem Softwareprozess, der auf das Netzwerk zugreifen muss, wird eine Port Nummer 6

zugewiesen, die auf dem jeweiligen Host eindeutig ist. Diese Port Nummer wird im Transportschicht Header verwendet, um anzugeben, zu welcher Anwendung das Datenelement gehört. In der Transportschicht nennt man jede Datengruppe, die zwischen einer Absender und einer Zielanwendung ausgetauscht wird, einen Kommunikationsvorgang. Die Unterteilung von Daten in kleinere Teile und das Versenden dieser Teile vom Absender an den Empfänger ermöglicht das Verschachteln (Multiplexen) vieler verschiedener Kommunikationsvorgänge im selben Netzwerk. Die Transportschicht ist die Verbindung zwischen der Anwendungsschicht und den untergeordneten Schichten, die für die Übertragung im Netzwerk zuständig sind. Diese Schicht akzeptiert Daten verschiedener Kommunikationsvorgänge und übergibt diese in Form handlicher Einheiten an die unteren Schichten, damit diese sie am Ende über das Medium multiplexen. Anwendungen müssen die Betriebseigenschaften des verwendeten Netzwerks nicht im einzelnen kennen: Sie generieren Daten, die von einer Anwendung an eine andere geschickt werden, ohne dass Parameter wie der Typ des Zielhosts, der Medientyp, über den die Daten versendet werden, der von den Daten genommene Pfad, Verbindungsüberlastungen oder die Größe des Netzwerks hierbei eine Rolle spielen. Ebenso wissen die unteren Schichten auch nicht, dass mehrere Anwendungen die Daten über das Netzwerk senden, ihre Aufgabe besteht lediglich darin, die Daten an das vorgesehene Gerät zu übergeben. Die Transportschicht sortiert diese Dateneinheiten dann, bevor sie sie an die entsprechende Anwendung übergibt. Flusskontrolle Die Ressourcen von Netzwerkhosts zum Beispiel Speicher oder Bandbreite, sind stets eingeschränkt. Wenn die Transportschicht feststellt, dass diese Ressourcen überbeansprucht sind, sind einige Protokolle in der Lage, die sendende Anwendung zur Verringerung ihrer Datenrate aufzufordern. Die Verringerung erfolgt in der Transportschicht, wobei die Menge der Daten reguliert wird, die der Absender als Datengruppe überträgt. Diese Flusskontrolle (manchmal auch»flusssteuerung«genannt) verhindert den Verlust von Segmenten im Netzwerk und beseitigt so die Notwendigkeit einer Neuübertragung. Wenn wir an anderer Stelle in diesem Kapitel die Protokolle behandeln, werden wir auf diesen Dienst noch genauer eingehen. Fehlerwiederherstellung Aus verschiedenen Gründen ist es möglich, dass Dateneinheiten bei der Übertragung durch das Netzwerk beschädigt werden oder verloren gehen. Die Transportschicht kann sicherstellen, dass alle Teile ihr Ziel erreichen. Hierzu muss das Absendergerät alle verloren gegangenen Daten neu senden. Eine Sitzung einleiten Die Transportschicht kann eine Verbindungsorientierung liefern, indem sie zwischen Anwendungen eine Sitzung erstellt. Solche Verbindungen bereiten die Anwendungen auf die Kommunikation miteinander vor, bevor Daten übertragen werden. Innerhalb solcher Sitzungen können die Daten für einen Kommunikationsvorgang zwischen den beiden Anwendungen sehr genau gesteuert werden. Variierende Anforderungen an Daten Es gibt mehrere Transportschichtprotokolle, um die Anforderungen unterschiedlicher Anwendungen zu erfüllen. So verlangen Benutzer beispielsweise, dass eine E Mail oder eine Webseite vollständig empfangen und dargestellt wird andernfalls wären die Informationen nutzlos. Leichte Verzögerungen gelten als akzeptabel, sofern sichergestellt ist, dass die Daten vollständig empfangen und angezeigt werden. Im Gegensatz dazu können kleine Aussetzer während eines Telefongesprächs durchaus hingenommen werden. Sie können die fehlenden Teile entweder aus dem Kontext des Gesprächs heraus ergänzen oder den Gesprächspartner bitten, das Gesagte zu wiederholen. Dies wird spürbaren Verzögerungen vorgezogen, wie sie entstehen könnten, wenn das Netzwerk aufgefordert würde, fehlende Segmente zu erkennen und neu zu senden. In diesem Beispiel erfolgt der Neuversand oder die Ersetzung fehlender Informationen durch den Benutzer statt im Netzwerk. In den modernen integrierten Netzwerken, in denen Sprache, Video und Daten gemeinsam übertragen werden, können Anwendungen mit sehr unterschiedlichen Transportbedürfnissen über dasselbe Netzwerk kommunizieren. Die verschiedenen Protokolle der Transportschicht unterliegen unterschiedlichen Regeln, die es den Geräten ermöglichen, die diversen Datenanforderungen zu 7

verarbeiten. Einige Protokolle wie etwa UDP (User Datagram Protocol) bieten nur Grundfunktionen für ein effizientes Zustellen von Dateneinheiten zwischen den jeweiligen Anwendungen. Solche Protokolle sind nützlich für Anwendungen, deren Daten Verzögerungen nicht tolerieren. Andere Transportschichtprotokolle wie TCP (Transmission Control Protocol) beschreiben Prozesse, die zusätzliche Eigenschaften bieten, zum Beispiel eine zuverlässige Auslieferung zwischen den Anwendungen. Diese Zusatzunktionen bieten in der Transportschicht zwar eine robustere Kommunikation zwischen Anwendungen, verursachen aber einen höheren Aufwand und stellen höhere Anforderungen an das Netzwerk. Um die einzelnen Datensegmente zu identifizieren, fügt die Transportschicht einen Header zur Dateneinheit hinzu, der Binärdaten enthält. Genau genommen enthält dieser Header ein Feld mit Bits, deren Werte verschiedene Transportschichtprotokolle aktivieren, um unterschiedliche Funktionen durchzuführen. 1.1.2 Unterstützung einer zuverlässigen Kommunikation Sie wissen bereits, dass die wesentliche Funktion der Transportschicht darin besteht, die Anwendungsdaten für die Kommunikationsvorgänge zwischen den Hosts zu steuern. Allerdings stellen verschiedene Anwendungen aufgrund ihrer Daten unterschiedliche Anforderungen, weswegen mehrere Transportprotokolle entwickelt wurden, um diese Anforderungen zu erfüllen. TCP ist ein Protokoll der Transportschicht, das implementiert werden kann, um eine zuverlässige Auslieferung der Daten zu gewährleisten. In der Netzwerkterminologie bedeutet Zuverlässigkeit, dass jede vom Absender gesendete Dateneinheit auch beim Empfänger ankommt. In der Transportschicht gibt es drei grundsätzliche Funktionen für die Zuverlässigkeit: Verfolgung übertragener Daten Bestätigung des Datenempfangs Neuübertragung nicht bestätigter Daten Die Transportschicht des sendenden Hosts verfolgt alle Dateneinheiten jedes Kommunikationsvorgangs und überträgt alle Daten neu, die der empfangende Host nicht bestätigt. Diese Zuverlässigkeitsfunktionen erhöhen die Belastung der Netzwerkressourcen zusätzlich aufgrund von Bestätigungen, Nachverfolgung und Neuübertragung. Um diese Funktionen zu unterstützen, werden weitere Steuerdaten zwischen dem sendenden und dem empfangenden Host ausgetauscht. Die Steuerdaten sind im Schicht 4 Header enthalten. Es entsteht also ein Kompromiss zwischen dem Wert der Zuverlässigkeit und der hierdurch entstehenden zusätzlichen Netzwerkbelastung (Overhead). Anwendungsentwickler müssen basierend auf den Anforderungen ihrer Anwendungen auswählen, welcher Transportprotokolltyp der geeignetste ist (siehe auch Abbildung 7.1). In der Transportschicht geben Protokolle Methoden entweder für eine zuverlässige, garantierte Zustellung oder eine Best Effort (d. h. bestmögliche) Auslieferung an. In diesem Kontext der Netzwerktechnik wird eine Best Effort Auslieferung als unzuverlässig bezeichnet, weil der Empfänger nicht bestätigt, dass er Daten empfangen hat. 8

Abb. 7.1 Protokolle der Transportschicht Anwendungen wie Datenbanken, Webseiten oder E Mail erfordern, dass alle gesendeten Daten in ihrem Originalzustand beim Empfänger eintreffen, weil andernfalls nichts mit ihnen anzufangen ist. Fehlende Daten könnten einen Kommunikationsvorgang beschädigen, da dieser dann unvollständig oder unleserlich ist. Aus diesem Grund muss für diese Anwendungen ein Transportschichtprotokoll verwendet werden, welches die Zuverlässigkeit implementiert. Das zusätzliche Datenaufkommen im Netzwerk wird in diesen Fall als notwendig betrachtet. Andere Anwendungen sind toleranter, was den Verlust kleiner 9

Datenmengen angeht. Wenn beispielsweise ein oder zwei Segmente eines Videodatenstroms nicht ankommen, würde dies nur eine kurzzeitige Unterbrechung hervorrufen. Unter Umständen wird das Bild dann leicht verzerrt, aber vielleicht bemerkt der Benutzer es auch gar nicht. Ein Mehraufkommen, das die Zuverlässigkeit für diese Anwendung garantiert, könnte den Nutzen der Anwendung beeinträchtigen. Die Qualität eines Videostreams würde sich erheblich verschlechtern, wenn das Zielgerät auf verlorene Daten warten und deswegen die Wiedergabe unterbrechen müsste, bis alle Daten eingetroffen sind. Es ist immer besser, mit den zum gegebenen Zeitpunkt vorhandenen Segmenten das bestmögliche Bild darzustellen und auf Zuverlässigkeit zu verzichten. Ist aus irgendeinem Grund Zuverlässigkeit erforderlich, so können diese Anwendungen Fehlerprüfungen vermitteln und gegebenenfalls eine Neuübertragung anfordern. 1.1.3 TCP und UDP Die beiden meistverwendeten Transportschichtprotokolle der TCP/IP Familie sind TCP (Transmission Control Protocol) und UDP (User Datagram Protocol). Beide Protokolle steuern die Kommunikation mehrerer Anwendungen. Der Unterschied zwischen ihnen besteht in den speziellen Funktionen, die die beiden Protokolle implementieren. Das UDP Protokoll UDP ist ein einfaches, verbindungsloses Protokoll, das in RFC 768 bschrieben ist. Sein Vorteil ist die Datenzustellung ohne großen Overhead. Die Segmente der UDP Kommunikation heißen Datagramme. UDP sendet Datagramme nach dem Prinzip des Best Effort Transports. Die folgenden Anwendungen verwenden UDP: DNS Videostreams VoIP Abb. 10.1 UDP Datagramm Das TCP Protokoll TCP ist ein verbindungsorientiertes Protokoll, das in RFC 793 beschrieben wird. TCP generiert bei der Erledigung seiner Aufgaben einen zusätzlichen Overhead. In TCP definierte Zusatzfunktionen sind die Auslieferung in derselben Reihenfolge, zuverlässige Auslieferung sowie Flusskontrolle. Jedes TCP Segment umfasst 20 Overhead Bytes im Header, in dem die Anwendungsschichtdaten gekapselt sind, während der Overhead bei UDP nur 8 Bytes beträgt. 10

Abbildung zeigt das TCP Datagramm. Abb. 11.1 TCP Datagramm Die folgenden Anwendungen verwenden TCP: Webbrowser E Mail Dateiübertragungen 1.1.4 Port Adressierung Vergegenwärtigen wir uns noch einmal das oben beschriebene Beispiel eines Computers, der gleichzeitig E Mail, Instant Messaging Nachrichten, Webseiten und einen VoIP Anruf sendet und empfängt. Die TCP und UDP basierten Dienste überwachen die verschiedenen miteinander kommunizierenden Anwendungen. Um die Segmente und Datagramme für jede Anwendung auseinanderhalten zu können, verfügen TCP wie auch UDP über Header Felder, die diese Anwendungen eindeutig identifizieren. Kommunikationsvorgänge identifizieren Der Header jedes Segments oder Datagramms enthält einen Absender und einen Zielport. Die Absender Port Nummer ist die mit der Ursprungsanwendung auf dem lokalen Host verknüpfte Nummer für diesen Kommunikationsvorgang. Die Ziel Port Nummer ist die mit der Zielanwendung auf dem Remote Host verknüpfte Nummer für diesen Kommunikationsvorgang. Port Nummern werden auf unterschiedliche Weise abhängig davon zugewiesen, ob die Nachricht eine Anforderung oder eine Antwort ist. Während Serverprozesse über statische Port Nummern verfügen, wählen Clients für jeden Kommunikationsvorgang eine Port Nummer dynamisch aus. Wenn eine Clientanwendung eine Anforderung an eine Serveranwendung sendet, ist der im Header enthaltene Zielport die Port Nummer, die dem Dienst Daemon zugeordnet ist, der auf dem Remote Host ausgeführt wird. Die Clientsoftware muss wissen, welche Port Nummer dem Serverprozess auf dem Remote Host zugewiesen ist. Diese Ziel Host Nummer ist entweder vorgegeben oder wird manuell konfiguriert. Wenn beispielsweise eine Webbrowseranwendung eine Anforderung an einen Webserver sendet, verwendet der Browser TCP und die Port Nummer 80, sofern nichts anderes festgelegt ist. TCP Port 80 ist der Default Port für Webdienstanwendungen. Viele gängige Anwendungen haben Default Ports. Der Absender Port in einem Segment oder Datagramm Header einer Clientanforderung wird zufällig generiert. Solange er nicht im Konflikt mit anderen Ports gerät, die auf dem System verwendet werden, kann der Client jede beliebige Zahl auswählen. 11

Diese Port Nummer agiert als Rücksendeadresse für die anfragende Anwendung. Die Transportschicht überwacht diesen Port und die Anwendung, die die Anforderung eingeleitet hat, damit eine gegebenenfalls erhaltene Antwort an die korrekte Anwendung übergeben werden kann. Die Port Nummer der anfordernden Anwendung wird als Ziel Port Nummer in der Antwort verwendet, die vom Server zurückkommt. Die Kombination der Port Nummer in der Transportschicht und der IP Adresse in der Vermittlungsschicht bezeichnet eindeutig einen bestimmten Prozess, der auf einem bestimmten Host ausgeführt wird. Eine solche Kombination bezeichnet man als Socket. Gelegentlich werden die Begriffe PortNummer und Socket synonym verwendet. In unserem Kontext bezeichnet Socket jedoch nur die eindeutige Kombination aus IP Adresse und Port Nummer. Ein aus Absender und Ziel IP Adressen und Port Nummern bestehendes Socket Paar ist eindeutig und bezeichnet den Kommunikationsvorgang zwischen zwei Hosts. So würde etwa die Anforderung einer HTTP Webseite, die an einen Webserver (Port 80) gesendet wird, der auf einem Host mit der IPv4 Adresse (Schicht 3 Adresse) 192.168.1.20 ausgeführt wird, an Socket 192.168.1.20:80 gerichtet sein. Wenn der Webbrowser, der die Webseite angefordert hat, auf dem Host 192.168.100.48 ausgeführt wird und ihm die dynamische Port Nummer 49152 zugewiesen wurde, lautet der Socket der Webseite dementsprechend 192.168.100.48:49152. Die eindeutigen Kennungen für Anwendungen sind die Port Nummern. Abbildung 12.1 zeigt den Prozess der Unterscheidung verschiedener Kommunikationsvorgänge über Port Nummern. Abb. 10.1 Kommunikationsvorgänge unterscheiden 12

Abb. 13.1 Arten von Port Nummern Die IANA (Internet Assigned Numbers Authority) legt bestimmte Port Nummern fest. Es handelt sich hierbei um eine Standardisierungsorganisation, die für die Zuweisung verschiedener Adressierungsstandards zuständig ist. Unterschieden werden die folgenden Arten von Port Nummern: Well Known Ports (0 1023) registrierte Ports (1024 49151) dynamische oder private Ports (49152 65535) Die folgenden Abschnitte beschreiben die drei Port Nummerntypen und erläutern anhand von Beispielen, wann TCP und UDP unter Umständen dieselbe Port Nummer verwenden. Außerdem werden Sie das Netzwerk Utility netstat kennenlernen. Well Known Ports Well Known Ports (0 1023) sind für Dienste und Anwendungen reserviert. Sie werden meist für Anwendungen wie HTTP (Webserver), POP3/SMTP (Mailserver) und Telnet eingesetzt. Durch Definition dieser Well Known Ports für Serveranwendungen können Clientanwendungen so programmiert werden, dass sie eine Verbindung zu diesem speziellen Port und dem zugehörigen Dienst herstellen. 13

TCP und UDP Abb. 14.1 Well known Ports Registrierte Ports Registrierte Ports (1024 49151) werden Benutzerprozessen oder anwendungen zugeordnet. Diese Prozesse sind meist Einzelanwendungen, die ein Benutzer installiert hat also nicht solche, die einen Well Known Port erhalten würden. Einen registrierten Port, der nicht für eine Serverressource verwendet wird, kann ein Client dynamisch als Absender Port auswählen. Tabelle 11.2 führt registrierte Ports für TCP und UDP auf. Abb. 14.2 Registrierte Ports 14

Dynamische oder private Ports Dynamische oder private Ports (49152 65535) werden meist in dynamischer Form Clientanwendungen zugewiesen, sobald eine Verbindung hergestellt wird. Dass ein Client eine Verbindung mit einem Dienst herstellt und dabei einen dynamischen oder privaten Port verwendet, ist eher ungewöhnlich (auch wenn einige Peer to Peer Programme für das Filesharing dies tun). TCP und UDP gemeinsam verwenden Einige Anwendungen können sowohl TCP als auch UDP verwenden. So ermöglicht es beispielsweise der geringe Overhead von UDP dem DNS System, sehr schnell viele Clientanforderungen zu beantworten. Manchmal jedoch benötigt die Übermittlung der angeforderten Daten die Zuverlässigkeit von TCP. Beide Protokolle verwenden den Well Known Port 53 für diesen Dienst. Tabelle 15.1 führt Beispiele für registrierte und Well Known Ports auf, die TCP und UDP gleichermaßen verwenden. Abb. 15.1 Gemeinsame Ports von TCP und UDP Der Befehl»netstat«15

Manchmal ist es notwendig, zu wissen, welche aktiven TCP Verbindungen auf einem vernetzten Host offen sind und ausgeführt werden. Der Befehl netstat ist ein wichtiges Netzwerk Utility, mit dem Sie diese Verbindungen ermitteln können. netstat führt das verwendete Protokoll, die lokale Adresse und Port Nummer, die Zieladresse und Ziel Port Nummer sowie den Status der Verbindung auf. Nicht nachvollziehbare TCP Verbindungen können ein Hinweis darauf sein, dass irgend jemand oder irgend etwas mit dem lokalen Host verbunden ist dies stellt ein erhebliches Sicherheitsrisiko dar. Zudem verbrauchen unnötige TCP Verbindungen wertvolle Systemressourcen und reduzieren so die Leistung des Hosts. Untersuchen Sie mit netstat die offenen Verbindungen auf einem Host, falls Sie den Eindruck haben, dass die Leistung beeinträchtigt ist. Für den Befehl netstat gibt es viele nützliche Optionen. So kann beispielsweise mit dem Parameter o Rückschluss auf die dazugehörige PID (Programm ID) im Task Manager gezogen werden. Listing 16.1 zeigt noch einmal eine Ausgabe von netstat: Abb. 16.1 Listing Befehl netstat 1.1.5 Teile und herrsche: Segmentierung und Wiederzusammensetzung In der Anwendungsschicht werden die Daten nach unten übergeben und zu kleineren Einheiten segmentiert. Ein UDP Segment wird als Datagramm, ein TCP Segment schlicht als Segment bezeichnet. Der UDP Header enthält Angaben zu Absender und Ziel Ports, der TCP Header zusätzlich die Funktionalitäten Sequenzierung, Bestätigungen und Flusskontrolle. Auf dem Zielhost verläuft der Prozess umgekehrt, bis die Daten wieder an die Anwendung übergeben werden können. Abbildung 17.1 zeigt ein Beispiel. Einige Anwendungen übertragen große Datenmengen, in manchen Fällen sogar viele Gigabyte. All diese Daten am Stück zu übertragen, wäre praktisch nicht machbar: Die Übertragung könnte Minuten oder gar Stunden dauern, und währenddessen könnten anderen Daten im Netzwerk nicht übermittelt werden. Außerdem wäre, wenn während der Übertragung Fehler aufträten, die gesamte Datei verloren und müsste gegebenenfalls neu versendet werden. Auch verfügen Netzwerkgeräte nicht über Pufferspeicher, die ausreichend groß wären, um so viele Daten während des Versands oder Empfangs zwischen zu speichern. Die Größe des Segments schwankt abhängig von der verwendeten Netzwerktechnik und dem jeweilig benutzten physischen Medium. 16

Abb. 17.1 Funktionen der Transportschicht Die Unterteilung von Daten in Segmente gewährleistet sowohl, dass Daten innerhalb der Grenzen des Mediums übertragen werden, als auch, dass Daten unterschiedlicher Anwendungen im Medium»gemultiplext«werden können. TCP und UDP führen die Segmentierung unterschiedlich aus. Bei TCP enthält jeder Segment Header eine Sequenznummer. Diese ermöglicht es den Transportschichtfunktionen auf dem Zielhost, die Segmente in der Reihenfolge, in der sie übertragen wurden, wieder zusammenzusetzen. So ist sichergestellt, dass die Zielanwendung die Daten in exakt der vom Absender vorgesehenen Form erhält. Zwar überwachen auch Dienste, die UDP einsetzen, die Kommunikationsvorgänge zwischen den Anwendungen, kümmern sich aber weder um die Reihenfolge, in der die Daten gesendet wurden, noch um die Aufrechterhaltung der Verbindung. Der UDP Header enthält keine Sequenznummer. UDP ist einfacher strukturiert und generiert weniger Overhead als TCP, wodurch die Datenübertragung schneller erfolgt. Daten können in einer anderen als in der Versandreihenfolge eintreffen, weil verschiedene Pakete unterschiedliche Wege' durch das Netzwerk nehmen können. Eine Anwendung, die UDP verwendet, muss diese Tatsache tolerieren können. 17

Packet Tracer Aktivität UDP und TCP Port Nummern Bei dieser Aktivität werfen wir einen Blick in das Innere von Paketen, um zu sehen, wie DNS und HTTP Port Nummern verwenden. Zur Durchführung der Aktivität verwenden Sie Packet Tracer und die Datei el 4162.pka, die sie von mir bekommen. 1.2 TCP: Zuverlässig kommunizieren Der wichtigste Unterschied zwischen TCP und UDP ist die Zuverlässigkeit. Die Zuverlässigkeit der TCP Kommunikation wird mithilfe verbindungsorientierter Sitzungen implementiert. Bevor ein Host Daten via TCP an einen anderen Host versendet, leitet die Transportschicht einen Prozess ein, der eine Verbindung mit dem Empfänger herstellt. Diese Verbindung ermöglicht das Überwachen einer Sitzung (d. h. eines Kommunikationsdatenstroms) zwischen den Hosts. Der Vorgang stellt sicher, dass jeder Host über den Kommunikationsvorgang Bescheid weiß und sich darauf vorbereiten kann. Ein vollständiger TCP Kommunikationsvorgang erfordert die Herstellung einer Sitzung zwischen Hosts in beiden Richtungen. Nach der Herstellung der Sitzung sendet der Empfänger für jedes erhaltene Segment eine Bestätigung an den Absender. Diese Bestätigungen bilden die Grundlage der Zuverlässigkeit einer TCP Sitzung. Wenn der Absender eine Bestätigung empfängt, weiß er, dass diese Daten erfolgreich übertragen wurden, und kann deren Überwachung beenden. Empfängt der Absender hingegen innerhalb einer bestimmten Zeitspanne keine Bestätigung, dann überträgt er die betreffenden Daten noch einmal an den Empfänger. Bestandteil des durch TCP generierten zusätzlichen Overheads sind die Netzwerkdaten, die durch Bestätigungen und Neuübertragungen entstehen. Die Herstellung von Sitzungen generiert einen zusätzlichen Overhead in Form der ausgetauschten Segmente. Dieser zusätzliche Overhead ist Folge der Überwachung von Bestätigungen und der Neuübertragung, die der Host durchführen muss, falls die Bestätigung ausbleibt. Die Zuverlässigkeit wird mithilfe von Feldern im TCP Header erzielt, die jeweils eine eigene Funktion haben. Diese Felder werden wir im weiteren Verlauf noch beschreiben. 1.2.2 TCP Serverprozesse Wie früher»funktionalität und Protokolle der Anwendungsschicht«, beschrieben, werden Anwendungsprozesse auf Servern ausgeführt. Diese Prozesse warten, bis ein Client einen Kommunikationsvorgang einleitet, indem er Daten oder andere Dienste anfordert. Für jeden Anwendungsprozess, der auf dem Server läuft, ist eine Portnummer konfiguriert. Dabei kommt entweder eine Default Nummer zum Einsatz, oder der Systemadministrator legt die Nummer manuell fest. Auf demselben Server kann dieselbe Port Nummer nicht zwei Transportschichtdiensten gleichzeitig zugewiesen sein. Ein Host, auf dem eine Webserver und eine Datenübertragungsanwendung ausgeführt werden, kann hierfür nicht denselben Port verwenden (z. B. den TCP Port 8080). Wenn einer aktiven Serveranwendung ein bestimmter Port zugewiesen wird, spricht man davon, dass der Port auf dem Server»geöffnet«wird. Das bedeutet, dass die Transportschicht Segmente, die an diesen Port gerichtet sind, akzeptiert und verarbeitet. Eingehende Clientanforderungen, die an den korrekten Socket gerichtet sind, werden entgegengenommen, und die Daten werden an die Serveranwendung weitergereicht. Auf einem Server können viele Ports gleichzeitig geöffnet sein je einer für jede aktive Serveranwendung. Dass Server mehrere Dienste gleichzeitig bereitstellen, beispielsweise einen Webserver und einen FTP Server, ist durchaus normal. Eine Möglichkeit, die Sicherheit auf einem Server zu erhöhen, besteht darin, den Serverzugriff auf diejenigen Ports bzw. die dazugehörigen Dienste und Anwendungen zu beschränken, auf die autorisierte Benutzer zugreifen können sollen. Abbildung 19.1 zeigt die typische Zuordnung von Absender und Empfän ger Ports bei TCP basierten Client/Server Operationen. 18

Abb. 19.1 TCP Verbindungsanforderungen von zwei Clients 1.2.3 TCP Verbindungen auf und abbauen Wenn zwei Hosts via TCP miteinander kommunizieren, wird eine Verbindung hergestellt, damit Daten ausgetauscht werden können. Nach Abschluss des Kommunikationsvorgangs werden die Sitzungen geschlossen, und die Verbindung wird abgebaut. Verbindungs und Sitzungsmechanismen sind Grundlage der Zuverlässigkeitsfunktion von TCP. 1.2.4 Der Drei Schritte Handshake Die Hosts überwachen jedes Datensegment in einer Sitzung und tauschen Informationen darüber aus, welche Daten von den jeweiligen Hosts empfangen werden. Hierzu kommen Daten aus dem TCP Header zum Einsatz. Jede Verbindung stellt zwei unidirektionale Kommunikationsdatenströme (Sitzungen) dar. Um die Verbindung herzustellen, führen die Hosts den so genannten Drei Schritte Handshake durch. Steuerbits im TCP Header geben Fortschritt und Status der Verbindung an. Der Drei Schritte Handshake führt die folgenden Funktionen aus: Er überprüft, ob das Empfängergerät im Netzwerk vorhanden ist. Er stellt sicher, dass auf dem Empfängergerät ein aktiver Dienst ausgeführt wird und dass das Gerät Anforderungen über die Ziel Port Nummer entgegennimmt, die der initiierende Client für die Sitzung verwenden will. Er setzt das Empfängergerät darüber in Kenntnis, dass der Absenderdienst die Absicht hat, eine Kommunikationssitzung aufzubauen. Bei TCP Verbindungen leitet der als Client fungierende Host die Sitzung mit dem Server ein. Der Vorgang der TCP Verbindungsherstellung läuft wie folgt ab: 1. Der einleitende Client sendet ein Segment, das einen ersten Sequenzwert enthält, der als Anforderung an den Server dient, eine Kommunikationssitzung einzuleiten. 2. Der Server antwortet mit einem Segment, das einem Bestätigungswert mit der empfangenen Sequenznummer plus 1 entspricht und seinen eigenen synchronisierenden Sequenzwert enthält. Der Bestätigungswert ist um 1 größer als die Sequenznummer, weil noch keine Daten enthalten sind, die bestätigt werden müssen. Dieser Bestätigungswert ermöglicht es dem Client, die Antwort dem ursprünglichen Segment zuzuordnen, das er an den Server geschickt hat. 3. Der einleitende Client antwortet mit einem Bestätigungswert, der dem empfangenen Sequenzwert plus 1 entspricht. Hierdurch wird der Vorgang der Verbindungsherstellung abgeschlossen. 19

Abbildung 16.2 zeigt die Schritte zur Herstellung einer TCP Verbindung. Abbildung 20.1 Schritte zur Herstellung einer TCP Verbindung Abbildung 20.2 Koventionelles Ablaufdiagramm (früher, heute Sequenzdiagramme, s. später UML) 20

Um den Drei Schritte Handshake zu verstehen, muss man die verschiedenen Werte der Felder kennen, die die bei den Hosts austauschen. Innerhalb des TCP Segment Headers enthalten die folgenden sechs 1 Bit Felder Steuerdaten, mit denen die TCP Prozesse gesteuert werden: URG (Urgent) ACK (Acknowledgement) SH (Push) RST (Reset) SYN (Synchronize) FIN (Finish) Diese Felder werden als Flags bezeichnet, weil der Wert jeweils nur durch ein Bit dargestellt wird, das heißt, es sind nur zwei Werte darstellbar: 1 und O. s. Microcontrollertechnik Wenn ein Bitwert gesetzt ist (1), gibt dies an, welche Steuerdaten im Segment enthalten sind. In den nächsten Abschnitten beschreiben wir die einzelnen Schritte des Drei Schritte Handshakes ausführlicher. Schritt 1: SYN Ein TCP Client leitet den Drei Schritte Handshake ein, indem er ein Segment mit gesetztem SYN Steuerflag setzt. Hierdurch zeigt er an, dass im Sequenznummernfeld im Header ein Ausgangswert enthalten ist. Dieser Ausgangswert für die Sequenznummer auch ISN (Initial Sequence Number) genannt wird zufällig ausgewählt, um die Überwachung des Datenflusses vom Client zum Server in dieser Sitzung zu verfolgen. Die ISN im Header wird im Verlauf des Kommunikationsvorgangs für jedes vom Client an den Server gesendete Datenbyte um den Wert 1 erhöht. Das SYN Steuerflag wird gesetzt, und die relative Sequenznummer ist 0. Schritt 2: SYN und ACK Der TCP Server muss den Empfang des SYN Segments vom Client bestätigen, um die Sitzung vom Client zum Server aufzubauen. Zu diesem Zweck sendet der Server ein Segment mit gesetztem ACK Flag zurück an den Client und gibt damit an, dass die Bestätigungsnummer gültig ist. Wenn dieses Flag im Segment gesetzt ist, betrachtet der Client dies als Bestätigung dafür, dass der Server das SYN Segment vom TCP Client empfangen hat. Der Wert des Bestätigungsnummernfeldes entspricht der Summe der Client ISN plus 1. Hierdurch wird nun eine Sitzung vom Client zum Server aufgebaut. Das ACK Flag bleibt für die Dauer der Sitzung gesetzt. Bei der Kommunikation zwischen Client und Server handelt es sich um zwei unidirektionale Sitzungen, nämlich einer vom Client zum Server und einer zweiten vom Server zum Client. In diesem zweiten Schritt des Drei Schritte Handshakes muss, der Server die Serverantwort an den Client richten. Um diese Sitzung zu starten, verwendet der Server das SYN Flag auf die gleiche Weise wie zuvor der Client. Das Flag wird also im Header gesetzt, um eine Sitzung vom Server zum Client einzurichten. Es gibt an, dass der Startwert des Sequenznummernfeldes im Header enthalten ist. Dieser Wert wird verwendet, um den Datenfluss in dieser Sitzung vom Server zurück zum Client nach zu verfolgen. Schritt 3: ACK Abschließend antwortet der TCP Client mit einem Segment mit gesetztem ACK Flag, welches die Antwort auf das vom Server gesendete SYN Segment darstellt. Dieses Segment enthält keine Benutzerdaten. Der Wert im Bestätigungsnummernfeld ist um 1 höher als die vom Server empfangene ISN. Nachdem beide Sitzungen zwischen Client und Server aufgebaut wurden, ist in allen weiteren in diesem Kommunikationsvorgang ausgetauschten Segmenten das ACK Flag gesetzt. 21

Wir können die Sicherheit im Datennetz wie folgt verbessern: Den Aufbau von TCP Sitzungen grundsätzlich ablehnen. Den Aufbau von Sitzungen auf bestimmte Dienste beschränken. Einen Datenaustausch nur im Zuge bereits hergestellter Sitzungen zulassen. Diese Sicherheitsmaßnahmen können Sie für ausgewählte oder alle TCP Sitzungen implementieren. 1.2.5 TCP Sitzung beenden Um eine Verbindung zu schließen, wird das FIN Flag im Segment Header gesetzt. Zur Beendigung jeder unidirektionalen TCP Sitzung wird jeweils ein Zwei Schritte Handshake verwendet, der ein FIN und ein ACK Segment umfasst. Aus diesem Grund müssen also zum Beenden eines von TCP unterstützten Kommunikationsvorgangs vier Segmente ausgetauscht werden: 1. Wenn der Client keine Daten mehr zum Senden hat, sendet er ein Segment mit gesetztem FIN Flag. 2. Der Server sendet ein ACK Flag, um den Empfang des FIN Flags zu bestätigen und so die Sitzung vom Client zum Server zu beenden. 3. Der Server sendet nun seinerseits ein FIN Segment an den Client, um die Sitzung vom Server zum Client zu beenden. 4. Der Client antwortet mit einem ACK Segment, um das FIN Segment des Servers zu bestätigen. Abbildung 22.1 zeigt die Schritte zur Beendigung einer TCP Verbindung. Abb. 22.1 Abbau einer TCP Verbindung: FIN und ACK Die Sitzung kann im Folgenden von jedem der beiden, Client oder Server eingeleitet werden. 22

Wenn am clientseitigen Ende der Sitzung keine Daten mehr zur Übertragung vorhanden sind, setzt der Client das FIN Flag im Header eines Segments. Danach sendet das serverseitige Ende der Verbindung ein normales Segment, das Daten mit gesetztem ACK Flag enthält; die enthaltene Bestätigungsnummer bescheinigt, dass alle Datenbytes empfangen wurden. Nach Bestätigung aller Segmente wird die Sitzung geschlossen. In der umgekehrten Richtung wird die Sitzung auf die gleiche Weise beendet. Der Server signalisiert, dass keine Daten mehr zu übertragen sind, indem er das FIN Flag im Header eines Segments setzt, das an den Absender geschickt wird. Die zurückerhaltene Bestätigung besagt, dass alle Datenbytes empfangen wurden und die Sitzung nun auch auf dieser Seite beendet wird. Es ist außerdem möglich, die Verbindung durch einen Drei Schritte Hand shake zu beenden. Hat der Client keine Daten mehr zu versenden, dann schickt er ein FIN Segment an den Server. Hat der Server ebenfalls keine Daten mehr zu versenden, dann kann er mit gesetzten FIN und ACK Flags antworten und diese beiden Schritte zu einem zusammenfassen. Der Client antwortet dann mit einem ACK Segment. Packet Tracer Aktivität TCP Sitzungen auf und abbauen Bei dieser Aktivität analysieren wir den Drei Schritte Handshake zur Herstellung einer TCP Sitzung und den TCP Vorgang beim Beenden der Sitzung. Viele Anwendungsprotokolle verwenden TCP. Durch die Veranschaulichung von Sitzungsauf und abbau mit Packet Tracer werden wir unsere Kenntnisse vertiefen. Zur Durchführung der Aktivität verwenden Sie Packet Die Datei el 4252.pka bekommen Sie von mir. 1.2.6 TCP Bestätigung mit Fenstertechnik (Windowing) Eine Funktion von TCP besteht darin, sicherzustellen, dass alle Segmente ihr Ziel erreichen. Die TCP Dienste auf dem Zielhost bestätigen den Empfang der eingegangenen Daten gegenüber der Absenderanwendung. Die Sequenz und Bestätigungsnummern im Segment Header werden gemeinsam verwendet, um den Empfang der in den Segmenten enthaltenen Datenbytes zu bestätigen. Die Sequenznummer gibt die relative Anzahl der Bytes, die in dieser Sitzung bereits übertragen wurden, einschließlich der Bytes im aktuellen Segment an. TCP verwendet die Bestätigungsnummer in Segmenten, die an den Absender zurückgeschickt werden, um das nächste vom Empfänger erwartete Byte in dieser Sitzung anzugeben. Dieser Ansatz wird als Erwartungsbestätigung bezeichnet. Der Absender wird darüber informiert, dass der Empfänger alle Bytes in diesem Datenstrom bis zu dem Byte vor dem mit der Bestätigungsnummer bezeichneten erhalten hat. Der sendende Host soll dann ein Segment schicken, das eine Sequenznummer enthält, die gleich der Bestätigungsnummer ist. Vergessen Sie nicht, dass es sich bei jeder Verbindung eigentlich um zwei unidirektionale Sitzungen handelt. Sequenz und Bestätigungsnummern werden in beiden Richtungen ausgetauscht. In Abbildung 24.1 sendet der Host auf der linken Seite Daten an den Host zur Rechten. Er sendet ein Segment mit zehn Datenbytes für diese Sitzung sowie der Sequenznummer 1 im Header. Host B empfängt das Segment in Schicht 4 und stellt fest, dass die Sequenznummer 1 lautet und dass zehn Datenbytes enthalten sind. Danach schickt Host B ein Segment zurück an Host A, um den Empfang dieser Daten zu bestätigen. In diesem Segment setzt der Host die Bestätigungsnummer auf 11, um anzugeben, dass das nächste erwartete Datenbyte in dieser Sitzung die Bytenummer 11 aufweist. 23

Abb. 24.1 Bestätigung von TCP Segmenten Empfängt Host A diese Bestätigung, so kann er das nächste Segment mit Daten für diese Sitzung übermitteln. Dieses beginnt mit der Bytenummer 11. Betrachten Sie das Beispiel noch einmal. Wenn Host A auf die Empfangsbestätigungen aller 10 Byte Gruppen warten müsste, entstünde im Netzwerk eine Menge Overhead. Um den Overhead durch diese Bestätigungen zu verringern, können mehrere Datensegmente gesendet werden, deren Bestätigung dann mit nur einer TCP Nachricht erfolgt. Diese Bestätigung enthält eine Bestätigungsnummer, die auf der Gesamtzahl der in der Sitzung empfangenen Segmente basiert. Wenn man beispielsweise bei der Sequenznummer 2000 beginnt und zehn Segmente mit je 1000 Bytes empfangen wurden, würde die Bestätigungsnummer 12001 an den Absender zurückgegeben. Die Anzahl der Daten, die ein Absender übertragen kann, bevor eine Bestätigung empfangen werden muss, heißt Fenstergröße. Die Fenstergröße ist ein Feld im TCP Header, das die erneute Übertragung verloren gegangener Daten und die Flusskontrolle ermöglicht. Das Prinzip des Fenstermechanismus ist eigentlich ganz einfach. Wenn man das Bild betrachtet, ergibt sich folgende Sachverhalt: Die Fenstergröße im Beispiel beträgt drei Bytes. Byte 1 wurde von der Datenquelle gesendet und vom Empfänger quittiert. Die Quelle hat die Bytes 2, 3 und 4 gesendet, sie wurden aber vom Empfänger noch nicht quittiert (Quittung eventuell noch unterwegs). Byte 5 wurde von der Quelle noch nicht gesendet. Er geht erst dann auf die Reise, wenn die Quittung für Byte 2 (oder höher) eingetroffen ist. 24

1.2.7 TCP Neuübertragung Egal, wie gut ein Netzwerk auch entworfen ist: Datenverluste treten immer auf. Aus diesem Grund stellt TCP Methoden zur Erkennung dieser Segmentverluste einschließlich eines Mechanismus, der Segmente mit unbestätigten Daten neu überträgt, zur Verfügung. Ein Zielhostdienst, der TCP verwendet, bestätigt Daten gewöhnlich nur für fortlaufende Sequenzbytes. Fehlen ein oder mehrere Segmente, dann werden nur Daten in solchen Segmenten bestätigt, die den Datenstrom vervollständigen. Wenn beispielsweise Segmente mit den Sequenznummern 1500 bis 3000 sowie 3400 bis 3500 empfangen würden, lautete die Bestätigungsnummer 3001, weil die Segmente mit den Sequenznummern 3001 bis 3399 nicht empfangen wurden. Falls TCP auf dem Absenderhost nach einer gewissen Zeitspanne keine Bestätigung empfängt, werden die Daten beginnend bei der zuletzt empfangenen Bestätigungsnummer erneut gesendet. Die Neuübertragung ist nicht in RFC 793 spezifiziert, sondern bleibt der jeweiligen TCP Implementierung überlassen. Bei einer typischen TCP Implementierung wird ein Host ein Segment übertragen, eine Kopie dieses Segments in eine Warteschlange für Neuübertragungen einreihen und einen Zeitgeber starten. Wird die Datenbestätigung empfangen, dann wird das Segment aus der Warteschlange entfernt; trifft die Bestätigung jedoch vor Ablauf des Zeitgebers nicht ein, dann wird das Segment erneut übertragen. Moderne Hosts unterstützen häufig auch eine optionale Eigenschaft namens Selektivbestätigung. Falls beide Hosts die Selektivbestätigung unterstützen, kann der Empfänger auch Bytes nicht fortlaufender Segmente bestätigen, und der Host muss nur die fehlenden Daten erneut übertragen. 1.2.8 Segmentverluste durch TCP minimieren TCP verfügt über eine Netzüberlastungssteuerung durch Flusskontrolle und dynamische Fenstergrößen. In den folgenden Abschnitten wird beschrieben, wie mithilfe dieser Methoden die Segmentverluste und damit auch der durch die Neuübertragung entstehende Overhead minimiert werden. Flusskontrolle Die Flusskontrolle unterstützt die Zuverlässigkeit der TCP Übertragung durch Einstellen einer effizienteren Datenrate zwischen den beiden an der Sitzung beteiligten Diensten. Sobald der Absender die Information erhält, dass die spezifizierte Datenmenge in Segmenten empfangen wurde, kann er weitere Daten dieser Sitzung senden. Das Fenstergrößenfeld im TCP Header gibt die Menge der Daten an, die übertragen werden dürfen, bevor eine Bestätigung empfangen werden muss. Die anfängliche Fenstergröße wird während des Sitzungsstarts über den Drei Schritte Handshake festgelegt. Der TCP Feedback Mechanismus stellt die optimale Datenübertragungsrate auf den maximal möglichen Wert ein, der von Netzwerk und Empfängergerät verlustfrei unterstützt wird. TCP versucht, die Übertragungsrate so zu steuern, dass alle Daten empfangen und möglichst wenige neu übertragen werden müssen. Abbildung 26.1 zeigt eine vereinfachte Darstellung der Fenstergröße und der Bestätigungen. In diesem Beispiel ist die anfängliche Fenstergröße für die dargestellte TCP Sitzung auf 3000 Byte festgelegt. Wenn der Absender also 3000 Byte übertragen hat, wartet er auf eine Bestätigung dieser Bytes, bevor er weitere Segmente dieser Sitzung überträgt. Sobald der Absender diese Bestätigung vom Empfänger erhalten hat, kann er weitere 3000 Byte senden. 25

Abb. 26.1 TCP Segment Bestätigung und Fenstergröße Während der Pause beim Empfang der Bestätigungen überträgt der Absender keine weiteren Segmente für diese Sitzung. Die hierdurch bewirkte Latenz kann sich erhöhen, wenn das Netzwerk oder die Ressourcen des empfangenden Hosts überlastet sind. Falls diese Latenz sehr groß wird, verringert sich die effektive Übertragungsrate der Daten für diese Sitzung. Hier durch kann der konkurrierende Zugriff auf Ressourcen eingeschränkt werden. Dynamische Fenstergrößen Eine andere Möglichkeit, den Datenfluss zu steuern, ist die Verwendung dynamischer Fenstergrößen. Sind die Netzwerkressourcen überlastet, kann TCP die Fenstergröße verringern, damit empfangene Segmente häufiger bestätigt werden. Hierdurch wird im Endeffekt die Übertragungsrate verringert, weil der Absender häufiger auf Bestätigungen warten muss. Der empfangende Host sendet den Fenstergrößenwert an den sendenden TCP Host und gibt dabei die Anzahl der Bytes an, auf deren Empfang der Zielhost im Zuge der Sitzung vorbereitet ist. Wenn der Empfänger die Datenrate aufgrund eines eingeschränkten Pufferspeichers verringern muss, kann er mit einer Bestätigung einen kleineren Fenstergrößenwert an den Absender übermitteln. Wie in Abbildung 26.1 gezeigt, kann ein empfangender Host, auf dem eine Überlastung auftritt, ein Segment mit einer geringeren Fenstergröße an den sendenden Host übergeben. Die Abbildung zeigt den Verlust eines Segments. Der Empfänger hat das Fenstergrößenfeld im TCP Header der zurückgegebenen Segmente in diesem Kommunikationsvorgang von 3000 auf 1500 heruntergesetzt. Aus diesem Grund hat der Absender die Fenstergröße entsprechend reduziert. Abb. 26.1 TCP Überlastung und Flusskontrolle 26

Treten nachfolgend wieder Übertragungsperioden ohne Datenverluste oder Ressourceneinschränkungen auf, erhöht der Empfänger den Wert im Fenstergrößenfeld nach und nach erneut. Hierdurch wird der Overhead im Netzwerk verringert, da weniger Bestätigungen gesendet werden müssen. Die Fenstergröße steigt dann weiter an, bis ein Datenverlust auftritt, woraufhin sie wieder verringert wird. Das dynamische Erhöhen und Verringern der Fenstergröße ist ein fortlaufender Prozess in TCP, um die optimale Fenstergröße für jede TCP Sitzung zu bestimmen. In sehr zuverlässigen Netzwerken können die Fenster ziemlich groß werden, weil keine Daten verloren gehen. In Netzwerken hingegen, in denen die zugrunde liegende Infrastruktur hochgradig beansprucht wird, bleibt die Fenstergröße eher gering. 1.3 UDP: Kommunikation mit niedrigem Overhead UDP ist ein einfaches Protokoll, das grundlegende Funktionen für die Transportschicht bereitstellt. Es generiert weitaus weniger Overhead als TCP, da es nicht verbindungsorientiert ist und keine fortgeschrittenen Mechanismen zur Neuübertragung, Sequenzierung und Flusskontrolle bietet. Die folgenden Abschnitte beschreiben, wie UDP sich in puncto niedriger Overhead und Zuverlässigkeit, Wiederzusammensetzung von Daten, Serverprozesse und anforderungen sowie Clientprozesse verhält. 1.3.1 UDP: Niedriger Overhead vs. Zuverlässigkeit Da UDP einen niedrigen Overhead generiert und keine Zuverlässigkeitsfunktionen wie etwa TCP bietet, sollte UDP nur mit Bedacht gewählt werden. Anwendungen, die UDP verwenden, sind allerdings nicht immer unzuverlässig. Vielmehr bedeutet die Verwendung von UDP lediglich, dass die Zuverlässigkeit nicht vom Transportschichtprotokoll gewährleistet wird und deswegen gegebenenfalls an anderer Stelle implementiert werden muss. Einige Anwendungen wie Online Spiele oder VoIP tolerieren den Verlust einiger Daten. Würden solche Anwendungen TCP verwenden, so könnten erhebliche Verzögerungen auftreten, sobald TCP einen Datenverlust bemerkt und die Daten neu überträgt. Solche Latenzen wären für diese Anwendungen jedoch nachteiliger als geringfügige Datenverluste. Einige Anwendungen wie etwa DNS wiederholen ihre Anforderung einfach, sofern sie keine Antwort erhalten, und benötigen TCP deswegen nicht, um die Nachrichtenzustellung zu garantieren. Der niedrige Overhead macht UDP für solche Anwendungen wünschenswert. 1.3.2 Wiederzusammensetzung von UDP Datagrammen Da UDP verbindungslos ist, werden anders als bei TCP keine Sitzungen eingerichtet, bevor eine Kommunikation erfolgt. UDP ist transaktionsbasiert, das heißt, wenn eine Anwendung Daten zu versenden hat, tut sie dies einfach. Viele Anwendungen, die UDP verwenden, schicken kleine Datenmengen, die in ein Segment passen. Andere Anwendungen hingegen senden größere Datenmengen, die auf mehrere Segmente verteilt werden müssen. Die UDP PDU heißt Datagramm, auch wenn die Termini Segment und Datagramm gelegentlich synonym verwendet werden, um eine Transportschicht PDU zu beschreiben. Falls mehrere Datagramme an einen Empfänger gesendet werden, können sie unterschiedliche Pfade nehmen und in der falschen Reihenfolge eintreffen (siehe Abbildung 28.1 ). UDP überwacht keine Sequenznummern, wie es TCP tut. Deswegen verfügt UDP über keine Möglichkeit, die Datagramme in ihre ursprüngliche Versandreihenfolge zu bringen, sondern hängt sie einfach in der Reihenfolge aneinander, in der sie empfangen wurden, und reicht sie dann an die Anwendung weiter. Sofern die Abfolge der Daten für die Anwendung wichtig ist, muss die Anwendung selbst die korrekte Datenreihenfolge ermitteln und bestimmen, wie diese verarbeitet wird. 27