This topic is to discuss the following lesson:
1 Like
Thank you for you videos! I know if I’m able to understand them then any/everybody should be able to understand because I have no computer background p. Question, I would like to checkout the wire shark but am not sure as to how it works. Suggestions? Thanks again for your help.
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:
https://www.wireshark.org/download.html
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?
Rene
Rene,
Excellent lesson!!! It’s so good read a lesson like this, because you make it be so simple!
Thanks and Abraço
Great lesson again! I like an application called tcpdump, which is like Wireshark but much less clunky. There is a little learning curve, but so much better for just watching traffic.
Thanks 
Tcpdump is a great (linux) tool, it’s really useful for capturing traffic and you don’t need a GUI for it. It’s very useful when you SSH into a remote box and want to capture some stuff.
For analysis I prefer wireshark…you can capture with tcpdump and then look at it in wireshark.
Hi, Rene! Thanks for a good brief of TCP/UDP!
After reading I have one question, may be you can give me a simple explanation or send me to look something else on the web.
If I understand right, in simplified way, TCP sequence number grows up by window size, while sending data. When sequence number is over (32 bit max or 4Gb data), but data more than 4Gb - what will happen?
Hi Dmitriy,
The sequence numbers work like a clock so once you hit the maximum value, we start at 0 again. You can read a bit more about this in the RFC:
https://www.rfc-editor.org/rfc/rfc793.txt
Look for 3.3. Sequence Numbers
Rene
Great lesson that schools me a lot, it is worth every second reading it
Rene,
Can you give examples when TCP flags PUSH, URG are used and how are they different?
Thanks
Rakesh,
The online TCP/IP Guide has a good write up and example of these. I will summarize briefly:
Push
TCP has its own buffer that it prefers to fill before sending the data. In most cases, this is efficient because it lowers the overhead requirement for the TCP session since fewer segments are sent. With time sensitive traffic, however, it may not be desirable for an application to have the delay for the TCP buffer to fill. The Push flag tells TCP “send whatever you have right now!”
Urgent
In most cases, but not always, data sent by TCP will be FIFO (first in first out), and the receiver of the stream will generally (but not always) get the data in the order sent. There are situations where it might be best not to do this. The example given by the TCP/IP Guide is imagine a large file transfer that is in progress, but it needs to be cancelled. The “abort” command might be marked with Urgent so as to minimize the time that wasted data will continue to be sent.
1 Like
Hi,
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.
Rene
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!
Laz
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.
http://www.iptel.org/~jiri/publications/da/html/da-6.gif
I hope this was useful for you!
Laz
1 Like
Rene
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!
Laz
2 Likes
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