Introduction to TCP and UDP


what is the need of generating a random number for sequence number during handshaking time? Instead it can directly start from 0, right?

Hi Kishor,

TCP is vulnerable to some security issues like spoofing, injection and/or resetting the connection when the sequence number is predictable. That’s one of the reasons why they made it random.


Hi Rene! Thanks a lot for this material. One question, where can I check how to use wireshark? I have never used that software before. Thanks a lot!

Hi Rene,

Can you please tell why is the TCP Sequence no. random and how is the sequence no. choosen? Do we have a process or an algorithm for it?
Also, can you please elaborate on the process of ending the TCP connection?

Thank You
Best Regards,
Prathamesh Gokarn

Hello Paola!

You can find out more about wireshark online as there are many sites that extensively cover its use from the most basic to the most advanced topics. Some good sites to start off with are the following:

I hope this has been helpful!


Hello Prathamesh!

The TCP sequence number is random because, as Rene mentioned earlier, TCP is vulnerable to security issues like spoofing, injection or connection resetting. If an a attacker is able to determine the sequence number, he/she would be able to spoof a trusted source, and thus compromise the TCP session.

For an example of such a spoofing attack, take a look at the following link:

(Notice that this paper is almost 20 years old and yet it’s still valid today!!! Shows just how well designed and robust these protocols are.)

The sequence number is generated by the OS of the device sending the data. Each OS may use a different method for that calculation, but in general it is calculated as a function of the current time. The method has to be random enough so that the sequence numbers cannot be predicted.

Concerning the ending of a TCP session, the initiator is responsible for sending a TCP segment with the FIN flag set in the header. This indicates to the receiver that the initiator is requesting to end the session. The receiver responds with the ACK flag set in the header. Next, the receiver responds with a FIN flag and the initiator responds with an ACK. The session is ended. Take a look at the following image that depicts this process.

I hope this was useful for you!



In TCP checksum.? , what it does.?

Hello Rayniero.

A TCP checksum is used to determine if a TCP segment has been transmitted successfully and without corruption. The sender of the segment computes a checksum by applying an algorithm to the payload and getting a result. The result is placed in the TCP checksum field. When the segment reaches the receiver, the checksum is recomputed with the same algorithm and compared to the checksum sent by the sender. If a bit is flipped or some other badness happens to the segment in transit, then it is highly likely that the receiver of that broken packet will notice the problem due to a checksum mismatch. This provides end-to-end assurance that the data stream is correct. If the checksum does not match, the segment is dropped. The “reliability” characteristics of TCP kick in and the bad segment is requested again from the sender.

I hope this was helpful!


1 Like

Hi Rene ,
Thanks for explaining networking so nicely . I have a question here . Why TCP needs 3 way handshake why 2 way is not enough

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:

  1. A-B (SYN)
  2. A-B (ACK), B-A (SYN)
  3. 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.

1 Like

I want to know if the last sequence number of the three way handshake is the same after the hanshake?

i have another question please.
It only adds 1 when handshaking, but not during data transfer?

1 Like

Hello Samuel.

Concerning your questions about sequence numbers:

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:

This mechanism with the sequence and acknowledgement numbers can be more clearly understood in the diagram I have attached to this post.

I hope this has been helpful for you!


ٍVery good explanation, it helped me a lot thanks…

In the lecture of TCP in class the professor did something like in the picture that i attached is this correct or i miswrote the diagram?

Hello again Samuel

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.

I hope this has been helpful!


Thank you again Lazaros

So whenever the handshake is completed, i need to increase the sequence number by one?.

Also i notice that when the client send a PSH flag the ACK of the receiver decrease by 1.why?

Hello again Samuel.

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…

I hope this has been helpful!


Thank you laz,it is not wireshark capture it’s the same diagram,it ends with something like this

Hello Samuel

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.