computernetzwerke 5.auflage 978-3-8689-4185-2 …3.1 einführung und transportschichtdienste 229...

Computernetzwerke

Higher Education München • Harlow • Amsterdam • Madrid • Boston

San Francisco • Don Mills • Mexico City • Sydney

a part of Pearson plc worldwide

James F. KuroseKeith W. Ross

Computernetzwerke Der Top-Down-Ansatz

5., aktualisierte Auflage

Fachliche BetreuungMartin MauveBjörn Scheuermann

Bibliografische Information Der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht. Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht vollständig ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen.Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar.

Authorized translation from the English language edition, entitled COMPUTER NETWORKING: A TOP-DOWN APPROACH, 5th Edition by JAMES KUROSE; KEITH ROSS, published by Pearson Education, Inc, publishing as Addison-Wesley, Copyright © 2011 All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.GERMAN language edition published by PEARSON DEUTSCHLAND GMBH, Copyright © 2012.

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig.

Fast alle Hardware- und Softwarebezeichnungen und weitere Stichworte und sonstige Angaben, die in diesem Buch verwendet werden, sind als eingetragene Marken geschützt. Da es nicht möglich ist, in allen Fällen zeitnah zu ermitteln, ob ein Markenschutz besteht, wird das ®-Symbol in diesem Buch nicht verwendet.

10 9 8 7 6 5 4 3 2 1

13 12

ISBN 978-3-86894-185-2

© 2012 by Pearson Deutschland GmbHMartin-Kollar-Straße 10–12, D-81829 MünchenAlle Rechte vorbehaltenwww.pearson.deA part of Pearson plc worldwideProgrammleitung: Birger Peil, [email protected]Übersetzung: Dr. Gunnar Radons, Mannheim; [email protected]: Prof. Dr. Martin Mauve

Prof. Dr. Björn ScheuermannKorrektorat: Petra Kienle, FürstenfeldbruckEinbandgestaltung: Thomas Arlt, [email protected]: Monika Weiher, [email protected]: Kösel, KrugzellDruck und Verarbeitung: Drukarnia Dimograf, Bielsko-Biała

Printed in Poland

Transportschicht

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

3.1 Einführung und Transportschichtdienste . . . . . . . . . 227

3.2 Multiplexing und Demultiplexing . . . . . . . . . . . . . . . . 232

3.3 Verbindungslose Kommunikation: UDP . . . . . . . . . . . 239

3.4 Grundlagen des zuverlässigen Datentransfers . . . . 245

3.5 Verbindungsorientierter Transport: TCP . . . . . . . . . . 272

3.6 Grundlagen der Überlastkontrolle . . . . . . . . . . . . . . . . 301

3.7 TCP-Überlastkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

3

ÜB

ER

BL

IC

K

226

Transportschicht3

EINLEITUNGZwischen der Anwendungs- und der Netzwerkschicht gelegen, ist die Transport-schicht ein zentrales Element der geschichteten Netzwerkarchitektur. Sie hat die

zentrale Rolle, den Anwendungsprozessen auf verschiedenen Hosts Kommunikations-dienste zu erbringen. Der pädagogische Ansatz, den wir in diesem Kapitel benutzen,wechselt zwischen der Diskussion der theoretischen Grundlagen der Transportschichtund Diskussionen, wie diese Grundlagen in vorhandenen Protokollen implementiertsind. Wie üblich widmen wir den Internetprotokollen besondere Aufmerksamkeit, ins-besondere den Transportschichtprotokollen TCP und UDP.

Wir beginnen mit der Diskussion der Beziehung zwischen Transport- und Netzwerk-schicht. Dies bereitet den Boden, um die erste wichtige Funktion der Transportschichtzu untersuchen – die Erweiterung der Kommunikation zwischen zwei Endsystemen, wiesie die Netzwerkschicht anbietet, hin zur Kommunikation zwischen zwei auf diesenEndsystemen ablaufenden Anwendungsschichtprozessen. Wir werden diese Funktiondurch die Betrachtung des verbindungslosen Transportprotokolls UDP illustrieren.

Danach kehren wir zu den Grundlagen zurück und stellen uns einem der fundamen-talsten Probleme in Computernetzwerken: Wie können zwei Kommunikationsteilneh-mer sicher über ein Medium kommunizieren, das Daten verlieren oder verändernkann? Mittels immer komplizierteren (und realistischeren!) Szenarien erarbeiten wiruns eine Reihe von Techniken, die Transportprotokolle zur Lösung dieses Problemsanwenden. Wir zeigen danach, wo wir diese Grundlagen in TCP, dem verbindungs-orientierten Transportprotokoll des Internets, wiederfinden.

Anschließend wenden wir uns einem zweiten fundamental wichtigen Problem inNetzwerken zu – der Kontrolle der Übertragungsrate von Instanzen der Transport-schicht, um Überlast im Netzwerk zu vermeiden oder abzubauen. Wir erörtern dieUrsachen und Konsequenzen von Überlast sowie die gebräuchlichsten Techniken zuihrer Kontrolle. Nachdem wir so ein grundlegendes Verständnis der Themen gewon-nen haben, die hinter der Überlastkontrolle stecken, betrachten wir den vonTCP benutzten Ansatz.

»

«

3.1 Einführung und Transportschichtdienste

227

3.1 Einführung und TransportschichtdiensteIn den beiden vorangegangenen Kapiteln haben wir die Bedeutung der Transport-schicht und der von ihr angebotenen Dienste nur gestreift. Lassen Sie uns kurz wie-derholen, was wir bereits über die Transportschicht wissen.

Ein Transportschichtprotokoll ermöglicht die logische Kommunikation zwischenAnwendungen, die auf verschiedenen Hosts laufen. Mit logischer Kommunikationmeinen wir, dass es aus Sicht einer Anwendung erscheint, als wären die Hosts, aufdenen die Prozesse ablaufen, direkt miteinander verbunden. Tatsächlich können sichdie Hosts auf entgegengesetzten Seiten dieses Planeten befinden und durch zahlrei-che Router sowie ein breites Spektrum an verschiedenartigen Verbindungen mitein-ander verknüpft sein. Anwendungsprozesse benutzen die logische Kommunikationmittels der Transportschicht, um sich gegenseitig Nachrichten zuzusenden, ohne sichum Details der physikalischen Infrastruktur kümmern zu müssen, die diese Nachrichtenübertragen. Abbildung 3.1 illustriert den Begriff der logischen Kommunikation.

Wie in Abbildung 3.1 dargestellt, sind die Protokolle der Transportschicht in den End-systemen implementiert, aber nicht in Netzwerkroutern. Auf der Seite des Senders ver-packt die Transportschicht die Nachrichten, die sie von einer sendenden Anwendungempfängt, in Pakete der Transportschicht, die in der Internetterminologie als Segmenteder Transportschicht bezeichnet werden. Dies erfolgt (wenn nötig), indem die Nachrich-ten der Anwendungen in kleinere Stücke aufgeteilt werden. Anschließend wird jedemTeil von der Transportschicht ein Header hinzugefügt. Dadurch entsteht das Segment.Die Transportschicht reicht dieses Segment an die Netzwerkschicht des sendenden Sys-tems weiter. Dort wird das Segment in ein Datenpaket der Netzwerkschicht eingepackt(ein sogenanntes Datagramm) und an den Empfänger versandt. Wichtig zu erwähnenist, dass Netzwerkrouter im Datagramm nur auf die Felder der Netzwerkschicht reagie-ren, d.h., sie untersuchen nicht die Felder des im Datagramm eingekapselten Transport-schichtsegmentes. Auf Empfängerseite extrahiert die Netzwerkschicht das Segment derTransportschicht aus dem Datagramm und reicht das Segment an die Transportschichtweiter. Diese bearbeitet dann das eingegangene Segment und stellt die darin enthalte-nen Daten der empfangenden Anwendung zur Verfügung.

Netzwerkanwendungen können mehr als ein Transportschichtprotokoll einsetzen.Das Internet benutzt z.B. zwei Protokolle – TCP und UDP. Jedes dieser Protokollebietet den aufrufenden Anwendungen einen unterschiedlichen Satz von Transport-schichtdiensten.

3.1.1 Beziehung zwischen Transport- und Netzwerkschicht

Erinnern Sie sich daran, dass die Transportschicht im Protokollstapel direkt über derNetzwerkschicht liegt. Während die Transportschicht die logische Kommunikation zwi-schen Prozessen auf unterschiedlichen Hosts ermöglicht, bietet die Netzwerkschicht dielogische Kommunikation zwischen den Hosts. Der Unterschied mag gering sein, aber erist wichtig. Untersuchen wir ihn mithilfe einer Analogie aus dem täglichen Leben.

228

Transportschicht3

Stellen Sie sich zwei Häuser vor, eines an der Nordsee, das andere in den Alpen. Injedem Haus leben ein Dutzend Kinder. Die Kinder an der Nordsee sind Cousins derKinder, die in den Alpen leben. Die Kinder dieser beiden Haushalte lieben es, einan-der zu schreiben – jedes Kind schreibt jedem Cousin einmal in der Woche, wobeijeder Brief vom traditionellen Briefdienst der Post in einem eigenen Umschlag trans-portiert wird. Auf diese Weise sendet jeder Haushalt dem anderen in einer Woche144 Briefe (die Kinder könnten eine Unmenge Geld sparen, wenn sie E-Mail hätten!).In jedem Haushalt ist ein Kind für das Sammeln und Verteilen der Post zuständig –

Abbildung 3.1: Die Transportschicht realisiert logische, nicht physikalische Kommunikation zwischen Anwendungsprozessen

Nationaler oderglobaler ISP

Mobilfunknetz

Lokaler oderregionaler ISP

Firmennetzwerk

HeimnetzwerkLogischer Ende-zu-Ende-Transport

Netzwerk

Sicherung

Bitübertragung

Anwendung

Transport

Netzwerk

Sicherung

Bitübertragung

Anwendung

Transport

Netzwerk

Sicherung

BitübertragungNetzwerk

Sicherung

Bitübertragung

Netzwerk

Sicherung

Bitübertragung

Netzwerk

Sicherung

Bitübertragung

Netzwerk

Sicherung

Bitübertragung


229

Anna macht dies an der Nordsee und Bill in den Alpen. Jede Woche schaut Anna bei allihren Brüdern und Schwestern rein, sammelt die Post ein und übergibt sie einem Mit-arbeiter der Post, der die Häuser täglich besucht. Treffen Briefe im Haus an der Nordseeein, übernimmt Anna auch die Aufgabe, die Post an ihre Brüder und Schwestern zuverteilen. Bill erledigt die gleichen Arbeiten im anderen Haus.

In diesem Beispiel stellt der Postdienst die logische Kommunikation zwischen denbeiden Häusern dar – der Postdienst transportiert Briefe von Haus zu Haus, nicht vonPerson zu Person. Anna und Bill stellen dagegen die logische Kommunikation zwi-schen den Cousins her – Anna und Bill sammeln die Post von ihren Geschwistern einund liefern Post an ihre Geschwister aus. Aus Sicht der Cousins sind Anna und Billder Postdienst, obwohl Anna und Bill ja nur ein Teil (das letzte Glied) der Transport-kette bilden. Dieses Beispiel aus dem Haushalt ist eine nette Analogie, um die Bezie-hungen zwischen der Transportschicht und der Netzwerkschicht zu erklären:

Nachrichten der Anwendung Briefe in Umschlägen

Prozesse Cousins

Hosts (auch Endsysteme genannt) Häuser

Transportschichtprotokoll Anna und Bill

Netzwerkschichtprotokoll Postdienst (einschließlich des Zustellers)

Setzen wir diese Analogie fort, dann beachten Sie bitte, dass Anna und Bill ihre Auf-gaben nur in ihrem jeweiligen Haushalt durchführen. Die beiden sind keineswegs damitbefasst, die Post z.B. in einem Briefzentrum zu sortieren oder von einem Briefzentrumzu einem anderen zu fahren. In gleicher Weise sind Transportschichtprotokolle in denEndsystemen angesiedelt. In einem solchen Endsystem leitet das TransportprotokollNachrichten von den Anwendungsprozessen zum Rand des Netzwerkes (network edge,also an die Netzwerkschicht) weiter und umgekehrt. Das Transportprotokoll kann aberkeinerlei Aussage machen, wie die Nachrichten im Inneren des Netzwerkes (networkcore) übertragen werden. Wie Abbildung 3.1 zeigt, können die dazwischengeschaltetenRouter Informationen weder erkennen noch reagieren sie auf Informationen, welche dieTransportschicht an die Nachrichten der Anwendungen angehängt haben könnte.

Setzen wir unsere Familiensaga fort und nehmen nun für den Fall eines Urlaubs vonAnna und Bill an, dass ein anderes Paar von Cousins, nennen wir sie Susanne undHarvey, für sie einspringen und das haushaltsinterne Sammeln und Verteilen vonBriefen übernehmen. Unglücklicherweise für die beiden Familien führen Susanneund Harvey das Sammeln und Verteilen nicht in genau derselben Weise durch wieAnna und Bill. Da sie jünger sind, sammeln Susanne und Harvey die Briefe unregel-mäßiger und verlieren gelegentlich Briefe (die manchmal vom Familienhund gefressenwerden). Dadurch bietet das Paar Susanne-Harvey nicht dieselben Dienste an(genauer gesagt nicht dasselbe Dienstmodell) wie Anna und Bill. In gleicher Weisekann ein Computernetzwerk mehrere Transportprotokolle zur Verfügung stellen, dieden Anwendungen jeweils andere Dienstmodelle anbieten.

230

Transportschicht3

Der Umfang der Dienstleistungen, die Anna und Bill anbieten, wird klarerweise vonden Dienstleistungen eingeschränkt, die der Postdienst anbietet. Wenn dieser bei-spielsweise keine maximale Zeit sicherstellen kann, in der die Briefe von einem Hauszum anderen transportiert werden (z.B. drei Tage), dann können auch Anna und Billkeine maximale Verzögerungszeit für den Transport der Briefe zwischen den Cousinsgarantieren. Auf ähnliche Weise werden die Dienste eines Transportprotokolls oftvom Dienstmodell der darunterliegenden Netzwerkschicht eingeschränkt. Falls dasProtokoll der Netzwerkschicht keine Verzögerungs- oder Bandbreitengarantien für diezwischen den Hosts ausgetauschten Segmente geben kann, kann auch das Transport-schichtprotokoll den zwischen den Prozessen ausgetauschten Nachrichten weder Ver-zögerung noch Bandbreiten garantieren.

Allerdings können bestimmte Dienstleistungen auch dann vom Transportprotokollangeboten werden, wenn das darunterliegende Netzwerkprotokoll die entsprechen-den Dienstleistungen in der Netzwerkschicht nicht zur Verfügung stellt. Wie wir indiesem Kapitel sehen werden, kann z.B. ein Transportprotokoll einer Anwendungauch dann zuverlässige Datentransfers anbieten, wenn die zugrunde liegende Netz-werkschicht unzuverlässig ist, also selbst dann, wenn die Netzwerkschicht Daten-pakete verliert, durcheinanderwürfelt oder dupliziert. Als weiteres Beispiel (das wirin Kapitel 8 untersuchen, wenn wir die Sicherheit von Netzwerken diskutieren)könnte ein Transportprotokoll selbst dann mittels Datenverschlüsselung verhindern,dass Eindringlinge die Nachrichten lesen, wenn die Netzwerkschicht die Vertraulich-keit der Transportschichtsegmente nicht gewährleisten kann.

3.1.2 Überblick über die Transportschicht im Internet

Erinnern Sie sich bitte daran, dass das Internet, allgemeiner ein TCP/IP-Netzwerk, derAnwendungsschicht zwei verschiedene Transportschichtprotokolle anbietet. Einesdieser Protokolle ist UDP (User Datagram Protocol), das den aufrufenden Anwendun-gen einen unzuverlässigen, verbindungslosen Dienst zur Verfügung stellt. Das zweiteProtokoll ist TCP (Transmission Control Protocol), welches den aufrufenden Anwen-dungen einen zuverlässigen, verbindungsorientierten Dienst anbietet. Wenn Anwen-dungsentwickler eine Netzwerkanwendung entwerfen, müssen sie sich auf eines die-ser beiden Protokolle festlegen. Wie wir in den Abschnitten 2.7 und 2.8 gesehenhaben, wählt der Entwickler beim Erstellen der Sockets zwischen UDP und TCP aus.

Um die Terminologie zu vereinfachen, werden wir im Kontext des Internets dasDatenpaket der Transportschicht immer als Segment bezeichnen. Wir weisen aller-dings darauf hin, dass die Internetliteratur (beispielsweise die RFCs) die Transport-schichtpakete von TCP als Segmente, die Pakete von UDP dagegen als Datagrammbezeichnet. Dieselbe Internetliteratur benutzt den Begriff Datagramm auch für diePakete der Netzwerkschicht! In einer Einführung in Computernetzwerke, wie sie die-ses Buch darstellt, ist der Begriff Segment sowohl für TCP- als auch für UDP-Paketeweniger verwirrend und wir verwenden den Begriff Datagramm nur für Pakete derNetzwerkschicht.


231

