All geek questions in one place

Justification for ACK and SEQ?

I'm not sure people find this obvious, but I have two questions:

  • During a three-way handshake, why is ACK = SEQ + 1, then why am I ACKing for the next byte that I expect from the sender?
  • After a handshake, my ACK = SEQ + len. Why is this different from a handshake? Why not just an ACK for the next byte I expect (same as during a handshake)?

I know that I must have missed the base point somewhere. Can anyone clarify this?

+4
source share
3 answers

This is because the first byte of the serial number corresponds to the SYN value, not the data byte. (The FIN flag at the end also consumes the byte of the sequence number itself.)

+6
source

During a handshake, you synchronize. The sequence number is known data. After you are synchronized, the length of the data is known data, as well as a useful pseudo-random verifier. The sender knows how much he sent, and if you answer, he assumes that you received it. This is easier than responding with, say, a checksum or data hash, and usually that's enough.

+3
source

Both SYN and FIN flags cause the stream sequence number to increase by one. Thus,

SYN (seq x) --------------> <--- SYNACK (ack x+1, seq y) ACK (seq x+1, ack y+1) --->

This is your three-way handshake. This is because the SYNs and FINs require acknowledgment of receipt. Thus, everyone can be on the same page for the entire life of the connection.

Theoretically, any packet in the TWHS part may have a payload, but if any of the packets with the SYN flag set has a payload, the opposite side must confirm both the data and the flag.

0
source

Source: https://habr.com/ru/post/1302790/

More articles:


All Articles