Da dem Internet Protokoll jegliche Möglichkeiten fehlen den Informationsfluss über ein Netzwerk zu steuern und eine zuverlässige Übermittlung zu garantieren, müssen diese und weitere Aufgaben in höheren Schichten des OSI-Referenzmodells durchgeführt werden.

In Schicht 4 des OSI-Referenzmodells übernimmt überwiegend das Transmission Control Protocol (TCP) diese Aufgaben. Es wird immer dann eingesetzt, wenn sichergestellt werden muss, dass die übertragenen Daten beim Empfänger auch ankommen.

Anmerkung: Dies ist beim jeder Art des Datenaustauschs zwar grundsätzlich immer wünschenswert, abhängig von der Verwendung der zu übertragenden Daten aber nicht immer zwingend erforderlich.

Für die Umsetzung der garantierten Datenübermittlung gibt es nur eine brauchbare Lösung. Der Empfänger muss dem Absender gegenüber den korrekten Empfang bestätigen. Ein weiteres Merkmal von TCP ist die Eigenschaft, für die Dauer des Datenaustauschs zwischen zwei Teilnehmern eine bidirektionale Sitzung (exklusiver Sende- und Empfangkanal) aufzubauen, die bis zum beidseitigen Einverständnis der Teilnehmer zum Abbau Bestand hat. Daher wird TCP, neben der Eigenschaft empfangene Daten zu bestätigen, auch als verbindungsorientiertes (Sitzung) und zuverlässiges (Bestätigungen) Protokoll bezeichnet.

Damit die weiteren Ausführungen nicht zu abstrakt wirken, soll einleitend die folgende Grafik unterstützen. Sie reflektiert die relevanten Status beim Datenaustausch, mit dem Fokus auf TCP:

Eine Applikation übergibt Daten an den TCP-Prozess. Dieser segmentiert die Daten und übergibt sie an den Sendepuffer (TX). Anschließend werden die Segmente aus dem Sendepuffer an die unteren OSI-Schichten (< Schicht 4) übergeben und schließlich auf den Weg zum Empfänger geschickt. Beim Empfänger erfolgt dieser Vorgang entsprechend anders herum, wobei die Segmente hier nicht im Sendepuffer, sondern im Empfangspuffer (RX) landen. Wenn die Empfangsapplikation bereit ist, ruft sie die Segmente ab und verarbeitet sie. Der gesamte Vorgang ist zeitgleich in Gegenrichtung möglich.

Anmerkung: Die Puffer sind für die aktuelle Sitzung gebildete Bereiche im Arbeitsspeicher.

Was sich in der Theorie einfach anhört, ist in der Praxis ein stellenweise hochkomplexer Vorgang. In letzter Konsequenz steht und fällt eine optimale Datenübertragung mit der zeitlichen Abstimmung von gesendeten und bestätigten Bytes. Schließlich unterliegen die Eigenschaften eines jeden Netzes gewissen Schwankungen. Mal mehr (Internet), mal weniger (LAN). Die Herausforderung bei diesem Prozess ist eine möglichst kontinuierliche Datenübermittlung unter der Ausnutzung des bestmöglichen Durchsatzes. Dazu stehen TCP mehrere Mechanismen zur Verfügung, die im späteren Verlauf dieses Beitrags behandelt werden.

Den Regeln für TCP folgend, muss jede Sitzung zwischen zwei Sockets initialisiert werden. Ein Socket ist ein virtuelles Konstrukt aus der IP-Adresse (OSI Schicht 3) und einem Port (OSI Schicht 4). Ziel der Initialisierung ist es, beide Teilnehmer für die bereitgestellten Mechanismen zur Datenübertragung zu synchronisieren. Dieser Vorgang wird als 3-Way-Handshake bezeichnet:

1. Host A nimmt über seinen eigenen Socket (Quelladresse + Quellport) Kontakt mit einem Socket von Host B (Zieladresse + Zielport) auf. Dabei übermittelt er einen Zufallswert als Startwert für eine Sequenznummer und kennzeichnet den Verbindungaufbau durch ein gesetztes SYN-Flag im TCP-Header. Weiterführender Weblink
2. Host B antwortet mit einer Bestätigungsnummer, die der empfangenen Sequenznummer + 1 entspricht. Zusätzlich übermittelt er den Startwert für eine eigene Sequenznummer. Ebenfalls ein Zufallswert. Der TCP-Header hat hier zusätzlich das Flag ACK für die Bestätigung des Empfangs der Sequenznummer von Host A gesetzt.
3. Host A bestätigt schließlich ebenfalls mit dem Flag ACK im TCP-Header die Sequenznummer von Host B, erhöht um 1. Nachdem Host B die Bestätigung empfangen hat, gilt die Sitzung als aufgebaut.

