From the course: Cisco Certified Network Associate (CCNA) v1.1 (200-301) Cert Prep

TCP vs. UDP

From the course: Cisco Certified Network Associate (CCNA) v1.1 (200-301) Cert Prep

Start my 1-month free trial Buy for my team

TCP vs. UDP

“

(soft music) - [Instructor] This video compares TCP with UDP. And if you've ever studied the OSI model, you know that these two protocols are transport layer protocols, also known as layer 4 protocols. In other words, the data is going to be wrapped up inside of a TCP segment or a UDP segment, and then it's going to be wrapped up in an IP packet, which is going to have source and destination IP addresses. And if we're on an ethernet network, that IP packet is going to be wrapped up inside of an ethernet frame, and that ethernet frame is going to be sent on the network as a series of ones and zeros. But here we're focused on the transport layer and the differences between transmission control protocol and user datagram protocol. One of the big ones you hear about is that TCP is considered to be reliable, and UDP is unreliable. But what exactly does that mean? Well, reliable means that if I send a TCP segment and it's not received, then I as the sender am going to realize it was not received, and I will resend it. UDP, however, is more of a fire and forget approach. We send the segment and we sure hope it gets there, but we have no assurance that it ever did get there. TCP is also considered to be a connection oriented protocol while UDP is connectionless. Here we're talking about the fact that TCP sets up a connection prior to sending the data. It's TCP's 3-way handshake, which we'll discuss in just a few moments. And because of TCP's characteristics being more robust than UDP, it does have more overhead. So if you looked at a TCP header side by side with a UDP header, the TCP header would be quite a bit bigger, and that leaves a little less vein with available for sending our actual data. TCP also can have more delay than UDP. For one thing, we spend extra time sending that bigger header. And we also have delay because of how windowing works with TCP, and we'll discuss that in just a few moments as well. But with windowing, we send a certain number of segments and then we wait for an acknowledgement from the far end. Well, that waiting period is adding to our delay. We don't have that with UDP and after this side-by-side comparison, you might wonder, when would I ever want to use an unreliable protocol? Well, a really common use for UDP, and there's several uses, but a common use that we see is IP telephony. If we're sending voice over IP those voice packets need minimal delay, otherwise the conversation can start to feel awkward. And if we do drop an occasional voice packet, a lot of the IP telephony equipment is smart enough to extrapolate approximately what that dropped segment would've sounded like to the listener. So instead of having a potentially noticeable gap in the audio while we retransmit the dropped segment, with UDP we might drop the occasional segment and hopefully it's not going to even be noticed by the listener. So please understand that with TCP and UDP one is not necessarily better than the other one. They just have different use cases. And now let's focus in on how TCP is reliable, how it sets up that connection and how windowing works. Let's say as an example that this PC is going to be the sender in this conversation, and the server is going to be the receiver, and we're going to be using TCP, the transmission control protocol. We said that was a layer 4 protocol in the OSI model, which is called the transport layer and as we're sending our TCP segments, they're going to have a number that identifies them. And I as the sender if I know that I sent segment 10, but I don't get an acknowledgement from the other side that it received at segment 10, I can conclude that it was not received successfully and I can retransmit it. But before we even start sending data, we set up a connection using TCP's 3-way handshake. The first step in this 3-way handshake is when the sender, the PC in this case, tells the receiver the server in this case, that it wants to set up a connection. So the PC is saying, hey, server, I would like to talk to you. It does that by sending a synchronization message, abbreviated SYN, and we commonly call that a SYN message for SYN. And when the server gets that, it says, oh, great, I would like to talk to you too. And by the way, here is an acknowledgement that I received your SYN message. So when the server says, I want to talk to you too, that's a SYN message coming from the server. And then we have an ACK message acknowledging the receipt of the SYN message that the PC sent the server. That's step two of the 3-way handshake. So again, in step one, the PC says, with a SYN message, hey, I want to talk to you, and the server says, I want to talk to you too, that's a SYN message, and I acknowledge the SYN that I just received from you. That's the ACK message. And the only thing left in this 3-way handshake is for the PC to acknowledge receipt of the server's SYN message. So it sends an ACK back to the server. That makes up the 3-way handshake. There's a SYN, SYN-ACK, and finally an ACK. Now let's see how data gets transmitted once this connection is set up. The PC might start out by saying, I'm going to send one segment and I'm going to wait for an acknowledgement that segment number one was successfully received. So the PC sends segment one to the server, the server responds with an ACK two message saying, I acknowledge that I got your segment and I'm ready for segment number two. Since the receiver is ready for segment two, the sender concludes that segment one was received successfully. And it's not terribly efficient to send one segment and wait, one segment and wait, but at the same time, we don't want to send too aggressively and have packets drop. So we start out at a very low number, like sending a single segment, and then the PC says, okay, that worked. Let's double that. Instead of sending one segment, I'm going to send two segments before expecting an acknowledgement. And by increasing the number of segments we send before expecting an acknowledgement, we are increasing our window size. And the sender might start out with a window size of one and then double it to two, and then 4, 8, 16, 32, 64, 128, 256, 512 1024, 2048, 4096, 8192 16384, 32768. And that's as high as I can go from memory. But as the window size increases, the efficiency increases because the sender is spending less time waiting for an acknowledgement. And just now you saw the sender send two segments and the receiver says, okay, I got segments two and three. I'm going to send you an acknowledgement and say, I'm ready for segment number four. And the sender says, oh, a window size of two worked. I'm going to double that again. We've gone from a window size of one segment to two segments. Now let's go to four segments that I'm going to send before I expect an acknowledgement. So here, the four segments were received by the receiver, and that process would repeat, the receiver would send an acknowledgement, and the sender would then send a window size of eight and so on and so on, until that sender did not receive an acknowledgement within an appropriate amount of time, or it received an acknowledgement asking for a segment that it had already sent. At that point, if either of those two things occur, then the sender realizes that it is sending too aggressively and it will reduce its window size. And that's a look at a comparison between a couple of layer 4 protocols, TCP a connection oriented reliable transport protocol, and UDP, a connectionless unreliable transport protocol. And then we took a look at how TCP sets up its connection with that 3-way handshake and how it can reliably send segments because it gets acknowledged for those segments and how we can over time send more efficiently by adjusting our window size.

Contents