Welcome back to Acing the A+, FSET’s introductory guide to CompTIA’s A+ Certification, a.k.a. the basics of information technology! In this edition, we’ll be taking a look at Internet Protocol and how data is transferred over modern networks.
In most cases, getting from point A to point B means taking a certain path. You might drive down a highway, or maybe a backroad, but what about moving information digitally on a computer? Regardless of if your connection is wired or wireless, the path forward will be across what’s known as a network.
This begs the question – what is driven along the path? Cars on roads are one thing, but within a network, the vehicle in question is Internet Protocol – or IP for short. IPs are meant to handle and transport pretty much kind of information without actually knowing what’s being moved. After all, you wouldn’t want your taxi driver peeking in your bags, would you?
To this end, Internet Protocol determines what and where specific information is moved to. Some data might be specific to an application, while other data might be meant to function in a certain way within your network. Going back to the vehicle analogy one last time, if you think of IP like a moving truck, the truck knows where each box you’ve packed is supposed to go before its unpacked. In the digital world, this process is known as encapsulation.
On a computer, this often sees data go from a server to a client (device) over a network. Maybe you’re receiving a sensitive email on your work laptop, or, you’re downloading a new game onto your personal desktop. If your connection is wired, it will most likely be with an ethernet cable, which will itself respectfully contain data referred to as an ethernet payload.
An ethernet payload could contain pretty much anything, but in most cases, it will use Internet Protocol – meaning that the ethernet payload will contain an IP payload with certain information inside. Catching on to the whole ‘payload’ thing yet? IP payloads can contain TCP payloads, which can then contain HTTP payloads, and so on and so forth. You can think of it kind of like a Matryoshka Doll.
In addition to the term payload, batches of data are also referred to as packets (which, as you might guess, are encapsulated). In addition to TCP (Transmission Control Protocols), UDP (User Datagram Protocol) and OSI (Open Systems Interconnection) are both common ways for networks to communicate and send data over each other.
TCP, UDP and OCI add additional capabilities that IP doesn’t have on its own – based on our road analogy, you could think of them as different vehicles with different functionalities. Multiplexing, for example, is something that TCP and UDP enable so that you can run several applications at once and have them all send information to one server simultaneously.
TCP has been designed to optimize connections and the flow of information by verifying that what’s been sent has actually been received on the other end. TCP can also re-order the information that’s being sent, which can come in handy if a lot of information is being sent at once. Finally, TCP can both resend information and slow down the rate of transfer if necessary.
UDP, on the other hand, takes a much less nuanced approach to sending information – in fact, it really is along the lines of going from Point A to B, without any kind verification or adjustment along the way. While this might make it sounds like UDP is ‘lesser’ than TCP, it’s actually quite useful for sending information where you know how the job needs to get done, as its simplicity makes it quite reliable. One example would be a phone call, where the ‘information’ (talking) can’t be rewound, and the data just needs to be ‘sent’ (spoken). If the phone call is momentarily broken up, it picks back up right where it should in real time.
DHCP (Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol) both use UDP as a transport mechanism. HTTPS (Hypertext Transfer Protocol Secure), meanwhile, favours the use of TCP to take advantage of its receipt functionality. If packets containing HTTPS data are lost during transfer, TCP will recognize it and re-send the data.
When networks deliver information from one IP (server) to another IP (client), their final place of delivery is typically determined by the data’s port number, or port for short. If packets were a box marked for delivery, the port number would be written on the outside so the delivery could make it to where it belongs – say, a specific application or folder on your computer, all of which will have their own (matching) port numbers.
Multiple servers can (and often do) send information to the same IP address – say, a mail server on port 69, encrypted data on port 210, unencrypted data on port 99, and a time server on port 177. This is where multiplexing and UDP come in handy – the more ports that are delivered to an IP at once, the better it is to have a UDP protocol double-checking all of the deliveries. You wouldn’t want an update for your favourite game downloading into your pictures folder, would you?
Many IP protocols, such as web servers, have designated port numbers that don’t change over time in order to make deliveries easier. When port numbers are permanent, they’re referred to as non-ephemeral ports. For example, port number 80 is often associated with HTTP, and port number 443 is commonly associated with HTTPS. Port numbers will usually range between 0 and 1023, but they can theoretically be any number (just don’t expect to see them in the field).
Temporary port numbers, on the other hand, are known as ephemeral ports. They’re usually assigned to devices that are receiving data from a server. Ephemeral port numbers typically range from 1,024 to 65,535, but they’re often assigned in real time and you might never see the same temporary port number twice.
Notably, port numbers are not designed to be a security measure. In fact, it’s relatively easy to use a port scanner to search for all of the open ports on a particular server. When it comes to security protocols and the protection of data, ports are not the name of the game.
It’s also important to note that UDP and TCP use their own numbers – meaning that communications on UDP 45 and TCP 45 would not overlap. However, to prevent confusion in the backend, using the same number across different protocols is usually avoided by programmers.
Considering port numbers can go all the way up to 65,535 and multiple kinds of information can be sent at once, you might think that the transfer of information from one IP to another would be super complicated – but thanks to how specific and well-designed protocols and port number systems are, the server will always know exactly where everything goes.
Welcome back to Acing the A+, FSET’s introductory guide to CompTIA’s A+ Certification, a.k.a. the basics of information technology! In this edition, we’ll be taking a look at Internet Protocol and how data is transferred over modern networks.
In most cases, getting from point A to point B means taking a certain path. You might drive down a highway, or maybe a backroad, but what about moving information digitally on a computer? Regardless of if your connection is wired or wireless, the path forward will be across what’s known as a network.
This begs the question – what is driven along the path? Cars on roads are one thing, but within a network, the vehicle in question is Internet Protocol – or IP for short. IPs are meant to handle and transport pretty much kind of information without actually knowing what’s being moved. After all, you wouldn’t want your taxi driver peeking in your bags, would you?
To this end, Internet Protocol determines what and where specific information is moved to. Some data might be specific to an application, while other data might be meant to function in a certain way within your network. Going back to the vehicle analogy one last time, if you think of IP like a moving truck, the truck knows where each box you’ve packed is supposed to go before its unpacked. In the digital world, this process is known as encapsulation.
On a computer, this often sees data go from a server to a client (device) over a network. Maybe you’re receiving a sensitive email on your work laptop, or, you’re downloading a new game onto your personal desktop. If your connection is wired, it will most likely be with an ethernet cable, which will itself respectfully contain data referred to as an ethernet payload.
An ethernet payload could contain pretty much anything, but in most cases, it will use Internet Protocol – meaning that the ethernet payload will contain an IP payload with certain information inside. Catching on to the whole ‘payload’ thing yet? IP payloads can contain TCP payloads, which can then contain HTTP payloads, and so on and so forth. You can think of it kind of like a Matryoshka Doll.
In addition to the term payload, batches of data are also referred to as packets (which, as you might guess, are encapsulated). In addition to TCP (Transmission Control Protocols), UDP (User Datagram Protocol) and OSI (Open Systems Interconnection) are both common ways for networks to communicate and send data over each other.
TCP, UDP and OCI add additional capabilities that IP doesn’t have on its own – based on our road analogy, you could think of them as different vehicles with different functionalities. Multiplexing, for example, is something that TCP and UDP enable so that you can run several applications at once and have them all send information to one server simultaneously.
TCP has been designed to optimize connections and the flow of information by verifying that what’s been sent has actually been received on the other end. TCP can also re-order the information that’s being sent, which can come in handy if a lot of information is being sent at once. Finally, TCP can both resend information and slow down the rate of transfer if necessary.
UDP, on the other hand, takes a much less nuanced approach to sending information – in fact, it really is along the lines of going from Point A to B, without any kind verification or adjustment along the way. While this might make it sounds like UDP is ‘lesser’ than TCP, it’s actually quite useful for sending information where you know how the job needs to get done, as its simplicity makes it quite reliable. One example would be a phone call, where the ‘information’ (talking) can’t be rewound, and the data just needs to be ‘sent’ (spoken). If the phone call is momentarily broken up, it picks back up right where it should in real time.
DHCP (Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol) both use UDP as a transport mechanism. HTTPS (Hypertext Transfer Protocol Secure), meanwhile, favours the use of TCP to take advantage of its receipt functionality. If packets containing HTTPS data are lost during transfer, TCP will recognize it and re-send the data.
When networks deliver information from one IP (server) to another IP (client), their final place of delivery is typically determined by the data’s port number, or port for short. If packets were a box marked for delivery, the port number would be written on the outside so the delivery could make it to where it belongs – say, a specific application or folder on your computer, all of which will have their own (matching) port numbers.
Multiple servers can (and often do) send information to the same IP address – say, a mail server on port 69, encrypted data on port 210, unencrypted data on port 99, and a time server on port 177. This is where multiplexing and UDP come in handy – the more ports that are delivered to an IP at once, the better it is to have a UDP protocol double-checking all of the deliveries. You wouldn’t want an update for your favourite game downloading into your pictures folder, would you?
Many IP protocols, such as web servers, have designated port numbers that don’t change over time in order to make deliveries easier. When port numbers are permanent, they’re referred to as non-ephemeral ports. For example, port number 80 is often associated with HTTP, and port number 443 is commonly associated with HTTPS. Port numbers will usually range between 0 and 1023, but they can theoretically be any number (just don’t expect to see them in the field).
Temporary port numbers, on the other hand, are known as ephemeral ports. They’re usually assigned to devices that are receiving data from a server. Ephemeral port numbers typically range from 1,024 to 65,535, but they’re often assigned in real time and you might never see the same temporary port number twice.
Notably, port numbers are not designed to be a security measure. In fact, it’s relatively easy to use a port scanner to search for all of the open ports on a particular server. When it comes to security protocols and the protection of data, ports are not the name of the game.
It’s also important to note that UDP and TCP use their own numbers – meaning that communications on UDP 45 and TCP 45 would not overlap. However, to prevent confusion in the backend, using the same number across different protocols is usually avoided by programmers.
Considering port numbers can go all the way up to 65,535 and multiple kinds of information can be sent at once, you might think that the transfer of information from one IP to another would be super complicated – but thanks to how specific and well-designed protocols and port number systems are, the server will always know exactly where everything goes.