Die Initialisierung vermittelt schon einen ersten Eindruck, wie auf Protokollebene die Eigenschaft der Zuverlässigkeit umgesetzt wird. Dem Zusammenspiel von Sequenz- und Bestätigungsnummern. Die von einem Host gesendete Bestätigungsnummer entspricht dabei immer der als nächstes erwarteten Sequenznummer.

Um nun detaillierter auf die übertragenen Informationen eingehen zu können, soll folgende Protokollierung einer HTTP-Anfrage als Hilfe dienen. Sie beinhaltet den kompletten Vorgang einer Kommunikation über TCP (Verbindungsaufbau, Nutzdatenübermittlung, Verbindungsabbau):

Capture info:
Time (in seconds) means "leaving or reaching the client!"
Direction "-->" means "client(52222) to server(80)"
Direction "<--" means "server(80) to client(52222)"
Round Trip Time ~ 60ms
*******************************************************************************
No. Time   Direction  Flags      Seq    Ack  Additional Values
01  0.000        -->  SYN          0      0  Win=8192  Len=0 MSS=1460 WS=2 SACK
02  0.061  <--        SYN,ACK      0      1  Win=65535 Len=0 MSS=1452 WS=3 SACK
03  0.061        -->  ACK          1      1  Win=66792 Len=0
04  0.061        -->  PSH,ACK      1      1  Win=66792 Len=407
05  0.155  <--        PSH,ACK      1    408  Win=66792 Len=250
06  0.165  <--        ACK        251    408  Win=66792 Len=1452
07  0.165        -->  ACK        408   1703  Win=66792 Len=0
08  0.175  <--        ACK       1703    408  Win=66792 Len=1202
09  0.237  <--        ACK       2905    408  Win=66792 Len=1452
10  0.237        -->  ACK        408   4357  Win=66792 Len=0
11  0.249  <--        ACK       4357    408  Win=66792 Len=1452
12  0.251  <--        ACK       5809    408  Win=66792 Len=250
13  0.251        -->  ACK        408   6059  Win=66792 Len=0
14  0.307  <--        ACK       6059    408  Win=66792 Len=1452
15  0.319  <--        ACK       7511    408  Win=66792 Len=1452
16  0.319        -->  ACK        408   8963  Win=66792 Len=0
17  0.329  <--        ACK       8963    408  Win=66792 Len=1202
18  0.341  <--        ACK      10165    408  Win=66792 Len=1452
19  0.341        -->  ACK        408  11617  Win=66792 Len=0
20  0.345  <--        ACK      11617    408  Win=66792 Len=586
21  0.389  <--        ACK      12203    408  Win=66792 Len=1452
22  0.389        -->  ACK        408  13655  Win=66792 Len=0
23  0.401  <--        ACK      13655    408  Win=66792 Len=1452
24  0.413  <--        ACK      15107    408  Win=66792 Len=1452
25  0.413        -->  ACK        408  16559  Win=66792 Len=0
26  0.423  <--        ACK      16559    408  Win=66792 Len=1202
27  0.459  <--        ACK      17761    408  Win=66792 Len=1452
28  0.459        -->  ACK        408  19213  Win=66792 Len=0
29  0.463  <--        ACK      19213    408  Win=66792 Len=586
30  0.483  <--        ACK      19799    408  Win=66792 Len=1452
31  0.483        -->  ACK        408  21251  Win=66792 Len=0
32  0.493  <--        PSH,ACK  21251    408  Win=66792 Len=1204
33  0.496        -->  FIN,ACK    408  22455  Win=65588 Len=0
34  0.519  <--        FIN,ACK  22455    409  Win=66792 Len=0
35  0.519        -->  ACK        409  22456  Win=66792 Len=0

collapse/expand

