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:
Um diese Situation gezielt und effektiv behandeln zu können, wurde im mittlerweile obsoleten RFC 1072 (TCP Extensions for Long-Delay Paths) die zusätzliche TCP-Option SACK vorgeschlagen, die selektive Quittungen (Selective Acknowledgments) gestattet. Auf diese Weise kann der Empfänger dem Sender auch den Erhalt von isolierten, d.h. nicht lückenlos aufeinanderfolgenden Segmenten bestätigen. Dies ist, wie wir schon bei der Diskussion duplizierter Quittungen (duplicate ACKs) festgestellt hatten, mit den normalen TCP-Quittungen auf Grund ihres kumulativen Charakters nicht möglich, so daß es unter Umständen zwangsläufig zur Retransmission von Segmenten kommt, die bereits korrekt empfangen wurden.
Durch die selektiven Quittungen lassen sich dagegen solche unnötigen Sendewiederholungen vermeiden, indem der Sender nur diejenigen Segmente seines Sendefensters wiederholt, deren Empfang noch nicht explizit bestätigt wurde. Im RFC 1323 (TCP Extensions for High Performance) wurde auf die Option SACK dennoch bewußt verzichtet. Die Autoren erwarteten zwar einerseits, daß selektive Quittungen im Umfeld der LFNs stark an Bedeutung gewinnen würden, waren aber andererseits der Ansicht, daß vor deren praktischem Einsatz noch wichtige technische Fragen hinsichtlich Format und Semantik der Option SACK zu klären seien.
Mit dem RFC 2018 (TCP Selective Acknowledgment Options) existiert nun seit Oktober 1996 ein Proposed Standard, der einen Vorschlag für die Option SACK enthält, welcher sich stark an die Vorarbeiten im RFC 1072 anlehnt. Eine TCP-Implementierung, die die Option SACK unterstützt, kann und sollte dies ihren Partnern durch die Option SACK-permitted, die lediglich beim Verbindungsaufbau im SYN-Segment angegeben werden darf, signalisieren. Tut sie das nicht, so dürfen die Partner die Option SACK nicht verwenden.
SACK bewirkt keinerlei Änderung der Bedeutung der Bestätigungsnummer im TCP-Kopf, sondern bietet einem Empfänger die Möglichkeit, zusätzliche Quittungs-Informationen zum Sender zu übertragen und so den Empfang von isolierten Datenblöcken (Segmenten) zu bestätigen. Die Option enthält zu diesem Zweck eine Liste mit jeweils expliziten Angaben der beiden Ränder von isolierten Datenblöcken, die innerhalb des Empfangsfensters liegen und beim Empfänger in der Hoffnung zwischengespeichert wurden, daß die noch fehlenden Segmente durch eine Retransmission in Kürze eintreffen und die Lücken so geschlossen werden.
Die Ränder eines isolierten Datenblocks (und damit implizit dessen Länge) werden durch zwei vorzeichenlose 32-Bit-Integer-Zahlen beschrieben:
Diese Angaben signalisieren implizit, daß die Bytes links und rechts von
einem derart spezifizierten Block, also diejenigen mit den Sequenznummern
Eine SACK-Option, die n Blöcke quittiert, hat eine Länge von 8×n+2 Byte. Da im TCP-Kopf insgesamt nur 40 Byte für Optionen zur Verfügung stehen, kann man höchstens 4 Blöcke angeben. Da man zusätzlich davon ausgeht, daß SACK oft zusammen mit der Timestamp-Option genutzt werden wird, reduziert sich in diesen Fällen die maximale Anzahl der durch SACK beschreibbaren Blöcke auf 3.
Ist diese Zeit kürzer als die maximale Segmentlebensdauer (MSL), dann besteht die Gefahr, daß das Paket, welches das Byte mit der Sequenznummer N enthält, durch eine Verzögerung erst dann eintrifft, wenn der Empfänger das Byte mit der Sequenznummer N+232 erwartet. Da nur die identischen letzten 32 Bit beider Zahlen im TCP-Kopf gespeichert sind, läßt sich anhand der Bytenummern nicht entscheiden, ob es sich um das aktuelle oder ein altes Paket handelt. Diesem Problem begegnet der Algorithmus PAWS (s. unten).
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.440TCP-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:
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):
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?