YouTube Instagram TikTok How it works FAQ

The fastest way to turn talking videos into clean, searchable text. Free, private and no account required.

About

Built by Rishav Raj with one goal: free transcripts for everyone.

rishav@yttotranscript.com

Transcribe

YouTube to text
YouTube with timestamps
Instagram Reels
TikTok videos

Learn

How it works
FAQ
YouTube transcripts guide

More

Chrome extension
Contact
Privacy policy
Terms of service

© 2026 YTtoTranscript. Made for creators & researchers.

Not affiliated with YouTube, Instagram or TikTok. Respect creators’ copyright.

Introduction to IP - CompTIA A+ 220-1201 - 2.1 — Transcript · YTtoTranscript

Home/Transcripts/YouTube

YouTube Transcript

Introduction to IP - CompTIA A+ 220-1201 - 2.1

Professor Messer · 3,269 words · 16 min read · EN-ORIG

Watch on YouTube

Share X LinkedIn WhatsApp

Below is the complete, readable transcript of Introduction to IP - CompTIA A+ 220-1201 - 2.1 by Professor Messer on YouTube. Read the full text, copy any part you need, or generate a transcript for any video with our free tool.

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

Transcribe another video

Paste any YouTube, Instagram or TikTok link to get a free transcript.

Free · No sign-up · Unlimited

Add to Chrome — transcribe in one click

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.