Nach der ersten Kontaktaufnahme hat jede Übertragung das Bestätigungsflag (ACK), in Verbindung mit einer Bestätigungsnummer, gesetzt. Das Prinzip, wie die Bestätigungsnummer definiert wird, ändert sich jedoch sobald Nutzdaten übermittelt werden (Len > 0). Dann entspricht die Bestätigungsnummer der empfangenen Sequenznummer + Len. Dabei ist das Längenfeld (Len) gleichbedeutend, mit den übermittelten Nutzdaten in Bytes.

Ein wesentliches Verhalten beim generieren von Bestätigungen (ACKs) ist, dass der Empfänger kumulativ bestätigt. Für den Sender bedeutet dies, dass die Gegenstelle alle bisher übermittelten Bytes (Bestätigungsnummer - 1) korrekt empfangen hat.

Ein weiteres verwendetes Flag ist Push (PSH). Es sorgt dafür, dass Segmente nicht erst im Sende- oder Empfangspuffer (Bereiche im RAM) zwischengespeichert werden. Die Nutzung der Puffer hat grundsätzlich erstmal den Vorteil, dass Segmente effizienter gesendet werden können, beziehungsweise eine Applikation auf der Empfängerseite nicht jedes Segment einzeln aufnehmen muss, nur um festzustellen, dass erst weitere Segmente zur sinnvollen Datenrekonstruktion notwendig sind.

Nun gibt es aber auch Fälle, in denen das Puffern nachteilig sein kann, weil es technisch bedingt eine Verzögerung verursacht. Beispiele dafür sind Mediastreams oder die kommandozeilenbasierte Administration (Telnet, etc.). Segmente dieser Applikationen erhalten alle das PSH Flag, um Verzögerungen zu vermeiden.

In allen Fällen jedoch erhält die letzte Übertragung das PSH Flag. Auch hier liegt der Grund darin, dass die letzten Bytes nicht noch unnötig lange im Empfangspuffer gehalten werden.

Zum geregelten Verbindungsabbau findet schließlich das Flag Finished (FIN) Verwendung. Da die TCP Sitzung beidseitig geschlossen werden muss um als beendet zu gelten, sendet auch jeder Teilnehmer das Flag FIN, welches von der Gegenstelle bestätigt wird. Da hier keine Nutzdaten übermittelt werden (Len = 0), gilt für die Bestätigungsnummer wieder empfangene Sequenznummer + 1. TCP kennt natürlich auch Verfahren, um eine Sitzung zu beenden, die nicht geregelt abgebaut wird. Beispielweise bei Verbindungsabbruch. Hier wird die Sitzung einfach nach Ablauf einer gewissen Zeit der Inaktivität beendet.

Anmerkung: In diesem Mitschnitt nicht verwendete Flags werden beim Betrachten des Headeraufbaus angesprochen.

Nun zu einigen Werten, die im obigen Beispiel unter Additional Values aufgeführt wurden. Das Längenfeld (Len) wurde ja bereits im Zusammenhang mit dem Bestätigungsflag (ACK) besprochen und die Option SACK wird im späteren Verlauf genauer betrachtet.

Mit dem Wert Maximum Segment Size (MSS) übermitteln die Teilnehmer ihre lokal größtmögliche Segmentgröße. Damit es bei der Übertragung nicht zur ungewünschten Fragmentierung kommt, einigen sich beide Teilnehmer auf den kleinsten gemeinsamen Nenner. Das bedeutet in diesem Fall, dass Host A für diese Verbindung ebenfalls eine MSS von 1452 nutzt. Das schließt zwar eine mögliche Fragmentierung auf dem Pfad im Internet nicht aus, beugt aber zumindest schonmal der Fragmentierung aufgrund lokaler Gegebenheiten vor.

Die Werte Window Size (WIN) und Window Scale (WS) bestimmen ein Fenster. In der Netzwerkterminologie werden beide Werte auch oft als Receive Window (RWIN) zusammengefasst. Beide Werte hängen direkt zusammen, da WS eine nachträgliche Implementierung zu WIN ist, um der steigenden Performance der höheren Bandbreiten im Netz genüge zu tragen. WS (max. 14 Bit) bestimmt, um wieviele Bitstellen sich WIN (16 Bit) rechtsseitig (LSB) erweitert. Nachfolgend ein Beispiel:

Daraus lässt sich folgende allgemeine Formel ableiten: RWIN = WIN • 2^WS

