Two details in TCP

Article source cxuan’s own public number: Two details of TCP

There are many hard-core articles on the official account, please pay attention to it~ Let's start this article.

TCP timeout and retransmission

does not always have an error communication , this sentence shows that no matter how complete the external conditions are, there will always be errors. Therefore, in the normal communication process of TCP, errors may also occur. This error may be caused by the loss of data packets, or it may be caused by repeated data packets, or even caused by the out-of-sequence of

In the process of TCP communication, the receiving end of TCP will return a series of confirmation messages to determine whether there is an error. Once packet loss occurs, TCP will start the retransmission operation to retransmit the unconfirmed data.

There are two ways to retransmit TCP, one is based on time, and the other is based on confirmation information. Generally, it is more efficient to pass confirmation information than pass time.

So it can be seen from this point that TCP confirmation and retransmission are based on the premise of whether the data packet is confirmed.

TCP will set a timer when sending data. If the confirmation message is not received within the time specified by the timer, it will trigger the corresponding timeout or timer-based retransmission operation. The timer timeout is usually called Retransmission Timeout (RTO) .

But there is another way that does not cause delay, which is fast retransmission .

After TCP retransmits a packet each time, its retransmission time will be doubled . This "doubling of the interval time" is called binary exponential backoff . When the interval time is doubled to 15.5 min, the client will display

Connection closed by foreign host.

TCP has two thresholds to determine how to retransmit a segment. These two thresholds are defined in RFC[RCF1122]. The first threshold is R1 , which indicates the number of retransmission attempts. The threshold R2 indicates that TCP should give up. Time to connect. R1 and R2 should be set to at least three retransmissions and 100 seconds to abandon the TCP connection.

It should be noted here that for the connection establishment message SYN, its R2 should be set to at least 3 minutes, but in different systems, the R1 and R2 values are set in different ways.

In Linux systems, the values of R1 and R2 can be set by the application, or by modifying the values of net.ipv4.tcp_retries1 and net.ipv4.tcp_retries2 The variable value is the number of retransmissions.

The default value of tcp_retries2 is 15. The time for this enrichment is about 13-30 minutes. This is only an approximate value. The final time will depend on the RTO, which is the retransmission timeout. The default value of tcp_retries1 is 3.

For the SYN segment, the two values net.ipv4.tcp_syn_retries and net.ipv4.tcp_synack_retries limit the number of SYN retransmissions. The default is 5, which is about 180 seconds.

There are also R1 and R2 variables under Windows operating system, and their values are defined in the registry below

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
HKLM\System\CurrentControlSet\Services\Tcpip6\Parameters

One of the very important variables is TcpMaxDataRetransmissions . This TcpMaxDataRetransmissions corresponds to the tcp_retries2 variable in Linux. The default value is 5. The meaning of this value is the number of times that TCP has not confirmed the data segment on the existing connection.

Fast retransmission

We mentioned fast retransmission above. In fact, the fast retransmission mechanism is triggered based on the feedback information of the receiving end, and it is not affected by the retransmission timer. Therefore, compared with timeout retransmission, fast retransmission can effectively repair the packet loss. When out-of-sequence packets (such as 2-4-3) arrive at the receiving end during the TCP connection, TCP needs immediately generate an acknowledgment message, which is also called Repeat ACK .

When an out-of-sequence message arrives, the repeated ACK must be returned immediately, and no delay in sending is allowed. The purpose of this action is to tell the sender that a segment of the message has arrived out of sequence, and hope that the sender will indicate the sequence number of the out-of-sequence message segment.

There is also a situation that will cause repeated ACKs to be sent to the sender, that is, subsequent messages of the current segment are sent to the receiving end, and it can be judged that the current sender's segment is missing or delayed in arrival. Because the consequence of these two situations is that the receiver did not receive the message, but we cannot judge whether the message segment is lost or the message segment is not delivered. Therefore, the TCP sender will wait for a certain number of repeated ACKs to be accepted to determine whether the data is lost and trigger a fast retransmission. Generally, the number of this judgment is 3. This text may not be clearly understood. Let's take an example.

As shown in the figure above, segment 1 is successfully received and confirmed as ACK 2, and the expected sequence number of the receiving end is 2. When segment 2 is lost, segment 3. Arrival out of sequence, but does not match the expectation of the receiving end, so the receiving end will send redundant ACK 2 repeatedly.

