The characteristics of TCP protocol transmission are mainly byte-oriented, reliable transmission, and connection-oriented. In this blog, we will focus on how the TCP protocol ensures the reliability of transmission.
Ways to ensure transmission reliability
The main ways of TCP protocol to ensure the reliability of data transmission are:
- Checksum
- serial number
- Confirmation response
- Timeout retransmission
- Connection management
- flow control
- Congestion control
Checksum
Calculation method: In the process of data transmission, the sent data segment is regarded as a 16-bit integer. Add these integers. And the carry in the front can not be discarded, fill in the back, and finally reversed to get the checksum.
Sender: Calculate the checksum before sending the data and fill in the checksum.
Receiver: After receiving the data, calculate the data in the same way, find the checksum, and compare with the sender.
Note: If the receiver checksum is inconsistent with the sender, the data must be transmitted incorrectly. However, if the receiver checksum is consistent with the sender, the data may not be successfully transmitted. (The checksum guarantees the correctness of the data, the mechanism introduced below is to ensure that the data can be successfully received)
Confirm response and serial number
Serial number: Each byte of data is numbered during TCP transmission. This is the serial number.
Acknowledgement response: During the TCP transmission, each time the receiver receives the data, it will acknowledge the transmission side. That is to send ACK message. This ACK message carries the corresponding confirmation sequence number, which tells the sender what data has been received and where the next data will be sent.
The function of the serial number is not just the response. With the serial number, the received data can be sorted according to the serial number, and the data with the repeated serial number can be removed. This is also one of the guarantees of TCP transmission reliability.
Timeout retransmission
During TCP transmission, due to the confirmation response and sequence number mechanism, that is to say, after the sender sends part of the data, it will wait for the ACK message sent by the receiver, and parse the ACK message to determine whether the data is successfully transmitted. What if the sender does not wait for the ACK message from the receiver after sending the data? What could be the reason for not receiving the ACK message?
First, there may be two reasons why the sender did not receive the response ACK message:
- During the transmission process, due to network reasons and other direct packet loss, the receiver did not receive it at all.
- The receiver received the response data, but the sent ACK packet response was lost due to network reasons.
When TCP solved this problem, it introduced a new mechanism called timeout retransmission mechanism. The simple understanding is that the sender waits for a period of time after sending the data. When the time arrives and no ACK message is received, the data just sent is resent. If it is the first reason just now, after receiving the retransmitted data, the receiver responds with an ACK. If it is the second reason, the receiver finds that the received data already exists (the basis for judging the existence is the serial number, so the serial number also has the effect of removing duplicate data), then it is directly discarded and the ACK response is still sent.
So how long does the sender wait after sending? If this waiting time is too long, it will affect the overall efficiency of TCP transmission. If the waiting time is too short, it will cause frequent sending of repeated packets. How to weigh?
Since TCP transmission guarantees a high-performance communication in any environment, the maximum timeout period (that is, the waiting time) is calculated dynamically.
在Linux中（BSD Unix和Windows下也是这样）超时以500ms为一个单位进行控制，每次判定超时重发的超时时间
都是500ms的整数倍。重发一次后，仍未响应，那么等待2*500ms的时间后，再次重传。等待4*500ms的时间继续
重传。以一个指数的形式增长。累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。
Connection management
Connection management is the process of three-way handshake and four-way wave. This process has been described in detail before and will not be repeated here. To ensure a reliable connection is a prerequisite for ensuring reliability.
flow control
After receiving the data, the receiving end processes it. If the sending speed of the sending end is too fast, the end buffer of the receiving end is quickly filled. At this time, if the sending end is still sending data, then the data sent next will be lost, which will result in a series of chain reaction of packet loss, retransmission over time or something. According to the data processing capability of the receiving end, TCP determines the sending speed of the sending end. This mechanism is flow control.
Among the header information of the TCP protocol, there is a window (receiver feedback window) size of 16-bit field. When introducing this window size, we know that the content of the window size is actually the remaining size of the receive data buffer at the receiving end. The larger the number, the larger the remaining space in the receiving buffer at the receiving end, and the greater the network throughput. The receiving end will fill in the size of its immediate window when sending the ACK message in the confirmation response, and send it along with the ACK message. The sender changes its sending speed according to the change of the window size in the ACK message. If the value of the received window size is 0, then the sender will stop sending data. And periodically send window detection data segment to the receiving end, let the receiving end tell the sending end the window size.
Note: The 16-bit window size can represent a maximum of 65535 bytes (64K), but the maximum TCP window size is not 64K. The 40-byte option in the TCP header also includes a window expansion factor M. The actual window size is 16 for the value of the window field shifted by M bits to the left. Each time it moves one bit, it doubles.
Congestion control
In the process of TCP transmission, when the sender starts sending data, if a large amount of data is sent at the beginning, it may cause some problems. The network may be very congested at the beginning. If you throw a lot of data into the network, the congestion will increase. The intensification of congestion will generate a lot of packet loss, which will affect the transmission of a large number of overtime retransmissions.
Therefore, TCP introduces a slow start mechanism. When sending data, a small amount of data is sent to find the way. Find out what the current network status is and then decide how fast to transmit. At this time, a concept called congestion window was introduced. At the beginning of the transmission, the congestion window is defined as 1. Every time an ACK response is received, the congestion window is increased by 1 (one bit is doubled). Before sending data, first compare the congestion window with the size of the window fed back by the receiving end, and take the smaller value as the actual sending window.
The growth of the congestion window is exponential. The mechanism of slow start is just to show that at the beginning, it sends less and sends slower, but the growth rate is very fast. In order to control the growth of the congestion window, the congestion window cannot be simply doubled. A threshold for the congestion window is set. When the size of the congestion window exceeds the threshold, it cannot be increased exponentially, but linearly. At the beginning of slow start, the threshold of slow start is equal to the maximum value of the window. Once the network is congested and the timeout retransmission occurs, the threshold of slow start will be half of the original (the original here refers to the congestion window when network congestion occurs) Size), and the congestion window is reset to 1.
Congestion control is that TCP transmits data as quickly as possible during transmission, and avoids a series of problems caused by congestion. It is a guarantee of reliability, and it also maintains the efficiency of transmission.
Original address: https://blog.csdn.net/liuchenxia8/article/details/80428157
