In this lesson, we are going to take a look at our transport protocols, TCP and UDP. If you know about IP and IP packets you know that we require a transport protocol to send our IP packets.
I want to focus on the transport protocols that are used most of the time:
- TCP (Transmission Control Protocol)
- UDP (User Datagram Protocol)
So why do we have two different transport protocols here, why do we care, and when do we need one over another?
The short answer is:
- TCP is a reliable protocol.
- UDP is an unreliable or best-effort protocol.
Unreliable you might think? Why do I want data transport which is unreliable? Does that make any sense? Let me tell you a little story to explain the difference between the two protocols.
You are sitting behind your computer and downloading the latest collection of firmware updates for your servers. The download is over 20 GB and takes 10 hours to complete. During the download, a couple of IP packets somehow don’t make it to your computer. After 10 hours, you look at the firmware files and it seems they are corrupt.
In most cases, you want to make sure the transport of your download to your computer is reliable, which is why we use TCP. In case some of the IP packets don’t make it to your computer, you want to make sure this data will be retransmitted to your computer!
In our second story, you are the network engineer for a major company, and you just told your boss how awesome this brand new open source Voice over IP solution is. You decide to implement this new VoIP solution and get rid of all the analog phones, but your users are now complaining big time that their phone call quality is horrible. You contact the open-source VoIP solution provider, and you find out that they thought it would be a good idea to use a reliable transport protocol like TCP since well, we want phone calls to be reliable right?
Wrong thinking! TCP does error correction which means that data that didn’t make it to your computer will be retransmitted. How weird will your phone call sound if you are talking to someone and you hear something that they said a few seconds ago? It’s real-time, so we don’t want retransmission. It’s better to send VoIP packets and lose a few than retransmit them afterward, your VoIP codec can also fix packet loss up to a certain degree. In this example, we’ll want to use a best-effort or unreliable protocol, which is UDP.
|
TCP |
UDP |
Connection Type: |
Connection-oriented |
Connectionless |
Sequencing: |
Yes |
No |
Usage: |
Downloads File Sharing Printing |
VoIP Video (streaming) |
What do we have in the table above? First of all, you see “connection type”. TCP is connection-oriented which means it will “setup” a connection and then start transferring data. UDP is connectionless, which means it will just start sending and doesn’t care if it arrives or not. The connection that TCP will set up is called the “3-way handshake,” which I will show you in a minute.
Sequencing means that we use a sequence number. If you download a big file, you need to make sure that you can put all those packets back in the right order. As you can see UDP does not offer this feature, there’s no sequence number there.
So what about VoIP? Don’t we need to put those packets back in order on the receiver side? Well actually yes we do. Otherwise, we get some strange conversations. UDP does not offer this “sequencing” feature though…let me tell you a little secret: for VoIP, it’s not just UDP that we use, but we also use RTP which does offer sequencing! (And some other cool features we need for VoIP).
Let’s take a look at a UDP header:
You can see how simple it is, it has the source and destination port number (this is how we know for which application the data is meant), there’s a checksum and the length.
Let’s sum up what we now know about UDP:
- It operates on the transport layer of the OSI model.
- Is a connectionless protocol that does not setup a connection…just sends data.
- Limited error correction because we have a checksum.
- Best-effort or unreliable protocol.
- No data-recovery features.
Now let’s see what TCP can offer us. First of all since TCP is a reliable protocol it will “setup” a connection before we start sending any data. This connection is called the “3 way handshake”. Let me explain this by showing two computers that want to send data to each other in a reliable way:
H1 wants to send data to H2 in a reliable way, so we are going to use TCP to accomplish this. First we will setup the connection by using a 3-way handshake, let me walk you through the process:
First our H1 will send a TCP SYN, telling H2 that it wants to setup a connection. There’s also a sequence number and to keep things simple I picked number 1.
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.