In this way, before the timeout retransmission timer expires, after receiving three consecutive identical ACKs, the sender will know which segment is lost, so the sender will retransmit the missing segment, so that there is no need Waiting for the expiration of the retransmission timer greatly improves efficiency.

SACK

In the standard TCP acknowledgment mechanism, if the sender sends data between 0-10000 sequence number, but the receiver only receives the data between 0 -1000, 3000-10000, and the data between 1000-3000 does not arrive On the receiving end, the sender will retransmit the data between 1000 and 10000 at this time. In fact, this is not necessary because the data after 3000 has already been received. But the sender cannot perceive the existence of this situation.

How to avoid or solve this kind of problem?

In order to optimize this situation, we need to let the client know more messages. In the TCP message segment, there is a SACK option field, this field is a selective acknowledgment (selective acknowledgment) mechanism, this The mechanism can tell the TCP client to explain it in our common saying: "I am allowed to receive the segment after 1000 at most, but I have received the segment between 3000-10000, please give me the segment between 1000-3000 Segment".

However, whether this selective acknowledgment mechanism is enabled is also affected by a field, this field is SACK allow option field, both parties in the SYN segment or SYN + ACK segment add the SACK allow option field to notify the peer host whether it supports SACK, if both parties support it, the SACK option can be used in the SYN segment later.

Note here: The SACK option field can only appear in the SYN section.

Pseudo timeout and retransmission

In some cases, even if there is no loss of message segment, it may cause message retransmission. This kind of retransmission is called spurious retransmission . This kind of retransmission is unnecessary. The cause of this situation may be due to , which means spurious timeout. An early determination timeout occurred. There are many factors that cause false timeouts, such as out-of-sequence arrival of message segments, duplication of message segments, and ACK loss.

There are many ways to detect and deal with spurious timeouts. These methods are collectively referred to as detection algorithm and response algorithm. The detection algorithm is used to determine whether there is a timeout phenomenon or a timer retransmission phenomenon. Once there is a timeout or retransmission, the response algorithm will be executed to cancel or reduce the impact of timeout. The following are several algorithms. This article will not go into these implementation details for the time being

• Repeat SACK extension-DSACK
• Eifel detection algorithm
• Forward RTO Recovery-F-RTO
• Eifel response algorithm

Out of order and duplicate packets

What we discussed above are how TCP handles packet loss. Let's discuss the problems of out-of-sequence and duplication of packets.

Packet out of order

The out-of-sequence arrival of data packets is an extremely prone situation in the Internet. Since the IP layer cannot guarantee the orderliness of the data packets, the transmission of each data packet may choose the link with the fastest transmission speed in the current situation, so It is very possible that three packets of A -> B -> C are sent, and the order of the packets arriving at the receiving end is C -> A -> B or B -> C -> A and so on. This is a phenomenon in which packets are out of order.

In packet transmission, there are mainly two links: forward link (SYN) and reverse link (ACK)

If the disorder occurs on the forward link, TCP cannot correctly determine whether the data packet is lost. The loss and disorder of the data will cause the receiving end to receive the disordered data packet, resulting in a gap between the data. If the vacancy is not large enough, this situation has little impact; but if the vacancy is relatively large, it may cause false retransmissions.

If the out-of-sequence occurs on the reverse link, it will cause the TCP window to move forward, and then receive repeated ACKs that should be discarded, resulting in unnecessary traffic bursts , which affects the available network bandwidth.

Going back to the fast retransmission we discussed above, since fast retransmission is started by inferring packet loss based on repeated ACKs, it does not have to wait until the retransmission timer expires. Since the TCP receiver will immediately return ACKs to the received out-of-sequence packets, any out-of-sequence packets in the network may cause duplicate ACKs. Assuming that once an ACK is received, the fast retransmission mechanism will be activated. When the number of ACKs increases sharply, a large number of unnecessary retransmissions will occur. Therefore, the fast retransmission should reach repetition threshold (dupthresh) before triggering. But in the Internet, serious disorder is not common, so the value of dupthresh can be set as small as possible. Generally speaking, 3 can handle most cases.

Packet duplication

Packet duplication is also a rare situation in the Internet. It refers to the situation that packets may be transmitted multiple times during network transmission. When retransmissions are generated, TCP may be confused.

The repetition of packets can cause the receiving end to generate a series of repeated ACKs. This situation can be solved by SACK negotiation.

I own six PDFs, which have been spread over 10w+ throughout the Internet. After searching for "programmer cxuan" on WeChat and following the

six PDF links