Vaishali,
The reason for more than two steps is because TCP works in both directions between two hosts. This means that each host needs its own two step process to establish a TCP relationship. So the real question is why isn’t a 3-way handshake a 4-way handshake? If you look at what is happening during the second step, you see that both a SYN and an ACK are happening, so this actually saves a step by doing two separate things in one step.
Imagine it this way:
Host A and Host B want to establish a TCP relationship.
A TCP relationship is bi-directional, so there needs to be two relationships established, A-B and B-A. Each of A-B and B-A requires two messages to complete (SYN and ACK). So here’s the three-way handshake:
A-B (SYN)
A-B (ACK), B-A (SYN)
B-A (ACK)
Take a look at Step 2. Each of the messages, A-B (ACK) and B-A (SYN) are originating with Host B and going to Host A. This means these messages can be combined to save a step. This is why a 3-way handshake is not a 4-way handshake.
I want to know if the last sequence number of the three way handshake is the same after the hanshake?
The quick answer is yes. Now for more detail. When a TCP session begins, a sequence number is chosen to begin the handshake. This very first sequence number is random. (However, if you look at the sequence numbers portrayed in Wireshark, you’ll see that it starts at 1. This is the RELATIVE sequence number, as it states in Wireshark. It is displayed in this way for simplicity.) Once the handshake is over and data is being sent, the sequence numbers that are used are in succession to the initial sequence numbers chosen during the handshake.
It only adds 1 when handshaking, but not during data transfer?
Yes, during the handshake, the ACK number that is returned by the second party is the original Sequence number plus 1. This is done to identify that this ACK is in response to the specific SYN request that started the handshake. So, during the handshake, the purpose of adding 1 is to indicate which request the acknowledgement is a response to.
Once the handshake is complete, the sequence and acknowledgement numbers have a different purpose. They are no longer incremented sequentially, but they are incremented based on the number of bytes the host is expecting to receive before needing to send the next set of data. This functionality is part of a mechanism called Windowing or Window Scaling which Rene explains here: https://networklessons.com/cisco/ccna-routing-switching/tcp-window-size-scaling/
This mechanism with the sequence and acknowledgement numbers can be more clearly understood in the diagram I have attached to this post.
The diagram is correct. Once the three way handshake is complete, the initiator of the session increments the sequence number sent in the 3rd portion of the handshake (SEQ=101) by 1 and sends a sequence number of 102 in the first segment of communication. I’m assuming the three numbers displayed in each communication are SEQ, ACK and Window Size in that order.
Yes, once the handshake is completed, the initiator of the handshake begins transmission. This very first segment should have SEQ_segment1 = SEQ_third_handshake + 1.
As for the PSH flag, I couldn’t tell you off the top of my head so I did a wireshark capture and tried to verify your findings. I was unable to duplicate what you described. In any case, the PSH flag is used to indicate to the receiver that the segment that has entered the buffer can be pushed up the stack. In other words, it doesn’t need to wait for additional data to come to the buffer to fill it up before being pushed up, thus increasing speed and efficiency. The ACK that returns from such a situation should be the last SEQ that was received + 1, or in other words, the sequence number of the next byte the receiver is expecting. I can’t see how the PSH flag could make a difference in the ACK…
Can you share a wireshark capture in which such a situation has been identified? If so, we can take a closer look at it…
So the first transmission is (4150,206,48,PSH). So that is:
SEQ_L = 4150, ACK_L = 206, length = 48, PSH flag where L refers to the device on the left
The response to this transmission is 207,4197,2048. SO that is:
SEQ_R = 207, ACK_R = 4197, length = 2048 where R refers to the device on the right
So SEQ_R = 207 is the next sequence number that the device on the right is using. This is based on the previous SEQ_R that was sent.
ACK_R = 4197 is the next byte that the Right device is asking the Left device to send. Assuming a length of 48, this number should actually be 4198 (SEQ_L sent 48 bytes starting at byte 4150).
Unless the numbers in parentheses refer to something different than I have assumed here, I believe that number should be 4198. Can you verify that the diagrams are correct and that they refer to the above values?
Yes the values you selected are the same in the diagram.the lenght_L(48)is MSS and lenght_r(2048)= buffer size,the mesage is 4096 octet .i think the professor made a mistake in class it’s 4198.
Why the sequence number is 207 ? it should be 206.
shantel
(Shantel - Networklessons.com)
Split this topic
32
Only one is right in the context of the challenge I had in mock up test. In my understanding the two ends start with SYN but progress to SYN/ACK and later just ACK is maintained till FIN is pushed to cancel the sessions. Please fix me up. thanks
Right off the bat I’d say the question of the mock up test is unclear.
You are correct. A TCP session begins after the three way handshake is complete. The handshake begins with the initiator sending a SYN flag, the receiver responding with a SYN and ACK flag and the initiator sending back an ACK flag. Once that is complete the session begins.
Out of the three parts of the handshake, I would say the third is the one that ESTABLISHES the connection. However, this is not a choice. If I had to answer, I’d say that the TCP connection is established with SYN/ACK. A connection will only be established if the receiver of the SYN flag responds positively to the request. If it does not, no connection is established.
Thank you so much for explaining UDP being used by VOIP packets! I now appreciate what is RTP ;). My question is that how come video streaming doesn’t need sequencing though? Will there be another protocol like RTP that will rearrange the packets once they reach their destination?
Video streaming doesn’t require reordering because video is a very forgiving application. If there are some packets that arrive out of sequence, several pixles will be out of place, have the wrong colour or may be missing altogether. This only shows up for 1/30th of a second, so any such reordering will not be noticed by the observer. Unlike an email, were the change of a single letter may change the whole meaning of a message, or in a financial transaction where the position of the decimal point may make all the difference in the world, video can tolerate such changes.
Introducing the overhead necessary to make sure all packets are processed in order may even have the opposute effect as it uses more bandwidth and may result in lower quality or choppy video.
RTP however, can and is often used for video, but the sequencing feature is not always employed. This is often the case for voice as well. It depends on how the receiver is set up to process the packets…
The TCP termination process involves the use of the flags FIN and ACK (ACK here is not the acknowledgement number, but the ACK flag). These are found in the header of the TCP segment, specifically in the section called FLAGS:
There are nine bits available for flags, two of which are FIN and ACK flags. Flags are single bits that are either 1 or 0, that is on or off. For more info about the flags, take a look at this lesson.
Now when a TCP session ends, the original initiator is the one who also terminates the session. If this is a web session between a PC and a web server, it is the PC that will begin and end the session.
Refer to the following exhibit:
The termination process begins by the initiator sending a TCP segment with the FIN flag set to 1. The receiver responds with a TCP segment with the ACK flag set to 1, acknowledging the FIN request. The Receiver then begins the same process by sending its own FIN flag and the initiator responds with an ACK to acknowledge it. Once this is complete, the session is closed.
The image above includes the TCP states that each host enters into during the process. These are the states that we often see when we use the netstat command on a Windows command prompt. It is difficult to see sessions in some of these states because they last for such short periods of time.
Your picture doesn’t match to what is described in the flow control section of Renes Introduction to TCP and UDP.
He had this picture where the initial SEQ was 10 and the ACK was 11.
According to your picture if the SEQ was initially 10 and the sender sent 10 Bytes of Data in that segment shouldn’t the ACK of the receiver be 21 then ?
Yes you are correct that there is a discrepancy. I believe that there may be a typo in the lesson, I’ll confirm with Rene and we’ll make the appropriate changes if necessary.
