Netzwerk-Analyse mit Wireshark: TCP-Fehlerkorrektur beobachten

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 Sequenz­nummern beginnend mit 0, und zwar für Client und Server.

Jeder der Partner erhöht im Verlauf der Kommu­nikation die Sequenz­nummer um die Anzahl der gesendeten Bytes. Zur Analyse der Fluss­kontrolle kann es daher hilfreich sein, die relativen Sequenz­nummern 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 Infor­mationen 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

sein, weil diese im Rahmen des TCP-Handshakes immer einfach um 1 erhöht wird. Beim Handshake selbst werden keine weiteren Daten gesendet.

Werfen wir noch einen Blick auf das dritte Paket des Handshakes.

Hier ist die Sequence-Number des Clients nun 3759279678, die Next-Sequence-Number wieder 3759279678  (denn auch der Server hat ja im Rahmen des Handshakes noch keine Daten gesendet) und die Acknowledgment-Number nun

842592582 + 1 = 3842592583

Dabei handelt es sich um eine beim TCP-Three-Way-Handshake um 1 erhöhte Sequenz-Nummer.