How is TCP reliable transmission realized?

Hello, everyone, I am Hong Jue Duck ~ today to talk about TCP is how to ensure reliable transmission. This is a common interview question that not only shows whether you really understand TCP, but also whether you have the ability to summarize it.

Let’s look at how TCP achieves reliable transmission in three parts.

The first is aboutSliding Windows in TCPIt is closely related to the reliable transmission of TCP. TCP’s sliding window is based onIn bytes, suppose that the sender has received the confirmation message segment sent by the receiver, where the window value is 14 bytes and the confirmation number is 36 (Indicates that the receiver expects to receive the next data numbered 36,35 has been received). The sender can maintain its own sending window based on the receiver’s acknowledgment segment (noteFront and back position!!) :

[imG-GFD3BUhh-1625894874335].png [imG-GFD3BUhh-1625894874335].png [imG-GFD3BUhh-1625894874335]

The sending end can continuously send out all data in the window. If no confirmation is received after sending out data, all data must be retained temporarily for use in timeout retransmission (which will be discussed later). If the receiver receives serial numbers 39-49 but does not receive 36, the sliding window will not move forward, but wait until the next byte is confirmed to have been received, then the sliding window will start to move.

The larger the sending window, the sender can continuously send more data before the receiver confirms it, thus potentially achieving higher transmission efficiency. The following part of the back edge of the send window indicates that it has been sent and received with acknowledgement, so the data is obviously not needed; The portion of the front edge of the send window indicates that the send is not allowed because the receiver does not reserve cache space for this part of the data.

The size of the sliding window is determined by the front edge and the back edge. The back edge of the sending window changes in two ways: forward and stationary.

It is impossible to move the back edge of the send window because you cannot undo confirmed data. Moving forward means that the data near the back edge is received, so the slide window moves forward, while not moving means that no new confirmation of the data near the back edge is received.

The front edge of the send window has three conditions: move forward, hold still, and move back. Moving forward is easy to understand. It may be that the window information accompanying the confirmation message tells the sender that the window has become larger or that it will move forward after receiving the ACK at the back edge. There are two situations in which the window information sent by the receiver does not change. One is that no new confirmation is received. The second type is to receive a new confirmation, but the notification window of the other party shrinks, so the sliding window front will remain the same. It is also possible for the front edge of the sliding window to shrink back when no new byte acknowledgment segment is received (sender and receiver are still interacting, but there is no ACK, no update, and the previous value) and the window shrinks. TCP strongly discourages this because of the problems it can cause.

TCP stipulates that the receiver must have the ability to accumulate acknowledgements to reduce transmission overhead. Recipients can send acknowledgements when it suits them, or when they have data to send. However, the receiver should not excessively delay sending confirmation, otherwise it will cause unnecessary retransmission and waste network resources. TCP states that confirmation delays should not exceed 0.5 seconds. If the receiver receives a series of segments with the maximum length, an acknowledgement is sent every other segment.

Because TCP communication isFull duplexOf, so in correspondenceEach side has send and receive Windows.

The second point is about the timeout retransmission time. As we mentioned earlier, if a TCP sender does not receive an acknowledgement within a specified period of time, it has to retransmit the sent segment. The concept of retransmission is simple enough to say, but retransmission timing is one of the most complex issues in TCP.

The next layer of TCP is the IP layer, which sends IP datagramsIt may go over a high rate network, or it may go over a low rate network.The route chosen for each datagram may be different, if the timeoutThe retransmission time is too short. Procedure, can causeUnnecessary retransmission, increase network load; If theThe timeout period is too long. Procedure.The transmission efficiency is reduced, the network idle time increases.

TCP uses an adaptive algorithm. It records the Time when a packet segment is sent and the Time when it is acknowledged. The difference between the two times is the round-trip Time (RTT) of the packet segment, and TCP keeps the weighted average round-trip Time of RTT[S]. For the first measurement, RTT[s] = RTT, and for each subsequent measurement of a new RTT sample, RTT[s] is recalculated according to the following formula.

