Bei Verwendung von TCP müssen Geräte zuerst eine Verbindung mit einem Peer-System
herstellen,
bevor die Datenübertragung stattfinden kann, sodass eine verbindungsorientierte
Sitzung zwischen Host A und Host B eingerichtet wird.
Protokollsoftwaremodule in den Betriebssystemen der Hostgeräte kommunizieren miteinander, indem sie Nachrichten
über das Netzwerk senden, um zu überprüfen, ob die Übertragung autorisiert
ist und dass beide Seiten
für die Datenübertragung bereit sind.
Damit dies geschieht, erfolgt ein Drei-Wege-Handshake zwischen den Hostgeräten, die TCP verwenden.
Der Host, der die Sitzung initiiert, setzt also das SYN-Flag oder das SYN-Bit im TCP-Header
des ersten Segments, das an Host B gesendet wird.
Host A wählt auch eine anfängliche Sequenznummer, die in
diesem Beispiel 100 ist.
Das Steuerflag SYN wird also gesetzt und die
Folgenummer wird auf einen Anfangswert von 100 gesetzt.
Damit wird der Handshake-Vorgang gestartet.
Dieses Synchronisationssegment gibt auch die Nummer des Ports an, zu dem der Absender eine
Verbindung herstellen möchte, beispielsweise für Port 80 oder HTTP.
Der Host auf der rechten Seite wartet auf eine Verbindungsanfrage vom Remote-Client, in
diesem Fall Host A.
Wenn SYN empfangen und akzeptiert
wird, sendet Host b ein TCP-Segment mit gesetzten SYN- und ACK-Flags zurück.
Die Steuerflags SYN und ACK werden also gesetzt und
verwendet, um die Verbindung auszuhandeln und den Empfang des
Initialsynchronisationssegments des Senders zu bestätigen.
B legt auch eine Anfangssequenznummer fest, um die
nächste Sequenznummer des nächsten Datenbytes anzugeben, das von
Host A erwartet wird.
Host B setzt auch das Bestätigungsflag auf, in diesem
Fall 101 zeigt ein ACK-Flag den nächsten Teil der Daten an, den der Host erwartet.
Also sendete Host A zunächst eine Sequenznummer von 100 und
Host B, in diesem Fall wurde von einer Fenstergröße von 1 eine Bestätigung
von 101 zurückgesendet.
Der dritte Schritt des Dreiwege-Handshakes besteht darin, dass der initiierende Host
in diesem Fall Host A die SYN von Host B empfangen hat und ein TCP-Segment zurücksendet, wobei das
Steuerfeld auf ACK gesetzt ist. 36 Host A bestätigt daher das nächste Segment, das er voraussichtlich
von Host B in diesem Fall 301 empfangen wird, wobei Host B zunächst eine Sequenznummer von 300 gesendet hat.
Host A erwartet also das nächste Segment 301.
Host A setzt die Sequenznummer auf 101.
Das erste gesendete Segment war 100 und das nächste Segment ist in diesem Fall 101, da das SYN-Bit
oder das SYN-Flag nicht
gesetzt ist. Dies bestätigt, dass der Dreiwege-Handshake erfolgreich abgeschlossen wurde.
Zur Wiederholung senden die Steuerbits oder Flags zunächst ein Segment, bei dem
das SYN-Bit oder das SYN-Flag gesetzt ist.
Das Steuerflag SYN wird also auf 1 gesetzt. 46 Host B im zweiten Schritt des
Dreiwege-Handshakes setzt seine Steuerflags oder Bits auf SYN ACK.
Mit anderen Worten, das SYN-Bit wird auf
1 und das ACK-Bit auf 1 gesetzt.
Im letzten Schritt des Dreiwege-Handshakes
setzt Host A das ACK-Bit auf 1 oder das ACK-Flag wird auf gesetzt.
Das SYN-Bit oder das SYN-Flag wird auf 0 gesetzt, um anzuzeigen,
dass der Dreiwege-Handshake erfolgreich abgeschlossen wurde.
Nun können Sequenznummern und Bestätigungen viel Verwirrung stiften. Ich werde sie jetzt
genauer erklären.
Wir gehen in diesem Beispiel davon aus, dass eine Fenstergröße von 1 verwendet wird.
Wenn Sie sich jetzt daran erinnern, ist die Fenstergröße die maximale Datenmenge,
die der Empfänger von einem Sender empfangen und korrekt verarbeiten kann. 59 Wir gehen also davon aus, dass zu
jedem Zeitpunkt nur ein Segment gesendet werden kann, bevor eine Bestätigung empfangen
wird, um den Empfang dieses Segments zu bestätigen.
Nehmen wir an, A beginnt mit einer anfänglichen Sequenznummer von
5, da bei einer Fenstergröße von 1 nur 1 Segment von A nach B gesendet werden kann.
B empfängt das Segment erfolgreich von A und
bestätigt das nächste Segment, das es empfangen möchte.
Anstatt den Empfang der Sequenznummer 5 zu
bestätigen, wird die Sequenznummer
6 bestätigt, was bedeutet, dass alle vorherigen Sequenznummern korrekt empfangen werden.
Also bestätigt B in diesem Fall die Folgenummer 6, aber B kann
mit einer Anfangsfolgenummer von 10 beginnen. 71 In dem TCP-Header teilt B daher A mit,
dass seine ursprüngliche Sequenznummer 10 ist und dass seine erfolgreich erhaltene Sequenznummer 5 von A
und die Sequenznummer 6 von A im nächsten Paket erwartet wird.
Nehmen wir an, dieses Segment wurde erfolgreich empfangen,
so dass A nun Segment 6 an B sendet, mit anderen
Worten, die nächste Folgenummer.
A bestätigt auch den Empfang von Segment 10 von Host B.
So hat A das Segment mit der Sequenznummer 10 erfolgreich erhalten.
Bitte beachten Sie
noch einmal, dass der Host die
anfänglichen Sequenznummern zufällig auswählen kann. Daher
müssen beim anfänglichen Dreiwege-Handshake die Informationen zwischen den beiden
Hosts kommuniziert werden, damit sie wissen, was die ursprünglichen Sequenznummern sind. 84 Also sendet A erneut Sequenznummer 6 an B und quittiert Sequenz 11.
Nehmen wir an, B empfängt dieses
Segment erfolgreich und wird daher für Segment 7 bestätigt.
Das nächste Segment, von dem erwartet
wird, dass es erneut 7 in der Bestätigung erhält, zeigt an, dass das vorherige Segment erfolgreich empfangen wurde.
Host B sagt also durch Setzen der Sequenznummer auf 7, dass
Sequenznummer 6 erfolgreich empfangen wurde.
Host B sendet die Sequenznummer 11, da dies die
nächste Sequenznummer ist, die A erwartet, zu empfangen.
Zu beachten ist noch einmal, dass die anfänglichen Sequenznummern,
die der Host erwartet, und die Sequenznummer von
beispielsweise 11 implizieren, dass die Sequenznummer 10 und die vorherige Sequenznummer erfolgreich empfangen wurden.
Nun verhindert die Flusskontrolle erneut ein Problem, bei dem der Sender so viele Daten sendet
99 dass die Puffer des Empfängers überlaufen.
Wenn dies eine sehr leistungsfähige Maschine ist und dies eine ältere Maschine ist das ist nicht so mächtig, es ist möglich, dass A überrannt wird die Puffer von B, weil es so viele Daten sendet. 103 Daher benötigt B einen Mechanismus, um A die Verlangsamung mitzuteilen, damit D
den empfangenen Datenverkehr erfolgreich verarbeiten kann. 105 Nehmen wir als Beispiel an, dass die Fenstergröße in diesem Beispiel 3
und nicht 1 ist. 107 A kann also drei Datensegmente senden, bevor er eine Bestätigung erhält. 108 Der Vorteil der Vergrößerung der Fenstergröße ist der Durchsatz kann dramatisch ansteigen, da ein Host mehr Daten senden kann mit weniger Bestätigungen und daher verringern sich die Rundfahrtzeitgeber dramatisch. 111 In diesem Beispiel sendet A also 3 Segmente an B. 112 Nehmen wir an,
der empfangene Puffer von B ist voll und kann diese Datenmenge nicht verarbeiten 114 B sendet eine nicht betriebsbereite Anzeige an A 115 Dies geschieht, indem Sie die Fenstergröße auf 0 setzen.
Dadurch wird der Absender angewiesen, das Senden von Daten zu stoppen und warten Sie auf die Bereitschaftsanzeige vom Empfänger. 118 Angenommen, Host B konnte die Daten jetzt verarbeiten in seinem Empfangspuffer und kann jetzt mehr Daten empfangen. 120 Es kann einen Bereitschaftsindikator an A senden, damit dieser das Senden von Datagrammen fortsetzen kann.
so nimmt A die Übertragung wieder auf, indem es beispielsweise 3 Segmente an B sendet. 122 Weil die Fenstergröße 3 ist. 123 Beachten Sie bitte, dass der TCP-Host im Hintergrund verschiedene Parameter aushandeln kann, und
eine davon ist die Flusssteuerung 125 wo ein Empfänger einen Absender anweisen kann, langsamer zu werden oder das Senden von Daten zu stoppen 126 bis der Empfänger über Pufferplatz verfügt, um gesendete Segmente zu empfangen.
Dies ermöglicht die Kommunikation zwischen einem sehr mächtigen oder eine schnelle Maschine und eine langsamere oder weniger leistungsfähige Maschine wo sie die Übertragungsrate aushandeln können.