The Internet uses a standard set of protocols to send traffic from one part of the world to another. In this video, you’ll learn about IP, TCP, UDP, port numbers, and how they all work together to enable worldwide communication over our wired and wireless networks.
This video is introduction to IP, and although it does not have a direct correlation back to the exam objectives, everything that’s in domain 2, or the networking domain, tends to build on the information that we provide in this video. If you’re unfamiliar with some of the details of networking and especially of IP, I highly recommend you watch this video as a primer for the videos that are to follow.
Our networks are designed to move information from one device to another device, and there is a lot of information that goes across our modern networks. We usually refer to these networks as ethernet networks, wireless networks, DSL networks, and other types. And from IP’s perspective, it really doesn’t matter what method you’re using for the transportation. The important part is what’s inside of those packets that we are sending across the network.
In this video, we’ll talk about the network as a series of highways or roads, which means that IP, or the Internet Protocol, is going to be the truck that is driving across that road. We’re going to put information into that truck, send that IP truck across the network, and we’re going to unpack that truck on the other side.
If we were to look inside the truck, we would see a lot of information. There is a box inside of the truck, and we refer to that box as holding TCP or UDP information. We’ll learn more about TCP and UDP later on in this video. And of course, just like boxes that you might use to move, inside of these TCP or UDP boxes is information that is important for us to get from one place to another.
You can see that we start to nest information within another. In the world of networking, we refer to this as encapsulation and decapsulation. Here’s a basic diagram of us sending information to a web server. On one side is our client or laptop computer, and on the other side is the web server itself. In this particular example, we’re sending this information across an ethernet network, and all of the information that’s being sent across the network is the ethernet payload.
Also included with this ethernet payload is information at the beginning of this payload– that is, a header– and information at the end. That’s a trailer. This allows us to know exactly where the data starts and where the data ends. Of course, there’s more information within this ethernet payload. And if we were to look a little bit closer at that payload, we would see that there is a specific kind of data contained within that payload.
In this particular example, we’re carrying IP traffic. So there is an IP payload and an IP header within that same ethernet frame. And as you probably already expected, within this IP payload, we have even more detail that consists of a TCP payload in this particular example. And that TCP payload also consists of a TCP header.
And we can continue to break this down. Since we know that this is web traffic, we know that within that TCP payload is HTTP, or Hypertext Transfer Protocol data, which holds all of that web server communication. So as you can see, this ethernet frame has within it IP traffic, TCP information, and HTTP information. And different protocols may have even more layers of information that we could drill into to see exactly what’s being sent between these two devices.
The Internet Protocol, or IP, is one of the most popular protocols that you’ll find. But you’ll also notice that within that IP, we commonly find TCP and UDP. TCP and UDP are very similar protocols that are used to transport information, but there are some interesting characteristics that are unique to each. And in this video, we’ll look at what some of those unique characteristics might be.
If you’re talking to a network professional or someone taking their Network+ certification, they’ll often refer to TCP or UDP as an OSI Layer 4 protocol. For the purposes of the A+, the OSI model is not important for us to know, but you will see that particular term show up when you’re reading through different books or referencing different materials.
From the purposes of a networking perspective, it’s important to know that TCP and UDP allow us to communicate across multiple devices all simultaneously and send information that might be very different than each other. We refer to this as multiplexing. This allows us to send different types of traffic across the network simultaneously and have all of that information properly received on the other side.
Let’s look with a little more detail into TCP, or the Transmission Control Protocol. This is a protocol that we refer to as connection-oriented. That means there is a formal process to set up a conversation with a device and a formal process to end that conversation.
You can think of this as making a phone call. You would put in a phone number. You would hear the phone ring on the other side. On the other side, the person might say hello, and you would say hello back to them, and then you can proceed with your conversation. At the end of that call, you would say, it was good talking to you, goodbye. The other person would say goodbye, and you hang up.
This is very similar to the process with TCP, where there is a formal connection setup and a formal connection teardown. You’ll sometimes see TCP referred to as reliable delivery. That means that we are able to know that the information that we’ve sent to another device really has been received. That’s because TCP includes an acknowledgment process.
So TCP sends the data, and the person receiving the data will send back an acknowledgment so that both sides of the conversation know that everything was received properly. If any of the information sent by the sender is damaged or corrupted in the transport process, the receiving station can send a message back to the sending device telling it that something did not work properly and they need to resend that data to be able to receive it properly.
This also allows the sender and the receiver to manage how much data is being sent at any particular time. We refer to this as flow control, and that means the receiving device can tell the sender to speed up the data or slow down the data, depending on how much information it’s able to receive at any particular time. It’s this constant sending of data and an acknowledgment of the data that provides that reliable delivery and enables all of those TCP-specific functions.
But there are some protocols that don’t need that very detailed level of reliability and the overhead that’s associated with TCP. That’s why we created UDP, or the User Datagram Protocol. We have a connection-oriented protocol with TCP, and with UDP, we are connectionless. There’s no formal process to start the communications flow, and there’s no formal teardown process to end the communication.
We refer to that as an unreliable delivery. Those terms are referring to the fact that there’s no way to know if the data really was received on the other side, because there are no acknowledgments coming back to the sender. Since there’s no acknowledgment being sent by the receiving device, we don’t have any way to recover from any errors, and there’s no way to perform any type of retransmission.
And since the sending station has no idea if everything really was received properly on the other side, there’s no way to set any type of flow control. The device that’s receiving all of this data has no way to send back any type of messages saying that they should speed up or slow down the data transfer process.
Given that explanation of UDP, you might be thinking, why would any application want to use UDP? One advantage of UDP is that there’s very little overhead. You don’t have to set up any formal communication. You can simply send data, and you have a best effort to get that data to the other side. A good example of an application that works exactly like this is one for real-time communication.
Applications that are voice over IP-related or send video across the network are all in real time. If information is lost along the way, we can’t stop our conversation, rewind what we were talking about, and then replay that through the same connection. Once we lose that data, we’ve lost that moment in time, and there’s no way to rewind time to go back to where we were. For that reason, voice over IP and any real time communication would prefer to use UDP since it has the least amount of overhead and it doesn’t have to worry about rescinding traffic that may have been lost.
There are other protocols that work with UDP that perform a similar function, where they need low overhead and aren’t concerned if the data is going to get to the other side or not. If there’s any problems in that communication, it will simply perform the process again from the application’s perspective. A good example of these connectionless protocols would be DHCP, or the Dynamic Host Configuration Protocol, that we commonly use to automatically assign IP addresses on all of the devices on our networks.
Another good example is TFTP, or the Trivial File Transfer Protocol, which often sends very small amounts of data across the network and doesn’t require any particular overhead or retransmission capability. Fortunately, even though UDP doesn’t provide any way to resend the data, the application can provide that same functionality. So instead of relying on UDP as the retransmission method, the application itself will keep track of everything that is sent back and forth, and the application will decide if it ever needs to resend any traffic across the network.
This requires the application itself to be able to manage that process. And some applications, like voice over IP apps, might not do anything if data is lost. If information doesn’t make it through, then it will simply continue sending the voice over IP traffic. And if the users didn’t receive information, they’ll simply ask someone to repeat what they just said.
Some applications, though, are very particular about making sure that data is properly received on the other side. Applications such as HTTPS, which is the Hypertext Transfer Protocol Secure, commonly used for our web server communication, or something like SSH, for Secure Shell, which is our terminal communication, is something that does use TCP and will resend data automatically using that TCP protocol.
TCP is able to confirm that data was received by receiving acknowledgments from the receiving station, very much like you would do with a return receipt. This means the application doesn’t have to worry if information was received or anything goes missing, because that entire process of maintaining the data flow is managed by TCP.
As we mentioned earlier, this TCP or UDP data is being transported across the network using IP, or the Internet Protocol. And again, IP is our truck, TCP and UDP are the boxes on the truck, and the network itself is the road that we drive on.
If you’re working with a mover to help move your house, then you know that the movers are going to load up your truck with all of those boxes, and they’re going to move that truck from one location to another. So they need the address of where they’re going to pick up this information, and they need the address of where they’re going to take it.
In the world of networking, we refer to these addresses as IP addresses. And every computer on your network has an IP address, just like every house on your block has a street address.
When we send information to a web server, we are sending that information to a specific IP address. These boxes of TCP or UDP data will arrive at that IP address. But then we have to decide where that particular box is going to go. Just as your house has many different rooms, you have servers that are running many different services.
Your web server might also be a DNS, or Domain Name Server. It could also be a file server, and it could provide voice over IP functions. When information is received by that server, it now needs to decide what room is going to receive this box so that we can properly process that data.
The operating system is sitting outside of your house, and it’s looking at all of the boxes that are coming in from the moving truck. Each box has the name of a room written on it, and it knows that that box should go to the bedroom. Another box perhaps goes to the living room. There might be a third box that goes to the kitchen.
TCP and UDP work in a similar way. But instead of writing the name of the service or the room on the box that’s being received, instead, we’re using something called a port number. So instead of having a room name, you instead have different services, and each service is assigned a particular number. These port numbers allow the incoming data to know exactly where that information should be sent so that it’s processed properly by the appropriate application.
This means when information is being sent from one device to another, there are usually at least three different types of information that are important. There is the IP address of the server. There is the TCP or UDP protocol that is being used. And then there is a port number. And from the server’s perspective, it would be a port number associated with that application.
The sending device also has an IP address. It’s sending information via TCP or UDP. And there’s a port number also used by the client, which is useful for sending information back to the client once the server has processed that data.
As you start looking at different services and memorizing different port numbers, you’ll notice that certain applications always tend to use the same port numbers. We refer to these as nonephemeral ports, or permanent port numbers. Usually, these port numbers are between port 0 and port 1,023, but it could use any port number available to be able to define what port number is associated with an application.
If you were to look at the configuration of a service that’s running on a device, such as a web server, an email server, or a file server, you’ll see that a port number is also associated with that particular service. This allows anyone who’s communicating to that service to always send information with a port number that will be recognized by that service.
To be able to communicate to that service, our client needs to have not only an IP address and TCP or UDP protocol, but it needs a client port number. Client port numbers can be any number, usually between 1,024 and 65,535. Because these port numbers are simply used temporarily, we refer to them as ephemeral ports. They are used for a single communication, and once the communication to the server is over, we close that connection, and we don’t use that port number any longer. If we need to communicate to that server again, we choose a new random port number and use that as our client port number.
So now we know that a TCP or UDP port number can be any value between 0 and 65,535. If we’re communicating to a server, that server is probably going to use a nonephemeral port number, but that may not always be the case. Fortunately, most applications will use a port number, and it will always be that port number running on that service.
Also, keep in mind that these port numbers sound like they could be used for some type of security process. But in reality, they’re simply a number that’s used for reference. They’re not designed to be a security mechanism, and it’s very easy to find a port number on a service, even if someone may have changed the port number to something else.
In fact, we often refer to these port numbers on a server as a well-known port number because you need to know the port number in order to communicate to that particular service. Also, keep in mind that TCP port numbers have a range between 0 and 65,535, and UDP port numbers also have a range between 0 and 65,535. But a TCP port 80 is not the same thing as a UDP port 80. These are different protocols that have a similar numbering scheme for their port numbers, but the port numbers are unique to each individual protocol.
Here’s an example of a client and a server having multiple forms of communication occurring simultaneously across the network and using different port numbers in order to do that. In this example, we have a server, and on this server are three different services. There’s a web server running at TCP port 80. There’s a voice over IP server running at UDP port 5,004. And there’s an email server using TCP port 143.
That means we’ll have three different types of communication going between our client and our server. Notice that our client has an IP address of 10.0.0.1, and our server has an IP address of 10.0.0.2. You can see that we’re sending information across an ethernet network because we have an ethernet header and an ethernet trailer. Inside of each of these communications is IP because IP is the protocol that we use the most for communication.
But notice that inside of these IP packets, some of these have TCP traffic. Others have UDP traffic. And you can see that the TCP traffic may be HTTP data using port 80. It might be voice over IP data using UDP port 5,004, or email data using port 143.
If we were to look at a protocol decode of this information, we get a lot more detail about the communication that’s occurring. We know that we have a source IP of 10.0.0.1 and a destination IP of 10.0.0.2. That matches the IP address of the client and the IP address of the server. Each of these communication flows have the same source IP and destination IP.
Notice that there are differences, though, inside of those IP packets. You can see in each of these examples that the destination port is the port that we listed above, or the well-known port for that particular application. But notice that the source port is using a random number, and each of these traffic flows is using a very different source port. That’s because those are ephemeral ports. They’re temporary ports that we’re simply using to be able to send this information to the server and receive information back.
If this client needed to send additional traffic flows to this server, then it would choose another random port number and send another flow of traffic that had some application data inside of it. This is the process that’s occurring for every device on your network to be able to send traffic from one place to another. Whether that’s on a local server or across the internet, the process is exactly the same, all thanks to IP, TCP, and UDP.