TCP and UDP are the primary transport protocols used in today’s modern networks. In this video, you’ll get an operational overview of the TCP and UDP protocols, and you’ll learn the TCP and UDP ports that will be important to know for your CompTIA A+ exam.
<< Previous Video: TCP/IP AddressingNext: Common Network Protocols >>
When you’re working with TCP/IP, there are two types of transport protocols that you will commonly see. The first one we’ll talk about is TCP. This is Transmission Control Protocol. One interesting characteristic of TCP is that it is connection-oriented.
Before you can send any TCP information from one station to the other, both of those stations have to synchronize themselves and create a connection between them. And once that connection is created, you can then send the traffic that you would like to send. And at the end of the connection, there’s a tear-down process that closes out the connectivity. So it’s a very formal process before you can send any data, during the process of sending data, and finally, when you decide to stop sending data. And this is all contained within TCP.
Another interesting characteristic of TCP is that it automatically knows when something has gone wrong in the communication. So if you’re sending information between point A and point B, and for some reason that information didn’t make it to point B, or that information came through in a corrupted type of form, you can recover from that. The point B will send information back to point A and say, I didn’t get this information. You’re going to please resend that to me.
TCP can also keep track of when information has been received out of order, or if information has been duplicated that it has received. It keeps track of every byte. And even if the originating station sends those packets to the network, and they get out of order somewhere in between point A and point B, when it’s received by the other side, TCP can put all of those back in order. Every byte is numbered in these TCP communications, so it simply tries to figure out which order these should come in based on the number of byte that happens to be received.
This can also take into account retransmission. So if duplicates are received, that’s fine with TCP. It will get rid of any extras that it might have.
In a way, you can think of TCP as being the foreman that’s sitting there waiting for all of the trucks coming in, and those IP trucks are coming in unloading the TCP data. It’s checking off whenever it receives a package. If a package is missing, it sends information back saying that package was lost somewhere in between. And if it’s receiving duplicates, it just throws away the extras, and it makes sure that the data that was sent on one side is absolutely received on the other.
Another transport protocol used by IP is UDP. That stands for User Datagram Protocol. UDP is the polar opposite of TCP. There is no formal connection process to set up to send information between two devices.
You simply have one device think yells to the other one and sends the information without any type of pretense. Without any type of warning, the packet is simply sent through the network. And we call that a connectionless communication.
UDP is also unreliable. It sends information out with no expectation that there will be a confirmation that that information was received, or that the information got to the other side in one piece. UDP is giving a best effort. It’s sending the information out, and it’s simply hoping that it makes it to the other side of the network.
Because there’s no mechanism in place to understand how much traffic has been sent, and how much traffic has not been sent there’s no way for UDP to put packets back in their original order. There’s no way to manage retransmissions, because UDP has no idea how many packets have been sent through the network. So therefore, it has no way to know if a packet is a retransmission or not.
This is a way to think about sending the type of traffic that doesn’t need any type of confirmation. We see UDP traffic, for instance, being used for voice over IP protocols. You don’t have time to recover if you lose a packet in voice over IP. You simply drop the packet on the floor, or you’ve missed the packet, and you’re waiting for the new ones to come down the line so that the voice communication can continue.
UDP doesn’t care about losing information. It doesn’t care about recovering from information. It’s simply doing a best effort to get information between point A and point B.
When you start looking at communications between two devices, you start to see these IP addresses and these port numbers start to be used for TCP and UDP. For example, with IP version 4, to send information from one side to the other, you would need the server– having an IP address– would send a server application port number. There’s also a client IP address, and a client port number.
So there’s these four separate numbers that are in use. The ones on the server are paired together with its IP address and port number. And the two on the client are paired together with its IP address and port number. That opens up the line of communication from one side to the other so that those two systems can send information between each other.
When we talk about port numbers, you may hear them referred to in two ways– one as non-ephemeral, and the other as ephemeral. Ephemeral, of course, meaning “temporary.” So if it is a non-ephemeral port number, it’s a port number that is permanent. It’s always used.
You see this often on a server. For instance, you’ll see a web server uses port 80 to communicate using that web service. It always uses port 80. That port 80 never changes. Therefore, that is a non-ephemeral port number.
The other type of port number is an ephemeral port number. It’s a temporary port number. It’s used by the client workstation that’s commonly communicating to that server. We always want the server to be in a port number we know because we need to be able to communicate with it, and if that port number ever changed, we’d never be able to talk to it.
So it’s important to have those non-ephemeral port numbers on the server, but the client can have any port number that it would like to use. It’s initiating the conversation with the server, and the server is simply going to respond back on the same port number that it received from the client. So we can have a single ephemeral port number that we’re using to the server.
The server sends us information. We communicate back and forth. When that connection is done, it closes the connection, and the client simply uses a different port number if it needs to communicate out to another device.
Well, since these client machines are using these temporary port numbers, we’re going to need a lot of them. And in TCP/IP, we can have TCP and UDP port numbers between 0 and 65,535. So you’ve got plenty of room to send information to open connections, and to use these temporary port numbers.
As we mentioned earlier, most servers are going to be permanent port numbers. Those port numbers will never change. And we call those non-ephemeral port numbers. So every machine that’s talking to a web server is always going to talk to that web server on port 80.
Now this doesn’t have to work this way. There are applications out there that do change port numbers all the time. That’s not always the case, and it’s certainly not required. But it becomes a little more difficult to connect to a service if you have no idea what the port number for that service happens to be.
Keep in mind that these port numbers are used for communication. They’re not a security method. You can’t take your web server on port 80, and change the port number to 6767, and expect that it now will be hidden from everybody because you’ve changed the port number that other people don’t know about. It’s a little bit obscure. People won’t know that it’s changed to 6767. But anybody who is knowledgeable on how to find a port number on a server can simply scan every port number on that server– all 65,536 of them– and it can determine what port numbers might be available, and it can easily find then that your web server has been changed to 6767.
So don’t consider port numbers to be some type of security mechanism. Always consider them as simply a communications mechanism. Port numbers need to be well known.
If people need to communicate to web server, our browsers are configured to always communicate to web server on port 80. Therefore, your web server needs to be on that well known port number. If you change your web server to be on a port number that is not well known, then people will not be able to communicate to your web server very easily.
Also keep in mind that TCP port numbers are not the same thing as UDP port numbers. We already discussed how TCP and UDP uses dramatically different methods to communicate. And although TCP has port numbers between 0 and 65,535, UDP has an entirely separate group of port numbers that it uses that also happens to be between 0 and 65,535.
So just because you’re communicating to a web server on TCP port 80 also means that there may be completely different service using UDP port 80 on the same device. These are two separate port numbers, and just keep in mind that they are considered to be completely separate.
Here’s how we use these port numbers. We have a computer on this network, and a server on this network. The computer has an IP address of 192.168.0.5. The web server has an IP address of 192.168.0.10.
Now, our client machine is going to communicate to a web server that happens to be on this device running on TCP port 80. But you also see that this device is running some service on UDP port 53– that’s probably DNS. And it’s also running a service on TCP port 443, which is probably a secure HTTP.
But let’s say that our computer only wants to communicate on the unencrypted TCP port 80 on this server. So our device determines a port number that it’s going to use for this communication. It comes up with one that’s ephemeral, which is TCP 1331. We’re just going to use it for this communication.
And we are going to send information to set up a communication with TCP port 80 on web server 192.168.0.10. The web server sees this communication, starts the communication, sends information back and forth. And once we’ve communicated with that web server, we’ve retrieved the page. We viewed the image, or whatever happens to be going on on that web server.
We then disconnect from that. We close down the connection. TCP port 1331 on the client goes away. And if we ever want to communicate to that web server again, we need to find a different port number to be able to communicate. And we simply will go through a random list of port numbers to be able to set up different connections to different services.
If you’ve not worked with a lot of these services before, then memorizing the port numbers is a lot more difficult. If you’ve already been working with networking, and doing some communication setups for applications that you’re using, then some of these port numbers will probably be familiar to you. But if you’re just getting into networking, or you haven’t used these services before, this will be a bit of a memorization chore.
One of the first sets of port numbers that you need to know are TCP port numbers. And the one we’ll look at first is for something called File Transfer Protocol, or FTP. FTP uses two separate TCP ports to communicate. TCP port 20 is used to send data back and forth, and TCP port 21 is the control mechanism, or the control channel, that’s used between the two devices.
If you’re working at a console screen that is remotely connected to a device over Telnet, then you’re communicating to that device over a TCP protocol, and usually that’s using port 23. The mail servers on the internet are constantly sending data back and forth, constantly transferring mail from one server to the other. And very often, they’re using a protocol called SMTP to make that happen. That stands for Simple Mail Transfer Protocol. And if you were to look at this communication, the SMTP server is almost always going to use TCP port 25.
We wouldn’t be able to communicate on the internet if we did not have our DNS servers. It makes it very easy for us to take a name of a server, and change that into an IP address. And therefore, we don’t have to remember a lot of different IP addresses. Normally, DNS works with a UDP protocol, but it can also work with a TCP protocol. This is a good example of how the TCP and UDP protocols are really completely separate.
Here in this case, DNS using TCP is used to communicate large amounts of information between point A and point B. These are often things like zone transfers. And if you see one of those occurring, it is using TCP port 53 to send that information back and forth. As we’ve already mentioned web servers use a well known port number, and TCP of port 80 to communicate to those web servers so that your browser can view information from that server.
If you’re retrieving your mail from a mail server on the internet, you may be using a protocol called POP3. This is version 3 of the Post Office Protocol, and it commonly uses this TCP port 110 to be able to retrieve that data from the server. IMAP is a more modern protocol that our mail clients often use, and it stands for Internet Message Access Protocol, version 4. It commonly uses TCP port 143 to retrieve your email using this IMAP protocol.
Our secure web servers run HTTPS. That stands for our Hypertext Transfer Protocol Secure, which sends an encrypted web page down to your clients so that nobody can look at that data as it’s transferred between those two devices, and see what you’re doing. It commonly uses TCP port 443 to be able to transfer that encrypted message. And the last TCP protocol that we’ll look at is one for remote desktop. In the Microsoft world, the remote desktop protocol uses TCP port 3389.
Let’s change our focus to the UDP protocols, and fortunately, there’s only one UDP protocol that we’ll need to know, and that’s the one for DNS. This is the one that is commonly done when we perform our DNS look-ups. You’ll notice that UDP port 53 is used for this domain name services and the queries that we will make. But notice it uses the same port number as the TCP version when it’s performing zone transfers.
So it’s very easy to remember DNS. You just need to remember, if it’s a TCP port 53 it’s a zone transfer. And if it’s a UDP port 53, it is our normal day-to-day DNS queries.
2 thoughts on “Common TCP and UDP Ports – CompTIA A+ 220-801: 2.4”
Nice video but you have omitted Secure Shell.
Secure shell (SSH, tcp/22) isn’t listed on CompTIA’s exam requirements.
Comments are closed.