Before we start today's video tutorial, I want to thank everyone who contributed to the popularity of my course on YouTube. When I started it about 8 months ago, I did not expect such a success - today 312724 people have viewed my lessons, I have 11208 subscribers. I never dreamed that this modest undertaking would reach such heights. But let's not waste time and immediately move on to today's lesson. Today we will fill in the gaps that took place in the last 7 video tutorials. Although today is only day 6, day 3 has been broken into 3 video lessons, so you will actually watch the eighth video lesson today.
Today we will deal with 3 important topics: DHCP, TCP forwarding and the most commonly used port numbers. We have already talked about IP addresses, and one of the most important factors in IP address configuration is DHCP.
DHCP stands for "Dynamic Host Configuration Protocol" and is a protocol that helps to dynamically configure IP addresses for hosts. So, we all saw this window. When you click on the “obtain an IP address automatically” option, the computer looks for a DHCP server configured on the same subnet and sends various packets and requests for the IP address. The DHCP protocol has 6 messages, of which 4 are critical for assigning an IP address.
The first message is a DHCP DISCOVERY message. The DHCP discovery message is similar to a hello. When a new device joins the network, it asks if there is a DHCP server on the network.
What you see on the slide looks like a broadcast request, when the device contacts all devices on the network in search of a DHCP server. As I said, this is a broadcast request, so all devices on the network hear it.
If there is a DHCP server on the network, it sends a packet - a DHCP OFFER. An offer means that the DHCP server, in response to a discovery request, sends a configuration to the client, prompting the client to accept a specific IP address.
The DHCP server reserves an IP address, in this case 192.168.1.2, does not provide, but rather reserves this address for the device. In addition, the offer package contains the DHCP server's own IP address.
If there is more than one DHCP server on this network, another DHCP server, upon receiving the client's broadcast request, would also offer its own IP address, for example, 192.168.1.50. Usually, two different DHCP servers are not configured on the same network, but sometimes this does happen. So when a DHCP offer is sent to a client, it receives 2 DHCP offers and must now decide which DHCP offer it wants to accept.
Let's assume that the client accepts the first application. This means that the client sends out a DHCP REQUEST that literally says "I accept the IP address 192.168.1.2 offered by the DHCP server 192.168.1.1".
Upon receiving the request, the DHCP server 192.168.1.1 replies "OK, I'll admit it", i.e. acknowledges the request and sends this DHCP ACK to the client. But we remember that another DHCP server DHCP reserved IP address 1.50 for the client. Upon receiving the client's broadcast request, it will become aware of the rejection and put that IP address back into the pool so that it can assign it to another client if it receives another request.
These are the 4 critical messages exchanged by DHCP at the start of IP address assignment. Further, DHCP has 2 more informational messages. An informational message is issued by the client if it needs more information than it received in the DHCP OFFER in the second step. If the DHCP server provided insufficient information in the DHCP offer, or if the client needs more information than what was contained in the offer packet, it requests additional DHCP information. There is one more message that the client sends to the server - this is a DHCP RELEASE. It says that the client wants to release the IP address he has.
However, most often it happens that the user is disconnected from the network before the client has time to send a DHCP RELEASE to the server. This happens when you turn off the computer, which we carry out with you. In this case, the network client, or computer, simply does not have time to tell the server to release the used address, so DHCP RELEASE is not a mandatory step. The mandatory steps to obtain an IP address are: DHCP discovery, DHCP offer, DHCP request, and DHCP handshake.
In one of the following lessons, I will explain how we configure the DHCP server when creating a DNCP pool. Pooling means that you tell the server to assign IP addresses in the range 192.168.1.1 to 192.168.1.254. Thus, the DHCP server will create a pool, place 254 IP addresses in it, and will be able to assign addresses to network clients only from this pool. So this is something like an administrative setting that the user can make.
Now let's look at TCP transmission. I don't know if you're familiar with the "telephone" in the picture, but when we were kids, we used these tin cans connected with string to talk to each other.
Unfortunately, today's generation cannot afford such a "luxury". I mean today kids are in front of the TV from the age of one, they play PSP and maybe it's a moot point but I think we had the best childhood, we really went out and played games, uh today's children can not be torn off the couch.
My son is only a year old and I can already see that he is addicted to the iPad, I mean he is still very young, but it seems to me that today's children are already born with the knowledge of how to handle electronic gadgets. So, I wanted to say that in childhood, when we played, we made holes in tin cans, and when we tied them with a string and said something into one can, then on the other end a person could hear what they were saying to him, simply by putting the can to his ear . So it's very similar to a network connection.
Today, even for TCP transmission, there must be a connection that must be established before the actual data transmission can begin. As we discussed in previous lessons, TCP is a network connection-oriented transmission, while UDP is a connectionless transmission. You could say UDP is when I throw the ball and it's up to you if you can catch it. Whether you're willing to do it or not, that's not my problem, I'm just going to quit.
TCP is more like talking to a guy and giving him advance warning that you're going to throw the ball, meaning you bond before you throw the ball, so your partner is more likely to be ready to catch it. So TCP actually builds the connection and then starts the actual transmission.
Let's see how it creates such a connection. This protocol uses a 3-way handshake to create a connection. This is not a very technical term, but it has long been used to describe a TCP connection. The 3-way handshake is initiated by the sending device, with the client sending a packet with the SYN flag to the server.
Suppose the girl in the foreground, whose face we can see, is device A, and the girl in the background, whose face is not visible, is device B. Girl A sends a SYN packet to girl B, and she says: “okay, someone he wants to communicate with me. So, I need to answer that I am ready to communicate!” How to do it? One could simply send back another SYN packet and then an ACK indicating receipt of the original SYN packet. But instead of sending ACKs separately, the server forms a common packet that contains SYN and ACK and sends it over the network.
So, at this point, device A has sent a SYN packet and received a SYN/ACK packet back. Now device A must send an ACK packet to device B, that is, confirm that it has received device B's consent to establish communication. Thus, both devices received SYN and ACK packets, and now we can say that the connection has been established, that is, a 3-way handshake has been performed using the TCP protocol.
Next, we will look at TCP Windowing technology. Simply put, it is a technique used in TCP/IP to negotiate the capabilities of a sender and a receiver.
Let's say that in Windows we are trying to transfer a large file, say 2 GB in size, from one drive to another. At the very beginning of the transfer, the system will inform us that the transfer of the file will take approximately 1 year. But a few seconds later, the system will correct itself and say, "oh wait a minute, I think it won't take a year, but about 6 months." A little more time will pass, and Windows will say: "I think I can probably transfer the file in 1 month." Then the message "1 day", "6 hours", "3 hours", "1 hour", "20 minutes", "10 minutes", "3 minutes" will follow. In fact, the entire file transfer process will only take 3 minutes. How did it happen? Initially, when your device tried to communicate with another device, it sends one packet and waits for an acknowledgment. If the device is waiting for confirmation for a long time, it thinks: "if I have to transfer 2 GB of data at this speed, then it will take about 2 years." After some time, your device receives an ACK and thinks, “OK, I sent one packet and received an ACK, so the recipient can receive 1 packet. Now I will try to send him 10 packets instead of one.” The sender sends 10 packets and after some time receives back an ACK from the receiving device, which means that the recipient is waiting for the next, 11th packet. The sender thinks: “great, since the recipient has dealt with 10 packets at once, now I will try to send him 100 packets instead of ten.” It sends 100 packets and the receiver responds that it has received them and is now waiting for 101 packets. Thus, over time, the number of transmitted packets increases.
That's why you're seeing a dramatic decrease in file copy time compared to what was originally claimed - this is due to the increase in the ability to transfer large amounts of data. However, there comes a point when further increase in transmission volume becomes impossible. Suppose you have sent 10000 packets, but the receiver's device buffer can only receive 9000. In this case, the receiver sends an ACK with the message: "I received 9000 packets and is now ready to receive 9001." From this the sender concludes that the buffer of the receiving device has a capacity of only 9000, which means that from now on I will send no more than 9000 packets at a time. At the same time, the sender quickly calculates the time it will take him to transmit the remaining amount of data in portions of 9000 packets, and issues 3 minutes. These three minutes are the actual transmission time. That's what TCP Windowing does.
This is one of those traffic throttling mechanisms where the transmitting device learns over time what the actual network throughput is. You might be wondering why they can't agree upfront on what the capacity of the receiving device is? The fact is that it is technically impossible, because there are various types of devices on the network. Let's say you have an iPad and it has a different upload/download speed than an iPhone, you might have different types of phones, or maybe you have a very old computer. Therefore, everyone has a different network bandwidth.
Therefore, the TCP Windowing technology was developed, when data transfer starts at a low speed or with the transfer of a minimum number of packets, gradually increasing the traffic “window”. You send one packet, 5 packets, 10 packets, 1000 packets, 10000 packets and slowly open this window more and more until the “opening” reaches the maximum possible amount of traffic sent in a specific period of time. Thus, the concept of Windowing is part of how the TCP protocol works.
Next, we will look at the most common port numbers. The classic situation is when you have 1 main server, perhaps a data center. It includes a file server, a web server, a mail server, and a DHCP server. Now, if one of the client computers contacts the data center, which is located in the middle of the picture, it will start sending file server traffic to client devices. This traffic is shown in red and will use a specific port for a specific application from a specific server.
How does the server know where certain traffic should go? It learns about it from the destination port number. If you look at the frame, you will see that in each data transfer there is a mention of the destination port number and the source port number. You can see that the blue and red traffic, and the blue traffic is web server traffic, both go to the same physical server that has different servers installed. If it is a data center, then it uses virtual servers. So how did they know that the red traffic was supposed to go back to that left laptop with that IP address? They know this because of the port numbers. If you refer to the Wikipedia article "List of TCP and UDP ports", you will see that it lists all the standard port numbers.
If you scroll this page, you can see how big this list is. It contains approximately 61 numbers. Port numbers from 000 to 1 are known as the most common port numbers. For example, port 1024/TCP is for sending ftp commands, port 21 for ssh, port 22 for Telnet, that is, for sending unencrypted messages. The very popular port 23 is for HTTP communication, while port 80 is for encrypted communication with HTTPS, which is similar to the secure version of HTTP.
Some ports are for both TCP and UDP, and some perform different tasks depending on whether the connection is TCP or UDP. So, officially, TCP port 80 is used for HTTP, and unofficially, UDP port 80 is used for HTTP, but using a different HTTP protocol - QUIC.
Therefore port numbers in TCP are not always meant to be the same as those in UDP. You don't need to memorize this list, it's impossible to remember, but some popular and most common port numbers need to be known. As I said, some of these ports have an official purpose, which is described in the standards, and some have an unofficial purpose, as is the case with Chromium.
So, this table lists all common port numbers, and these numbers are used to send and receive traffic when using specific applications.
Now let's look at how data moves around the web based on the little information we know. Suppose computer 10.1.1.10 wants to contact this computer, or this server, which has the address 30.1.1.10. Below the IP address of each device is its MAC address. I give an example MAC address with only the last 4 digits, but in practice it is a 48-bit hexadecimal number with 12 digits. Since each of these numbers consists of 4 bits, 12 hexadecimal digits is a 48-bit number.
As we know, if this device wants to contact this server, the first step of the 3-way handshake must be done first, that is, a SYN packet is sent. When making this request, the 10.1.1.10 computer will specify the source port number that Windows creates dynamically. Windows randomly selects a port number from 1 to 65,000. But since starting numbers in the range 1 to 1024 are widely known, in this case the system will consider numbers greater than 25000 and generate a random source port, for example, number 25113.
Next, the system will add the destination port to the packet, in this case port 21, because the application that tries to connect to this FTP server knows that it should send FTP traffic.
Next, our computer says, “Ok, my IP address is 10.1.1.10, and I need to contact the IP address 30.1.1.10.” Both of these addresses are also included in the packet, forming a SYN request, and this packet will not change until the end of the connection.
I want you to understand from this video how data moves over the network. When our requesting computer sees the source IP and the destination IP, it understands that the destination address is not on this local network. I forgot to say that these are all /24 IP addresses. So if you look at the /24 IP addresses, you will realize that computers 10.1.1.10 and 30.1.1.10 are not on the same network. Thus, the requesting computer understands that in order to leave this network, it must contact the gateway 10.1.1.1, which is configured on one of the router's interfaces. It knows that it should go to 10.1.1.1 and knows its MAC address 1111 but does not know the MAC address of the gateway 10.1.1.1. What does he do? It sends out an ARP broadcast request that all devices on the network will receive, but only the router with IP address 10.1.1.1 will respond to it.
The router will respond with its AAAA MAC address, and both source and destination MAC addresses will also be placed in this frame. Once the frame is ready, a CRC data integrity check, which is a checksum algorithm to detect errors, will be performed before leaving the network.
CRC means that this entire frame, from SYN to the last MAC address, is run through a hashing algorithm, say MD5, resulting in a hash value. The hash value, or MD5 checksum, is then placed at the beginning of the frame.
I named it FCS/CRC because FCS is a frame check sequence, a four byte CRC value. Some people use the FCS designation and some use the CRC designation, so I just listed both designations. But basically it's just a hash value. It is needed in order to make sure that all data coming over the network does not contain errors. Therefore, when this frame reaches the router, the first thing the router will do is calculate the checksum itself and compare it with the FCS or CRC value that contains the received frame. Thus, he will be able to check that the data received over the network does not contain errors, after which he will remove the checksum from the frame.
Next, the router will look at the MAC address and say "OK, MAC address AAAA means the frame is for me" and remove the MAC part of the frame.
Looking at the destination IP address 30.1.1.10, he will understand that this packet is not addressed to him and must pass through the router further.
Now the router "thinks" about how it needs to see where the network with the address 30.1.1.10 is located. We haven't looked at the full concept of routing yet, but we do know that routers have a routing table. This table has an entry for the network with the address 30.1.1.0. As you remember, this is not a host IP address, but a network ID. The router will “think” that it is possible to reach the address 30.1.1.0/24 by going through the router 20.1.1.2.
How does he know this, you may ask? Just keep in mind that it will know about it either from the routing protocols or from your settings if you configured a static route as an administrator. But anyway, this router's routing table contains the correct entry, so it knows it should send this packet to 20.1.1.2. Assuming the router already knows the destination MAC address, we'll just continue forwarding the packet. If he does not know this address, then he will start ARP again, get the MAC address of the router 20.1.1.2, and the process of sending the frame will continue again.
So, we assume that it already knows the MAC address, then we will have the source MAC address of BBB and the destination MAC address of CCC. The router calculates the FCS/CRC again and places it at the beginning of the frame.
It then sends this frame over the network, the frame reaches the router 20.1.12, which checks the checksum, makes sure that the data is not corrupted, and removes the FCS/CRC. It then "truncates" the MAC addresses, looks at the destination and sees that it is 30.1.1.10. It knows that this address is connected to its interface. The same framing process is repeated, the router adds the source and destination MAC address values, does the hashing, attaches the hash to the frame, and sends it over the network.
Our server, having finally received a SYN request addressed to it, checks the hash checksum, and if the packet does not contain errors, it deletes the hash. It then removes the MAC addresses, looks at the IP address and realizes that this packet is addressed to it.
After that, it truncates the IP addresses related to the third level of the OSI model and looks at the port numbers.
It sees port 21, which means FTP traffic, sees SYN, and therefore understands that someone is trying to communicate with it.
Now, based on what we've learned about the handshake, server 30.1.1.10 creates a SYN/ACK packet and sends it back to computer 10.1.1.10. Upon receiving this packet, device 10.1.1.10 will create an ACK, pass it through the network in the same way as a SYN packet, and upon receipt of the ACK by the server, the connection will be established.
One thing you should know is that it all happens in less than a second. This is a very, very fast process, which I tried to slow down so that you can understand everything.
I hope you find what you've learned from this tutorial useful. If you have any questions please write to me at [email protected] or leave questions under this video.
Starting from the next lesson, I will select 3 of the most interesting questions from YouTube, which I will consider at the end of each video. From now on, I will have a "Best Questions" section, so I will post a question along with your name and answer it live. I think it will be beneficial.
Thank you for staying with us. Do you like our articles? Want to see more interesting content? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of entry-level servers, which was invented by us for you: (available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps free until summer when paying for a period of six months, you can order .
Dell R730xd 2 times cheaper? Only here in the Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $99! Read about
Source: habr.com