Durch die Anwendung WS lässt sich RWIN von bisher maximal 64KB (WIN) auf bis zu etwa 1GB (WIN & WS) erweitern. WS wird nur während der Initialisierung (gesetztes SYN Flag) als Option übermittelt. Die Gegenstelle merkt sich fortan den Faktor für diese Verbindung und wendet ihn jedesmal auf aktualisierte Werte für WIN an, um lokal ein Sendefenster zu gebilden, welches der Größe von RWIN entspricht.

Die Auswirkungen von RWIN sind einfach erklärt. Zum einen bestimmt es die Größe des lokalen Empfangspuffers. Das bedeutet, sendet Host A ein Fenster von n Bytes an Host B, dann kann der lokale Empfangspuffer von Host A zu diesem Zeitpunkt auch mindestens n Bytes aufnehmen. Der lokale Empfangspuffer und RWIN stehen also immer in direktem Zusammenhang zueinander.

Für Host B bedeutet das RWIN von Host A, wieviele Bytes am Stück gesendet werden dürfen, bis zwingend auf eine Bestätigung (ACK) durch Host A zu warten ist. Damit hat RWIN von Host A auch eine direkte, wenn auch nicht alleinige Auswirkung auf das Sendefenster von Host B.

Tipp: Auch wenn der obige Mitschnitt der HTTP-Anfrage im ersten Moment den Eindruck erwecken kann, dass Host B erst wieder Segmente senden würde, wenn die entsprechende Bestätigung dafür eingetroffen ist (bspw. Bestätigung Nr. 07 und anschließende Bytes in Nr. 08), wird dies widerlegt, wenn man sich die Zeitabstände anschaut. Nr. 08 trifft schon 10ms nach dem Absenden der Bestätigung Nr. 07 ein. Bei einer RTT von etwa 60ms muss Host B diese Bytes also schon abgesendet haben, bevor Host A die die vermeintliche Genehmigung dafür erteilt hat. Dieses Verhalten ist auch völlig legitim, da die Bytes ab Nr. 08 noch im Sendefenster liegen, dass mit der letzten empfangenen Bestätigung mitgeteilt wurde (Win=66792 aus ACK Nr. 04).

Jetzt steht noch die Frage offen, anhand welcher Faktoren die Größe von RWIN überhaupt festgelegt wird. Das sind im Wesentlichen:

• Maximum Segment Size
  
• Füllstand des Empfangspuffers
• Bandwidth Delay Product (BDP)
  

Da die TCP-Puffer dazu verwendet werden, um Segmente zu puffern, beträgt RWIN grundsätzlich ein Vielfaches der MSS, auf die sich bei der Initialisierung geeinigt wurde.

Der Füllstand des Empfangspuffers ist ein lokaler Faktor und wird schlichtweg dadurch bestimmt, wie schnell die Zielapplikation die empfangenen Informationen aufnehmen kann, respektive wie schnell wieder Empfangspuffer frei wird. Bahnt sich ein Überlauf des Empfangspuffers an, muss dies dem Sender der Daten durch ein kleineres RWIN mitgeteilt werden. Dieser wiederum passt dann sein lokales Sendefenster umgehend an. Es kann also eine dynamische Anpassung erfolgen.

Der externe dynamische Faktor Bandwidth Delay Produkt (BDP) ermittelt die Anzahl der Bytes die man benötigt, um die Strecke zwischen Sender um Empfänger mit einem zusammenhängenden Bytestrom zu füllen:

Aufgrund der physikalisch bedingten Verzögerung (Signallaufzeit) bei der Datenübertragung, lässt sich zu jedem gegebenen Zeitpunkt die einfache Strecke zwischen zwei Teilnehmern mit einer bestimmten Menge an Bytes ausfüllen. Quasi die Bytes, die zum gegebenen Zeitpunkt den Sender schon verlassen, das Ziel jedoch noch nicht erreicht haben. Die Menge errechnet sich schlichtweg aus der maximalen Bandbreite der gesamten Strecke, multipliziert mit der Verzögerung. Um also die Bandbreite optimal ausnutzen zu können, muss der Kommunikationsprozess so aufeinander abgestimmt werden, dass sich möglichst zu jeder Zeit  so viele Bytes auf dem Weg vom Sender zum Empfänger hin befinden, wie das BDP hergibt. Im Folgenden einige Beispiele, wie sich das BDP bei unterschiedlichen Technologien auswirkt. (Satellit und DOCSIS sind mögliche Werte):