New RTT[s] = (1 - α) x (old RTT[s]) + α x (new RTT)Copy the code

The above expression α is of [0, 1]. If α is close to 0, then the new RTT sample has little effect on RTT[s], and if α is close to 1, then the new RTT sample has a great effect on RTT[s]. The recommendation standard recommends setting α to 1/8, i.e. 0.125.

Therefore, the timeout timer sets the timeout RetransmissionTime RTO (retransmissiontime-out) slightly greater than the weighted average round-trip time RTT[s].

RTO=RTT[s] + 4 x RTT[d]
Copy the code

RTT[d] is the weighted average of the deviation of RTT, you can make an understanding:

New RTT [d] = (1 - beta) x (old RTT [d]) + beta x | RTT [s] - | new RTT sampleCopy the code

Beta is recommended as 1/4, i.e. 0.25.

Now consider the following problem: Suppose that the sender sends a packet segment, the retransmission time expires, and no acknowledgement message is received. Therefore, the sender retransmits the packet segment, and after a period of time, the acknowledgement message segment is received. Is this an acknowledgement of the first or the second segment sent? And this judgment will affect the current RTT, resulting in the influence of RTT[S] is larger or smaller.

According to this situation, Karn proposed that if the message segment is retransmitted, then we do not record its round-trip time sample, so that the RTT[s] and RTO obtained will be more accurate.

However, this also causes a new problem. If the delay of the packet segment increases greatly and no acknowledgement packet is received within the set retransmission time, the packet segment is retransmitted. However, the retransmission time will not be updated because the retransmitted data is not sampled.

Therefore, Karn’s algorithm is modified to increase the RTO a bit for each timeout retransmission, which is generally two times of the old time. When retransmission of message segments does not occur again, the previous formula is used to calculate the result, which makes the calculation more reasonable.

The third point isSelect confirm SACKA lot of people may not know this. Let me give you A scenario where host A and host B are interacting. At this moment, Host A acts as the sender and host B acts as the receiver.

The receiving end has received the byte stream sent by host A, but it has received discontinuous serial numbers. The first byte block is called continuous byte block 1-500, and there are serial numbers 501-100 between the first byte block and the continuous byte block that have not been received. The sequence number 1501-2000 between the first byte block and the second byte block is not received.

Due to the TCP mechanism, the ACK bit in the acknowledgement packet segment is 1, and the ACK field is 501, which is the next data number 501 that the receiver expects to receive from the sender. Although it receives 1001-1500 bytes of data, TCP only tells the sender the sequence number of the nearest unreceived bytes at the back of the window.

At this time, if the sender finds that the receiver ACK = 501, it knows that the data before 501 has been received successfully, and the data after 500 has not been received, it will resend the data, so the content of the first byte block may be repeated to send. So how to solve this problem?

Read Hong Jue “interview must ask TCP, you really answer right?” As we all know, there is an option field in the TCP header, this field is up to 40 bytes, do not understand, you can go to see hong Jue’s “interview must ask TCP, do you really answer right?” , there is a very detailed introduction. The communication parties need to agree in advance to allow the SACK option, so that in the option we can pass information about receiving discontinuous blocks of bytes. Because a serial number need four bytes, if you receive a byte block need to use the range of 8 bytes, because of the need to tell to the border around the sender, normally can be 5 bytes of information transmission, because 5 x 8 = 40 bytes, but due to the need to use 1 byte to indicate the SACK option, One byte means that this option takes up several bytes, so only four byte blocks of information can be transferred.

This can be understood because most implementations still retransmit all unacknowledged blocks of data.

Well, this issue of TCP how to achieve reliable transmission here, looking forward to our next article oh!

May everyone read this article with skepticism and explore how it works.

Road obstruction and long, the past for preface, the future for chapter.

Looking forward to our next meeting!