Bevor wir mit unserer kurzen Einführung in UDP und TCP fortfahren, sind einigeWorte über die Netzwerkschicht des Internets nützlich. (Die Netzwerkschicht als sol-che wird in Kapitel 4 detailliert untersucht.) Das Netzwerkschichtprotokoll des Inter-nets hat einen eigenen Namen: IP für Internet Protocol. IP ermöglicht die logischeKommunikation zwischen Hosts. Das IP-Dienstmodell ist ein sogenannter Best-Effort-Dienst. Das bedeutet, IP tut „sein Bestes“, um die Segmente zwischen den kommu-nizierenden Hosts zu transportieren, aber es gibt keinerlei Garantien. Insbesonderegarantiert es nicht die Zustellung der Segmente, es garantiert nicht die geordnete Aus-lieferung der Segmente und es garantiert nicht die Integrität der Daten innerhalb derSegmente. Aus diesen Gründen wird IP als unzuverlässiger Dienst bezeichnet. Wirerwähnen an dieser Stelle auch, dass jeder Host mindestens eine Adresse der Netz-werkschicht besitzt, die sogenannte IP-Adresse. Wir werden die Adressierung in IP inKapitel 4 genauer untersuchen. In diesem Kapitel müssen wir nur im Hinterkopfbehalten, dass jeder Host eine IP-Adresse besitzt.

Nachdem wir einen kurzen Blick auf das IP-Dienstmodell geworfen haben, wollen wirjetzt die von UDP und TCP angebotenen Dienstmodelle zusammenfassen. Die wich-tigste Aufgabe von UDP und TCP ist das Erweitern des IP-Zustelldienstes zwischenzwei Endsystemen auf einen Zustelldienst zwischen zwei Prozessen, die auf den End-systemen laufen. Die Erweiterung der Host-zu-Host-Zustellung auf Prozess-zu-Prozess-Zustellung wird als Transportschicht-Multiplexing und -Demultiplexing bezeichnet.Wir werden das Transportschicht-Multiplexing und -Demultiplexing im nächstenAbschnitt diskutieren. UDP und TCP bieten auch Integritätsüberprüfungen, indem siein die Header der Segmente Felder für die Fehlererkennung einfügen. Diese beidenminimalen Transportschichtdienste – Prozess-zu-Prozess-Kommunikation und -Fehler-erkennung – sind die beiden einzigen Dienste, die UDP bietet! Insbesondere ist UDPwie IP ein unzuverlässiger Dienst – es garantiert nicht, dass von einem Prozess ver-schickte Daten intakt (oder überhaupt!) den Zielprozess erreichen. UDP wird imDetail in Abschnitt 3.3 erörtert.

TCP bietet den Anwendungen andererseits mehrere zusätzliche Dienste an. Zualler-erst realisiert es zuverlässigen Datentransfer. Mithilfe von Flusskontrolle, Sequenz-nummern, Acknowledgments und Timern (Techniken, die wir im Detail in diesemKapitel erkunden werden) stellt TCP sicher, dass die Daten vom sendenden Prozesskorrekt und in der richtigen Reihenfolge an den empfangenden Prozess geliefert wer-den. TCP wandelt auf diese Art den unzuverlässigen Dienst zwischen Endsystemen(der durch IP erbracht wird) in einen zuverlässigen Datentransportdienst zwischenProzessen um. TCP bietet auch Überlastkontrolle an. Überlastkontrolle ist wenigerein Dienst für eine aufrufende Anwendung, als vielmehr ein Dienst für das Internetals Ganzes, ein Dienst für das Allgemeinwohl. Salopp gesagt hindert die TCP-Über-lastkontrolle eine TCP-Verbindung daran, die Verbindungen und Router zwischenden kommunizierenden Hosts mit einem unverhältnismäßigen Verkehrsaufkommenzu überschwemmen. TCP ist bestrebt, jeder Verbindung, die einen überlasteten Linkdurchquert, einen gleich großen Anteil der Verbindungsbandbreite zuzuteilen. Dieserfolgt, indem die Rate, mit der die sendende Seite von TCP-Verbindungen Verkehr

232

Transportschicht3

ins Netz senden kann, reguliert wird. Der von UDP verursachte Verkehr ist im Gegen-satz dazu ungeregelt. Eine Anwendung, die auf UDP basiert, darf so lange und soschnell senden, wie sie will.

Ein Protokoll, das zuverlässigen Datentransfer und Überlastkontrolle bietet, ist not-wendigerweise komplex. Wir werden mehrere Abschnitte brauchen, um die Grund-lagen des zuverlässigen Datentransfers und der Überlastkontrolle zu erörtern. WeitereAbschnitte werden wir benötigen, um TCP selbst zu diskutieren. Diesen Themen sinddie Abschnitte 3.4 bis 3.8 gewidmet. Der diesem Kapitel zugrunde liegende didakti-sche Ansatz wechselt zwischen den Grundlagen und dem TCP-Protokoll ab. Zum Bei-spiel erörtern wir zuerst zuverlässigen Datentransfer in einem allgemeinen Kontextund diskutieren anschließend, wie TCP im Speziellen zuverlässigen Datentransferanbietet. Auf ähnliche Weise werden wir zuerst Überlastkontrolle allgemein betrach-ten und danach diskutieren, wie TCP sie konkret durchführt. Aber bevor wir uns die-sen Themen zuwenden, wollen wir zunächst das Transportschicht-Multiplexing und-Demultiplexing betrachten.

3.2 Multiplexing und DemultiplexingIn diesem Abschnitt erörtern wir Transportschicht-Multiplexing und -Demultiple-xing, also die Erweiterung des von der Netzwerkschicht angebotenen Host-zu-Host-Zustelldienstes zu einem Prozess-zu-Prozess-Zustelldienst für Anwendungen, die aufden Hosts laufen. Um die Diskussion konkret zu halten, erörtern wir diesen grundle-genden Transportschichtdienst im Kontext des Internets. Wir betonen jedoch, dass einMultiplexing/Demultiplexing-Dienst für alle Computernetzwerke erforderlich ist.

Am Zielhost erhält die Transportschicht Segmente von der direkt darunterliegendenNetzwerkschicht. Die Transportschicht hat die Aufgabe, die Daten in diesen Segmen-ten an die entsprechenden, im Host laufenden, Anwendungsprozesse zu liefern. Wer-fen wir einen Blick auf ein Beispiel. Nehmen Sie an, dass Sie vor Ihrem Computer sit-zen und Webseiten herunterladen, während Sie eine FTP-Sitzung und zwei Telnet-Sitzungen geöffnet haben. Sie lassen daher vier Anwendungsprozesse laufen – zweiTelnet-Prozesse, einen FTP-Prozess und einen HTTP-Prozess. Sobald die Transport-schicht in Ihrem Computer Daten von der darunterliegenden Netzwerkschicht erhält,muss sie die erhaltenen Daten zu einem dieser vier Prozesse lenken. Prüfen wir nun,wie dies geschieht.

Erinnern Sie sich zuerst an die Abschnitte 2.7 und 2.8. Dort haben Sie erfahren, dassein Prozess (als Teil einer Netzwerkanwendung) einen oder mehrere Sockets habenkann: Türen, durch die Daten vom Netzwerk zum Prozess und umgekehrt vom Pro-zess zum Netzwerk laufen. Wie in Abbildung 3.2 gezeigt, liefert die Transport-schicht im empfangenden Host die Daten nicht direkt an einen Prozess, sondern viel-mehr an einen dazwischenliegenden Socket. Weil es zu jedem beliebigen Zeitpunktmehr als einen Socket im empfangenden Host geben kann, hat jeder Socket eine ein-deutige Kennzeichnung. Das Format der Kennzeichnung hängt, wie wir in Kürze dis-kutieren werden, davon ab, ob der Socket ein UDP- oder ein TCP-Socket ist.

3.2 Multiplexing und Demultiplexing

233

Überlegen wir nun, wie ein empfangender Host ein eingehendes Transportschicht-segment an den entsprechenden Socket weiterleitet. Jedes Transportschichtsegmententhält zu diesem Zweck einen Satz von Feldern. Auf der Empfängerseite betrachtetdie Transportschicht diese Felder, um den empfangenden Socket zu identifizieren,und leitet dann das Segment an diesen Socket. Diese Aufgabe, das Abliefern derDaten am richtigen Socket durch die Transportschicht, wird Demultiplexing genannt.Die Aufgabe, Datenblöcke beim Quellhost von verschiedenen Sockets zu sammeln,jeden Block mit Header-Informationen zu verkapseln (die später beim Demultiplexingbenötigt werden), wodurch Segmente entstehen, und das Weiterleiten der Segmentean die Netzwerkschicht wird als Multiplexing bezeichnet. Beachten Sie, dass dieTransportschicht im mittleren Host in Abbildung 3.2 Segmente demultiplexen muss,die von der darunterliegenden Netzwerkschicht kommen, um sie einem der beidendarüber befindlichen Prozesse P1 oder P2 zukommen zu lassen. Das geschieht, indemdie ankommenden Datensegmente zu dem Socket des entsprechenden Prozessesgelenkt werden. Die Transportschicht im mittleren Host muss auch ausgehende Datenvon diesen Sockets einsammeln, Transportschichtsegmente formen und diese an diedarunterliegende Netzwerkschicht weitergeben. Obwohl wir Multiplexing und De-multiplexing im Kontext der Internet-Transportprotokolle eingeführt haben, mussman sich verdeutlichen, dass sie immer dann benötigt werden, wenn ein einzelnesProtokoll in einer Schicht (der Transportschicht oder einer anderen) von mehrerenProtokollen der nächsthöheren Schicht verwendet wird.

Um das Demultiplexing zu verdeutlichen, erinnern wir an die Analogie des Haushal-tes im vorherigen Abschnitt. Jedes der Kinder wird durch seinen Namen identifiziert.Wenn Bill einen Stapel Post vom Briefträger erhält, führt er die Operation des Demulti-plexing durch, indem er nachsieht, an wen die Briefe adressiert sind, und dann dieBriefe per Hand an seine Brüder und Schwestern ausliefert. Anna führt eine Multi-plex-Operation durch, indem sie Briefe bei ihren Brüdern und Schwestern abholt unddie gesammelte Post an den Briefträger weiterreicht.

Abbildung 3.2: Transportschicht-Multiplexing/Demultiplexing

Netzwerk

Legende:

Prozess Socket

Sicherung

Bitübertragung

Transport

Anwendung

Netzwerk

Anwendung

Sicherung

Bitübertragung

Transport

Netzwerk

Sicherung

Bitübertragung

Transport

P3 P2P1 P4 Anwendung

234

Transportschicht3

Nun, da wir die Rollen des Transportschicht-Multiplexing und -Demultiplexing ver-stehen, wollen wir überprüfen, wie dies in einem Host tatsächlich durchgeführt wird.Anhand der obigen Diskussion wissen wir, dass das Transportschicht-Multiplexing eserfordert, dass (1) der Socket eine eindeutige Kennzeichnung hat und (2) jedes Seg-ment spezielle Felder besitzt, welche den Socket festlegen, an den das Segment gelie-fert werden muss. Diese in Abbildung 3.3 gezeigten speziellen Felder sind das Port-nummerfeld der Quelle (source port number field) und das Portnummerfeld des Ziels(destination port number field). (Die UDP- und TCP-Segmente haben zudem nochandere Felder, die in den folgenden Abschnitten dieses Kapitels diskutiert werden.)Jede Portnummer ist eine 16 Bit-Zahl, die zwischen 0 und 65535 liegt. Die Port-nummern zwischen 0 und 1023 werden als wohlbekannte Portnummern (well-known port numbers) bezeichnet und sind festgelegt, d.h., sie sind für die Benutzungdurch weit verbreitete Anwendungsprotokolle reserviert, etwa HTTP (das Portnum-mer 80 benutzt) und FTP (das Portnummer 21 benutzt). Die wohlbekannten Port-nummern sind in RFC 1700 aufgelistet und werden unter http://www.iana.org aktu-alisiert [RFC 3232]. Wenn wir eine neue Anwendung entwickeln (wie die der inAbschnitt 2.7 oder 2.8 entwickelten Anwendungen), müssen wir der Anwendungeine Portnummer zuteilen.

Es sollte nun klar sein, wie die Transportschicht den Demultiplexing-Dienst durch-führen könnte: Jedem Socket im Host könnte eine Portnummer zugeteilt werden.Sobald ein Segment beim Host ankommt, prüft die Transportschicht die Zielportnum-mer im Segment und leitet das Segment zu dem entsprechenden Socket. Die Datendes Segmentes gehen dann durch den Socket in den dazugehörigen Prozess. Wie wirnoch sehen werden, beschreibt dies grundsätzlich die Arbeitsweise von UDP. Wirwerden aber auch erkennen, dass Multiplexing/Demultiplexing in TCP noch etwasverzwickter ist.

Verbindungsloses Multiplexing und Demultiplexing

Erinnern Sie sich aus Abschnitt 2.8 daran, dass ein in einem Host ausgeführtes Java-Programm durch die Zeile

DatagramSocket mySocket = new DatagramSocket();

Abbildung 3.3: Quell- und Zielportnummerfelder in einem Transportschichtsegment

Quellportnummer

32 bits

Zielportnummer

Andere Header-Felder

Anwendungsdaten(Nachricht)


235

einen UDP-Socket erzeugen kann. Wird ein UDP-Socket auf diese Weise geschaffen,teilt die Transportschicht dem Socket automatisch eine Portnummer zu. Insbesonderewählt die Transportschicht eine Portnummer aus dem Bereich 1024 bis 65535, diegegenwärtig nicht von irgendeinem anderen UDP-Port des Hosts verwendet wird.Alternativ könnte ein Java-Programm ein Socket mit folgender Zeile erzeugen:

DatagramSocket mySocket = new DatagramSocket(19157);

In diesem Fall legt die Anwendung einen bestimmten Port für das UDP-Socket fest –nämlich 19157. Wenn der Anwendungsentwickler, der den Code schreibt, die Server-Seite eines „wohlbekannten Protokolls“ entwickelt, dann müsste der Entwickler dieentsprechende wohlbekannte Portnummer zuteilen. Die Client-Seite der Anwendunglässt normalerweise zu, dass die Transportschicht die Portnummer automatisch (undtransparent) zuteilt, während die Server-Seite der Anwendung eine ganz bestimmtePortnummer festlegt.

Mit Portnummern, die UDP-Sockets zugeteilt sind, können wir jetzt UDP-Multiplexing/Demultiplexing genau beschreiben. Nehmen Sie einen Prozess auf Host A an, mit UDP-Port 19157, der einen Block Anwendungsdaten an einen Prozess mit UDP-Port 46428auf Host B senden will. Die Transportschicht des Hosts A erzeugt ein Transportschicht-segment, das die Anwendungsdaten, die Portnummer der Quelle (19157), die Portnum-mer des Ziels (46428) und zwei andere Werte enthält (die wir später kennenlernen wer-den; für die gegenwärtige Diskussion sind sie unwesentlich). Die Transportschichtreicht dann das entstehende Segment an die Netzwerkschicht weiter. Die Netzwerk-schicht kapselt das Segment in einem IP-Datagramm ein und unternimmt einen Best-effort-Versuch, das Segment beim empfangenden Host abzuliefern. Wenn das Segmentbeim empfangenden Host B ankommt, liest die Transportschicht des empfangendenHosts die Zielportnummer im Segment (46428) und liefert das Segment an den Socket,der durch Port 46428 identifiziert wird. Beachten Sie, dass auf Host B mehrere Prozesselaufen können, die jeweils ihren eigenen UDP-Socket mit zugehöriger Portnummerbesitzen. Wann immer UDP-Segmente aus dem Netz ankommen, leitet (demultiplext)Host B sie zum entsprechenden Socket, indem er die Zielportnummer des Segmentesverwendet.

Es ist wichtig anzumerken, dass ein UDP-Socket vollständig durch das Paar Ziel-IP-Adresse und Zielportnummer identifiziert wird. Daher werden zwei UDP-Segmente,die unterschiedliche Quell-IP-Adressen und/oder unterschiedliche Quellportnum-mern, aber dieselbe Ziel-IP-Adresse und Zielportnummer aufweisen, durch dasselbeZielsocket an denselben Zielprozess geleitet.

Sie fragen sich jetzt vielleicht, welchen Zweck die Portnummer der Quelle hat. Wie inAbbildung 3.4 dargestellt, dient die Portnummer der Quelle im Segment, das A an Bschickt, als Teil der „Rücksendeadresse“ – falls B ein Segment an A zurücksenden will,erhält dieses als Zielportnummer den Wert aus der Quellportnummer des ursprüngli-chen Segmentes. (Die vollständige Rücksendeadresse setzt sich aus der IP-Adresse vonA und der Quellportnummer zusammen.) Als Beispiel erinnern Sie sich an das UDP-

236

Transportschicht3

Server-Programm, das wir in Abschnitt 2.8 entwickelt haben. In UDPServer.java ver-wendet der Server eine Methode, um die Quellportnummer aus dem Segment auszu-lesen, das er vom Client erhält. Er sendet dem Client dann ein neues Segment zu, indem die extrahierte Quellportnummer als Zielportnummer des neuen Segmentes dient.

Verbindungsorientiertes Multiplexing und Demultiplexing

Um TCP-Demultiplexing zu verstehen, müssen wir einen genaueren Blick auf TCP-Sockets und den Aufbau von TCP-Verbindungen werfen. Einer der feinen Unterschiedezwischen einem TCP-Socket und einem UDP-Socket besteht darin, dass ein TCP-Socketdurch ein Viertupel identifiziert wird: Quell-IP-Adresse, Quellportnummer, Ziel-IP-Adresse, Zielportnummer. Wenn daher ein TCP-Segment aus dem Netz bei einem Hostankommt, nutzt der Host alle vier Werte, um das Segment zum richtigen Socket zu lei-ten (demultiplexen). Im Gegensatz zu UDP werden insbesondere zwei ankommendeTCP-Segmente mit unterschiedlicher Quell-IP-Adresse oder Quellportnummer an zweiverschiedene Sockets weitergeleitet (mit Ausnahme eines TCP-Segmentes, das dieursprüngliche Verbindungsaufbauanfrage enthält). Um noch mehr Einblick zu erhalten,erinnern wir uns an das TCP-Client-Server-Programmierbeispiel aus Abschnitt 2.7:

Die TCP-Server-Anwendung hat einen Eingangs-Socket, der auf Anfragen zum Ver-bindungsaufbau von TCP-Clients auf Portnummer 6789 wartet (Abbildung 2.31).

Der TCP-Client erzeugt ein Segment für den Verbindungsaufbau durch die ZeileSocket clientSocket = new Socket("serverHostName", 6789);

Eine Verbindungsaufbauanfrage ist nichts weiter als ein TCP-Segment mit derZielportnummer 6789 und einem speziellen Verbindungsaufbau-Bit, das im TCP-Header gesetzt ist (den wir in Abschnitt 3.5 erörtern werden). Das Segment ent-

Abbildung 3.4: Die Inversion von Quell- und Zielportnummern

Host A

Client-Prozess

SocketServer B

Quellport:19157

Zielport:46428

Quellport:46428

Zielport:19157


237

hält auch eine Quellportnummer, die vom Client gewählt wurde. Die obige Zeileerzeugt auch einen TCP-Socket für den Client-Prozess, durch den Daten in denund aus dem Client-Prozess gelangen können.

Sobald das Host-Betriebssystem des Computers, auf dem der Server-Prozess läuft,das ankommende Segment mit der Verbindungsaufbauanfrage für Zielportnummer6789 erhält, macht es den Server-Prozess auf Portnummer 6789 ausfindig, der aufeine Verbindung wartet. Der Server-Prozess erzeugt dann einen neuen Socketdurch die Zeile Socket connectionSocket = welcomeSocket.accept();.

Die Transportschicht auf dem Server merkt sich die folgenden vier Werte aus demVerbindungsaufbausegment: (1) die Quellportnummer, (2) die IP-Adresse des Quell-systems, (3) die Zielportnummer und (4) ihre eigene IP-Adresse. Der neu erzeugte Ver-

Port-Scanning

Wie wir gesehen haben, wartet ein Server-Prozess geduldig an einem offenenPort auf die Kontaktaufnahme durch einen entfernten Client. Einige Ports wer-den für wohlbekannte Anwendungen (z.B. FTP, DNS und SMTP-Server) reser-viert. Andere Ports werden üblicherweise von populären Anwendungen belegt(z.B. wartet der Microsoft 2000 SQL Server auf Requests auf dem UDP-Port 1434).Wenn wir daher feststellen können, dass ein Port auf einem Host geöffnet ist,sind wir in der Lage, von diesem Port Rückschlüsse auf bestimmte Anwendungenzu ziehen, die auf dem Host laufen. Das ist für Systemadministratoren sehr ange-nehm, wenn sie wissen möchten, welche Anwendungen auf den Hosts in ihremNetzwerk laufen. Aber auch Angreifer, die ein Netzwerk ausspionieren, wollenwissen, welche Ports auf einem Zielhost geöffnet sind. Wird ein Host entdeckt,auf dem eine Anwendung mit einem bekannten Sicherheitsproblem läuft, dannist dieser Host sturmreif (z.B. konnte bei einem SQL-Server, der auf Port 1434wartete, ein Pufferüberlauf stattfinden, wodurch ein entfernter Benutzer belie-bigen Code auf dem verwundbaren Host ausführen konnte – diese Sicherheits-lücke wurde vom Slammer-Wurm ausgenutzt [CERT 2003–04]).

Es ist relativ leicht festzustellen, welche Anwendungen auf welche Ports warten.Es gibt in der Tat zahlreiche Public Domain-Programme, sogenannte Port-Scan-ner, die genau das machen. Das vielleicht am weitesten verbreitete Programm istnmap, das unter http://insecure.org/nmap frei verfügbar und in den meistenLinux-Distributionen enthalten ist. Für TCP scannt nmap sequenziell die Portsund sucht nach Ports, die TCP-Verbindungen akzeptieren. Für UDP scannt nmapebenfalls nacheinander die Ports ab und sucht nach UDP-Ports, die auf übermit-telte UDP-Segmente warten. In beiden Fällen gibt nmap eine Liste der geöffne-ten, geschlossenen oder unerreichbaren Ports aus. Ein Host, auf dem nmap läuft,kann versuchen, jeden beliebigen Zielhost im gesamten Internet zu scannen. Wirwerden nmap in Abschnitt 3.5.6 bei der Verwaltung von TCP-Verbindungenerneut betrachten.

Fokus Sicherheit

http://insecure.org/nmap

238

Transportschicht3

bindungs-Socket wird durch diese vier Werte identifiziert. Alle später eintreffendenSegmente, deren Quellport, Quell-IP-Adresse, Zielport und Ziel-IP-Adresse mit die-sen vier Werten übereinstimmen, werden auf diesen Socket geleitet. Über die nunbestehende TCP-Verbindung können Client und Server Daten austauschen.

Der Serverhost kann gleichzeitig viele TCP-Sockets verwalten, wobei jeder Socketeinem Prozess zugeordnet ist und jeder durch sein eigenes Viertupel identifiziertwird. Wenn ein TCP-Segment beim Host ankommt, werden alle vier Felder (Quell-IP-Adresse, Quellport, Ziel-IP-Adresse, Zielport) verwendet, um das Segment zum ent-sprechenden Socket zu leiten (zu demultiplexen).

Dies zeigt auch Abbildung 3.5, in der Host C zwei HTTP-Sitzungen mit Server Baufbaut, während Host A eine HTTP-Sitzung mit B hat. Die Hosts A und C und derServer B haben jeweils ihre eigenen, eindeutigen IP-Adressen – A, C und B. Host Cweist seinen beiden HTTP-Verbindungen zwei verschiedene Quellportnummern zu(26145 und 7532). Weil Host A seine Quellportnummern unabhängig von C wählt,könnte er seiner HTTP-Verbindung auch den Quellport 26145 zuweisen. Das stelltkein Problem dar, denn Server B ist immer noch in der Lage, die beiden Verbindun-gen korrekt zu demultiplexen, weil sie zwar dieselbe Quellportnummer besitzen, aberdie beiden Verbindungen verschiedene Quell-IP-Adressen haben.

Abbildung 3.5: Zwei Clients, welche dieselbe Zielportnummer (80) benutzen, um mit denselben Server-Anwendungen zu kommunizieren

Quellport:7532

Zielport:80

Quell-IP:C

Ziel-IP:B

Quellport:26145

Zielport:80

Quell-IP:C

Ziel-IP:B

Quellport:26145

Zielport:80

Quell-IP:A

Ziel-IP:B

Ein HTTP-Prozesspro Verbindung

Transportschicht-Demultiplexing

Web- Server B

Web-ClientHost C

Web-ClientHost A

Legende:

Prozess Socket Demultiplexing

3.3 Verbindungslose Kommunikation: UDP

239

Webserver und TCP

Bevor wir diese Diskussion abschließen, sind einige zusätzliche Worte über Webser-ver und wie sie Portnummern verwenden lehrreich. Stellen Sie sich einen Host vor,auf dem ein Webserver, etwa ein Apache-Webserver, auf Port 80 läuft. Senden Clients(zum Beispiel Browser) Segmente an den Server, dann haben alle Segmente den Ziel-port 80. Insbesondere haben sowohl die anfänglichen Verbindungsaufbausegmente alsauch die Segmente, die HTTP-Request-Nachrichten enthalten, den Zielport 80. Wiewir gerade gesehen haben, unterscheidet der Server die Segmente der verschiedenenClients anhand der Quell-IP-Adressen und Quellportnummern.

Abbildung 3.5 stellt einen Webserver dar, der einen neuen Prozess für jede Verbin-dung erzeugt. Wie Abbildung 3.5 zeigt, hat jeder dieser Prozesse seinen eigenen Ver-bindungs-Socket, durch den die HTTP-Requests ankommen und die HTTP-Replysabgesandt werden. Wir wollen nicht unerwähnt lassen, dass nicht immer eine Einein-deutigkeit zwischen Verbindungs-Sockets und Prozessen besteht. Tatsächlich verwen-den heutige Hochleistungs-Webserver nur einen Prozess und erstellen für jede neueVerbindung zu einem Client einen neuen Thread. (Einen Thread kann man sich alsleichtgewichtigen Teilprozess vorstellen.) Wenn Sie die erste Programmieraufgabe inKapitel 2 bearbeitet haben, dann haben Sie einen Webserver erstellt, der genau dasmacht. Ein solcher Server kann zu jeder beliebigen Zeit viele Verbindungs-Socketshaben, die alle mit demselben Prozess verbunden sind.

Wenn Client und Server persistentes HTTP verwenden, dann tauschen Client undServer über denselben Server-Socket HTTP-Nachrichten aus, solange die persistenteVerbindung besteht. Verwenden jedoch Client und Server nichtpersistentes HTTP,dann wird für jedes Request/Response-Paar eine neue TCP-Verbindung geöffnet undgeschlossen. Gleichermaßen wird für jedes Request/Response-Paar ein Socket ge-öffnet und später geschlossen. Dieses häufige Erzeugen und Schließen von Socketskann die Leistung eines stark belasteten Webservers deutlich beeinflussen (obwohlBetriebssysteme eine Reihe von Tricks verwenden können, um mit diesem Problembesser umzugehen). Lesern, die sich für den Themenbereich Betriebssysteme und per-sistentes bzw. nichtpersistentes HTTP interessieren, empfehlen wir [Nielsen 1997;Nahum 2002].

Nun, da wir Transportschicht-Multiplexing und Demultiplexing erörtert haben, wollenwir mit einem der Transportprotokolle des Internets fortfahren, mit UDP. Im nächstenAbschnitt werden wir sehen, dass UDP der Netzwerkschicht kaum mehr hinzufügt alseinen Multiplexing/Demultiplexing-Dienst.

3.3 Verbindungslose Kommunikation: UDPIn diesem Abschnitt werfen wir einen genauen Blick auf UDP, was es bietet und wiees arbeitet. Wir möchten Sie dazu ermuntern, sich mit Abschnitt 2.1 zu befassen, dereinen Überblick über das UDP-Dienstmodell enthält, und mit Abschnitt 2.8, derSocket-Programmierung mithilfe von UDP diskutiert.

240

Transportschicht3

Um unserer Diskussion über UDP eine Motivation zu geben, nehmen Sie an, dass Siedaran interessiert sind, ein schlichtes, grundlegendes Transportprotokoll zu entwerfen.Wie könnten Sie das anpacken? Vielleicht ziehen Sie zuerst ein leeres Transportproto-koll in Betrachtung. Auf der sendenden Seite könnten Sie einfach die Nachrichten vomAnwendungsprozess annehmen und sie direkt an die Netzwerkschicht weiterreichen.Auf der Empfangsseite könnten Sie die in der Netzwerkschicht ankommenden Nach-richten annehmen und sie direkt an den Anwendungsprozess weiterleiten. Aber, wiewir im vorherigen Abschnitt gelernt haben, müssen wir schon etwas mehr tun als das!Die Transportschicht muss mindestens einen Multiplexing/Demultiplexing-Dienstanbieten, um Daten zwischen der Netzwerkschicht und dem richtigen Prozess derAnwendungsschicht auszutauschen.

UDP, definiert in [RFC 768], macht nur das, was ein Transportprotokoll unbedingt tunmuss. Abgesehen von der Multiplexing/Demultiplexing-Funktion und einer einfa-chen Fehlerprüfung fügt es IP nichts hinzu. Wählt ein Anwendungsentwickler UDPstatt TCP, dann kommuniziert die Anwendung in der Tat fast direkt mit IP. UDPnimmt Nachrichten vom Anwendungsprozess entgegen, fügt Quell- und Zielportnum-merfelder für den Multiplexing/Demultiplexing-Dienst ein, fügt zwei andere kleineFelder hinzu und leitet das entstehende Segment an die Netzwerkschicht weiter.Diese Netzwerkschicht verkapselt das Transportschichtsegment in ein IP-Datagrammund macht dann einen Best-effort-Versuch, das Segment an den empfangenden Hostauszuliefern. Sofern das Segment diesen erreicht, verwendet UDP die Zielportnum-mer, um die Daten des Segmentes an den richtigen Anwendungsprozess zu liefern.Beachten Sie, dass es bei UDP keinen Handshake zwischen sendenden und empfan-genden Instanzen der Transportschicht gibt, bevor das Segment gesendet wird. Ausdiesem Grund wird UDP als verbindungslos bezeichnet.

DNS ist ein Beispiel eines Anwendungsschichtprotokolls, das typischerweise UDP ver-wendet. Wenn die DNS-Anwendung in einem Host eine Anfrage stellen will, erzeugtsie eine DNS-Anfrage-Nachricht und reicht diese an UDP weiter. Ohne mit der auf demZielendsystem laufenden UDP-Instanz irgendein Handshake auszuführen, fügt UDP aufder Host-Seite Header-Felder an die Nachricht an und leitet das entstehende Segmentan die Netzwerkschicht weiter. Die Netzwerkschicht verkapselt das UDP-Segment inein Datagramm und sendet es an einen Name-Server. Die DNS-Anwendung auf demanfragenden Host wartet dann auf die Beantwortung der Anfrage. Erhält sie keine Ant-wort (vielleicht weil das zugrunde liegende Netz die Frage oder die Antwort verlorenhat), versucht sie entweder, die Frage an einen anderen Name-Server zu senden, odersie informiert die anfragende Anwendung, dass sie keine Antwort bekommt.

Sie fragen sich vielleicht, warum ein Anwendungsentwickler jemals UDP verwendensollte. Wäre TCP nicht immer vorzuziehen, da TCP doch einen zuverlässigen Daten-transferdienst erbringt? Die Antwort ist nein; viele Anwendungen eignen sich aus denfolgenden Gründen besser für UDP:

Bessere, in der Anwendungsschicht angesiedelte Kontrolle über die gesendetenDaten. Sobald ein Anwendungsprozess Daten an UDP weiterreicht, verpackt dieses


241

die Daten in einem UDP-Segment und reicht das Segment sofort an die Netzwerk-schicht weiter. TCP hat andererseits einen Überlastkontrollmechanismus, der dieTCP-Sender drosselt, sobald eine oder mehrere der zwischen Quelle und Zielhostliegenden Verbindungen überlastet ist. TCP sendet ein Segment auch immer wie-der, bis dessen Empfang am Zielort bestätigt worden ist, egal wie lange die zuver-lässige Übertragung dauert. Da Echtzeitanwendungen oft eine minimale Übertra-gungsrate erfordern, ihre Segmente nicht übermäßig verzögert sein sollten und sieeinen geringen Datenverlust verkraften können, passt das Dienstmodell von TCPnicht wirklich gut zu den Anforderungen dieser Anwendungen. Wie wir weiterunten besprechen werden, können diese Anwendungen UDP verwenden und im-plementieren, als Teil der Anwendung, jedwede zusätzliche Funktionalität, dieüber den von UDP gelieferten einfachen Segmentzustelldienst hinaus geht.

Kein Verbindungsaufbau. Wie wir später diskutieren werden, verwendet TCPeinen Drei-Wege-Handshake, bevor es mit der Datenübertragung beginnt. UDP legtohne formale Vorbereitungen einfach los. Auf diese Art führt UDP beim Herstelleneiner Verbindung nicht zu Verzögerungen. Das ist wahrscheinlich der Hauptgrund,warum DNS über UDP läuft, statt über TCP – DNS wäre viel langsamer, wenn esTCP benutzen würde. HTTP verwendet TCP statt UDP, da Zuverlässigkeit für Web-seiten mit Text entscheidend ist. Wie wir in Abschnitt 2.2 angesprochen hatten, istaber die durch TCP beim Verbindungsaufbau entstehende Verzögerung in HTTPein wesentlicher Teil der Verzögerungen, die beim Herunterladen von Webdoku-menten entstehen.

Kein Verbindungszustand. TCP merkt sich den Verbindungszustand in den Endsys-temen. Dieser Zustand beinhaltet Empfangs- und Sendepuffer, Überlastkontroll-parameter und Acknowledgment-Nummer. Wir werden in Abschnitt 3.5 sehen,dass diese Zustandsinformation benötigt wird, um den zuverlässigen Datentrans-ferdienst von TCP und seine Überlastkontrolle zu implementieren. UDP merkt sichdagegen keinen Verbindungsstatus und keinen dieser Parameter. Daher kann eineinzelner Server normalerweise viel mehr aktive Clients unterstützen, wenn dieAnwendung über UDP statt TCP läuft.

Geringe Header-Größe. TCP fügt 20 Byte zusätzliche Header-Information zu jedemSegment hinzu, während UDP mit nur 8 Byte auskommt.

Abbildung 3.6 listet populäre Internetanwendungen und die von ihnen benutztenTransportprotokolle auf. Wie zu erwarten, laufen E-Mail, Remote Login, das Web undauch der Dateitransfer mit FTP über TCP – all diese Anwendungen brauchen denzuverlässigen Datentransferdienst von TCP. Dennoch laufen viele wichtige Anwen-dungen über UDP statt über TCP. UDP wird für das Aktualisieren von RIP-Routing-Tabellen eingesetzt (Abschnitt 4.6.1). Da RIP-Aktualisierungen periodisch (normaler-weise alle fünf Minuten) gesandt werden, ersetzen neuere Updates ältere oder ver-lorene, wodurch diese veralteten Aktualisierungen nutzlos werden. UDP wird auchverwendet, um Daten für das Netzwerkmanagement zu übertragen (SNMP, sieheKapitel 9). UDP wird in diesem Fall oft gegenüber TCP bevorzugt, da Anwendungen