Anmerkung: Anbindung mit einem BDP >> 12,5KB ermöglichen, werden auch LFNs (Long Fat Networks) genannt.

Da nun aber die Bestätigung vom Empfänger zum Sender hin nochmal genau so lange dauert, vergeht folglich die zweifache Verzögerung. Daher lässt sich die theoretisch optimale Menge an Bytes die gesendet werden dürfen, bevor eine Bestätigung zu erwarten ist, auch mit der Round Trip Time berechnen. Im Resultat sollte ein effizientes RWIN also in etwa genau so groß sein, wie das BDP, multipliziert mit der zweifachen Verzögerung (Round Trip Time):

Soweit die Theorie zum Verhältnis vom BDP zum RWIN unter idealen und vorallem konstanten Bedingungen. Im Internet ist aber wenig ideal und noch weniger konstant. Daher haben sich im Laufe der Jahre verschiedene Ansätze entwickelt, wie man die Größe des Empfangspuffers möglichst effizient und trotzdem auf jede Verbindung universal anwendbar bestimmen kann. Diese Ansätze sind von Betriebssystem zu Betriebssystem unterschiedlich und würden den Rahmen dieses Beitrags sprengen. Allen ist jedoch gemein, dass dabei das BDP eine grundlegende Rolle spielt, damit ein möglichst kontinuierlicher Bytestrom zwischen Sender und Empfänger fließt und dabei nicht zu viele lokale Ressourcen (Speicher) verschwendet werden - der angestrebte Idealzustand:

Sollte die Zielapplikation (Browser) die Segmente nicht rechtzeitig aus dem Empfangspuffer entnehmen, muss der TCP-Prozess rechtzeitig ein kleineres RWIN in einer Bestätigung an den Sender übermitteln, so dass dieser im Resultat weniger Bytes sendet. Die Algorithmen nach denen bestimmt wird, wann genau der Empfänger ein kleineres RWIN übermittelt, hängt von der jeweiligen TCP Implementierung ab. Als Faustregel kann man aber sagen, dass der Empfänger spätestens beim Überschreiten von RWIN/2 im Empfangspuffer reagieren sollte.

Der Sendepuffer auf der Serverseite beinhaltet in jedem Fall alle fortlaufenden Bytes in der Größe von RWIN (8). Er kann aber auch größer sein. Im Gegensatz zum freien Empfangspuffer, der exakt dem übermittelten RWIN entspricht, ändert ein größerer Sendepuffer nichts am Sendefenster selbst.

Mit jeder empfangenen Bestätigung entfernt die Serverseite nun die bestätigten Bytes aus dem Sendepuffer und rückt neue Bytes ins Fenster nach, bis es wieder gefüllt ist. Würde die Serverseite im nächsten logischen Schritt ACK 18 (ink. RWIN 8) empfangen, dann werden 16 und 17 aus dem Fenster genommen, 24 und 25 rücken nach.

Betrachtet man die zu sendenen Bytes als aneinandergereihten Bytestrom, so kann man das Nachrücken auch so formulieren, dass das Sendefenster über den Bytestrom hinweggleitet. Dieses Verfahren nennt sich dementsprechend Sliding Window. Folgende Grafik soll dieses Prinzip veranschaulichen. Dabei wird auch eine Änderung von RWIN mit einbezogen:

Wie zu erkennen, ist es durchaus effizienter empfangene Bytes unabhängig von der Fenstergröße zu bestätigen. Bestätigungen (ACKs) erst nach dem Empfang eines kompletten Fensters zu senden, wurde zu unnötigen Leerlaufzeiten (jeweils RTT) führen.

Bisher wurde im Beitrag fast immer angenommen, dass die Kommunikation über TCP reibungslos verläuft. Der Sender also auch immer Bestätigungen (ACKs) für gesendete Segmente erhält. Nun sollen die Fehlerfälle genauer betrachtet werden.

Die Basis für die Erkennung von ausbleibenden Bestätigungen ist ein einfacher Timer, der für jedes jedes abgesendete Segment gestartet wird. Trifft keine Bestätigung (ACK) vor Ablauf des Timers ein, muss das Segment neu versendet werden. Dementsprechend nennt sich dieser Zeitrahmen in TCP Retransmission Time Out (RTO). Die Bestimmung vom RTO ist eine kritische Angelegenheit und keineswegs eine für die Dauer der TCP-Sitzung festgelegte Konstante. 

