Analysis of TCP principle (window control, three handshake and four waves)

  • Brief description of 1-TCP:

The TCP protocol is a connection-oriented, reliable, byte stream-based transport layer communication protocol.

Connection-oriented: TCP can only connect one-to-one, not one-to-many, one-to-one, and many-to-many connections like UDP;

Reliability: The reliability of TCP can be said to be due to his three handshake and four wave of hands

Byte stream: Data is generally of unidentifiable size, and generally can be transmitted in an orderly manner.

  • 2-TCP connection and disconnection:

Before we talk about the three-way handshake, we must first know how to determine a TCP connection. To determine a TCP connection, we must know the source address, source port, destination address, and destination port in order to guarantee a TCP connection.

2.1 First, let's talk about the three-way handshake , as shown in the figure below

1- First, both the client and the server are in the closed state, and the server actively monitors a port and is in the listening state

2- The client starts to send the first SYN message to the server: the client randomly generates a sequence number and places it in the sequence number field of the TCP header, and at the same time sets SYN to 1

3- The server sends a SYN+ACK message: When the server receives the SYN message from the client, the server will also randomly generate a serial number and place it in the serial number, and at the same time, the serial number in the message sent by the client +1 Write the confirmation response number field, the SYN and ACK of the TCP header are set to 1, and the status of the server becomes waiting to be received

4-The client sends an ACK message: After the client receives the SYN+ACK message from the server, it fills the acknowledgment number field of the TCP header with the serial number of the server + 1, and sends the ACK to 1 to the server , The two establish a connection, and the status of both parties becomes established

注意:序列号ISN(Initial Sequence Number)是随机产生的

The structure of the TCP header is shown below:

2.2 What is a semi-connected queue, as shown in the figure

Semi-connection queue : After the server receives the SYN from the client for the first time, it will be in the SYN_RCVD state. At this time, the two parties have not fully established their connection. The server will put the request connection in this state in a queue

Fully connected queue : The three-way handshake has been completed, and the connection will be placed in the fully connected queue

2.3 Why does the handshake need three times

 1- Avoid historical connections:

When the client sends multiple SYN messages, it is not necessarily in order. Sometimes network congestion causes the old message to arrive at the server earlier than the new message. The client can follow the SYN+ACK returned by the server. The message is judged based on its own context whether it is a historical connection, and thus the connection is terminated.

2-Synchronize the serial numbers of both the client and the server:

TCP improves reliability through sequence numbers and confirmation responses. Its role: the receiving parties can take out duplicate data, and can also confirm that the other party in the sent data packets has received

2.4 Does not receive the confirmation response data must be lost?

There are two possibilities for not receiving the confirmation response. The first is that the data packet is lost on the way to the server. In this case, the client does not receive the server confirmation response within a certain time interval, and the data will be retransmitted. ; The second is that the server receives the data, but it is lost on the way back to the response. In this case, the client will send the message again, but the server has already received the data, and it will give up when the same data is delivered.

2.5 SYN attack

1- About SYN:

The server-side resource allocation is allocated during the second handshake, and the client's resources are allocated during the three-way handshake, so the server is vulnerable to SYN flooding attacks. The SYN attack is that the client forges a large number of non-existent IP addresses in a short period of time, and continuously sends SYN packets to the server, and the server replies with confirmation packets and waits for the client to confirm. Because the source address does not exist, the server needs to retransmit until the timeout expires. , These forged SYN packets will occupy the unconnected queue for a long time, causing normal SYN requests to be discarded because the queue is full, causing network congestion and even system paralysis. SYN attack is a typical DoS/DDoS attack. as the picture shows

2- Solution:

  1. Control the queue size by modifying the linux kernel parameters

  2. SYN cookies technology

2.6 Wave four times:

   1- The client sends a FIN message: When the client needs to close, it sends a FIN message, the FIN position in the TCP header is marked 1, and the client enters the FIN_WAIT_1 state

   2- The server sends an ACK response message: when the server receives the FIN message from the client, the server sends an ACK response message to the client, and the server enters the CLOSED_WAIT state

   3- The client enters the FIN_WAIT_2 state after receiving the ACK message from the server. When the server finishes processing the data, it also sends a FIN message to the client, and the server enters the LAST_ACK state

   4- After the client receives the FIN message from the server, it also returns an ACK message to the client, and the client enters the TIME_WAIT state

   5- After the server receives the message from the client, it enters the CLOSED state. At this point, the server completes the connection closure

   6-After the client has experienced 2MSL, it also enters the CLOSED state, and the client has also completed the connection closure here

2.7 Why do we need to wait for 2MSL (MSL:  Maximum Segment Lifetime message maximum survival time )

Reasons for 2MSL:

There may be data packets from the sender in the network, and when these sender's data packets are processed by the receiver, they will send a response to the other party, so it takes twice as long to wait for each time.

Waiting for 2MSL reasons:

1-Ensure that the last ACK segment sent by the client can reach the server:

This ACK segment may be lost, so that the server in the LAST-ACK state cannot receive confirmation of the sent FIN+ACK segment. The server retransmits the FIN+ACK segment over time, and the client can The retransmitted FIN+ACK segment is received within 2MSL time, and then the client retransmits an acknowledgment, restarts the 2MSL timer, and finally both the client and server enter the CLOSED state. If the client is in TIME-WAIT The state does not wait for a period of time, but releases the connection immediately after sending the ACK segment. The server cannot receive the FIN+ACK segment retransmitted by the server, so the confirmation segment will not be sent again, and the server cannot Normally enter the CLOSED state.

