Understanding the fundamentals of IP are important for overall understanding of our modern network. In this video, you’ll learn how IP is used to move data across the world.
In this course, there will be a lot of conversations about TCP/IP moving packets across the network. And very often, we lose track of exactly what that means. So I thought it would be good if we started with an overview of Internet Protocol and how it operates.
The goal, of course, is to get data from one side of the network to another. And there are a number of different processes involved in being able to transfer large amounts of data from one computer to another. In the analogy that we use today, we’re going to describe this transfer of data from one device to another as using a moving truck to get data from one house to another.
We can also think of the roads that we’re using as the network that we’ve created. This might be a wired Ethernet network, a wireless network, a wide-area network technology, or many different types of network connections. But in this explanation, those network connections are referred to as the road that our moving truck will drive on.
In this example, this truck is the Internet Protocol. It’s the one that is doing the heavy lifting and moving that data across the network. Just as we might pack up items or objects in a room into a box and put that box onto the moving truck, we do effectively the same thing with our application data. We package that information into a virtual moving box. And we put that moving box onto the truck, which, in this case, would be IP.
So now we have a highway, which would be our network. We have a moving truck, which would be the Internet Protocol. We have boxes within that moving truck. We commonly refer to those boxes as the TCP or UDP protocol. And then inside of those boxes is application data that we need to transfer from one device to another.
This process of encapsulating data within other protocols which are then encapsulated within even larger protocols is a fundamental process when we describe the transfer of data across the network. If we were to visualize the Ethernet frame that we use on our networks, it would look a lot like the one that we have on our screen now. We have a client that is communicating to a server. And information is being sent between those two devices.
You’ll notice there is an Ethernet payload in the middle of this frame. At the beginning of the frame is an Ethernet header. And at the end of the frame is an Ethernet trailer. If we were to provide a little more detail about what’s inside of that Ethernet payload, you would see there would be some IP information. And within the IP header, the rest of the packet has the IP payload.
Deconstructing this further, you can see that the IP payload consists of a TCP or UDP header. And inside of that part of the packet is the TCP or UDP payload. So if we were to look at a protocol decode of a single frame on our Ethernet network, we would see an Ethernet header. Inside that Ethernet header would be an IP header. Inside the IP header might be a TCP header, which would hold HTTP or website data. And then finally, at the end of the frame, we would have the Ethernet trailer.
You’ll notice that inside of that IP header, we had either TCP IP data or UDP data. So it might be useful to break out those two protocols and describe what the differences might be. Both of these protocols are very similar in their function. They’re obviously moving data from one device to another. But the internals of how those protocols work are a bit different between the two. And an application will use the one that makes sense for its particular function.
If you recall our video on the OSI model, you’ll remember that TCP and UDP operate at OSI layer 4, or the transport layer. It’s in this layer that we’re able to send many different applications across the network simultaneously between exactly the same devices. We refer to this as multiplexing. And it describes the efficient process of transferring multiple applications simultaneously between multiple devices.
Let’s first look at TCP, or the Transmission Control Protocol. We refer to TCP as a connection-oriented protocol. That’s because there is a formal process to set up the communication between two devices. And when that communication is done, there is a formal process to tear down that particular session.
One feature that makes TCP different than UDP is the ability for a station to acknowledge that it has received data. We refer to this as a reliable delivery method. That’s because sending data to another device will always result in an acknowledgment that that device has successfully received that data. This means the sending station will always know if information was properly delivered to the destination.
This also means that the sending device can recover from any type of errors. If it doesn’t receive an acknowledgment, it can assume that that information was not received by the destination device. And it will resend that information to ensure that it is able to receive all of the data. These packets are also numbered. So the receiving device will also be able to request anything that may have been lost along the way without having to resend multiple packets and re-create that data.
Having this conversation between these two devices about how well traffic is able to be transferred allows the receiving station to configure flow control. This describes the process of the receiving station telling the sending device to either send data slower or speed up the transmission.
UDP, or the User Datagram Protocol, is a much more barebones protocol. There is no formal process to set up a session between two devices and no formal process then to tear down that session. We refer to this as a connectionless communication because there’s no setup or warning that information may be inbound to a particular device.
This means that we can send packet after packet of UDP data from one device to another. And no UDP acknowledgment is ever sent back to the originating device. We refer to this type of communication as unreliable, not because there is a higher chance of having problems communicating. In fact, UDP and TCP are able to communicate in exactly the same way with exactly the same probability of getting that information sent across the network. The difference is that we don’t receive any acknowledgments when using UDP. So we can’t guarantee that that information has truly been delivered.
And since there’s no acknowledgment and no notification that anything has been delivered, there’s no way to perform any type of error recovery or be able to retransmit portions of the data which may have not been received. And because there’s no ongoing communication back and forth between these two devices using UDP, there’s no way to configure any type of flow control. The receiving station can’t reach out and tell the sending station to speed up or slow down, because nothing is ever sent back to the originating station.
Now that we’ve loaded our boxes of data into our IP truck, we need to tell the truck driver where to take this information. And in a moving truck, we do this by giving the truck driver the destination address for the truck. In the world of IP, we give it a destination IP address. But, of course, in a house we have many different rooms that we might deliver these boxes to. Some boxes might be for the bedroom. Others might be for the kitchen or bathroom. And when we bring the box into the house, we can take that box directly to the appropriate room.
IP works in a similar way, where each box of data is provided a room name. And in the world of IP, it’s provided via a TCP or UDP port number. Instead of having bedroom, living room, kitchen, or bath, there will be a number associated with that data, such as port 80, port 443, port 123, or port 25. When those TCP or UDP boxes arrive at the house, we simply look at the TCP or UDP port number and deliver that box to the appropriate application running on that server.
If you were to look at a protocol decode of IPv4 traffic being sent over the network, you would see a set of IPv4 sockets for the server and for the client. This socket is a combination of data that consists of an IP address, a protocol, which would be TCP or UDP, and then there would be an application port number. For the server side, there would be a server application port number. And on the client side, there is a client port number.
Once both sides of the conversation know what the IP address is, they know the protocol, and they know the port numbers of both the server and the client, we’re able to send information properly between both devices to the appropriate application. If you were to look at well-known applications that are using TCP or UDP, you’ll notice that many of those port numbers are from 0 through 1,023. We refer to these as nonephemeral ports, which means they are permanent port numbers. If we need to communicate to a web server, we’re almost always going to use port 80 and port 443. Those are very common and permanent port numbers that you would find on almost any web server.
On the client side, we tend to use port numbers on a temporary basis. And we refer to those as ephemeral ports. Those are ports that are commonly associated with 1,024 through 65,535. Although it’s very common to find applications using nonephemeral ports and the clients using ephemeral ports, the reality is any device can use any port number that it would like to.
And although we commonly associate servers with nonephemeral ports and clients with ephemeral ports, the reality is you could find application servers using port numbers within the ephemeral port range. So you can see this is not a hard and fast rule but instead broadly describes the way that we use these port numbers on our network.
Anytime you see a TCP or UDP port, it can be a number between 0 and 65,535. That is a lot of room to be able to use different port numbers for different applications. Most servers, as we mentioned, will use nonephemeral or nontemporary port numbers. But that’s not always the case. And you could see applications using port numbers that are in the ephemeral port range.
Remember that changing port numbers is simply a way to designate what room inside of the house will be receiving that particular data. It’s used for communication. And this is not a security mechanism. You’ll still need a firewall to decide whether traffic is truly allowed or disallowed through the network. And simply changing a port number doesn’t increase or decrease any type of network security.
If you’re connecting to a web server, your browser automatically knows that it should be looking for port 80 or port 443. And it will use those ports by default. If you change the port numbers of the server, your browser will no longer know how to connect to that web server. That’s because we expect web servers to always use port 80 or always use port 443. These are well-known port numbers. And if you change those port numbers, you’ll have to make sure that all of the clients use the new port number instead of what normally would be well known.
Also, keep in mind that TCP port numbers are different than UDP port numbers. Although both of them can be between 0 and 65,535, TCP port 80 is a different port number than UDP port 80. And you could theoretically use two different applications with both of those protocols at the same time.
Here’s how this might be practically configured on our network. In this example, we have a server. Its IP address is 10.0.0.2. And we have a client at 10.0.0.1. These two devices are communicating across the network using three different applications. The server has a web server at TCP port 80, a voice-over-IP server at UDP port 5004. And it’s also providing email services over TCP port 143. This means the client can communicate to the server with all three of those applications simultaneously because they all have different TCP and UDP port numbers.
If we were to then look at the IP data that was being sent on a single communication, you can see that this IP address of 10.0.0.1, our client, is sending information to this 10.0.0.2 address. You’ll also notice that the client is using a temporary port number for this session. In this case, the randomized temporary port number is port 3000. And this device is communicating to the web server. So it’s using the well-known port number of port 80. And you can also see there is HTTP data contained within this packet as well.
This data is received by the server. And when the server needs to send information back to the client, it simply reverses the TCP source port and destination port and the IP source and destination to be able to send that information back to where the original request was sent. This same process occurs if you’re using voice-over-IP data. In this case, the client is using a source port of 7100. And the UDP destination port would be 5004, which would be the voice-over-IP service on that server. And for email data, the source port that’s being used is a random number of 4407. And the destination port is the well-known port for email, port 143.
So every device on the network that is communicating via IP is using this fundamental process to transfer data. This allows us to scale up into a worldwide internet and be able to send data between two devices anywhere in the world.