Warum ist ACK = 1 und nicht 2 in der ersten TCP-Anfrage nach dem Verbindungsaufbau?

Ich bin verwirrt über die ACK-und SEQ-Nummern im TCP-Pakete gleich nach dem 3-way-handshake. Ich dachte, dass die ACK-Nummer das nächste erwartete SEQ-Nummer.
Also, wenn ich die analyse eines TCP-Verbindung in Wireshark es sagt

TCP SYN with SEQ=0  
TCP SYN ACK with SEQ 0, ACK=1 (clear, server expects SEQ 1 in next packet)  
TCP ACK with SEQ 1, ACK=1 (clear, sender expects SEQ 1 in next packet)  

HTTP Request: TCP PSH ACK with SEQ 1, ACK=1

Die Letzte Zeile ist unklar. Ich würde sagen, der sender erwartet SEQ=2 weiter, so sollte es sein, ACK=2? Es wurde bereits ein Paket mit SEQ=1 vom server, warum macht der sender noch ein weiteres wollen?

Kann mir das jemand erklären?

InformationsquelleAutor cronor | 2011-04-05

  1. 6

    Gut, in der handshake der client erhält nur ein Paket vom server: SEQ=0 und ACK=1. Mit dieser information teilt der server dem client "ich warte auf ein Paket mit SEQ=1 jetzt'. Sie haben dieses Recht.

    Nun, im letzten Teil des Handshakes sendet der client eine SEQ=1 und ACK=1, was im Grunde bedeutet, die gleiche wie vom server: 'ich warte auf dein Paket mit SEQ=1'

    Aber: Nach einem TCP-handshake, wird der Kunde in der Regel nicht warten, für dieses Paket zu acked, sondern senden der ersten Daten-Pakete, die bereits (in der Tat, können die Daten bereits innerhalb der letzten Paket des Handshakes - ich nehme an, dies ist der Fall in deinem Beispiel, weil der HTTP-Anfrage hat die gleiche SEQ-wie die letzten handshake-Paket). Also jede nächste Paket wieder ACK=1. Aber warum? Er wieder sagt " ich warte auf ein Paket mit SEQ=1 aus. Und dieses vollkommen Sinn macht: Das Letzte Paket des Clients vom server empfangen hatte SEQ=0 (handshake). Bedenken Sie auch, dass beide client-und server-unabhängige SEQs. Das bedeutet, dass der Kunde versenden 100 Pakete. Solange der server nicht senden, würde der Kunde immer noch warten auf ACK=1, weil das Letzte Paket, das er vom server empfangen hat SEQ=0

    Noch Ein Edit:
    Um wirklich zu verstehen, was Los ist, möchten Sie vielleicht ein Beispiel wählen, mit unterschiedlichen Beginn SEQs (ich schrieb ja schon, SEQs von server-und client-unabhängig):

    Client -> SYN, SEQ=100
Client <- SYN, ACK, SEQ=700, ACK=101 <- Server
Client -> ACK = 701, SEQ=101 [50 Bytes of data]
Client -> ACK = 701 [Again, didn't receive sth from server yet], SEQ = 151
    Warum kommt die Linie 4 nutzen SEQ 1 wieder?
    In der Regel sollte dies nicht werden 1 wieder, wenn es ein neues Paket. Ich nehme aber an, dass der HTTP-Anfrage ist in der Tat das Letzte Paket des Handshakes. Das ist etwas unklar in meiner Antwort, ich werde es Bearbeiten
    Zeile 4 verwendet, SEQ 1, weil die ACK-Pakete nicht zur Erhöhung der SEQ Zähler und Zeile 3 ist nur ein ACK.
    Vielleicht bin ich in der Lage zu stoppen Verwirrung jetzt 😉 Siehe mein edit
    Ich glaube nicht, dass es jetzt. Die ACK in der 3-way-handshake enthält keine Daten. Es ist ein schlichtes ACK. Und die, die nicht erhöhen die Sequenznummer.

    InformationsquelleAutor Chris

  2. 1

    Acknowledgement-Nummer (32 bit) – wenn das ACK-flag gesetzt ist, dann ist der Wert dieses Feldes wird die nächste Sequenz-Nummer, die der Empfänger erwartet. Dieser bestätigt den Erhalt aller vorherigen bytes (wenn vorhanden). Das erste ACK gesendet, die von jedem Ende erkennt Sie das andere Ende initial sequence number selbst, aber keine Daten.

    So dass Sie einfach erkennen, wo Sie starten sollten.

    TCP auf Wikipedia

    InformationsquelleAutor bogdan.mustiata

Schreibe einen Kommentar