We rely on IP as the fundamental protocol on today’s networks. In this video, you’ll learn about the fundamentals of IP, TCP, UDP, and ICMP.
<< Previous Video: How to Pass your Network+ Exam Next: Common Ports >>
If you had an item that you needed to move between two addresses, it would be very common to use a moving truck. We would load the item into the back of the moving truck, drive it to the new address, and then unload the item. It works exactly the same way for our networks. We would take some data, put it inside of a moving truck, move it across a network, and then unload it on the other end.
You can think of the network topology itself as being the road. This might be your ethernet network or a DSL network or one that’s using a cable modem. Inside of this trunk, we have some data which means the truck is going to be our internet protocol. It’s going to be responsible for taking data from one end of the network and moving it to the other end of the network.
Inside of the moving truck is a box of data. This box of data is usually a TCP box of data or a UDP box of data. And we’ll talk more about what those two things are later on in this video. Inside of those boxes is the information that’s very important to us. Usually it’s application data, something that we can use to browse the internet or transfer a file.
That means that we have a road with a truck inside of the road that has a box inside of the truck that has data inside of the box. and so on. Everyone has a very specific job. The highway really doesn’t care what type of truck is driving on it. We’ve chosen to put an IP truck on this particular highway. The truck doesn’t really care what it’s hauling in the back, there’s simply a box that is in the back of the truck. All the truck is responsible for is getting to the address of its destination. And the people that are moving this box in and out of the truck don’t necessarily care what’s inside of the boxes as long as those boxes are able to be unloaded at the other end.
Let’s look at these protocols visually. Let’s start with an ethernet network. We have an ethernet ‘ header at the beginning of some ethernet data and we have an ethernet trailer that is at the end of this ethernet payload. Inside of this ethernet network, we’re transporting IP traffic. And IP also has a payload associated with it.
We know that we have TCP or UDP data. In this case, it will be some TCP data that has some TCP payload. And a good example of TCP payload might be some HTTP data or some web browsing data that we might send through the network. So to move this web browsing traffic across the network, we need to package it up and encapsulate it within TCP, which then needs to be encapsulated within IP, which is then encapsulated within ethernet.
Let’s look into more detail about these TCP and UDP protocols that are encapsulated within IP. There are two very different ways to move data from one side of the network to the other. Some applications work better using the TCP protocol. Other applications work better if they’re using the UDP protocol.
TCP and UDP operate at the OSI models layer 4. We have another video where we’re going to talk a lot about the OSI model but when someone refers to a layer 4 protocol, they’re almost always referring to either TCP or UDP. One nice feature of TCP and UDP is that it allows us to use multiple applications at the same time across the network. This is multiplexing and it’s one of the advantages of using these protocols on an IP network
TCP stands for Transmission Control Protocol and it’s what we call a connection oriented protocol. It’s connection oriented because there’s a formal connection made with a separate device on the network. Data is transferred and then that connection is formally terminated at the end of that communication. That means there’s some additional overhead that takes place every time you need to send information via TCP.
We also refer to TCP as a reliable mode of communication. This means that every time we send data to another device, we expect to receive an acknowledgment back from that device. You can think of this as being a return receipt. There is an evidence that delivery has been made and that’s why we call it a reliable delivery method.
TCP also numbers the data that it’s sending so that if data is lost or data is received out of order, the device can either request some additional retransmissions of the lost data or it can put all of the data back into its original order. TCP also allows the receiving device to control the flow of traffic. If the receiving device would like to slow down or speed up the traffic flow, it can send a message to the sending device and control the flow of that communication.
UDP stands for User Datagram Protocol. Unlike TCP, UDP does not have a formal call setup or a formal call breakdown process. It’s what we call a connection list protocol because it simply starts sending data whenever data is available and it hopes the device on the other end is ready to receive.
You’ll often hear UDP referred to as an unreliable form of delivery. This means that we don’t get a return receipt or an acknowledgment from the other device. It’s not that UDP works any better or worse than TCP to send this data. It’s that we simply don’t receive a verification that the data was indeed received.
This also means that UDP does not have a way to recover from data that may have been lost and it doesn’t have a way to reorder data that may have been received out of order. Since the device that’s sending UDP data never receives any type of feedback from the receiving device, there’s no way to provide any type of flow control. The sending device is the one that will make the determination of how much data will be transmitted at any particular time.
Some applications commonly use TCP to communicate and other applications commonly use UDP. The decision on which protocol to use is usually based on the way the application works. Some applications prefer to get an acknowledgment or return receipt that that information was received successfully, so those applications will use TCP. Other applications may not have the same requirements. They’re simply sending data and they’re not so concerned about whether that data got to the end station or not. In those cases, the application may choose UDP.
So now we know that our delivery truck is delivering from one address to another. If it’s the IP delivery truck, then it’s delivering from one IP address to another IP address. Just as every house has a physical address, all of your computers have their own IP address.
As our IP truck delivers this data to the destination IP address, the boxes are dropped off but then where do those boxes go? If this is a traditional moving truck, then the box inside of the moving truck would probably have the name of a room. So the box may go to the bedroom or it may go to the living room. With IP, we don’t use a room name to describe where we’re dropping off this box. We instead use a port number and this port number is instead written on the outside of the box. ‘ instead of a bedroom, you may see the port 80. Instead of the living room, you may see port 443. And that way the box knows exactly where inside the house it needs to go.
We commonly associate different port numbers with different applications. So the port number 80 would be web traffic that is not encrypted and port 443 would be web traffic that was encrypted. We might be using port 25 to describe mail communication and we might be using port 123 to describe a time Synchronization service. That way, when the data arrives at this computer, it knows exactly which application it’s destined for.
Let’s summarize this list of information that’s required to get data from one side of the network to the other using IP. We know that we have a server IP address that we’re sending this to. We’ll be using a TCP or UDP protocol and then we’ll also have a server application port number associated with this data. We also have a client IP address that is sending this data. It’s using a TCP or UDP protocol and we know there’s a port number on the client side where this data will be sent back to.
In IP networking, we tend to describe port numbers as one of two different groups. One of these groups is a non-ephemeral port group. Non-ephemeral means non temporary. This would be permanent port numbers that are used and they’re commonly used by applications or services that are running on a server. Those port numbers are usually defined as port 0 through 1,023.
Ephemeral port numbers are temporary port numbers that the client usually decides to use randomly as it’s sending this information back to the server. So our server IP address would commonly use a non-ephemeral port and the client IP address is commonly going to use an ephemeral port number. This means that TCP port numbers can be between 0 and 65,535 and UDP port numbers can be between 0 and 65,535.
Although most servers or services will use permanent or non-ephemeral port numbers, this is not always the case. A server could choose to use any number it would like between 0 and 65,535. These port numbers are used so that we can communicate back and forth from one device to another. Changing a port number doesn’t add any special kind of security and you shouldn’t use port numbers as a method to secure a particular application.
When you’re accessing a server using this port number, you need to know what that number is. And that’s why we often use this list of well known port numbers to describe certain applications. For instance, we know that HTTP commonly uses a well-known TCP port number of 80 and we know that HTTPS commonly used a well-known TCP port number of 443.
TCP port numbers are different than UDP port numbers. That means that one application could be using TCP port 80 to communicate and a completely different application could be using UDP port 80 to communicate and there’s no conflict between either the TCP port 80 or the UDP port 80.
What you would commonly see on a server, though, is not using the same port number for TCP or UDP. Instead, we would use the well-known port numbers to define certain applications that are running on that server. For example, we have in this view a client and we have a server. The client is IP address 10.0.0.1 and the server’s IP address 10.0.0.2.
This server has three applications that are running on this device. One of the applications is a web server and it’s using TCP port 80, the well-known TCP port number for web services. There’s also a voice over IP server running on the server, and it’s using UDP port 5,004 and there’s also an email server running on this server and it’s using TCP port 143. That means if we’re going to send traffic from our client to our server, we’ll send information via the TCP or UDP port numbers that are specified as the well known port numbers on that server.
That means, in order to use these applications, the client is going to send some TCP data over, for example, TCP port 80 to send the HTTP data. It will send information over UDP port 5,004 to communicate this voice over IP data and it will send email traffic over TCP port 143 to send the email data. All of this information looks very similar as it’s going across the network but the server is going to look at those port numbers to determine exactly what application is going to get what data.
If we were to look into this IP packet with much more detail, we’d be able to see the source and destination IP addresses, we’d be able to see the source ports and the destination ports that are used, and we’d be able to see the application data that was included inside of the packet. For example, we have a source IP address of 10.0.0.1– that’s our client machine– and it’s sending this packet to 10.0.0.2– that’s our server. The client needs to be able to communicate over some source port number, so it randomly chooses a port number of 3,000 so that the data will have somewhere to come back to once the server responds.
Then we have a TCP destination port 80. That means that we’re going to the port 80 web services that are located on the server and we’re sending some HTTP data. When the server sends the information back, it will simply switch the source and destination IP and the source and destination port numbers and send the information in the other direction.
We have similar traffic that’s communicating between these two devices. This client randomly chose source port 7,100 and it’s sending it to the well-known port number of 5,004, which is used for voice over IP communication. And finally, we have some email data. Again, the client device chose a random port number of 4,407 and it’s sending it to the TCP destination port number of 143 to be able to send email information into that server.
This conversation using IP addresses and port numbers and data occurs every time you’re sending IP information across the network. If you were to look at a protocol decode of all of this communication, you would very easily be able to break out the IP addresses, the port numbers, and all of the data so that you can examine the conversations that were occurring across the network.
Sometimes the IP truck that we’re sending from one IP address to another isn’t really transporting any application data at all. It simply wants to check in on you. One of the protocols that it uses for this is ICMP. This is the Internet Control Message Protocol. You can think of it as text messaging between devices, to check in and see how somebody might be doing.
This is yet another protocol that’s carried by IP and it’s not one that you’ll commonly see used for data transfer. ICMP is commonly used for administrative use. You may want to check to see if a machine is operating or not, so you might send an ICMP request to see if that device is there. And if that device is there, it might send an ICMP response to let the original station know that it is alive and able to communicate on the network.
Devices can also use ICMP to let other devices on the network know when things aren’t going so well. If you’re sending information out to another network and a router realizes that it’s not able to communicate to that network, it may send back to your workstation an ICMP message saying that it’s not able to communicate to that network. Or you may have traffic that is looping around the network and ultimately times out and the device that times out that traffic may send a message back to your workstation, letting you know that the time to live has expired. All of these administrative functions are all using this ICMP protocol to be able to make this happen.