Join Mike Meyers for an in-depth discussion in this video Introduction to TCP and UDP, part of CompTIA Network+ Exam Prep (N10-006) Part 4: Making TCP/IP Work.
- View Offline
- I've got two computers here in front of me. Well, okay, actually they're little Styrofoam blocks, but we're gonna pretend like they're computers for a minute. Now, one of these computers is going to be a server, and the other one's going to be a client. I mean, the whole reason we do TCP/IP is because we want to move data between computers, right? Isn't that the whole idea? Okay, well, if that being the case, we need to appreciate that within the TCP/IP world, what you have are servers and clients. Now a server is gonna be running some kind of server software. It could be running a web server, it could be running a game server, it could be running an email server, I don't know, but it's gonna be running some kind of server software.
The client is gonna be a computer that's running some kind of client software. It could be a web client, it could be an email client, it could be a game client, whatever it might be, pretty much everything that happens in the TCP/IP, which is the whole internet world, is a client-server type scenario. Okay, now assuming that's right, the idea is that we want to move data from one computer to the next. So usually what takes place is a client makes a request, and a server serves. Easy enough. But it's a lot more complicated than that.
And what it boils down to is that there's a lot of data on the internet that we want to get from the server to the clients in really good order. If I'm playing music, or if I'm downloading a video, or if I'm looking at pictures, or if I'm playing a game and I want to make sure that my tank is at the right position and all that kind of stuff, that data's gotta be right. And the people who invented TCP/IP knew that, and they came up with two different protocols, one for where you really need the data just right, and the other one where you just kinda throw it at the other machine and hope for the best.
The one where you need it absolutely right is called TCP, or Transmission Control Protocol. The one where we just kinda throw it is called UDP, or User Datagram Protocol. And I want to cover both of these right now. So in order to do that, let's take a look at the frame I've got right here in front of me. Okay, now before we get deeper into TCP and UDP, I want to take a moment to review a couple of bits here. First of all, I have got a complete ethernet frame here. Now when we talk about ethernet, and you'll notice that I've got the MAC address part, the ethernet part, even got the CRC.
This is a frame. Now if I strip away the ethernet part, I'm left with an IP packet. So this part is the packet itself. Now if I strip away the IP part, I'm left, in this case, with a TCP segment. Now a TCP segment is always gonna be distinct. You're going to have your port number to and your port number from, you'll have your sequence number, which is, we've seen the sequence number in earlier episodes, but now I've added a new little bit of information called ACK.
The thing you've gotta remember is that TCP is a connection-oriented protocol. That means it's gonna create a connection between two different computers, and it's gonna make darn good and sure that that data gets to the other machine in good order and complete. So there's a, what's called a three-way handshake process where the client and the server talk to each other and make sure that the data gets there in good order. So while I just say ACK here, this particular field is actually pretty complicated. It's got all kinds of stuff like, you know, what part of the handshake process are we in? The receiving system is ready right now to only handle so much data, or the receiving system is saying, "Wait a minute, "but don't lose the connection, but just hold on, "I'm busy." So this is actually very, very complicated.
Okay, so I've got my server and my client here, so what I want you to see right now, is a TCP three-way handshake process. This is what actually creates the connection. So here's my client and here's my server. Now keep in mind that the server right now is what we call listening. Right now, the software, let's say it's a web server running on here. When we say that a server is listening, that means any incoming packets that have the port 80 as the destination port number, are going to be handed to and acted upon by the web server.
So the web server is listening on port 80. Now the web client, he knows to send everything out on port 80, 'cause that's what web clients do by default. It all begins with a SYN. Now the client sends a SYN over to the server. The server now says, "Ah, okay, "somebody wants to talk to me." And the SYN does a lot of different things. For example, one of the things it'll do is it will increment the sequence number. It does a whole bunch of stuff to make sure that this works exactly right.
So the server gets the SYN, and he responds back to the client with a SYN ACK. So the SYN ACK is sent back to the client. And again, sequence numbers are updated, and there's all kinds of stuff goin' on. How fast the server is, lots of things are going on while this is taking place. So the client gets the SYN ACK, and then it finishes up with an ACK. So the client sends the server an ACK, and we now have a legitimate TCP connection ready to rock and roll.
So the data gets moved along, it's gonna do whatever it's supposed to do, but then we actually have to close the session, or the connection. Now there's two ways to close a connection. You can do it nice, and when you do it nice, I mean, you know, one guy says, usually the client's gonna say, "Okay, I've got what I needed, thank you very much," and say, "Okay, okay, okay, good-bye." But there's another way to close it, and that's if somebody just goes off the hook, or if, you know, this guy gets turned off, or whatever it might be. And that's where the one or the other will simply say, "Eh, you're gone, you've hit a time out, bye-bye." So let's do this one more time, except this time let's watch the close.
So here's my client and here's my server. Now they have an established connection, and they're sending data, whatever's taking place for this particular type of TCP application, and well, the client's got everything and he's done. So once the client's done, he's gonna send a FIN statement over to the server. Now once the server sees that, he's gonna respond back with a FIN ACK. So the FIN ACK goes to the client, the client sees the FIN ACK, and closes the connection with an ACK statement.
Once that gets to the server, the connection is over, there's nothing else left to do. Now that's TCP. So TCP's pretty complicated. You don't need to know a lot of these details for Network+, I just think it's cool, personally. The important thing to appreciate is that TCP is connection-oriented, and it's all these ACKs and SYN ACKs and FINs and FIN ACKs that allow this to take place. UDP's a bit of a different animal. So let's go ahead and change our TCP segment into a UDP datagram.
So what I'm gonna do here, is I'm gonna take this TCP segment and magically transform it into a UDP Datagram. Now a UDP Datagram, at first glance, you'd go, "Hey, the blocks are the same." Well, they're actually kinda different. First of all, you'll still have a port number to and a port number from, but you have two pieces of the UDP header that are very different than the TCP. We simply have the length of the data, and then a Check Sum to verify that data. Now this is important.
The thing you have to appreciate with UDP is that it's connectionless. So we don't have to worry about ACKs, SYN ACKs, and verifying data, and, "Are you ready?" and all that stuff. No handshake. The server system just takes that chunk of data and fires it over to the client. And hopefully, the client has some way to verify that it has that data. Now you would think that UDP would be a bad idea. Well, it's actually a really good idea in a lot of places. UDP is fast, there's not a whole bunch of overhead, and there are a lot of applications out there that need speed more than they need safety.
A great example would be DHCP. If you were watching earlier episodes, you know that that DHCP protocol uses a series of back and forths between a DHCP server and a DHCP client. Each one of those is a UDP packet, and it just assumes that the client's gonna catch what's sent to the client, and the server's gonna catch what sends to the server. In those situations, DHCP, if it doesn't hear back from you in enough time, it re-sends, and if it doesn't hear back after a certain amount of time, it says, "Hey, it never happened." So in that type of situation you can see that UDP can actually be better than TCP, because it's fast, and low overhead.
So when it comes to hauling traffic on the internet, you've got two choices. You've got TCP, which is connection-oriented, and you have UDP, which is connectionless. Now keep in mind, you don't set what you're gonna use. If you're gonna be setting up DHCP, you're gonna set up a DHCP server and a DHCP client, part of the application defines that they use UDP. And if you're gonna be setting up a web server and a web client, the application itself defines that it's going to be TCP. So just make sure you understand the difference.
We are now a CompTIA Content Publishing Partner. As such, we are able to offer CompTIA exam vouchers at a 10% discount. For more information on how to obtain this discount, please download these PDF instructions.