13

In the 3-way handshake, the initial sequence number of both endpoints of the TCP connection is synchronized.

Here is an example:

  • Endpoint A randomly generates an initial sequence number: 123.
  • Endpoint B randomly generates an initial sequence number: 678.

The endpoints agree that A will send the first data segment starting from 124, and endpoint B will start from 679.

enter image description here

Perfect.

However, I don't understand why they don't agree on sending their first data segment with their initial sequence numbers. Why don't they do something like this:enter image description here

As you can see, there is no increment in the sequence number when the SYN packets are sent (because the data octet they send is 0). Therefore, the endpoints could agree that A will send the first data segment starting from 123, and endpoint B will start from 678.

What is the reason why the TCP protocol uses the "increase by 1" logic in the presence of a SYN segment, even if the data octet is 0?

Improve this question
5
  • You've been told the answer several times already, with references. Third time you've posted this question.
    – user207421
    Jul 15 at 4:37
  • @user207421 From the brilliant Eddie answer, I understand why TCP has been designed in that way for FIN segments. Without the phantom byte logic, the protocol doesn't work. However, I believe that without the phantom byte logic, the protocol would still work for SYN segments. The TCP has been designed in this way primarily for consistency reasons. Do you agree with this perspective, or do you think there are other reasons why the SYN segments should have the phantom byte logic? (Please provide your own answer without references.)
    – ilBarra
    Jul 15 at 6:35
  • @ilkkachu: their two most recent posts on Stack Overflow: Why in TCP the first data packet is sent with "sequence number = initial sequence number + 1" instead of "sequence number = initial sequence number"? and Why in the 3 Way handshake the SYN packet cause an incremented ACK?
    – Peter Cordes
    Jul 16 at 20:22
  • @ilkkachu: They have comments like "RFC 793 #3.3 Sequence Numbers states that both SYN and FIN have sequence numbers, and explains why." which user207421 clearly felt was sufficient to point them in the right direction. I haven't looked into the details of what was asked and commented to decide whether that was a reasonable thing to say or not, but it's obviously what they're referring to.
    – Peter Cordes
    Jul 16 at 21:10
  • @PeterCordes, yes, perhaps. But I wasn't planning on arguing about this with you, so I'll leave it here. G'night.
    – ilkkachu
    Jul 16 at 21:25

1 Answer 1

Reset to default
22

This "bump the sequence# forward by 1 for SYN and FIN flags" is sometimes referred to as the "Phantom Byte" -- since no actual byte of data is sent, but the presence of the SYN or FIN flag still increased the sequence number by 1.

The why behind it I think is easier to see with the FIN than it is for the SYN. And to show it I'll use this screenshot:

12 simple ideas to understand TCP

(source: TCP - 12 simple ideas to explain the Transmission Control Protocol @ ~38:05)

In this illustration, Alice & Bob are closing a TCP connection using FIN flags. Here is a quick description of the first 4 packets:

  • Packet#1 is Alice sending her last 200 bytes of data, SEQ 1401
  • Packet#2 is Bob acknowledging reception by sending ACK 1601
  • Packet#3 is Alice closing her side of the connection with a FIN, SEQ 1601
  • Packet#4 is Bob acknowledging reception by sending ACK 1602

Look at packet#2 and #4 -- notice one was Bob sending ACK 1601, and the other was ACK 1602. Notice the packets are identical, except for the ACK#

If the phantom byte didn't exist, then the ACK in packet#4 would (still) be 1601... and Alice would not be able to differentiate between packet#2 and packet#4 -- Which means Alice would not be able to determine whether this simply a resend or duplicate copy of packet#2, or a new ACK altogether.

the Phantom byte allows Bob to explicitly acknowledge the FIN, independent from acknowledging reception of data.

The same effect occurs a bit later with Packet #7 and #9 -- the increase of the ACK# sent by Alice allows us to differentiate these two packets:

  • Packet#7 is Alice ACKnowledging receiving the last byte of Data
  • Packet#9 is Alice ACKnowledging receiving the FIN from Bob

Granted, that explains the Phantom Byte from the FIN perspective, but maybe not exactly with the SYN. My best guess is TCP chose to use the Phantom Byte strategy for the SYN as well to keep things consistent.

The general rule with TCP is anything that TCP intends to have acknowledged will increase the Sequence number: Data, FIN packets, and SYN packets.

Disclaimer: I created the video from which the screenshot above was taken.

Improve this answer
3
  • 3
    What an answer! Thank you Eddie a learnt a lot and I will also follow your youtube channel. I am new in the world of networking. Why you don't investigate a little bit with your connections about this so we will discover if about "SYN" your guess is true? Thank you again
    – ilBarra
    Jul 13 at 19:53
  • 1
    @ilBarra: if you like the answer so much, don't forget to click the grey check-mark below the score turning it into a beautiful green! ;-)
    – Fabby
    Jul 14 at 21:43
  • 1
    I check-marked the answer for the consensus it received. I was thinking that there were other reasons for that design choice instead looks like they did it just for consistency one.
    – ilBarra
    Jul 15 at 3:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.