2.3.10 Neuere TCP-Konzepte

In diesem Abschnitt wollen wir kurz auf ausgewählte neuere Entwicklungsrichtungen bei TCP eingehen. Dabei werden wir auch überblicksartig die restlichen der im Kapitel 2.3.4 grafisch dargestellten Optionen betrachten.

Moderne Implementierungen (z.B. Linux 2.x und Solaris 2.x) enthalten standardmäßig den Algorithmus Path MTU Discovery (RFC 1191) und bestimmen mit seiner Hilfe die MTU entlang des Pfades zum Partner. Die prinzipielle Vorgehensweise haben wir bei UDP kennengelernt.

Weitverkehrs-Netze mit sehr hohen Kapazitäten werden auch Long Fat Networks genannt, abgekürzt LFNs. Die Abkürzung wird meist wie das englische Wort für Elefanten, also "elefan(t)s" gesprochen. TCP-Verbindungen in diesen Netzen heißen auch Long Fat Pipes. Sie bringen einige neue Probleme mit sich:

Die Option Window Scale vergrößert das effektiv nutzbare Fenster durch eine Skalierung unter Verwendung von Zweierpotenzen, deren Exponent im Feld Shift Count angegeben wird und im Bereich von 0 bis 14 liegt. Null bedeutet "keine Skalierung". Die neue maximale Fenstergröße in Bytes errechnet sich wie folgt:

65535 * 214 = 65535 * 16384 = 1.073.725.440
TCP-intern wird die Fenstergröße jetzt als 32-Bit-Zahl verwaltet. Den Kopf muß man dazu allerdings nicht ändern. Die Option darf nur in einem Segment mit SYN-Flag angegeben werden, d.h., der Skalierungsfaktor ist nach dem Verbindungsaufbau nicht mehr veränderbar. Hin- und Rückrichtung können verschiedene Faktoren verwenden.

Die Option Timestamps gestattet, jedem Segment zwei Zeitstempel aufzuprägen. Der erste, der sog. Timestamp Value, entspricht der aktuellen Zeit der Zeitstempel-Uhr des Senders der Option. Das Feld Timestamp Echo Reply ist nur bei gesetztem ACK-Flag gültig und stellt das Echo eines zuvor vom Partner als Timestamp Value erhaltenen Wertes dar. In der Regel erscheint beim Echo der zuletzt empfangene Zeitstempel.

Die vom Sender erhaltenen Zeitstempel sendet der Empfänger lediglich zurück, er interpretiert sie aber nicht. Daher muß nur der Sender die verwendete Maßeinheit kennen. Eine Synchronisation der Uhren beider Seiten ist nicht erforderlich. Bei den Timestamps handelt es sich um monoton wachsende Werte, die es einem Sender gestatten, die RTT jeder eintreffenden Quittung zu ermitteln. Für Detailfragen sei auf den RFC 1323 verwiesen.

Zeitstempel gestatten nicht nur eine bessere Abschätzung der SRTT. Sie ermöglichen es dem Empfänger auch, bei der wiederholten Verwendung derselben Sequenznummer innerhalb der MSL aktuelle und alte Pakete (also jene, die die Bytes mit den Sequenznummern N+232 bzw. N enthalten) voneinander unterscheiden zu können. Der hierzu genutzte Algorithmus trägt die Bezeichnung PAWS: Protection Against Wrapped Sequence Numbers.

Auch hierbei ist keine Synchronisation der Uhren vonnöten. Es wird lediglich gefordert, daß die Werte der Zeitstempel streng monoton, d.h. mindestens um eins pro Fenster wachsen. Die Grundidee von PAWS besteht darin, alle Segmente als alt zu betrachten, deren Zeitstempel kleiner ist als die in letzter Zeit empfangenen Zeitstempel. Details können wieder dem RFC 1323 entnommen werden.

Die beiden erwähnten neuen Optionen werden von alten Implementierungen ignoriert, so daß sie keine Interoperabilitätsprobleme hervorrufen.

Die von TCP organisierten Virtual Circuits entsprechen den Bedürfnissen vieler Internet-Anwendungen (Telnet, FTP, SMTP, Secure Shell, ...) sehr gut. Anders verhält es sich hingegen in der Regel bei auf Transaktionen basierenden Anwendungen. Der Begriff Transaktion beschreibt eine Interaktion, bei der auf eine Anforderung des Klienten eine Antwort des Servers folgt, wobei folgendes gilt:

  1. Zur Reduktion des Overheads ist auf den Auf- und Abbau von Verbindungen zu verzichten. Nach Möglichkeit ist genau ein Paket mit der Anforderung zu senden und genau ein Paket mit der Antwort zu empfangen.

  2. Die Verzögerung soll minimal sein, also im Idealfall nur der Summe aus RTT und Bearbeitungszeit auf dem Server entsprechen.

  3. Der Server soll Duplikate bereits beantworteter Anforderungen erkennen, um den Auftrag nicht mehrfach auszuführen. Statt dessen soll er die zuvor gesendete und zwischengespeicherte Antwort einfach wiederholen.

Transaktionen dieser Art finden wir z.B. beim DNS, wobei dort duplizierte Anfragen nicht gesondert behandelt werden. Eine effektive Unterstützung von Transaktionen ist das Ziel der unter dem Namen T/TCP bekanntgewordenen TCP-Erweiterungen. Sie sind in den RFCs 1379 (Extending TCP for Transactions -- Concepts) und 1644 (T/TCP -- TCP Extensions for Transactions, Functional Specification) beschrieben.

Oft stellt sich die Frage nach dem maximal mit TCP-Verbindungen erreichbaren Durchsatz. Man kann allgemein sagen, daß bei gut eingestellten Implementierungen, die die neuen Algorithmen und Optionen verwenden, letztlich nur zwei Faktoren die Performance wirklich hart begrenzen: das maximal mögliche 1-Gigabyte-Fenster sowie die Lichtgeschwindigkeit, da aus letzterer ein unteres Limit für die RTT resultiert. Untersuchungen haben ergeben, daß viele Performance-Probleme aus Schwächen in den Implementierungen und nicht aus irgendwelchen dem Protokoll inhärenten Begrenzungen resultieren.

Zur Illustration sollen ein paar Zahlen dienen, die von Stevens übernommen wurden (beachten Sie dabei bitte, daß dieses Buch bereits 1994 erschienen ist):


Frage 2.3.10.1:

Was ist der kürzeste Zeitabstand, mit dem sich TCP-Sequenznummern wiederholen, wenn die Kommunikation über ein 100-Mbit/s-Medium erfolgt (wir nehmen an, daß 90% der Medien-Datenrate der IP-Schicht zur Verfügung stehen)?

Frage 2.3.10.2:

Bei terrestrischen Leitungen rechnet man mit einer Laufzeit von etwa 0,005 ms/km. Wie lang darf eine 34-Mbit/s-Leitung sein, damit man sie mit einer Standard-TCP-Verbindung (ohne Window-Scaling) noch voll auslasten kann?


© Holger Trapp, 8.2.1999