We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 617 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)


376 New Members signed up the last 30 days!


100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!


Forum Replies

  1. Hi Keith,

    Glad to hear you like it! Before you try wireshark, I would advise to dive into the OSI-model first (if you haven’t done it yet). Using wireshark is a nice exercise to see all the layers of the OSI-model.

    It’s best to download it and just give it a try:


    Make some captures when you try to visit a webpage or download something, see if you can recognize the TCP 3 way handshake and the different layers of the OSI-model.

    If there’s anything in particular you want, let me know and I’ll create something ok?


  2. 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: http://www.citi.umich.edu/u/provos/papers/secnet-spoof.txt

    (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!


  3. 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!


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

  5. 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: 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.

    I hope this has been helpful for you!


30 more replies! Ask a question or join the discussion by visiting our Community Forum