Alle neueren TCP-Implementierungen können mit jedem Segment einen Zeitstempel im Optionsfeld TSval übermitteln. Der Empfänger verschiebt dann den aktuellsten empfangenen Zeitstempel unverändert in das Optionsfeld TSecr und sendet ihn mit der nächsten Bestätigung (ACK) zurück. Zusätzlich übermittelt er einen eigenen Zeitstempel im Optionsfeld TSval. Der Sender kann damit jeweils die Verzögerung in Sende- und Empfangsrichtung exakt ermitteln.

Info:
LC = Local Clock
Delay = 50ms -> RTT = 100ms

LC Host A    TSval TSecr    Direction    TSval TSecr    LC Host B
...
0.100        100   50             -->    100   50       0.150
0.200        150   100      <--          150   100      0.150
0.200        200   150            -->    200   150      0.250
...

Aber auch ohne die Option der Zeitstempel kann ein Sender die RTT in etwa abschätzen, indem die Differenz zwischen dem Absenden und der Bestätigung eines Segments gemessen wird. In beiden Fällen wird die Round Trip Time über die Dauer der TCP-Sitzung ständig aktualisiert und angepasst (Round Trip Time Measurement; RTTM). Weiterführender Weblink

Ein Grund für ausbleibende Bestätigungen könnte sein, dass es auf dem Übertragungsweg zu einem Datenstau gekommen ist. Auch wenn die Teilnehmer einer TCP-Sitzung nichts davon mitbekommen, puffern auch Netzkoppelelemente wie Router Daten, um sie effizienter versenden zu können. Je nach Netzlast kann es aber auch da zu Überläufen kommen, so dass ankommende Bytes schlichtweg verworfen werden. Das einfache erneute Versenden bis zur Ausschöpfung des Sendefensters, würde zu einer Verschlimmerung der Situation bei den Routern führen. Dies kann bis hin zum Abbruch der Verbindung führen.

Daher vermutet der Sender bei ausbleibenden Bestätigungen (ACKs) grundsätzlich einen Datenstau als Ursache und wendet dann den Congestion Control Algorithmus an. Parallel zu RWIN wird das Sendefenster dabei zusätzlich durch das Congestion Window (CW) begrenzt. Dies kann man als zweites Fenster ansehen, welches über das Sendefenster gelegt wird und ebenfalls eine dynamische Größe annehmen kann. Die obere Grenze der zu sendenden Bytes, wird jeweils durch das kleinere der beiden Fenster (RWIN/CW) bestimmt:

Zu Beginn hat das CW die gleiche Größe wie RWIN. Kommt es zu einem Time Out, wird das CW auf den Startwert von 1 Segment gesetzt. Damit wird auch das Sendefenster auf 1KB begrenzt. Nach jeder erneuten Bestätigung wird das CW dann verdoppelt, bis es einen Schwellwert erreicht. Zu Beginn des Congestion Control Algorithmus beträgt dieser in der Regel RWIN/2. Wird der Schwellwert erreicht, vergrößert sich das CW nach jeder Bestätigung nur noch im 1 Segment. Kommt es wieder zu einem Time Out, dann startet der Congestion Control Algorithmus von vorne, allerdings diesmal mit einem Schwellwert, welcher der Hälfte der Segmentmenge entspricht, bei der der letzte Time Out stattgefunden hat. Ansonsten wird genau so verfahren, wie bisher. Dieses Prinzip setzt sich so lange fort, bis das CW die Größe von RWIN schneidet. Ab da entspricht das Sendefenster wieder RWIN.

Ein anderer Grund könnte aber auch sein, dass die gesendeten Daten einfach verlorengegangen sind. Beispielsweise durch die Verfälschung von Signalen durch EMI/RFI. Auch wenn dies in den heutigen kabelgebundenen Netzen eher selten der Fall ist, tritt dieses Problem mit dem Einzug von drahtlosen Verbindungen (WLAN, UMTS) wieder häufiger auf. Auch ein eintreffen der Segmente in unterschiedlicher Reihenfolge ist aufgrund von Reflektionen keine Seltenheit. In diesen Fällen würde ein Senken der Übertragungsleistung, wegen der fälschlichen Annahme eines Datenstaus, keinen Nutzen mit sich ziehen und nur unnötig den Durchsatz verringern.

