Do sequence and acknowledgment numbers treat 3-Way Handshake differently?

Question

1- Just as the message ID that is assigned to each message in PAR, the "sequence number" is a means of providing reliability in a transfer of a byte stream. So sequence numbers are assigned to every single byte.

2- But not all the bytes are acknowledged because that would be too slow. So (according to Kozierok's book) seq# and ack# are planned to be only the number of the first byte of a sent segment and the number of the last byte of a received segment respectively. (ignoring all the nuances here like accumulative/selective acknowledgment and etc, since they are irrelevant to the questions here).

3- Through the exchange of the first three packets, the ISN of each side is announced to the other side and acknowledged(Thank you Eddie). But, in the third packet exchange, when the client is acknowledging the reception of the server's ISN, the seq# and ack# are both 1.

4- Here are my two questions:

Question 1: ISN (like seq#) is a 32-bit number, i.e 4 bytes. So Why isn't the ack# returned by the server, 3 (counting from 0) instead of 1 in the second packet exchanged? And similarly why aren't both the seq# and ack#, 3 instead of 1 in the third packet exchanged? Is this an exception* forced by those who designed the protocol or there are other reasons?

Now, in case the answer is that these initial incrementings are exceptionally counted as only 1 byte, then it brings us to a second question:

Question 2: Why do we engage the ISN exchange in seq# & ack# incrementing at all? One might say we have no other ways of announcing acknowledgements other than changing the ack#, but IMO that's not true. Both the server and the client could just check the SYN and the ACK flags to realize everything.

So where am I wrong? Please let me know if there's anything I've understood wrong. Thank you in advance.

---

* It is not explicitly stated anywhere I've checked that this is an "exception", but I've found this article which says: "SYN, FIN or ZeroWindow segments count as 1 byte for SEQs/ACKs.". So my personal interpretation from this line is that we're talking about an "exception".

Answer 1

So (according to Kozierok's book) seq# and ack# are planned to be only the number of the first byte of a sent segment and the number of the last byte of a received segment respectively.

Either you misinterpreted what the book says, or the book is wrong. The acknowledgement number is not the last number of the sent segment, it is the sequence number of the next expected segment. The acknowledgement number, when combined with the ACK flag, tells the other side that is acknowledges all data prior to the acknowledgment number, but the number itself represents the next expected sequence number.

You should read RFC 793, Transmission Control Protocol, which is the definition of TCP. That is clearly explained in the RFC:

2.6. Reliable Communication

A stream of data sent on a TCP connection is delivered reliably and in order at the destination.

Transmission is made reliable via the use of sequence numbers and acknowledgments. Conceptually, each octet of data is assigned a sequence number. The sequence number of the first octet of data in a segment is transmitted with that segment and is called the segment sequence number. Segments also carry an acknowledgment number which is the sequence number of the next expected data octet of transmissions in the reverse direction. When the TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgment for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted.

An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the responsibility to do so.

To govern the flow of data between TCPs, a flow control mechanism is employed. The receiving TCP reports a "window" to the sending TCP. This window specifies the number of octets, starting with the acknowledgment number, that the receiving TCP is currently prepared to receive.