242

Transportschicht3

zum Netzwerkmanagement auch dann verlässlich funktionieren müssen, wenn dieLage im Netz angespannt ist – eben genau dann, wenn zuverlässiger Datentransfer mitÜberlastkontrolle nur schwierig durchzuführen ist. Außerdem, wie wir bereits frühererwähnt haben, läuft DNS über UDP, wodurch die von TCP verursachten Verzögerun-gen beim Verbindungsaufbau vermieden werden.

Wie Abbildung 3.6 zeigt, werden sowohl UDP als auch TCP heute von Multimedia-Anwendungen wie Internettelefonie, Echtzeitvideokonferenzen und Streaming vonAudio und Video verwendet. Wir werfen in Kapitel 7 einen genaueren Blick auf dieseAnwendungen. Hier erwähnen wir nur so viel, dass alle diese Anwendungen eingewisses Maß an Paketverlusten tolerieren können, so dass zuverlässiger Datentrans-fer für das Funktionieren der Anwendung nicht unbedingt notwendig ist. Weiterhinkönnen Echtzeitanwendungen wie Internettelefonie und Videokonferenzen nicht gutmit der Überlastkontrolle von TCP umgehen. Aus diesen Gründen entscheiden sichEntwickler von Multimedia-Anwendungen oft dafür, ihre Anwendungen über UDPstatt TCP auszuführen. Dennoch wird TCP in zunehmendem Maße für die Übertra-gung von Medieninhalten eingesetzt. So fand z.B. [Sripanidkulchai 2004] heraus,dass fast 75 % der On-Demand- und Live-Streams TCP einsetzen. Solange die Paket-verlustrate gering ist und gerade auch weil eine Reihe von Organisationen UDP-Ver-kehr aus Sicherheitsgründen blockieren (siehe Kapitel 8), wird TCP ein immer attrak-tiveres Protokoll für die Übertragung von Multimedia-Daten.

Obwohl heutzutage durchaus üblich, sind Multimedia-Anwendungen über UDPumstritten. Wie wir bereits erwähnt haben, hat UDP keine Überlastkontrolle. Diesewird aber gebraucht, um zu verhindern, dass das Netz in einen überlasteten Zustand

Anwendung Anwendungsschicht-protokoll

Zugrunde liegendes Transportprotokoll

E-Mail SMTP TCP

Remote Login Telnet TCP

Web HTTP TCP

Dateitransfer FTP TCP

Verteilte Dateisysteme NFS Normalerweise UDP

Multimedia-Streaming Normalerweise proprietär UDP oder TCP

Internettelefonie Normalerweise proprietär UDP oder TCP

Netzwerk-Management SNMP Normalerweise UDP

Routing-Protokoll RIP Normalerweise UDP

Namensauflösung DNS Normalerweise UDP

Abbildung 3.6: Populäre Internetanwendungen und ihre zugrunde liegenden Transportprotokolle


243

gerät, in dem nur wenig nützliche Arbeit möglich ist. Wenn alle Videoströme ohneirgendeine Art von Überlastkontrolle mit hoher Bitrate starten würden, würde anden Routern eine riesige Flut von Paketen eintreffen, so dass nur sehr wenige UDP-Pakete den Weg von Quelle zu Zielort erfolgreich durchqueren könnten. Außerdemwürden die hohen Verlustraten, welche die unkontrollierten UDP-Sender verursa-chen, dazu führen, dass die TCP-Sender (welche, wie wir sehen werden, ihre Sen-deraten im Fall von Überlast tatsächlich senken) ihre Raten dramatisch verringern.Auf diese Weise kann der Mangel an Überlastkontrolle in UDP zu hohen Verlust-raten zwischen UDP-Sender und -Empfänger führen und außerdem zu einem Ver-drängen von TCP-Sitzungen – ein möglicherweise ernstes Problem [Floyd 1999].Viele Forscher haben neue Mechanismen vorgeschlagen, um alle Quellen, ein-schließlich UDP-Quellen, zu einer adaptiven Überlastkontrolle zu zwingen [Mah-davi 1997; Floyd 2000; Kohler 2006; RFC 4340].

Vor der Diskussion der UDP-Segmentstruktur erwähnen wir, dass es einer Anwen-dung möglich ist, trotz Verwendung von UDP einen zuverlässigen Datentransferdurchzuführen. Das ist machbar, wenn die Zuverlässigkeitsmechanismen in dieAnwendung selbst eingebaut sind (zum Beispiel durch Hinzufügen von Bestätigungs-paketen und Mechanismen zum Wiederholen von Übertragungen, wie jene, die wirim nächsten Abschnitt untersuchen werden). Aber das ist keine triviale Aufgabe undsie wird einen Anwendungsentwickler viel Zeit für die Fehlersuche kosten. Dennochwürde das direkte Implementieren von Zuverlässigkeit in der Anwendung es dieserermöglichen, auf zwei Hochzeiten gleichzeitig zu tanzen: Die Anwendungsprozessekönnten zuverlässig miteinander kommunizieren, ohne den Beschränkungen derÜbertragungsrate unterworfen zu sein, die durch die Überlastkontrollmechanismenvon TCP erzwungen werden.

3.3.1 UDP-Segmentstruktur

Die in Abbildung 3.7 gezeigte UDP-Segmentstruktur wird in RFC 768 definiert. DieAnwendungsdaten füllen das Datenfeld des UDP-Segmentes. So enthält z.B. im Falleines DNS-Paketes das Datenfeld entweder eine Anfrage-Nachricht oder eine Ant-wort-Nachricht. Bei Anwendungen für Audioströme enthält das Datenfeld die Audio-daten. Der UDP-Header hat nur vier Felder, die jeweils aus zwei Byte bestehen. Wieim vorherigen Abschnitt besprochen, ermöglichen die Portnummern es dem Zielhost,die Anwendungsdaten an den richtigen Prozess weiterzuleiten (d.h., er kann dasDemultiplexing durchführen). Die Prüfsumme (Checksum) wird vom empfangendenHost dazu verwendet, die Segmente auf Fehler zu untersuchen. Tatsächlich werdenzusätzlich zum UDP-Segment auch einige Felder des IP-Headers in die Berechnungder Prüfsumme einbezogen. Wir ignorieren dieses Detail aber, um den Überblick nichtzu verlieren, und diskutieren die Prüfsummenberechnung unten. Grundprinzipiender Fehlererkennung werden in Abschnitt 5.2 beschrieben. Das Längenfeld enthältdie Länge des UDP-Segmentes einschließlich des Headers in Byte.

244

Transportschicht3

3.3.2 UDP-Prüfsumme

Die UDP-Prüfsumme ermöglicht eine Fehlererkennung. Die Prüfsumme wird also ver-wendet, um festzustellen, ob Bits innerhalb des UDP-Segmentes verändert wordensind, während sie sich von der Quelle zum Zielort bewegten (z.B. aufgrund von Stö-rungen in den Verbindungen oder während es in einem Router zwischengespeichertwurde). UDP auf der Absenderseite berechnet das 1er-Komplement der Summe aller16 Bit-Worte im Segment, wobei ein möglicher Übertrag beim Addieren in die nied-rigstwertige Stelle zurückübertragen wird. Dieses Ergebnis wird in das Prüfsummen-feld des UDP-Segmentes eingetragen. Wir zeigen hier ein einfaches Beispiel für diePrüfsummenberechnung. Details effektiver Implementierungen der in RFC 1071 defi-nierten Berechnung und ihrer Geschwindigkeit auf realen Daten sind in [Stone 1998;Stone 2000] zu finden.

Nehmen Sie z.B. an, dass uns die folgenden drei 16 Bit-Worte vorliegen:

011001100110000001010101010101011000111100001100

Die Binärsumme der ersten beiden dieser 16 Bit-Worte ist:

011001100110000001010101010101011011101110110101

Addieren des dritten Wortes zur obigen Summe führt zu:

10111011101101011000111100001100 0100101011000010

Beachten Sie, dass bei dieser letzten Addition ein Überlauf auftrat, der zurück ansrechte Ende übertragen wurde, deswegen lauten die letzten beiden Stellen des Ergeb-nisses 10 und nicht 01. Das 1er-Komplement entsteht, indem jede 0 in eine 1 umgewan-delt wird und umgekehrt. Das 1er-Komplement der Summe 0100101011000010 lautet

Abbildung 3.7: UDP-Segmentstruktur

Quellportnummer

32 Bit

Zielportnummer

Länge Prüfsumme

Anwendungsdaten(Nachricht)

3.4 Grundlagen des zuverlässigen Datentransfers

245

daher 1011010100111101, was als Prüfsumme verwendet wird. Beim Empfängerwerden alle vier 16 Bit-Worte, einschließlich der Prüfsumme, addiert. Haben sich keineFehler in das Paket eingeschlichen, dann lautet die Summe beim Empfänger1111111111111111. Ist ein Bit eine 0, dann wissen wir, dass bei der Übertragung Fehleraufgetreten sind.

Sie können sich fragen, warum UDP überhaupt eine Prüfsumme verwendet, wo doch soviele Sicherungsschichtprotokolle (einschließlich des weitverbreiteten Ethernet-Proto-kolls) ebenfalls eine Fehlerprüfung anbieten. Der Grund liegt darin, dass es keinerleiGarantie gibt, dass alle Leitungen zwischen Quelle und Zielort eine Fehlerprüfungdurchführen; das bedeutet, dass irgendeine der Leitungen ein Sicherungsschichtproto-koll verwenden kann, das keine Fehlerprüfung beinhaltet. Darüber hinaus können Feh-ler auch beim Speichern der Segmente im Router auftreten, also selbst dann, wenn dieSegmente korrekt über jede einzelne Leitung übertragen wurden. Da eine korrekte Über-tragung auf jeder einzelnen Leitung und eine Fehlererkennung im Speicher eines jedenRouters nicht garantiert werden kann, muss UDP die Fehlererkennung auf einer Ende-zu-Ende-Basis in der Transportschicht durchführen, sofern der Ende-zu-Ende-Über-tragungsdienst Fehlererkennung anbieten soll. Dies ist ein Beispiel für das berühmteEnde-zu-Ende-Prinzip des Systemdesigns [Saltzer 1984], welches besagt, dass bestimmteFunktionalität (in diesem Fall Fehlererkennung) auf einer Ende-zu-Ende-Basis durchge-führt werden muss: „In niedrigeren Schichten angesiedelte Funktionen können redun-dant oder von geringem Mehrwert im Verhältnis zu den Kosten sein, die ihre Gewähr-leistung auf einer höheren Schicht verursacht.“

Weil IP praktisch jedes beliebige Schicht-2-Protokoll nutzen können soll, ist eine Feh-lerprüfung in der Transportschicht als Sicherheitsmaßnahme sinnvoll. Obwohl UDPeine Fehlerprüfung durchführt, ist es außerstande, einen Fehler zu korrigieren. EinigeImplementierungen von UDP verwerfen das beschädigte Segment einfach; anderereichen es mit einer Warnung an die Anwendung weiter.

Das beendet unsere Diskussion von UDP. Wir werden bald sehen, dass TCP seinenAnwendungen zuverlässigen Datentransfer garantiert, sowie einige andere Dienste,die UDP nicht bietet. Natürlich ist TCP auch komplexer als UDP. Bevor wir jedochTCP diskutieren, sollten wir uns zurücklehnen und zuerst die zugrunde liegendenPrinzipien des zuverlässigen Datentransfers erörtern.

3.4 Grundlagen des zuverlässigen DatentransfersIn diesem Abschnitt erörtern wir das Problem des zuverlässigen Datentransfers imAllgemeinen. Dies ist sinnvoll, weil uns das Implementieren eines zuverlässigenDatentransfers nicht nur in der Transportschicht, sondern auch noch in der Siche-rungsschicht und der Anwendungsschicht begegnen wird. Das allgemeine Problem istdaher von zentraler Bedeutung für die Arbeit in Netzwerken. Müsste jemand eineListe der zehn wichtigsten Netzwerkprobleme verfassen, wäre dies sicher ein Kandi-dat für die Spitzenposition. Im nächsten Abschnitt werden wir TCP untersuchen und

246

Transportschicht3

insbesondere zeigen, dass in TCP viele der hier beschriebenen Grundlagen zurAnwendung kommen.

Abbildung 3.8 illustriert den Rahmen unserer Untersuchung eines zuverlässigenDatentransfers. Der abstrakte Dienst, der den Instanzen der höheren Schichten zur Ver-fügung gestellt wird, entspricht einem zuverlässigen Kanal zur Übertragung von Daten.Auf einem zuverlässigen Kanal werden die übertragenen Bits nicht verändert (siekönnen also nicht von 0 auf 1 bzw. von 1 auf 0 springen), sie können nicht verlorengehen und werden alle in der Reihenfolge zugestellt, in der sie abgesandt wurden. Dasist genau das Dienstmodell, das TCP den aufrufenden Internetanwendungen bietet.

Es liegt in der Verantwortung eines zuverlässigen Datentransferprotokolls, diesen abs-trakten Dienst zu implementieren. Diese Aufgabe wird durch die Tatsache erschwert,dass die Schicht unterhalb des zuverlässigen Datentransferprotokolls unzuverlässigsein kann. So ist beispielsweise TCP ein zuverlässiges Datentransferprotokoll, das ober-halb der unzuverlässigen Ende-zu-Ende-Netzwerkschicht (IP) implementiert ist. All-gemein betrachtet könnte die Schicht zwischen den beiden zuverlässigen Endpunktender Kommunikation aus einer einzigen physikalischen Verbindung (wie im Fall einesDatentransferprotokolls auf der Sicherungsschicht) oder aus einem globalen Verbundvon Netzwerken wie dem Internet bestehen (wie im Fall eines Protokolls auf der Trans-portschicht). Für unsere Zwecke genügt es jedoch, diese tieferliegende Schicht als einenunzuverlässigen Punkt-zu-Punkt-Kanal aufzufassen.

In diesem Abschnitt werden wir immer detaillierter die sendenden und empfangen-den Seiten eines zuverlässigen Datentransferprotokolls entwickeln, wobei wir immerkomplexere Modelle des zugrunde liegenden Kanals betrachten. Abbildung 3.8 (b)zeigt die Schnittstellen unseres Datentransferprotokolls. Die sendende Seite desDatentransferprotokolls wird von oben durch einen Anruf an rdt_send() aktiviert.Mit diesem Aufruf wird ein Dienst angefordert, der die Daten zuverlässig an die emp-fangende Seite weiterleitet. (Hier bedeutet rdt zuverlässiger Datentransfer (reliabledata transfer) und _send deutet darauf hin, dass die sendende Seite von rdt aufgeru-fen wird. Der erste Schritt bei der Entwicklung jedes Protokolls liegt in der Wahl einesguten Namens!) Auf der empfangenden Seite wird rdt_rcv() aufgerufen, sobaldPakete bei der empfangenden Seite des Kanals ankommen. Will das rdt-ProtokollDaten an die darüberliegende Schicht weitergeben, ruft es deliver_data() auf. ImFolgenden benutzen wir den Begriff „Paket“ anstelle des in der Transportschicht übli-chen Begriffes „Segment“. Da die in diesem Abschnitt entwickelte Theorie ganz all-gemein auf Computernetzwerke anwendbar ist und nicht nur für das Internet gilt, istder generische Begriff „Paket“ besser geeignet.

Wir werden in diesem Abschnitt nur den Fall eines unidirektionalen Datentransfersberücksichtigen, also die Datenübertragung von der sendenden zur empfangendenSeite. Der Fall des verlässlichen bidirektionalen Datentransfers (also Vollduplex) isteigentlich nicht schwieriger, müsste aber äußerst weitschweifig erklärt werden.Obwohl wir nur unidirektionalen Datentransfer betrachten, dürfen wir nicht verges-sen, dass die sendende sowie die empfangende Seite unseres Protokolls trotzdemPakete in beide Richtungen übertragen müssen, was auch in Abbildung 3.8 skizziert


247

wird. Wir werden in Kürze sehen, dass zusätzlich zum Austausch von Paketen, indenen die zu übertragenden Daten enthalten sind, die sendenden und empfangendenSeiten von rdt Kontrollpakete austauschen müssen. Diese beiden Seiten von rdt sen-den die Pakete mittels eines Aufrufes von udt_send() zur anderen Seite (wobei udtfür unzuverlässigen Datentransfer (unreliable data transfer) steht).

3.4.1 Aufbau eines zuverlässigen Datentransferprotokolls

Wir gehen nun eine Reihe von immer komplexer werdenden Protokollen durch, mitdem Ziel eines einwandfreien und zuverlässigen Datentransferprotokolls.

Zuverlässiger Datentransfer über einen perfekt zuverlässigen Kanal: rdt1.0

Wir gehen zunächst vom einfachsten Fall aus, in dem der zugrunde liegende Kanalvollkommen zuverlässig ist. Das Protokoll, das wir rdt1.0 nennen, ist daher trivial.Die Definitionen der endlichen Automaten (finite state machine, FSM) für den Sen-der und Empfänger von rdt1.0 sind in Abbildung 3.9 dargestellt. Die FSM inAbbildung 3.9 (a) legt die Operationen des Senders fest, während die FSM inAbbildung 3.9 (b) die Operationen des Empfängers definiert. Zu beachten ist, dass esfür Sender und Empfänger voneinander unabhängige FSMs gibt. Sender- und Emp-fänger-FSM in Abbildung 3.9 besitzen jeweils nur einen Zustand. Die Pfeile in derBeschreibung der FSM zeigen den Übergang des Protokolls von einem in einen ande-

