I recently built a personal blog, and the link is here: Tobe's ravings , the article will be updated on the blog and the official account first~ Everyone, please collect it.
The last time I talked about the UDP protocol, from this time on, I will talk about the TCP protocol. Because the TCP protocol involves a lot of things, an article can't be summed up, so I divided the content of the TCP protocol into several parts and broke them one by one.
TCP segment structure
When it comes to the TCP protocol, the first words that come to mind are " connection-oriented " and " reliable ". Yes, the TCP protocol is designed to be able to establish a reliable connection between the client and the server.
Before talking about the connection process, let's take a look at the TCP segment structure. Through this structure, we can know what information TCP can provide:
Here are a few things to note:
- The TCP protocol requires a four-tuple (source IP, source port, destination IP, destination port) to determine the connection, which is different from the UDP protocol. To put it another way, the IP address is located in the IP segment, and the TCP segment does not contain IP address information.
- The length of the basic TCP header is 20 bytes, but since the length of the " options " is indeterminate, the "header length" field needs to explicitly give the header length. It should be noted here that the unit of the header length field is 32 bits, that is, 4 bytes, so the minimum value of this field is 5.
- The fields marked in orange ( confirmation sequence number, receiving window size, ECE, ACK ) are used to "reply" the other party. For example, after the server receives the data packet from the other party, it does not send a separate data packet to respond, but waits for a while. , attach the confirmation information to the next data frame sent to the client , that is, piggybacking .
- The window size is a 16-bit unsigned number, which means that the window is limited to 65535 bytes, which limits the throughput performance of TCP, which is not very friendly to some high-speed and high-latency networks (think about why) . Fortunately, TCP provides additional window scaling (Window Scale) options, allowing this value to be scaled.
The following are the meanings of the 8 flags. Some protocols are older and may not have the first two flags:
Although there are many flags, if you look at them in a specific scene, it is easy to understand their role.
TCP three-way handshake
The three-way handshake is to establish a connection between the client and the server. This process is not complicated, but there are many details to pay attention to.
This picture is the process of handshake. You can see that there are three messages passed between the client and the server. These three handshakes are actually the mutual confirmation status between the two machines. Let's take a look at it bit by bit.
first handshake
The first is that the client initiates the connection , and the first packet sets the SYN bit (that is, SYN = 1), indicating that this packet is a SYN segment (also known as segment 1 ). The purpose of sending this time is to tell the server that its initial serial number is client_isn, and there is another implicit information that is not shown in the figure, that is, to inform the server of the port number it wants to connect to . In addition to these, the client will also send some options , but this has little to do with the three-way handshake, so let's not list it for now.
The most important thing to notice in Section 1 is this client_isn, the initial serial number. "RFC0793 ^1 " states:
When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours.
The translation is that the initial sequence number is a 32-bit (virtual) counter, and this counter is incremented every 4 microseconds, that is, the value of the ISN is cycled every 4.55 hours . This move is to prevent overlapping serial numbers .
But even this still has security implications - since the initial ISN is still predictable, a malicious program may analyze the ISN, then predict the ISN of subsequent TCP connections based on the ISN used previously, and then attack, a well-known example is "The Mitnick attack ^2 ". Here is an excerpt from the original:
Mitnick sent SYN request to X-Terminal and received SYN/ACK response. Then he sent RESET response to keep the X-Terminal from being filled up. He repeated this for twenty times. He found there is a pattern between two successive TCP sequence numbers. It turned out that the numbers were not random at all. The latter number was greater than the previous one by 128000.
So in order to make the initial sequence number more difficult to predict , modern systems often use a semi-random method to select the initial sequence number, and the detailed method is not expanded here.
second handshake
When the server receives the connection request from the client, it will send ACK to the client to indicate that it has received the connection request, and the server has to tell the client its initial sequence number . This is actually two steps, but sending a data The package can be completed, using the piggybacking technique mentioned earlier. In the ACK = client_isn + 1figure refers to the value of the acknowledgment number field , which should be distinguished from the ACK flag bit .
The ACK field actually has a lot of points to pay attention to, but this is more intuitive with the sliding window, so I won't mention it here.
It is emphasized here that when a SYN segment arrives, the server will check whether the number of connections in the SYN_RCVD state exceeds tcp_max_syn_backlogthis parameter. If it exceeds, the server will refuse the connection . Of course, this can also be exploited by hackers, "SYN Flood" is a good example. Because the server will wait for the client's ACK after replying to the SYN-ACK. If it does not receive the ACK within a certain period of time, it is considered that the packet is lost, and it will resend the SYN-ACK. After repeating several times, the connection will be disconnected. Linux may need to It will only be disconnected in one minute, so if an attacker makes a large number of SYN requests and does not reply, the server's SYN queue will be exhausted quickly, and during this period, normal connections will not receive a response.
This state of the server is called muted . In order to resist SYN flood attacks, the server can use "SYN cookies". The idea is that when SYN arrives, it does not allocate memory directly for it , but encodes and saves the connection information in the SYN-ACK segment. If the client replies, the server calculates the important information of the SYN message from the ACK field ( a bit of black magic), and allocates memory for the connection after the verification is successful. In this way, the server will not respond to the attacker's request, and normal connections will not be affected.
However, SYN cookies themselves have some limitations and are not suitable as default options. If you are interested, you can Google them yourself.
third handshake
This is the last step in establishing a TCP connection. After the first two handshakes, the client (server) already knows the size of the sliding window of the other party , the initial sequence number and other information. Isn't this the end? Why the third handshake?
This is because although the server has sent the data packet, it still does not know whether the client has received the packet , so the server needs to wait for the client to return an ACK, indicating that the client has received the data. At this point, the connection is completed.
After the connection is established, it enters the stage of data transmission. There are many technologies involved here. I will write another article.
waved four times
With the basis of the three-way handshake, the four-way wave is easier to understand:
The process of waving hands four times is actually very simple, that is, the server and the client send FIN and ACK segments to each other, informing the other party to disconnect.
The point worth paying attention to with the four waves is the TIME_WAIT state, which means that the party that actively closes the connection, even if it receives the FIN message from the other party, will have to wait for 2 MSL before completely closing the connection. (The MSL here refers to the maximum segment generation period , which refers to the longest time a segment is allowed to exist on the network .) Why not just close the connection ?
One reason is that the ACK segment of the fourth wave does not necessarily reach the server . In order not to keep the server in the LAST_ACK state (the server will resend the FIN until it receives the ACK ), the client has to wait for a while to see if Need to resend. If the packet is really lost, the server sends a FIN, and the FIN message will not exceed 2MSL when it reaches the client (up to 2MSL once and for all). At this time, the TCP on the client side has not been turned off, and the ACK can be resent. .
Another reason is that after 2MSL, the packets related to the connection in the network have disappeared and will not interfere with the new connection. Let's look at an example: if the client establishes a new connection to the server , some delayed data in the old connection persists until the new connection is established, and the serial number is still within the sliding window, the server mistakenly regards it as a new connection The data packets received , as shown in the following figure:
The 2MSL mechanism avoids this situation.
There are still many interesting things about TIME_WAIT. I think I can write another article separately, so I won't say more here.
It feels a bit messy to write, because the knowledge of TCP is indeed a bit much, I hope readers don't mind.
If this article is helpful to you, welcome to pay attention to the ravings of my public account tobe , and take you deep into the world of computers~ There are surprises in the background of the public account to reply to the keyword [computer]~
