In einer TCP-Session erkennt der Empfänger anhand von Sequence Numbers, ob Pakete in der richtigen Reihenfolge bzw. mehrfach eintreffen. Mit Acknowledgments bestätigt er den korrekten Empfang oder veranlasst eine erneute Übertragung. Dieser Vorgang lässt sich in Wireshark gut nachvollziehen.
Die folgende Abbildung illustriert die Sequence- und Acknowledgment-Nummern, mit deren Hilfe TCP die Fehlerkorrektur und die Flusskontrolle realisiert.
Wie in einem früheren Beitrag gezeigt, generiert jeder der Partner beim Aufbau einer TCP-Verbindung eine zufällige, 32-Bit lange Sequence Number. Wireshark ersetzt diese lediglich der Übersicht halber durch relative Sequenznummern beginnend mit 0, und zwar für Client und Server.
Jeder der Partner erhöht im Verlauf der Kommunikation die Sequenznummer um die Anzahl der gesendeten Bytes. Zur Analyse der Flusskontrolle kann es daher hilfreich sein, die relativen Sequenznummern zu deaktivieren.
Das sieht dann für das erste SYN-Paket so aus:
Dabei vermerkt jeder der Partner in der Zeile „[Next sequence number:]“ eine Folge-Sequenz-Nummer. Hierbei handelt es sich immer um genau diejenige Acknowledgment-Number, die als nächste von der Gegenstelle erwartet wird.
In der Abbildung oben ist die zufällige Start-Sequenz-Nummer des Clients 3759279677. Die eigene Acknowledgement-Number ist noch 0, da der Client noch keine anderen Informationen vom Server erhalten hat.
Die Next-Sequence-Number ist identisch mit der eigenen Sequence Number 3759279677, da noch keine Daten vom Client gesendet wurden. Werfen wir nun einen Blick in das zweite Paket:
Die beliebige Start-Sequenze-Number des Servers ist 3842592582. Demnach ist der Wert für Next-Sequence-Number ebenfalls 3842592582, da von hier ebenfalls noch keine Daten gesendet wurden.
Die Acknowledgement-Number muss allerdings
3759279677 + 1 =3 759279678