Abbildung 3.8: Verlässlicher Datentransfer: Dienstmodell und Dienstimplementierung

Zuverlässiger Kanal

Unzuverlässiger Kanal

rdt _ send()

udt _ send()

Sender-prozess

Empfänger-prozess

deliver _ data

Anwendungs-schicht

Transport-schicht

Angebotener Dienst

Netzwerk-schicht

Legende:

Daten Paket

Dienstimplementierung

ZuverlässigesTransportprotokoll

(Senderseite)

ZuverlässigesTransportprotokoll(Empfängerseite)

rdt _ rcv()

a b

248

Transportschicht3

ren Zustand. (Da jede FSM in Abbildung 3.9 nur einen Zustand besitzt, ist ein Über-gang von diesem einen Zustand auf sich selbst notwendig. In Kürze werden wir kom-pliziertere Zustandsdiagramme sehen.) Das Ereignis, das diesen Übergang hervorruft,ist oberhalb der horizontalen Linie zu sehen, die den Übergang kennzeichnet und dieAktionen, die nach Eintreten des Ereignisses ausgeführt werden, sind unterhalb die-ser horizontalen Linie dargestellt. Löst ein Ereignis keine Aktion aus, oder tritt keinEreignis ein und es wird trotzdem eine Aktion ausgeführt, benutzen wir das Symbol oberhalb beziehungsweise unterhalb dieser Linie, um explizit das Fehlen einerAktion oder eines Ereignisses zu kennzeichnen. Der Ausgangszustand der FSM wirddurch den gestrichelten Pfeil dargestellt. Die FSMs in Abbildung 3.9 können nureinen einzigen Zustand einnehmen. Die FSMs, denen wir in Kürze begegnen, könnenjedoch mehrere Zustände besitzen. Daher ist es wichtig, den Ausgangszustand jederFSM zu kennzeichnen.

Die sendende Seite von rdt akzeptiert einfach Daten der darüberliegenden Schichtmittels des Ereignisses rdt_send(data), erzeugt ein Paket, welches diese Daten ent-hält (mithilfe der Aktion make_pkt(data)) und sendet das Paket in den Kanal. In derPraxis würde das rdt_send(data)-Ereignis durch einen Funktionsaufruf (z.B. anrdt_send()) der Anwendung ausgelöst werden.

Auf der empfangenden Seite erhält rdt von dem darunterliegenden Kanal ein Paketdurch das Ereignis rdt_rcv(paket), es entfernt die Daten aus dem Paket (mithilfe derAktion extract(paket, data)) und reicht die Daten an die darüberliegende Schichtweiter (durch die Aktion deliver_data(data)). In der Praxis würde das Ereignisrdt_rcv(paket) von einem Funktionsaufruf des Protokolls der tieferliegendenSchicht ausgelöst.

Abbildung 3.9: rdt1.0 – ein Protokoll für einen zuverlässigen Kanal

Warten aufAufruf von

oben

rdt1.0-Sender

rdt _ send(data)

packet=make _ pkt(data)udt _ send(packet)


unten

rdt1.0-Empfänger

rdt _ rcv(packet)

extract(packet,data)deliver _ data(data)

a

b


249

In diesem einfachen Protokoll gibt es keinen Unterschied zwischen einer Datenein-heit und einem Paket. Darüber hinaus geht der komplette Paketfluss vom Sender zumEmpfänger. Da wir einen perfekt zuverlässigen Kanal annehmen, besteht keinerleiNotwendigkeit seitens des Empfängers, irgendeine Rückmeldung an den Sender zugeben, denn nichts kann schief gehen! Beachten Sie, dass wir auch vorausgesetzthaben, dass der Empfänger die Daten genauso schnell annehmen kann, wie sie derSender liefert. Daher besteht keine Notwendigkeit für den Empfänger, den Sender umeine langsamere Übertragung zu bitten.

Zuverlässiger Transfer über einen Kanal mit Bitfehlern: rdt2.0

In einem realistischeren Modell des zugrunde liegenden Kanals können die Bitsinnerhalb eines Paketes verändert worden sein. Solche Bitfehler treten üblicherweisein einer physikalischen Komponente des Netzwerkes auf, während ein Paket übertra-gen, weitergeleitet oder gepuffert wird. Wir gehen zunächst weiter davon aus, dassalle übertragenen Pakete in derselben Reihenfolge empfangen werden, in der siegesendet wurden (allerdings könnten ihre Bits verändert worden sein).

Bevor wir ein Protokoll für die zuverlässige Kommunikation über einen derartigenKanal entwickeln, lassen Sie uns erst darüber nachdenken, wie Menschen mit soeiner Situation umgehen. Stellen Sie sich vor, dass Sie selbst eine lange Nachrichtüber das Telefon diktieren. In einem typischen Szenario würde der Empfänger derNachricht nach jedem Satz, den er gehört, verstanden und gespeichert hat, mit „OK“antworten. Hört der Empfänger einen verstümmelten Satz, werden Sie gebeten, denSatz zu wiederholen. Dieses Nachrichten-Diktat-Modell benutzt sowohl positiveRückmeldungen („OK“) als auch negative Rückmeldungen („Bitte wiederholen Siedas“). Mit diesen Kontrollnachrichten kann der Empfänger dem Sender mitteilen, waser richtig verstanden hat und was fehlerhaft empfangen wurde und daher wiederholtwerden muss. Im Kontext eines Computernetzwerkes werden zuverlässige Daten-transferprotokolle auf der Basis solcher Rückmeldungen als ARQ-Protokolle (Auto-matic Repeat reQuest, automatische Wiederholungsanfrage) bezeichnet.

Grundsätzlich müssen ARQ-Protokolle drei zusätzliche Fähigkeiten beinhalten, umdie Anwesenheit von Bitfehlern behandeln zu können:

Fehlererkennung: Zuerst wird ein Mechanismus benötigt, der es dem Empfängerermöglicht, aufgetretene Bitfehler zu erkennen. Erinnern Sie sich an den vorange-gangenen Abschnitt und daran, dass UDP ein Prüfsummenfeld für genau diesenZweck benutzt. In Kapitel 5 werden wir Techniken zur Fehlererkennung und Feh-lerkorrektur detaillierter betrachten. Solche Techniken erlauben einem Empfängerdas Erkennen und manchmal auch das Korrigieren von Bitfehlern in Paketen. Zumjetzigen Zeitpunkt müssen wir nur wissen, dass diese Techniken die Übertragungzusätzlicher Bits (über die Bits der ursprünglich übertragenen Originaldaten hin-aus) vom Sender zum Empfänger erfordern. Diese Bits befinden sich im Feld derPaketprüfsumme des rdt2.0-Paketes.

250

Transportschicht3

Rückmeldung des Empfängers: Da Sender und Empfänger üblicherweise auf unter-schiedlichen Endsystemen laufen, die möglicherweise Tausende Kilometer vonein-ander entfernt sind, besteht die einzige Möglichkeit für den Sender, etwas über denZustand in der Welt des Empfängers zu erfahren (genau gesagt zu erfahren, ob einPaket korrekt angekommen ist), darin, dass der Empfänger auf jeden Fall eineRückmeldung an den Sender übermittelt. Die positiven (ACK – für ACKnowledg-ment) und negativen (NAK – für Negative AcKnowledgment) Rückmeldungen imNachrichten-Diktat-Szenario sind Beispiele einer solchen Rückantwort. Unserrdt2.0-Protokoll sendet analog dazu ACK- und NAK-Pakete vom Empfänger anden Sender zurück. Im Prinzip müssen diese Pakete nur ein Bit lang sein. Bei-spielsweise könnte der Wert 0 das NAK und der Wert 1 das ACK bedeuten.

Wiederholte Übertragung: Ein Paket, das beim Empfänger fehlerhaft ankommt,wird vom Sender erneut übertragen.

Abbildung 3.10 zeigt die FSM-Darstellung von rdt2.0, einem Datentransferprotokoll,das Fehlererkennung beherrscht und positive sowie negative Rückmeldungen gibt.Die sendende Seite von rdt2.0 besitzt zwei Zustände. Im linken Zustand wartetdas senderseitige Protokoll auf Daten, die von der oberen Schicht heruntergereicht wer-den. Sobald das Ereignis rdt_send(data) eintritt, erzeugt der Sender ein Paket (sndpkt),welches die zu übertragenden Daten sowie eine Paketprüfsumme enthält (z.B. die-jenige, die wir im Abschnitt 3.2 für den Fall eines UDP-Segmentes diskutiert haben)und schickt danach das Paket mittels der Operation udt_send(sndpkt) ab. Im rechtenZustand wartet das Senderprotokoll auf ein ACK- oder NAK-Paket vom Empfänger.Trifft ein ACK-Paket ein (die Notation rdt_rcv(rcvpkt) && isACK(rcvpkt) inAbbildung 3.10 entspricht diesem Ereignis), weiß der Sender, dass das zuletzt übertra-gene Paket korrekt angekommen ist. Daher kehrt das Protokoll in den Zustand zurück,in den es auf Daten von der oberen Schicht wartet. Trifft ein NAK ein, wiederholt dasProtokoll das zuletzt gesendete Paket und wartet wieder auf ein ACK oder NAK, wel-ches vom Empfänger als Antwort auf die erneute Datenübertragung zurückgesandtwird. Dabei ist es wichtig, dass der Sender keinerlei Daten von der oberen Schicht emp-fangen kann, solange er sich im Zustand des Wartens auf ACK oder NAK befindet. Dasbedeutet, das Ereignis rdt_send() kann nicht eintreten. Dieses Ereignis kann erst dannwieder auftreten, wenn der Sender ein ACK erhält und diesen Zustand verlässt. Daherüberträgt der Sender keine neuen Daten, bis er sicher ist, dass der Empfänger das aktu-elle Paket richtig erhalten hat. Aufgrund dieses Verhaltens werden Protokolle wierdt2.0 als Stop-and-Wait-Protokolle (Anhalten-und-Warten) bezeichnet.

Die Empfänger-FSM für rdt2.0 hat immer noch nur einen einzigen Zustand. Beider Ankunft eines Paketes antwortet der Empfänger entweder mit einem ACKoder einem NAK, je nachdem, ob das erhaltene Paket beschädigt war oder nicht. InAbbildung 3.10 entspricht die Notation rdt_rcv(rcvpkt) && corrupt(rcvpkt) demEreignis eines empfangenen Paketes, in dem Fehler gefunden wurden.

Unser Protokoll rdt2.0 erweckt zwar den Anschein, als ob es funktionieren würde,aber es hat einen fatalen Fehler. Wir haben noch nicht die Möglichkeit berücksichtigt,


251

dass die ACK- oder NAK-Pakete selbst fehlerhaft sein könnten! (Bevor Sie weiter-lesen, sollten Sie darüber nachdenken, wie dieses Problem gelöst werden könnte.)Unglücklicherweise ist unsere Nachlässigkeit nicht so harmlos, wie es scheint.Zunächst müssen wir auf jeden Fall Prüfsummenbits an ACK-/NAK-Pakete hinzufü-gen, um solche Fehler zu entdecken. Die schwierigere Frage ist aber, wie das Proto-koll sich von Fehlern in ACK- oder NAK-Paketen erholen sollte. Die Schwierigkeitbesteht darin, dass im Fall eines korrumpierten ACK oder NAK der Absender nichterfahren kann, ob der Empfänger den letzten Teil der gesendeten Daten richtig erhaltenhat.

Betrachten Sie folgende drei Möglichkeiten, wie Sie mit korrupten ACKs oder NAKsumgehen könnten:

Überlegen Sie zuerst, was ein Mensch im Nachrichten-Diktat-Szenario tun könnte.Wenn der Sprecher die Antworten „OK“ oder das „Bitte wiederholen Sie das“ desEmpfängers nicht versteht, würde der Sprecher wahrscheinlich rückfragen, „Was

Abbildung 3.10: rdt2.0 – ein Protokoll mit Behandlung von Bitfehlern


oben

rdt2.0-Sender

rdt2.0-Empfänger

rdt _ rcv(rcvpkt)&&corrupt(rcvpkt)

sndpkt=make _ pkt(NAK)udt _ send(sndpkt)

rdt _ rcv(rcvpkt)&&isNAK(rcvpkt)

udt _ send(sndpkt)

rdt _ rcv(rcvpkt)&&isACK(rcvpkt)

rdt _ send(data)

sndpkt=make _ pkt(data,checksum)udt _ send(sndpkt)

rdt _ rcv(rcvpkt)&&notcorrupt(rcvpkt)

extract(rcvpkt,data)deliver _ data(data)sndpkt=make _ pkt(ACK)udt _ send(sndpkt)


unten

Warten aufACK oder

NAK

a

b

252

Transportschicht3

sagten Sie?“ (und auf diese Weise unserem Protokoll ein neues Sender-zu-Empfän-ger-Paket hinzufügen). Der Sprecher würde dann die Antwort wiederholen. Aberwas, wenn die Rückfrage des Sprechers ebenfalls korrumpiert ist? Der Empfänger,der keine Ahnung hat, ob der wirre Satz Teil des Diktats war oder eine Bitte, dieletzte Antwort zu wiederholen, würde wahrscheinlich mit „Was sagten Sie?“ ant-worten. Natürlich könnte auch diese Antwort undeutlich sein. Wir bewegen unseindeutig auf einem schmalen Grat.

Die zweite Alternative besteht darin, so viele Prüfsummenbits hinzuzufügen, dassder Absender Bitfehler nicht nur wahrnimmt, sondern sie auch korrigieren kann.Dies löst das unmittelbare Problem für einen Kanal, der Pakete zwar verändern, sieaber nicht verlieren kann.

Ein dritter Ansatz besteht darin, dass der Sender einfach das gegenwärtige Daten-paket erneut abschickt, wenn er ein verfälschtes ACK- oder NAK-Paket erhält. Die-ser Ansatz fügt jedoch Paketduplikate in den Kanal vom Sender zum Empfängerein. Die grundlegende Schwierigkeit bei Paketduplikaten besteht darin, dass derEmpfänger ja nicht weiß, ob das zuletzt gesandte ACK oder NAK vom Absenderrichtig empfangen wurde. Auf diese Art kann der Empfänger a priori gar nicht wis-sen, ob ein ankommendes Paket neue Daten enthält oder die Wiederholung einerÜbertragung ist!

Abbildung 3.11: rdt2.1-Sender

Warten aufAufruf 0von oben

rdt _ rcv(rcvpkt)&&(corrupt(rcvpkt)||isNAK(rcvpkt))

udt _ send(sndpkt)

rdt _ rcv(rcvpkt)&&(corrupt(rcvpkt)||isNAK(rcvpkt))

udt _ send(sndpkt)

rdt _ rcv(rcvpkt)&&notcorrupt(rcvpkt)&&isACK(rcvpkt)

rdt _ rcv(rcvpkt)&&notcorrupt(rcvpkt)&&isACK(rcvpkt)

rdt _ send(data)

sndpkt=make _ pkt(0,data,checksum)udt _ send(sndpkt)

rdt _ send(data)


Warten aufACK oder

NAK 0

Warten aufACK oder

NAK 1



253

Eine einfache Lösung dieses neuen Problems (eine, die von fast allen heute existieren-den Datentransferprotokollen, einschließlich TCP, übernommen wurde) besteht darin,dem Datenpaket ein neues Feld hinzuzufügen und den Absender seine Datenpaketenummerieren zu lassen, indem er in dieses Feld eine fortlaufende Sequenznummer(sequence number) einträgt. Der Empfänger muss dann nur diese Zahl überprüfen, umzu bestimmen, ob das erhaltene Paket die Wiederholung einer früheren Übertragungist. Für den einfachen Fall eines Stop-and-Wait-Protokolls genügt sogar eine 1-Bit-Zahl, da sie dem Empfänger sagt, ob der Absender das zuvor gesendete Paket erneutsendet (dann ist die Sequenznummer des eingetroffenen Paketes identisch mit der deszuletzt erhaltenen Paketes) oder ob es sich um ein neues Paket handelt (die Sequenz-nummer ändert sich und wird in einer Modulo-2-Arithmetik hochgezählt). Da wirmomentan von einem Kanal ausgehen, der keine Pakete verliert, müssen ACK- undNAK-Pakete die Sequenznummer der Pakete, die sie gerade bestätigen, nicht mitangeben. Der Absender weiß, dass ein erhaltenes ACK- oder NAK-Paket (ob verfälschtoder nicht) als Antwort auf sein zuletzt gesendetes Datenpaket erzeugt wurde.

Abbildung 3.11 und Abbildung 3.12 zeigen die FSM-Beschreibung für rdt2.1,unsere korrigierte Version von rdt2.0. Die FSMs des rdt2.1-Senders und -Empfän-gers haben jetzt doppelt so viele Zustände wie zuvor, weil der Protokollzustand wie-dergeben muss, ob das gerade gesendete Paket (das vom Sender stammt) oder das(beim Empfänger) erwartete Paket die Sequenznummer 0 oder 1 haben sollte. Beach-ten Sie, dass die Aktionen in jenen Zuständen, in denen ein mit einer 0 gekennzeich-netes Paket versandt oder erwartet wird, die Spiegelbilder jener Aktionen sind, indenen ein mit 1 nummeriertes Paket versandt bzw. erwartet wird. Der einzige Unter-schied besteht in der Behandlung der Sequenznummern.

Abbildung 3.12: rdt2.1-Empfänger

rdt _ rcv(rcvpkt)&&notcorrupt(rcvpkt)&&has _ seq0(rcvpkt)

sndpkt=make _ pkt(ACK,checksum)udt _ send(sndpkt)