Offensichtlich sind die Mechanismen Fast Retransmit/Fast Recovery allerdings recht kompliziert. Zudem wird grundsätzlich vom Verlust aller Bytes ab den Duplicate Acks ausgegangen, was nicht zwangsläufig der Fall sein muss. Mit den Selective Acknowledgements (SACKs) geht man deshalb einen anderen Weg. Wird bei der Initialisierung (SYN) die Möglichkeit von SACKs mitgeteilt, dann kann der Empfänger dem Sender genau mitteilen, welche Bytes ihm bei einer lückenhaften Übertragung fehlen. Damit reduziert sich der Overhead für die Korrektur und der Vorgang wird schneller abgeschlossen. Weiterführender Weblink

Damit wären alle wesentlichen Punkte zu Mechanismen und Verfahrensweisen von TCP erläutert. Abschließend soll noch der Header von TCP genauer betrachtet werden. Bereits im Beitrag behandelte Flags oder Felder werden nur oberflächlich angesprochen:

• Source Port / Destination Port
  Der Quell- und Zielport bestimmen zusammen mit der Quell- und Zieladresse aus dem IPv4-Header die an der TCP-Sitzung teilnehmenden Sockets.
• Sequence Number / Acknowledgement Number
  Fortlaufende Nummerierungen, die im Zusammenspiel eine Auskunft über den aktuellen Stand der Datenübertragung geben. 
• Data Offset
  Größe des TCP-Headers (Wert • 32 Bit). Je nach Größe des Optionsfeldes kann dieser Wert variieren. Mit dem Data Offset wird der Beginn der Nutzdaten (segmentierte Daten) gekennzeichnet.
• Reserved
• URG (Urgent Flag)
  Wird das Urgent Flag von einer Applikation gesetzt, dann haben die Nutzdaten absoluten Vorang bei der weiteren Bearbeitung. Der Beginn dieser vorrangigen Daten inerhalb des Datenfeldes wird durch den Urgent Pointer markiert. Ein Beispiel für den Einsatz wäre der Abbruch eines Prozesses per Tastenkombination über Telnet.
• ACK (Acknowledgement Flag)
  Das Acknowledgement Flag bestätigt im Zusammenspiel mit der Acknowledgment Number 1:1 die empfangenen Bytes. Ausnahmen von dieser Regel stellen der Verbindungsaufbau und der Verbindungsabbau dar.
  
• PSH (Push Flag)
  Bei gesetztem Push Flag werden Segmente umgehend gesendet und beim Empfänger direkt an die Zielapplikation weitergeleitet. Ein Zwischenspeichern in den Puffern findet hier nicht statt.
• SYN (Sync Flag)
  Das Sync Flag wird nur beim Verbindungsaufbau (3-Way-Handshake) verwendet.
• FIN (Finish Flag)
  Das Finish Flag wird nur beim Verbindungsabbau (Teardown) verwendet.
• Window
  Im Feld Window übermittelt ein Teilnehmer der Gegenstelle stetig den aktuell freien Empfangspuffer in Bytes.
• Checksum
  Mit der Prüfsumme können Übertragungsfehler festgestellt werden. Die Besonderheit bei der Berechnung der Prüfsumme für TCP liegt darin, dass TCP für die Berechnung der Prüfsumme auch auf Bestandteile des Internet Protokolls (Schicht 3) zurückgreift. Der Grund dafür beruht im Wesentlichen darauf, dass es Netzkoppelelemente in den frühen Zeiten des Internets (und davor) an Zuverlässigkeit mangeln ließen und die Eigenschaft der Zuverlässigkeit des TCPs nur auf diese Weise gewährleistet werden konnte. Neben den Nutzdaten wird durch die Prüfsumme also auch immer der korrekte Socket geprüft.
• Urgent Pointer
  siehe Urgent Flag
• Options
  Maximal kann das Feld Options eine Größe von 40 Bytes annehmen (10 • 32 Bit). Reichen die Informationen nicht aus, um es auf 32 Bit zu schaffen, werden sie mit Fülldaten (Padding) auf 32 Bit aufgefüllt.  Im Feld Options werden die Informationen hinterlegt, für die im oberen Bereich des Headers kein Platz mehr vorhanden ist. Dazu zählen beispielsweise Window Scale, die MSS oder Timestamps.