2- Prevent "failed connection request segment" from appearing in this connection:

After the client finishes sending the last ACK segment, after 2MSL, all the segments generated during the duration of this connection can disappear from the network, so that this will not appear in the next new connection. Old connection request segment

  • 3- Retransmission timeout

      3.1 TCP is sent in units of segments (slices)

            When TCP transmits a large amount of data, the data is divided and transmitted by the size of MSS (the unit of MSS is also used for retransmission), and the maximum message length during transmission is equal to MTU, so that the IP layer will not be divided .

MTU(Maximum  Transmission  Unit):一个网络包最大的数据长度
MSS(Maximum  Segment Size):除去IP头部,TCP头部,一个网络所容纳最大的TCP数据长度。MSS是在三次握手的时候写入TCP头部
MSS选项中

     3.2 There is fragmentation at the IP layer, why does TCP still need MSS?

     If the entire TCP message (header + data) is handed over to the IP layer for fragmentation, what will happen?

When the IP layer has a piece of data (TCP header + TCP data) that exceeds the MTU size to be sent, then the IP layer must fragment and divide the data into several fragments to ensure that each fragment is smaller than the MTU. After fragmenting an IP datagram, it is reassembled by the IP layer of the target host and then handed over to the upper TCP transport layer. This looks orderly, but there are hidden dangers. If an IP fragment is lost, all fragments of the entire IP message must be retransmitted. Because the IP layer itself does not have a timeout retransmission mechanism, it is the TCP of the transport layer that is responsible for timeout and retransmission. When the receiver finds that a piece of the TCP packet (header + data) is missing, it will not respond to the ACK to the other party. Then the sender’s TCP will retransmit the entire TCP packet (header + data) after the timeout. )”. Therefore, it can be known that fragmented transmission by the IP layer is very inefficient. Therefore, in order to achieve the best transmission performance, the TCP protocol usually negotiates the MSS value of both parties when establishing a connection. When the TCP layer finds that the data exceeds the MSS, it will first fragment, and of course the length of the IP packet formed by it It will not be larger than the MTU, so IP fragmentation is naturally unnecessary.

   3.3 Retransmission timeout

    The segments of TCP data packets arrive through different lines, so different round trips in the network environment may cause a large swing. In Unix and Widows systems, timeouts are controlled in units of 0.5 seconds, so retransmission timeouts are generally multiples of 0.5 seconds. Initially, the round-trip time is not known for the data packet, so the retransmission timeout is generally set to about 6 seconds. If the data is retransmitted and the confirmation response is still not received, it will be sent again, and the time waiting for the confirmation response will be extended by an exponential function of 2 times and 4 times.

  • 4- Window control

    1- Why do you need window control

    As mentioned above, TCP does not send a segment and requires an acknowledgement response processing. This processing has a disadvantage: the longer the packet round trip time (RTT), the worse the capacity. To solve this problem, TCP uses a window, and each transmission is no longer in each segment, but in larger units (assuming 4 segments each time, it can be understood as a batch operation)

   2-Window control and retransmission mechanism

    There will be data loss when each segment is sent before, so what if there is data loss in the window control?

    The first case: the client sends data to the server, and the server receives the data but the server returns an ACK to the client and it is lost. In this case, there is no need to retransmit

    The second case: the client sends data to the server, and the data (some packet data is lost) is lost during the sending. The client will receive the confirmation response from the server multiple times. If the same is received three times in a row Acknowledge the response and retransmit the corresponding data. This mechanism is called high-speed retransmission control.

  3- Flow control

      3.1- Possible problems

      The server receives a data packet from the client. This data packet may take some time to deal with other problems. Sometimes it will take a certain amount of time to process this data packet, and even other data packets cannot be accepted under high load. If the data packet is lost, it will return to the retransmission mechanism, resulting in a waste of network traffic.

      3.2- Solve this problem

       In the TCP header, there is a field used to inform the window size (the larger the field, the greater the throughput of the network). The server puts the buffer size it can receive into this field to notify the client. Also note that the client will also send a data segment for window detection from time to time. This data segment is only one byte to obtain the latest window. Size information. When the buffer of the server faces data overflow, the value of the window size will also be set to a smaller value to notify the client, thereby controlling the amount of data sent. The client controls the amount of data sent according to the instructions of the server. This is flow control.

   4- Congestion control

       4.1 Problems

             When the network is congested, if a large data packet is suddenly sent, it is very likely to cause network paralysis

       4.2 Solve the problem

              In order to prevent the above problems, TCP will obtain data through a slow-start algorithm at the beginning of communication and control the amount of data sent.

              Define a congestion window to adjust the amount of data to be sent by the client, set the congestion window to 1 data segment (1MSS) during slow start to send data, and then send data to the size of the congestion window and the window notified by the server The size is compared, and their smaller value is used as the amount of data sent.

             The size of the congestion window will increase with an exponential function of 1, 2, or 4 with each round-trip of a data packet. In order to prevent a surge in congestion or even network congestion, a slow start threshold is introduced. As long as the value of the congestion window is greater than this threshold, each time a confirmation response is received, only the following formula is allowed to enlarge the congestion window:

            TCP window changes:

  • 5- Learning link:

         Know the principle of TCP congestion control

   Author's message:

   If you have time, you can buy a graphic TCP/ip for yourself. The book is still very good. Many times you will read it for yourself first, and then you will find that it’s not difficult to understand when you wait until later. Come on

 

 

Guess you like

Origin blog.csdn.net/lin_keys/article/details/105444779