sndpkt=make _ pkt(NAK,checksum)udt _ send(sndpkt)

rdt _ rcv(rcvpkt) &&corrupt(rcvpkt)

sndpkt=make _ pkt(NAK,checksum)udt _ send(sndpkt)

sndpkt=make _ pkt(ACK,checksum)udt _ send(sndpkt)


extract(rcvpkt,data)deliver _ data(data)sndpkt=make _ pkt(ACK,checksum)udt _ send(sndpkt)

rdt _ rcv(rcvpkt)&&notcorrupt(rcvpkt) &&has _ seq0(rcvpkt)

extract(rcvpkt,data)deliver _ data(data)sndpkt=make _ pkt(ACK,checksum)udt _ send(sndpkt)

Wartenauf 0 von

unten

Wartenauf 1 von

untenrdt _ rcv(rcvpkt)&& notcorrupt(rcvpkt)&&has _ seq1(rcvpkt)

254

Transportschicht3

Das Protokoll rdt2.1 benutzt sowohl positive als auch negative Acknowledgments vomEmpfänger zum Sender. Trifft ein Paket außerhalb der Reihenfolge ein, sendet der Emp-fänger ein positives Acknowledgment für das davor erhaltene Paket. Wird ein korrum-piertes Paket empfangen, sendet der Empfänger ein negatives Acknowledgment. Wirerzielen dasselbe Ergebnis wie ein NAK, indem wir statt eines NAK, ein ACK für dasletzte richtig erhaltene Paket senden. Ein Absender, der zwei ACKs für dasselbe Paketerhält (das heißt, er erhält doppelte ACKs (duplicate ACKs)), weiß, dass der Empfängerdas Paket nicht richtig erhalten hat, das auf das zweimal bestätigte Paket folgte. UnserNAK-freies zuverlässiges Datenübertragungsprotokoll für einen Kanal mit Bitfehlern,rdt2.2, ist in Abbildung 3.13 und Abbildung 3.14 zu sehen. Eine kleine Änderungzwischen rtdt2.1 und rdt2.2 besteht darin, dass der Empfänger nun die Sequenznum-mer des Paketes, das durch die ACK-Nachricht bestätigt wird, angeben muss (indemdas Argument ACK,0 oder ACK,1 an make_pkt() in der Empfänger-FSM übergebenwird). Außerdem muss der Absender nun die Sequenznummer des von einer eingegan-genen ACK-Nachricht bestätigten Paketes überprüfen (dies erfolgt durch Übergabe derArgumente 0 oder 1 an isACK() in der Sender-FSM).

Zuverlässiger Datentransfer über einen verlustbehafteten Kanal mit Bitfehlern:rdt3.0

Nehmen Sie nun an, dass außer dem Verfälschen von Bits auch Pakete auf demzugrunde liegenden Kanal verloren gehen können – ein nicht ungewöhnliches Ereig-



rdt _ rcv(rcvpkt)&&(corrupt(rcvpkt)||isACK(rcvpkt,1))

udt _ send(sndpkt)


udt _ send(sndpkt)

rdt _ rcv(rcvpkt)&&notcorrupt(rcvpkt)&&isACK(rcvpkt,0)


rdt _ send(data)


rdt _ send(data)


Warten aufACK 0

Warten aufACK 1



255

nis in den heutigen Computernetzwerken (einschließlich des Internets). Zwei zusätz-liche Fragen müssen jetzt durch das Protokoll angegangen werden: Wie kann Paket-verlust entdeckt werden und was soll geschehen, wenn er eintritt? Das Berechnen vonPrüfsummen, Sequenznummern, ACK-Pakete und wiederholte Übertragungen – Tech-niken, die bereits in rdt2.2 entwickelt wurden – ermöglichen es uns, letztere Frageanzugehen. Für die erste Frage wird ein neuer Protokollmechanismus notwendig.

Es gibt viele mögliche Ansätze für den Umgang mit Paketverlusten (einige erkundenwir in den Übungen am Ende des Kapitels). Im Moment bürden wir dem Sender dieVerantwortung auf, Paketverluste zu entdecken und zu korrigieren. Nehmen Sie an,dass der Absender ein Datenpaket sendet, und entweder dieses Paket oder dessenACK durch den Empfänger geht verloren. Auf jeden Fall trifft beim Absender keineAntwort des Empfängers ein. Sofern der Absender bereit ist, so lange zu warten, dasser sicher sein kann, dass ein Paket verloren gegangen ist, kann er das Datenpaket ein-fach noch einmal übertragen. Sie sollten sich davon überzeugen, dass dieses Protokollwirklich funktioniert.

Aber wie lange muss der Sender warten, bis er sicher sein darf, dass etwas verlorengegangen ist? Klarerweise muss der Sender mindestens eine Rundlaufzeit zwischenAbsender und Empfänger warten (in der ja auch das Puffern in dazwischenliegendenRoutern steckt) plus der Zeitdauer, die das Paket für die Verarbeitung beim Empfängerbenötigt. In vielen Netzwerken ist es schon sehr schwierig, diese maximale Verzöge-rung auch nur abzuschätzen, geschweige denn, sie sicher zu kennen. Außerdem solltedas Protokoll idealerweise so schnell wie möglich den Paketverlust beheben. DieWorst-Case-Verzögerung abzuwarten, könnte bedeuten, dass bis zur Fehlerbehebungeine lange Wartezeit verstreicht. Der in der Praxis benutzte Ansatz besteht darin,

Abbildung 3.14: rdt2.2-Empfänger

Wartenauf 0 von

unten

rdt _ rcv(rcvpkt)&&(corrupt(rcvpkt)||has _ seq0(rcvpkt))

udt _ send(sndpkt)

rdt _ rcv(rcvpkt)&&(corrupt(rcvpkt)||has _ seq1(rcvpkt))

if(oncethru==1)udt _ send(sndpkt)


extract(rcvpkt,data)deliver _ data(data)sndpkt=make _ pkt(ACK,1,checksum)udt _ send(sndpkt)


extract(rcvpkt,data)deliver _ data(data)sndpkt=make _ pkt(ACK,0,checksum)udt _ send(sndpkt)oncethru=1oncethru=0

Wartenauf 1 von

unten

256

Transportschicht3

einen Zeitraum geschickt so festzulegen, dass Paketverlust wahrscheinlich ist, auchwenn er nicht sicher eingetreten ist. Wird innerhalb dieser Zeit kein ACK empfangen,wird das Paket nochmals übertragen. Beachten Sie, dass ein Paket, das eine besonderslange Verzögerung erfährt, auch erneut übertragen werden kann, obwohl weder dasDatenpaket noch sein ACK verloren gegangen sind. Dadurch besteht die Möglichkeitdoppelter Datenpakete auf dem Kanal zwischen Sender und Empfänger. Glücklicher-weise hat das rdt2.2-Protokoll bereits genügend Funktionalität (in Form von Sequenz-nummern), um mit doppelten Paketen umgehen zu können.

Aus Sicht des Absenders ist die Übertragungswiederholung ein Allheilmittel. DerSender weiß nicht, ob ein Datenpaket bzw. ein ACK verloren ging oder ob Datenpaketbzw. ACK nur übermäßig verzögert sind. In allen Fällen bleibt die daraus resultie-rende Handlung dieselbe: erneute Übertragung. Das Implementieren eines zeitbasier-ten Übertragungswiederholungsmechanismus erfordert einen Countdown-Timer, derden Absender benachrichtigen kann, nachdem eine bestimmte Zeit verstrichen ist.Der Absender muss daher in der Lage sein, (1) jedes Mal, wenn ein Paket (entwederzum ersten Mal oder als Wiederholung) verschickt wird, den Timer neu zu starten, (2)auf einen auslaufenden Timer zu reagieren (und die entsprechenden Maßnahmen zuergreifen) und (3) den Timer anzuhalten.

Abbildung 3.15 zeigt die Sender-FSM für rdt3.0, ein Protokoll, das zuverlässigDaten über einen Kanal überträgt, der Pakete verändern oder verlieren kann.




timeout

udt _ send(sndpkt)start _ timer

rdt _ rcv(rcvpkt)



stop _ timer


stop _ timer

timeout

udt _ send(sndpkt)start _ timer

rdt _ send(data)

sndpkt=make _ pkt(0,data,checksum)udt _ send(sndpkt)start _ timer

rdt _ send(data)

sndpkt=make _ pkt(1,data,checksum)udt _ send(sndpkt)start _ timer

Warten aufACK 0

Warten aufACK 1


rdt _ rcv(rcvpkt)


257

In den Übungsaufgaben werden Sie sich damit beschäftigen, die Empfänger-FSM fürrdt3.0 zu konstruieren. Abbildung 3.16 zeigt, wie das Protokoll verlustfrei bzw.ohne verzögerte Pakete abläuft und wie es mit dem Verlust von Datenpaketen fertigwird. In Abbildung 3.16 verläuft die Zeit von oben nach unten im Diagramm. Ein sol-ches Diagramm nennt man auch Zeit-Ablauf-Diagramm. Beachten Sie, dass der Emp-fangszeitpunkt eines Paketes notwendigerweise später liegen muss als der zugehörigeSendezeitpunkt, eine Folge der Übertragungs- und Ausbreitungsverzögerungen. Inden Abbildungen 3.16 (b)–(d) geben die senderseitigen Klammern die Zeitpunkte an,

Abbildung 3.16: Arbeitsweise von rdt3.0 (Alternierendes-Bit-Protokoll)

empfange pkt0sende ACK0



Sender Empfänger

Operation ohne Verlust

pkt0

ACK0

pkt1

pkt0

ACK1

ACK0

(Verlust) X

Verlorenes Paket



Verlorenes ACK

sende pkt0

empfange ACK0sende pkt1


sende pkt0


timeoutpkt1 erneut

senden



empfange pkt1(erkenneDuplikat)sende ACK1

sende pkt0



timeoutpkt1 erneut

senden


Zu früher Timeout


empfange ACK1tue nichts


empfange pkt 1(erkenne Duplikat)sende ACK1

Sender Empfänger EmpfängerSender

pkt0

ACK0

pkt1

ACK1

ACK1

ACK0

ACK1

ACK0

pkt1

pkt0

pkt0

pkt1

pkt1

pkt0ACK1

ACK0

X (Verlust)

pkt1


sende pkt0


timeoutpkt1 erneut

senden




Sender Empfänger

pkt0

ACK0

pkt1

pkt0

ACK1

ACK0

a b

c d

258

Transportschicht3

zu denen der Timer gesetzt wurde und später abläuft. Mehr Feinheiten dieses Proto-kolls werden Sie in den Übungen am Ende dieses Kapitels erkunden. Weil dieSequenznummern der Pakete immer zwischen 0 und 1 wechseln, wird das Protokollrdt3.0 manchmal als Alternierendes-Bit-Protokoll (alternating-bit protocol) bezeichnet.

Wir haben nun die Schlüsselelemente eines zuverlässigen Datentransferprotokollszusammengetragen. Prüfsummen, Sequenznummern, Timer sowie positive und nega-tive Acknowledgment-Pakete spielen jeweils eine entscheidende Rolle im Ablauf desProtokolls. Wir haben jetzt ein lauffähiges zuverlässiges Datentransferprotokoll!

3.4.2 Zuverlässige Datentransferprotokolle mit Pipelining

rdt3.0 ist zwar ein korrekt funktionierendes Protokoll, aber es ist unwahrscheinlich,dass irgendjemand mit seiner Leistung zufrieden wäre, insbesondere in den heutigenHochgeschwindigkeitsnetzen. Der Kern des Leistungsproblems von rdt3.0 liegtdarin, dass es ein Stop-and-Wait-Protokoll ist.

Um den Einfluss dieses Stop-and-Wait-Verfahrens auf die Leistung abzuschätzen,betrachten Sie den idealisierten Fall zweier Hosts, von denen einer an der amerikani-schen Westküste, der andere an der Ostküste steht, wie in Abbildung 3.17 gezeigt.Die bei einer Signalausbreitung mit Lichtgeschwindigkeit auftretende Rundlauf-Aus-breitungsverzögerung zwischen diesen beiden Endsystemen, die RTT, beträgt etwa30 Millisekunden. Nehmen Sie an, dass Sie durch einen Kanal verbunden sind, des-sen Übertragungsgeschwindigkeit R 1 Gbps (109 Bit pro Sekunde) beträgt. Bei einerPaketgröße L von 1.000 Byte ergibt sich

Abbildung 3.18 (a) zeigt, was bei unserem Stop-and-Wait-Protokoll geschieht:Überträgt der Sender das Paket ab dem Zeitpunkt t 0, dann tritt bei t L/R 8 Mikrosekunden das letzte Bit auf der Absenderseite in den Kanal ein. Das Paketreist dann in 15 ms quer durch das Land, wobei das letzte Bit zum Zeitpunkt

Abbildung 3.17: Stop-and-Wait im Vergleich zu Pipelining

DatenpaketeDatenpaket

ACK-Pakete

Ablauf bei Stop-and-Wait Ablauf bei Pipelininga b

trans 98000 Bits/Paket

8 Mikrosekunden/Paket10 Bits/s

Ld

R


259

t RTT/2 L/R 15,008 ms auf der Empfängerseite aus dem Kanal austritt. Der Ein-fachheit halber nehmen wir an, dass ACK-Pakete äußerst klein sind (so dass wir ihreÜbertragungszeit ignorieren können) und dass der Empfänger ein ACK sendet,sobald das letzte Bit eines Datenpaketes eingetroffen ist. Dann taucht das ACK zumZeitpunkt t RTT L/R 30,008 ms beim Empfänger auf. Zu diesem Zeitpunktkann der Sender die nächste Nachricht senden. Während der Gesamtdauer von30,008 ms hat der Sender also nur 0,008 ms lang Daten übertragen. Definieren wirdie Auslastung des Absenders (oder des Kanals) als den Bruchteil der Zeit, in derder Absender tatsächlich damit beschäftigt ist, Bits in den Kanal einzuspeisen, sozeigt die Analyse in Abbildung 3.18 (a), dass das Stop-and-Wait-Protokoll nur eineziemlich schwache Auslastung USender von

erreicht: Der Sender war nur während weniger als drei Hundertstel eines Prozents dergesamten Zeitspanne aktiv! Aus einem anderen Blickwinkel betrachtet hat der Senderwährend der 30,008 Millisekunden nur 1.000 Byte versendet, was einem effektivenDurchsatz von nur 267 Kbps entspricht – obwohl eine 1 Gbps-Leitung zur Verfügungsteht! Stellen Sie sich den unglücklichen Netzwerkadministrator vor, der gerade einkleines Vermögen für eine Gigabit-Leitung gezahlt hat und dann nur einen Durchsatzvon 267 Kbit pro Sekunde erreicht!

Dies ist ein deutliches Beispiel dafür, wie Netzprotokolle das Ausnutzen der zu-grunde liegenden Netzwerk-Hardware einschränken können. Zudem haben wir dieVerarbeitungszeiten von Prozessen in den niedrigeren Schichten von Sender undEmpfänger vernachlässigt, ebenso wie die Verarbeitungs- und die Warteschlangenver-zögerungen, die in den zwischen Sender und Empfänger liegenden Routern auftretenwürden. Das Berücksichtigen dieser Effekte würde die Verzögerung weiter vergrößernund die Leistung noch mehr verschlechtern.

Die Lösung für dieses spezielle Leistungsproblem ist einfach: Anstatt ein Stop-and-Wait-Verfahren zu benutzen, darf der Absender, wie in Abbildung 3.17 (b) gezeigt, meh-rere Pakete senden, ohne zwischenzeitlich auf eine Bestätigung warten zu müssen. WieAbbildung 3.18 (b) zeigt, wird die Auslastung des Senders praktisch verdreifacht, wenner drei Pakete absenden darf, bevor er auf Bestätigungen warten muss. Weil man sichdie vielen Pakete im Transit zwischen Sender und Empfänger wie das Befüllen einerPipeline vorstellen kann, wird diese Technik als Pipelining bezeichnet. Pipelining hatdie folgenden Konsequenzen für zuverlässige Datentransferprotokolle:

Der Wertebereich der Sequenznummern muss vergrößert werden, da jedes Paket imTransit (ohne die Übertragungswiederholungen zu berücksichtigen) eine eindeu-tige Sequenznummer haben muss und es mehrere unbestätigte Pakete im Transitgeben kann.

Sender- und Empfängerseite des Protokolls müssen unter Umständen mehr alsein Paket zwischenspeichern. Zumindest muss der Absender die Pakete puffern,

Sender/ 0,008

0,00027RTT / 30,008

L RU

L R

260

Transportschicht3

die gesendet, aber noch nicht bestätigt worden sind. Auch das Zwischenspei-chern korrekt empfangener Pakete beim Empfänger könnte, wie weiter untennoch diskutiert wird, notwendig werden.

Abbildung 3.18: Datenübertragung mit Stop-and-Wait sowie Pipelining

Erstes Bit des erstenPakets übertragen, t = 0

Letztes Bit des erstenPakets übertragen, t = L/R

Erstes Bit des ersten Pakets übertragen, t = 0

Letztes Bit des ersten Pakets übertragen, t = L/R

ACK trifft ein, sende nächstes Pakett = RTT+ L/R

Ablauf bei Stop-and-Wait

Sender Empfänger

RTTErstes Bit des ersten Pakets kommt an

Letztes Bit des ersten Pakets kommt an,sende ACK

Erstes Bit des ersten Pakets kommt an

Letztes Bit des ersten Pakets kommt an,sende ACK

ACK trifft ein, sende nächstes Pakett = RTT+ L/R

Ablauf bei Pipelining

Sender Empfänger

RTT

