In this video, we'll cover the two major transport protocols, UDP and TCP. Before we do that though, let's talk about transport protocols in general to understand why we need them in the first place. On the internet, every network packet follows this five-layer structure. We have the application layer, the transport layer, the network layer, the link layer, and the physical layer. I might do a full video on this five layer structure at some point, but for now just remember that UDP and TCP are part of the transport layer.
Have you ever wondered why it's possible that two applications can use the same internet connection at the same time? Well, that's because of what the transport layer provides. It allows multiple applications to use one network connection simultaneously.
Much like street names have house numbers, the transport layer creates about 65,000 ports on your computer per network connection. These ports can be reserved and used by applications on your computer, and one application can use multiple ports at the same time if it wants. Let's say that an application reserved port 12437 to send a message to port 80 on some other machine.
Whenever the application layer creates a message, it is passed on to the transport layer. On this layer, we wrap the message inside what we call a segment. This segment contains some additional information, like the source port as well as the destination port.
Then, when the segment is created, it is passed on to the network layer for further processing. Our segment will show up on the receiver side when it is passed on from its network layer to the transport layer. The segment will be examined to determine the destination port, and then the message is unwrapped and delivered to port 80. So that's the general idea of the transport layer, but there's more to it than that.
We have two major transport protocols, UDP and TCP, and they both have their own characteristics. Let's look at UDP first. One of the biggest advantages of UDP is that its packet sizes are smaller than TCP, about 60% even. UDP headers are 8 bytes and TCP headers are 20 bytes, so that's a big difference.
UDP is connectionless. This means that you don't have to create a connection first before sending out data. And finally, you have more control over when data is being sent out. Now, I do realize that this may sound a little vague to you, but once we get TCP into the mix, this will become clearer.
Because data corruption is a common occurrence on the internet, UDP has a primitive form of error detection. Its packets carry a 16-bit checksum, but it is not that reliable. When UDP does detect corruption, it will not try to recover from it. In most cases, the corrupted segment will just be discarded.
In some cases, it will keep the corrupted segment, but turn on a warning flag for the application. UDP does not attempt to compensate for lost packets. Every packet gets sent out once.
If it gets dropped on its way to the receiver, tough luck, it's gone. UDP does not guarantee in-order packet delivery. Packets won't necessarily arrive in the application in the order that they were sent.
There's no congestion control in UDP. Even if your network's really busy, UDP will just try to cram those packets in there. This is usually a bad strategy, because on a congested network, packets get dropped more often.
In conclusion, UDP may be lightweight, but it's not that reliable. This is where TCP comes in. The transmission control protocol has certain features that make it more reliable than UDP.
However, it also has a bigger communication overhead than UDP. Since TCP is connection based, we have to negotiate a connection first before we can do anything. This procedure is known as the three-way handshake.
First, the initiator will ask the acceptor if it wants to set up a connection. The acceptor will reply to this request, and when the initiator receives this reply, it will send a packet to the acceptor that acknowledges that the connection has now been established. A similar song and dance takes place when they close down a connection.
Now that we have this connection, we can implement all kinds of nice features like delivery acknowledgements. When data gets sent from one host to another, the receiver will acknowledge that it got that data. This is one of the reasons why TCP segments carry a number. Another feature that TCP offers is retransmission.
When a sender doesn't get a delivery acknowledgement within a certain amount of time, it will assume that the packet got lost on its way, so it will send it again. Because segments are numbered in TCP, it can also implement in-order delivery. Although packets may still arrive out of order, TCP will rearrange them before sending them to the application. Other TCP enhancements include congestion control, This feature will delay transmission of data when the network is congested.
It eases the strain on the network and it helps minimize packet loss. TCP enforces a small change to error detection. While there is no technical improvement of the error detection feature, the checksum has now been made mandatory for IPv4 as well as IPv6.
For UDP segments, the checksum is only mandatory for IPv6 packets. Let's look at the downsides of using TCP. TCP segments need bigger headers than UDP segments. As you may remember, UDP headers are about 60% smaller than TCP headers. A side effect of TCP's congestion control mechanism is that data doesn't always get sent out immediately.
This is of course done on purpose to ease network congestion, but sometimes that's not what you want. Take Skype for example. When you're making a voice call, you kind of want it to feel like a real-time conversation, right? Well, what TCP's congestion control does is when the network is congested, it deliberately introduces latency, so your real-time conversation will not feel as real-time as you want it to be.
As you can see, congestion control can be either a nuisance or an enhancement. It all depends on the context really. Finally, TCP has a bigger overhead.
All those retransmissions and packet acknowledgements and all that jazz. Well, that's overhead. Sometimes you don't want every packet to arrive. Sure, you want packets to arrive, but if certain packets drop out, you don't care that much. For example, to stream HD video you need lots of bandwidth, but if you use TCP for it you need even more because you have to send around Acknowledgements you have to do retransmissions and besides video streaming can deal with a certain amount of packet loss They have ways to compensate for that in this case It makes more sense to use UDP than TCP both protocols are also different on a conceptual level We call UDP message oriented, which means that applications send their data in distinct chunks.
Think of it as snail mail, email or text messaging. Now TCP on the other hand is stream oriented. It is used as a continuous flow of data.
Under TCP your application does not choose how data is sliced into packets. Just let it know whenever anything needs to be sent, and then TCP will slice that into packets and recompose everything on the other end. It could use lots of small packets, but it could also choose to go with few big packets.
It just picks whatever works best at that time. Rest assured though, you don't have to worry about how the packets are sliced. All you need to know is that on the receiver end, everything gets recomposed into a stream that you can read from.
So which one's better, UDP or TCP? It all depends on the type of application that you're building. Let's look at text communication.
Performance-wise, this isn't a big challenge, because you don't need a lot of bandwidth to send some text around after all. Under TCP, everything will work fine. With UDP, however, you could get text in the wrong order, or text could get lost along the way.
There's no guarantee anything could go wrong there, because UDP doesn't do retransmissions, and it doesn't guarantee in-order delivery. When it comes to text communication, TCP clearly takes the cake. Now, I don't know about you, but when I download files off the internet, I'd like to have all the parts, including the chunks that didn't make it through the first time.
TCP offers retransmission, UDP does not. We're also going to need in-order delivery because seriously, what good is a scrambled JPEG? For similar reasons, remote access protocols like SSH also use TCP.
If you need delivery acknowledgements, UDP isn't going to do you any good. If you insist on using UDP, you could implement some sort of acknowledgement system in your application layer for important packets but most of the time it's not worth the hassle. With multimedia streaming things are a little more ambiguous. It could either be UDP or TCP.
Traditionally people have chosen UDP because it has less overhead, it doesn't do that congestion control thing that introduces latency and we can compensate for a certain percentage of lost packets. More recently people have started to use TCP for multimedia streaming. If the bandwidth is there, you might as well enjoy the benefits that TCP brings.
Also, some firewalls block UDP altogether for security reasons and then you're forced to use TCP. UDP can also be used for small question and answer transactions such as DNS lookups. The main benefit here is that you don't have the overhead of creating and closing a connection every time you need something. As is the case with multimedia streaming, bandwidth-intensive apps that can tolerate some amount of packet loss usually go with UDP. And that about wraps up today's discussion.
If there's anything you'd like to see explained here, please let me know in the comments. Thanks for watching, see you next time.