Rationale behind ACKs and SEQs?

Question

I am not sure if people find this obvious but I have two questions:

1. During the 3-way handshake, why is ACK = SEQ + 1 i.e. why am I ACKing for the next byte that I am expecting from the sender?
2. After the handshake, my ACK = SEQ + len. Why is this different from the handshake? Why not just ACK for the next byte I am expecting as well (the same as during the handshake)?

I know I must've missed out a basic point somewhere. Can someone clarify this?

Answer 1

During the handshake you're synchronizing. The sequence number is the known data. Once you've synced, the data length is the known data as well as a useful pseudo-random verifier. Sender knows how much he sent and if you reply, he assumes you got it. This is easier than reply with, say a checksum or hash of the data, and is usually sufficient.

Answer 2

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

Answer 3

Both the SYN and FIN flags cause the sequence number of the stream to increment by one. Thus

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

Is your three way handshake. It's done that way because SYNs and FINs require acknowledgement of receipt. That way everyone can be on the same page during the lifetime of the connection.

Theoretically any packet in part of the TWHS could have payload, but if either of the packets with the SYN flag set have payload, the opposite side needs to acknowledge both data AND the flag.