Letztes Bit des zweiten Pakets kommt an,sende ACK

Letztes Bit des dritten Pakets kommt an,sende ACK

a

b


261

Der Bereich der Sequenznummern und die Anforderungen an das Zwischenspei-chern hängen davon ab, wie ein Datentransferprotokoll auf verlorene, verfälschteund übermäßig verzögerte Pakete reagiert. Es gibt zwei grundlegende Möglichkeitenfür die Fehlerbehebung in Protokollen mit Pipelining: Go-Back-N (N-Schrittezurück) und Selective Repeat (Selektive Sendewiederholung).

3.4.3 Go-Back-N (GBN)

Bei einem Go-Back-N-Protokoll (GBN) darf der Sender mehrere Pakete senden (soferner welche hat), ohne auf eine Bestätigung zu warten. Er darf aber nicht mehr als einemaximal zulässige Zahl, N, von unbestätigten Paketen in der Pipeline haben. Wir wer-den das GBN-Protokoll in diesem Abschnitt detailliert beschreiben. Aber bevor Sieweiterlesen, möchten wir Sie dazu ermuntern, mit dem GBN-Applet (einem wirklichbeeindruckenden Applet!) zu spielen, das Sie auf der Website unseres Buches finden.

Abbildung 3.19 zeigt die Sichtweise des Senders auf den Sequenznummernbereichin einem GBN-Protokoll. Definieren wir base als die Sequenznummer des ältestenunbestätigten Paketes und nextseqnum als die kleinste ungenutzte Sequenznummer(also die Sequenznummer des nächsten zu sendenden Paketes), dann können wir inden Sequenznummern vier Bereiche erkennen. Sequenznummern im Intervall[0, base1] entsprechen Paketen, die schon gesendet und bestätigt worden sind. DasIntervall [base, nextseqnum1] umfasst Pakete, die zwar gesendet wurden, aber nochnicht bestätigt worden sind. Sequenznummern im Intervall [nextseqnum, baseN1]können für Pakete genutzt werden, die sofort abgesandt werden dürfen, sollten Datenvon der darüberliegenden Schicht eintreffen. Schließlich können Sequenznummerngrößer oder gleich baseN nicht benutzt werden, bis ein noch unbestätigtes, derzeit inder Pipeline befindliches Paket (genauer gesagt, das Paket mit der Sequenznummerbase) bestätigt wurde.

Wie Abbildung 3.19 deutlich macht, kann der Bereich der erlaubten Sequenznum-mern für gesendete, aber noch nicht bestätigte Pakete als Fenster der Größe N überdem Bereich der Sequenznummern betrachtet werden. Während das Protokollabläuft, schiebt sich dieses Fenster über den Bereich der Sequenznummern vorwärts.Deshalb wird N oft als Fenstergröße und das GBN-Protokoll selbst als ein Protokollmit Schiebefenster (sliding window protocol) bezeichnet. Sie fragen sich vielleicht,warum wir überhaupt die Anzahl von offenen, unbestätigten Paketen auf den Wertvon N begrenzen. Warum nicht eine unbegrenzte Anzahl solcher Pakete erlauben? Wir

Abbildung 3.19: Sequenznummern aus Sicht des Senders bei Go-Back-N

base nextseqnum

FenstergrößeN

Legende:

Bereitsbestätigt

Gesendet, nochnicht bestätigt

Nutzbar, nochnicht gesendet

Nicht benutzbar

262

Transportschicht3

werden in Abschnitt 3.5 sehen, dass ein Grund, eine solche Beschränkung für denSender festzulegen, die Flusskontrolle ist. Wir werden in Abschnitt 3.7, wenn wir dieTCP-Überlastkontrolle studieren, noch einen anderen Grund dafür kennenlernen.

In der Praxis wird die Sequenznummer eines Paketes in einem Feld fester Länge imPaket-Header übertragen. Ist k die Anzahl der Bits im Feld der Sequenznummerndes Paketes, dann ist der Bereich der Sequenznummern [0, 2k1]. Mit einem be-grenzten Bereich von Sequenznummern müssen alle arithmetischen Operationen,die Sequenznummern betreffen, modulo-2k ausgeführt werden. (Das heißt, den Raumder Sequenznummern kann man sich als Ring der Größe 2k denken, bei dem auf dieSequenznummer 2k1 wieder die Sequenznummer 0 folgt.) Erinnern Sie sich daran,dass rdt3.0 eine 1 Bit-Sequenznummer und einen Bereich von Sequenznummern von[0,1] hatte. Mehrere Übungsaufgaben am Ende dieses Kapitels untersuchen die Folgeneines begrenzten Bereiches von Sequenznummern. Wir werden in Abschnitt 3.5 sehen,dass TCP ein Sequenznummernfeld mit einer Größe von 32 Bit benutzt, wobei es Bytesim übertragenen Datenstrom statt Paketen nummeriert.

Abbildung 3.20 und Abbildung 3.21 geben erweiterte FSM-Beschreibungen derSender- und Empfängerseite eines ACK-basierten, NAK-freien GBN-Protokolls wie-der. Wir nennen diese FSM-Beschreibung erweiterte FSMs, weil wir Variablen fürbase und nextseqnum hinzugefügt haben (die den Variablen in Programmier-sprachen entsprechen), dazu auch Operationen auf diesen Variablen und bedingteAktionen, an denen diese Variablen beteiligt sind. Beachten Sie, dass die erweiterteFSM-Spezifikation gewisse Ähnlichkeiten mit Anweisungen in einer Programmier-

Abbildung 3.20: Erweiterte FSM-Beschreibung des GBN-Senders

rdt _ send(data)

if(nextseqnum<base+N){ sndpkt[nextseqnum]=make _ pkt(nextseqnum,data,checksum) udt _ send(sndpkt[nextseqnum]) if(base==nextseqnum) start _ timer nextseqnum++ }else refuse _ data(data)

rdt _ rcv(rcvpkt)&&notcorrupt(rcvpkt)

base=getacknum(rcvpkt)+1If(base==nextseqnum) stop _ timerelse


base=1nextseqnum=1

timeout

start _ timerudt _ send(sndpkt[base])udt _ send(sndpkt[base+1])...udt _ send(sndpkt[nextseqnum-1])

Warten


263

sprache aufweist. [Bochman 1984] liefert eine exzellente Übersicht über zusätzlicheErweiterungen von FSMs sowie weiterer programmiersprachenbasierter Methoden,um Protokolle zu spezifizieren.

Der GBN-Absender muss auf drei Arten von Ereignissen antworten:

Aufrufe von oben. Wird rdt_send() von höheren Schichten aufgerufen, prüft derSender zuerst, ob das Fenster voll ist, d.h., ob es N unbestätigte Pakete gibt. Ist dasFenster nicht voll, wird ein Paket erzeugt und verschickt und die Variablen werdenentsprechend aktualisiert. Ist das Fenster aber bereits gefüllt, gibt der Sender dieDaten einfach an die höher liegende Schicht zurück, wodurch implizit mitgeteiltwird, dass das Fenster voll ist. Die obere Schicht wird es dann später nochmalsversuchen müssen. In einer echten Implementierung wäre es wahrscheinlicher,dass der Sender die Daten entweder zwischenspeichert (aber nicht sofort sendet)oder einen Mechanismus für die Synchronisation besitzt (zum Beispiel einen Sig-nalgeber oder ein Flag), so dass die obere Schicht rdt_send() nur dann aufruft,wenn das Fenster nicht gefüllt ist.

Erhalt eines ACK. In unserem GBN-Protokoll wird eine Bestätigung für ein Paketmit Sequenznummer n als kumulative Bestätigung (cumulative acknowledgment)benutzt, mit der deutlich gemacht wird, dass alle Paketsequenznummern bis ein-schließlich n korrekt beim Empfänger angekommen sind. Wir werden in Kürze aufdieses Thema zurückkommen, wenn wir die Empfängerseite von GBN betrachten.

Ein Timeout-Ereignis. Das Protokoll namens „Go-Back-N“ wird vom Verhalten desSenders beim Auftreten verloren gegangener oder übermäßig verzögerter Paketeabgeleitet. Wie beim Stop-and-Wait-Protokoll wird wieder ein Timer verwendet,um verlorene Daten oder Acknowledgment-Pakete zu reparieren. Tritt ein Timeoutauf, sendet der Absender alle bereits zuvor abgesandten, aber noch nicht bestätig-ten Pakete erneut. Unser Sender in Abbildung 3.20 verwendet nur einen einzelnenTimer, den Sie sich als Timer für das älteste übertragene, aber bislang unbestätigte

Abbildung 3.21: Erweiterte FSM-Beschreibung des GBN-Empfängers

rdt _ rcv(rcvpkt) &&notcorrupt(rcvpkt) &&hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data)deliver _ data(data)sndpkt=make _ pkt(expectedseqnum,ACK,checksum)udt _ send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt=make _ pkt(0,ACK,checksum)

default

udt _ send(sndpkt)Warten

264

Transportschicht3

Paket vorstellen können. Wenn ein ACK empfangen wird, aber es immer nochübertragene, unbestätigte Pakete gibt, wird der Timer neu gestartet. Wenn es keineoffenen unbestätigten Pakete mehr gibt, dann wird der Timer gestoppt.

Der Empfänger in GBN ist ebenfalls einfach strukturiert. Wenn ein Paket mit Sequenz-nummer n korrekt empfangen wird und auch die Reihenfolge der Pakete stimmt (d.h.,die zuletzt an die obere Schicht gelieferten Daten kamen von einem Paket mit Sequenz-nummer n 1), dann sendet der Empfänger ein ACK für Paket n und gibt den Datenteildes Paketes an die obere Schicht weiter. In allen anderen Fällen verwirft der Empfängerdas Paket und sendet ein ACK für das zuletzt erhaltene und korrekte Paket. BeachtenSie, dass Pakete einzeln an die obere Schicht geliefert werden und daher alle Pakete miteiner Sequenznummer niedriger als k richtig ausgeliefert wurden, sofern Paket k emp-fangen und nach oben weitergegeben worden ist. Daher ist die Verwendung von kumu-lativen Bestätigungen eine natürliche Wahl für GBN.

In unserem GBN-Protokoll verwirft der Empfänger Pakete, die in der falschen Reihen-folge eintreffen. Obwohl es albern und verschwenderisch scheint, wenn ein richtig(aber in der falschen Reihenfolge) eingetroffenes Paket verworfen wird, gibt es einenGrund für dieses Vorgehen. Erinnern Sie sich daran, dass der Empfänger die Daten inder richtigen Reihenfolge an die obere Schicht liefern muss. Nehmen Sie an, Paket nwird erwartet, aber Paket n 1 kommt an. Weil die Daten in der richtigen Reihenfolgeabgeliefert werden müssen, könnte der Empfänger Paket n 1 zwischenspeichern undes später, nachdem er auch Paket n empfangen hat, an die höherliegende Schicht wei-tergeben.

Geht das Paket n verloren, wird wegen der Arbeitsweise der Übertragungswiederho-lung in GBN jedoch vermutlich auch Paket n 1 nochmals vom Sender übertragen.Daher kann der Empfänger auch einfach Paket n 1 verwerfen. Der Vorteil diesesAnsatzes ist die Einfachheit des Pufferns beim Empfänger – der Empfänger muss keinPaket zwischenspeichern, das außerhalb der korrekten Reihenfolge eintrifft. Währendder Sender also die obere und untere Grenze seines Fensters und die Position vonnextseqnum innerhalb dieses Fensters speichern muss, ist die einzige Information,die der Empfänger sich merken muss, die Sequenznummer des nächsten Paketes inder Reihenfolge. Dieser Wert wird, wie in Abbildung 3.21 gezeigt, in der Variablenexpectedseqnum der Empfänger-FSM gespeichert. Natürlich liegt der Nachteil derVorgehensweise, ein eigentlich korrekt erhaltenes Paket wegzuwerfen, darin, dass esbei der anschließenden Übertragungswiederholung verloren gehen oder verfälschtwerden könnte und auf diese Art noch mehr Übertragungswiederholungen erforder-lich werden.

Abbildung 3.22 zeigt die Arbeitsweise des GBN-Protokolls für den Fall einer Fens-tergröße von vier Paketen. Wegen dieser Beschränkung der Fenstergröße sendet derAbsender die Pakete 0 bis 3, muss dann aber warten, bis ein oder mehrere dieserPakete bestätigt wurden, bevor er weitersenden kann. Während die einzelnen aufein-anderfolgenden ACKs (zum Beispiel ACK0 und ACK1) empfangen werden, wird dasFenster weitergeschoben und der Sender darf ein neues Paket (Paket 4 beziehungs-


265

weise Paket 5) senden. Auf dem Weg zum Empfänger geht aber Paket 2 verloren unddaher sind die Pakete 3, 4 und 5 nicht mehr in der richtigen Reihenfolge und werdenverworfen.

Bevor wir unsere Diskussion von GBN abschließen, sollten wir anmerken, dass eineImplementierung dieses Protokolls in einem Protokollstapel sehr wahrscheinlich eineStruktur hätte, die der erweiterten FSM in Abbildung 3.20 ähneln würde. Die Imple-mentierung würde wohl auch die Form verschiedener Prozeduren haben, die als Ant-wort auf die verschiedenen möglichen Ereignisse die entsprechenden Aktionendurchführen. Bei dieser ereignisbasierten Programmierung werden die verschiede-nen Funktionen entweder von anderen Funktionen im Protokollstapel oder infolgeeines Interrupts (Unterbrechung) aufgerufen. Beim Absender wären diese Ereignisse(1) ein Aufruf aus der höheren Schicht, um rdt_send() zu starten, (2) ein Timer-Inter-rupt und (3) ein Aufruf von rdt_rcv() durch die niedrigere Schicht, wenn ein Paketankommt. Die Programmierübungen am Ende dieses Kapitels geben Ihnen Gelegen-heit, diese Routinen tatsächlich in einer simulierten, aber realistischen Netzwerk-umgebung zu implementieren.

Wir möchten hier anmerken, dass das GBN-Protokoll schon fast alle Techniken bein-haltet, denen wir begegnen werden, wenn wir die zuverlässigen Datentransferkompo-nenten von TCP in Abschnitt 3.5 studieren. Diese Techniken beinhalten die Verwen-dung von Sequenznummern, kumulative Bestätigungen, Prüfsummen und eineOperation für Timeouts und erneutes Übertragen.

3.4.4 Selective Repeat (SR)

Das GBN-Protokoll ermöglicht es dem Absender in Abbildung 3.17, die Pipeline mitPaketen zu füllen, um auf diese Art die Kanalauslastungsprobleme zu vermeiden,denen wir bei Stop-and-Wait begegnet sind. Es gibt jedoch Szenarien, in denen GBNselbst Leistungsprobleme aufweist. Insbesondere, wenn sowohl die Fenstergröße alsauch das Produkt von Bandbreite und Verzögerung groß sind, können viele Pakete inder Pipeline sein. Ein einzelner Paketfehler kann daher bewirken, dass GBN eine sehrgroße Anzahl von Paketen erneut überträgt, viele davon unnötigerweise. Steigt dieWahrscheinlichkeit von Übertragungsfehlern, kann die Pipeline mit diesen unnötigenÜbertragungswiederholungen gefüllt sein. Stellen Sie sich in unserem Nachrichten-Dik-tat-Szenario vor, dass jedes Mal, wenn ein Wort fehlerhaft wäre, die umliegenden 1.000Wörter (z.B. bei einer Fenstergröße von 1.000 Wörtern) wiederholt werden müssten.Das Diktat würde wegen all der wiederholten Wörter äußerst langsam voranschreiten.

Wie der Name schon andeutet, vermeiden Selective-Repeat-Protokolle unnötige Über-tragungswiederholungen, indem sie nur jene Pakete nochmals vom Sender übertragenlassen, von denen sie vermuten, dass sie Fehler hatten (d.h., sie sind verlorengegangenoder wurden korrumpiert). Diese individuell wiederholten Übertragungen erfolgen nur,wenn sie notwendig werden. Dies erfordert, dass der Empfänger die richtig erhaltenenPakete einzeln bestätigt. Eine Fenstergröße von N wird auch hier wieder verwendet, umdie Anzahl offener, unbestätigter Pakete in der Pipeline zu beschränken.

266

Transportschicht3

Jedoch kann der Sender im Gegensatz zu GBN schon ACKs für einige der Pakete imFenster erhalten haben. Abbildung 3.23 zeigt die Sicht des Selective-Repeat-Sendersauf den Bereich der Sequenznummern. Abbildung 3.24 zeigt detailliert die verschie-denen Aktionen des SR-Senders.

Der SR-Empfänger bestätigt ein richtig erhaltenes Paket, ungeachtet dessen, ob es inder richtigen Reihenfolge eingetroffen ist. Pakete außerhalb der Reihe werden zwi-schengespeichert, bis die fehlenden Pakete (das heißt, Pakete mit niedrigerenSequenznummern) empfangen werden, wonach ein Schub von Paketen – in der rich-tigen Reihenfolge – an die obere Schicht geliefert werden kann. Abbildung 3.25 ver-deutlicht die vom SR-Empfänger ergriffenen Maßnahmen. Abbildung 3.26 zeigt einBeispiel der SR-Operation im Falle von verlorenen Paketen. Beachten Sie, dass in

Abbildung 3.22: Arbeitsweise von Go-Back-N

Sender Empfänger

sende pkt0

sende pkt1

sende pkt2

sende pkt3

(warten)

empfange ACK0

sende pkt4

empfange ACK1

sende pkt5

sende pkt2

sende pkt3

sende pkt4

sende pkt5

pkt2 timeout

empfange pkt0

sende ACK0

