IP, TCP, and UDP Explained: Networking Fundamentals for A+ Certification

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 methods 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's 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 plus 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 multipplexing. 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 connectionoriented. That means there is

a formal process to set up a conversation with the 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 tearown. 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 acknowledgement process. So TCP sends the data and the person receiving the data will send back

an acknowledgement 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 acknowledgement 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 datagramgram protocol. We have a connectionoriented protocol with TCP and with UDP we are

connectionless. There's no formal process to start the communications flow and there's no formal tearown 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 acknowledgements coming back to

the sender. Since there's no acknowledgement 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, Voiceover 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 rescending 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 voiceover IP apps might not do anything if data is lost. If information doesn't

make it through, then it will simply continue sending the voiceover 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 the 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 acknowledgements 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 voiceover 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 non-ephemereral ports or permanent port

numbers. Usually these port numbers are between port zero and port 1023, 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 124 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 non-ephemeral 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 voiceover IP server running at UDP port

504 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 voiceover IP data using UDP port 504 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 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.