empfange pkt1

sende ACK1

empfange pkt3, verwerfen

sende ACK1


sende ACK1


sende ACK1

empfange pkt2, ausliefern

sende ACK2

empfange pkt3, ausliefern

sende ACK3

X(Verlust)


267

Abbildung 3.26 der Empfänger anfangs die Pakete 3, 4 und 5 puffert und sie, alsPaket 2 schließlich empfangen wurde, zusammen mit Paket 2 an die obere Schichtweiterleitet.

Abbildung 3.24: Ereignisse und Aktionen im SR-Sender

Abbildung 3.23: Sender- und Empfängersicht des Bereiches der Sequenznummern bei Selective Repeat (SR)

Daten von oben erhalten. Wenn Daten von oben empfangen werden,bestimmt der SR-Sender die nächste verfügbare Sequenznummer für dasPaket. Wenn die Sequenznummer innerhalb des Fensters des Senders ist,werden die Daten in ein Paket verpackt und gesendet; ansonsten werden sieentweder gepuffert oder, wie in GBN, an die obere Schicht zurückgegeben.

Timeout. Timer werden auch hier gegen verloren gegangene Pakete einge-setzt. Jedoch muss jedes Paket nun seinen eigenen logischen Timer haben,weil nur ein einzelnes Paket beim Timeout gesendet wird. Ein einzelnerHardware-Timer kann verwendet werden, um die Operation von mehrerenlogischen Timern zu simulieren [Varghese 1997].

Eintreffen eines ACK. Wird ein ACK empfangen, kennzeichnet der SR-Sen-der dieses Paket als bestätigt, vorausgesetzt, es befindet sich im Fenster. Istdie Sequenznummer des Paketes gleich send_base, wird send_base zu demunbestätigten Paket weitergeschoben, das die kleinste Sequenznummerbesitzt. Bewegt sich das Fenster und es gibt noch nicht übertragene Paketemit Sequenznummern, die jetzt innerhalb des Fensters liegen, werden diesePakete gesendet.

send _ base nextseqnum

FenstergrößeN

Legende:

Legende:

Bereitsbestätigt

Gesendet, nochnicht bestätigt

Nutzbar, noch nicht gesendet

Nicht benutzbar

Außerhalb derReihenfolge, ge-puffert und bereits bestätigt

Erwartet, nochnicht eingetroffen

Akzeptierbar(innerhalbdes Fensters)

Nicht benutzbar

Sequenznummern aus Sicht des Senders

Sequenznummern aus Sicht des Empfängers

rcv _ base

FenstergrößeN

a

b

1.

2.

3.

268

Transportschicht3

Abbildung 3.25: Ereignisse und Aktionen im SR-Empfänger

Es ist wichtig anzumerken, dass beim zweiten Schritt in Abbildung 3.25 der Empfän-ger schon erhaltene Pakete mit bestimmten Sequenznummern unterhalb des aktuellenFensters erneut bestätigt (anstatt sie stillschweigend zu ignorieren). Sie sollten sichklarmachen, dass diese erneute Bestätigung wirklich erforderlich ist. Wird z.B. beiden Sequenznummerbereichen für Sender und Empfänger aus Abbildung 3.23 keinACK für das Paket send_base, das sich auf dem Weg vom Sender zum Empfängerbefindet, geschickt, dann wird der Sender das Paket send_base schließlich erneutsenden, obwohl klar ist (für uns, nicht für den Sender!), dass der Empfänger das Paketschon erhalten hat.

Würde der Empfänger dieses Paket nicht bestätigen, würde sich das Fenster desAbsenders nie vorwärts bewegen! Dieses Beispiel verdeutlicht einen wichtigenAspekt von SR-Protokollen (und auch vielen anderen Protokollen). Sender und Emp-fänger werden nicht immer den gleichen Blick auf das haben, was korrekt empfangenworden ist und was nicht. Für SR-Protokolle bedeutet dies, dass die Sender- undEmpfängerfenster nicht immer zusammenfallen.

Der Mangel an Synchronisierung zwischen Sender- und Empfängerfenstern hat wichtigeFolgen, wenn wir mit der Realität eines begrenzten Bereiches von Sequenznummernkonfrontiert sind. Überlegen Sie, was z.B. bei einem endlichen Bereich von vierPaketsequenznummern – 0, 1, 2, 3 – und einer Fenstergröße von drei geschehenwürde. Nehmen Sie an, dass die Pakete 0 bis 2 übertragen wurden, richtig beim Emp-fänger eingetroffen sind und bestätigt wurden. An dieser Stelle ist das Fenster desEmpfängers über dem vierten, fünften und sechsten Paket, welche die Sequenznum-mern 3, 0 und 1 tragen. Jetzt stellen Sie sich zwei Szenarien vor. Im ersten, dargestellt

Paket mit Sequenznummer im Intervall [rcv_base, rcv_base N 1] wird feh-lerfrei empfangen. In diesem Fall fällt das eingetroffene Paket in das Fensterdes Empfängers und ein selektives ACK-Paket wird an den Absender zurück-gesandt. Wurde das Datenpaket zuvor noch nicht empfangen, wird es gepuf-fert. Hat das Paket eine Sequenznummer gleich der Basis des Empfangsfens-ters (rcv_base in Abbildung 3.22), dann wird dieses Paket die höhereSchicht weitergegeben. Danach wird geprüft, ob zuvor gepufferte Pakete jetztan die höhere Schicht ausgeliefert werden können. Das Empfangsfensterwird dann um die Anzahl der an die obere Schicht ausgelieferten Paketeweiterbewegt. Als Beispiel betrachten Sie Abbildung 3.26. Wenn ein Paketmit einer Sequenznummer von rcv_base 2 empfangen wird, kann es,zusammen mit den Paketen 3, 4 und 5 der oberen Schicht zugestellt werden.

Paket mit Sequenznummer im Intervall [rcv_base N, rcv_base 1] wird feh-lerfrei empfangen. In diesem Fall muss ein ACK erzeugt werden, obwohldies ein Paket ist, das der Empfänger bereits zuvor bestätigt hat.

Sonst. Das Paket wird ignoriert.

1.

2.

3.


269

in Abbildung 3.27 (a), gehen die ACKs der ersten drei Pakete verloren und derAbsender überträgt diese Pakete erneut. Der Empfänger erhält auf diese Art ein Paketmit Sequenznummer 0 – eine Kopie des ersten übertragenen Paketes.

Im zweiten Szenario, dargestellt in Abbildung 3.27 (b), werden die ACKs der erstendrei Pakete alle richtig abgeliefert. Der Absender bewegt daher sein Fenster vorwärtsund sendet das vierte, fünfte und sechste Paket mit den Sequenznummern 3, 0 und 1.Das Paket mit Sequenznummer 3 geht verloren, aber das Paket mit Sequenznummer 0kommt an – ein Paket, das neue Daten enthält.

Jetzt nehmen Sie den Standpunkt des Empfängers in Abbildung 3.27 ein. Ein sprich-wörtlicher Vorhang zwischen Sender und Empfänger verhindert, dass der Empfängersehen kann, welche Maßnahmen vom Sender ergriffen wurden. Alles, was der Empfän-ger beobachtet, ist die Abfolge der Nachrichten, die er vom Kanal erhält und in denKanal sendet. Soweit er betroffen ist, sind die beiden Szenarien in Abbildung 3.27identisch. Es gibt keinen Weg, die wiederholte Übertragung des ersten Paketes von einerOriginalübertragung des fünften Paketes zu unterscheiden. Offensichtlich funktioniertalso eine Fenstergröße, die um eins geringer ist als der Bereich der Sequenznummern,

Abbildung 3.26: SR-Arbeitsweise

pkt0 empfangen, ausgeliefert, ACK0 gesendet

0 1 2 3 4 5 6 7 8 9

pkt1 empfangen, ausgeliefert, ACK1 gesendet

0 1 2 3 4 5 6 7 8 9

pkt3 empfangen, gepuffert, ACK3 gesendet

0 1 2 3 4 5 6 7 8 9

pkt4 empfangen, gepuffert, ACK4 gesendet

0 1 2 3 4 5 6 7 8 9

pkt5 empfangen; gepuffert, ACK5 gesendet

0 1 2 3 4 5 6 7 8 9

pkt2 empfangen, pkt2,pkt3,pkt4,pkt5ausgeliefert, ACK2 gesendet

0 1 2 3 4 5 6 7 8 9

pkt0 gesendet

0 1 2 3 4 5 6 7 8 9

pkt1 gesendet

0 1 2 3 4 5 6 7 8 9

pkt2 gesendet

0 1 2 3 4 5 6 7 8 9

pkt3 gesendet, Fenster voll

0 1 2 3 4 5 6 7 8 9

ACK0 empfangen, pkt4 gesendet

0 1 2 3 4 5 6 7 8 9

ACK1 empfangen, pkt5 gesendet

0 1 2 3 4 5 6 7 8 9

pkt2 TIMEOUT, pkt2erneut gesendet

0 1 2 3 4 5 6 7 8 9

ACK3 empfangen,nichts gesendet

0 1 2 3 4 5 6 7 8 9

X(Verlust)

Sender Empfänger

270

Transportschicht3

nicht. Aber wie groß muss das Fenster sein? In einer Übungsaufgabe am Ende des Kapi-tels sollen Sie zeigen, dass bei SR-Protokollen die Fenstergröße kleiner oder gleich derHälfte des Sequenznummernbereiches sein muss.

Auf der Webseite zum Buch finden Sie ein Applet, das die Operation des SR-Proto-kolls anschaulich macht. Versuchen Sie, dieselben Versuche durchzuführen, die Sie

Abbildung 3.27: Dilemma des SR -Empfängers bei zu großen Fenstern: neues Paket oder Übertragungswiederholung?

pkt0

Timeout,erneutes Über-tragen von pkt0

0 1 2 3 0 1 2

pkt0

pkt1

pkt2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2ACK0

ACK1

ACK2x

0 1 2 3 0 1 2

0 1 2 3 0 1 2

Senderfenster(nach Empfang)

Empfängerfenster(nach Empfang)

Empfange Paket mitSequenznummer 0

0 1 2 3 0 1 2

pkt0

pkt1

pkt2

pkt3

pkt0

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2ACK0

ACK1

ACK2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

Senderfenster(nach Empfang)

Empfängerfenster(nach Empfang)

Empfange Paket mitSequenznummer 0

0 1 2 3 0 1 2

x

x

x

a

b


271

mit dem GBN-Applet gemacht haben. Stimmen die Ergebnisse mit dem überein, wasSie erwarten?

Dies beendet unsere Diskussion zuverlässiger Datenübertragungsprotokolle. Wir habenviele Themenbereiche betrachtet und zahlreiche Mechanismen eingeführt, die zusam-men einen zuverlässigen Datentransfer ermöglichen. Tabelle 3.1 fasst diese Mecha-nismen zusammen. Nun, da wir sie alle in Aktion gesehen haben und in der Lagesind, das Gesamtbild zu erkennen, möchten wir Sie dazu anregen, diesen Abschnitterneut zu lesen. Sie sollen erkennen, wie diese Techniken schrittweise zusammenge-fügt wurden, um immer komplexere (und realistischere) Modelle des Kanals zu unter-stützen, der Absender und Empfänger verbindet, sowie um die Leistung der Proto-kolle zu steigern.

Mechanismus Einsatzzweck, Kommentare

Prüfsumme Wird verwendet, um Bitfehler in einem gesendeten Paket zu erkennen.

Timer Wird verwendet, um ein Paket nochmals zu übertragen, möglicherweise weil das Paket (oder das zugehörige ACK) auf dem Kanal verloren ging. Weil Time-outs auftreten können, wenn ein Paket verzögert wird, aber nicht verloren geht (frühzeitiger Timeout), oder weil ein Paket beim Empfänger eingetroffen sein kann, aber das ACK verloren ging, können doppelte Kopien eines Paketes beim Empfänger ankommen.

Sequenznummer Wird für die fortlaufende Nummerierung von Datenpaketen verwendet, die vom Sender zum Empfänger laufen. Lücken in den Sequenznummern der erhaltenen Pakete erlauben es dem Empfänger, ein verlorenes Paket zu erkennen. Pakete mit doppelten Sequenznummern ermöglichen es dem Empfänger, doppelte Kopien eines Paketes zu erkennen.

Acknowledgment (ACK)

Wird vom Empfänger verwendet, um dem Absender mitzuteilen, dass ein Paket oder ein Satz von Paketen richtig empfangen worden ist. Acknowledgments tragen normalerweise die Sequenznummer des Paketes oder der Pakete, die bestätigt werden. Acknowledgments können je nach Protokoll einzeln oder kumulativ sein.

Negatives Acknowledgment (NAK)

Wird vom Empfänger verwendet, um dem Absender mitzuteilen, dass ein Paket nicht richtig empfangen wurde. Ein negatives Acknowledgment enthält normaler-weise die Sequenznummer des Paketes, das nicht richtig empfangen wurde.

Pipelining, Sendefenster

Der Sender darf mehrere unbestätigte Pakete senden, deren Sequenznummern innerhalb eines gegebenen Bereiches, dem Sendefenster, liegen müssen. Indem mehrere Pakete gesendet werden dürfen, aber noch nicht bestätigt werden müssen, kann die Auslastung im Vergleich zum Stop-and-Wait-Ansatz gesteigert werden. Wir werden später sehen, dass die Fenstergröße von verschiedenen Parametern beeinflusst wird, etwa der Fähigkeit des Empfängers, Nachrichten zu empfangen und zu puffern oder der (Über-)Lastsituation im Netz.

Tabelle 3.1: Zusammenfassung von Mechanismen für die zuverlässige Datenübertragung und ihrer Verwendung

300

Transportschicht3

Der SYN-Flood-Angriff

Wir haben bei unserer Diskussion des Drei-Wege-Handshakes von TCP gesehen,dass ein Server Verbindungsvariablen und Puffer als Antwort auf ein empfange-nes SYN allokiert und initialisiert. Der Server sendet dann ein SYNACK undwartet auf ein ACK-Segment vom Client, den dritten und letzten Schritt desHandshakes vor dem vollständigen Aufbau einer Verbindung. Sendet der Clientkein ACK, um den dritten Schritt des Drei-Wege-Handshakes durchzuführen,beendet der Server schließlich (oft erst nach einer Minute oder mehr) die halb-offene Verbindung und gibt die reservierten Ressourcen wieder frei.

Dieses TCP-Verbindungsmanagement-Protokoll ermöglicht einen klassischenDoS-Angriff, nämlich den SYN-Flood-Angriff. Bei diesem Angriff sendet derAngreifer eine große Zahl von TCP-SYN-Segmenten, ohne den dritten Schritt desHandshakes durchzuführen. Der Angriff kann verstärkt werden, wenn SYNs vonmehreren Quellen gesendet werden, in Form eines DDoS-SYN-Flood-Angriff(DDoS = Distributed Denial of Service). Mit dieser Schwemme von SYN-Segmen-ten können die Verbindungsressourcen des Servers schnell erschöpft sein, da siezwar für halboffene Verbindungen reserviert, aber nie tatsächlich verwendetwerden. Sind die Ressourcen des Servers erschöpft, wird rechtmäßigen Clientsder Dienst versagt. Solche SYN-Flood-Angriffe [CERT SYN 1996] waren unterden ersten von CERT dokumentierten DoS-Angriffen [CERT 2007].

SYN-Flooding ist ein potenziell verheerender Angriff. Glücklicherweise gibt eseine wirkungsvolle Verteidigung, die als SYN-Cookies bezeichnet wird [Skoudis2006; Cisco SYN 2007; Bernstein 2007]. Mittlerweise in den meisten größerenBetriebssystemen eingesetzt, funktionieren SYN-Cookies wie folgt:

Erhält der Server ein SYN-Segment, weiß er nicht, ob das Segment von einemrechtmäßigen Benutzer kommt oder Teil eines SYN-Flutenangriffs ist. Also er-zeugt der Server keine halboffene TCP-Verbindung für dieses SYN. Stattdessenerzeugt der Server eine initiale TCP-Sequenznummer, die eine komplexe Funk-tion (eine Hash-Funktion) der Quell- und Ziel-IP-Adressen und der Portnummerndes SYN-Segmentes sowie einem nur dem Server bekannten geheimen Wert ist.(Der Server verwendet denselben geheimen Wert für eine große Anzahl von Ver-bindungen.) Diese sorgfältig gestaltete initiale Sequenznummer ist der sogenannteCookie. Der Server sendet dann ein SYNACK-Paket mit dieser speziellenSequenznummer. Wichtig ist dabei, dass sich der Server nicht an den Cookie oderirgendeine andere Zustandsinformation des SYN-Segmentes erinnert.

Handelt es sich um einen rechtmäßigen Client, dann gibt er ein ACK-Segmentzurück. Der Server muss beim Erhalten dieses ACK sicherstellen, dass dasACK zu einem früher übersandten SYN gehört. Wie kann dies geschehen,wenn der Server keine Aufzeichnungen über die erhaltenen SYN-Segmente be-hält? Vielleicht haben Sie schon vermutet, dass es mithilfe des Cookies ge-schieht. Der Wert im Acknowledgment-Feld eines legitimen ACK ist gleich derSequenznummer im SYNACK plus eins (Abbildung 3.39). Der Server führtdann dieselbe Funktion aus und verwendet dabei dieselben Felder im ACK-

Fokus Sicherheit

computernetzwerke 5.auflage *978-3-8689-4185-2* …3.1 einführung und transportschichtdienste 229...

Documents

computernetzwerke 5.auflage 978-3-8689-4185-2 …3.1 einführung und transportschichtdienste 229...