Article content overview
It is recommended to read this article in conjunction with my previous article: the basic principles of reliable transmission
Reliable transmission of TCP protocol
- The reliable transmission of TCP is based on the continuous ARQ protocol (for the ARQ protocol, please see my previous article)
- There are two important concepts in the ARQ protocol: sliding window and cumulative confirmation . These two concepts are equally applicable in TCP's reliable transmission
- TCP sliding window in byte units
Suppose there is a segment of byte stream to be transmitted, and the size of the sliding window is 7. This is to facilitate understanding, so the window is set to be small, but the window in actual conditions is very large. The 7 bytes in the window indicate that all can be transmitted, the left side of the window is the confirmed byte sequence number , and the right side of the window is the byte sequence number that is not allowed to be sent . The 23 in the figure represents the next byte that the other party expects to receive, which is actually the concept of the confirmation number in the TCP header
If at a certain time the four bytes 23~26 have been sent out, but the confirmation message has not been received, this is the byte that has been sent but not confirmed . The remaining three bytes in the window belong to the available window , that is, the last three bytes can be sent. However, because the four bytes sent out have not yet received the confirmation, the window cannot be moved back yet. Assuming that after a period of time, a confirmation message of 23 and 24 bytes is received, the window can be moved back by two bytes at this time
Assuming that the 7 bytes in the window have been sent out, but a confirmation message has not been received , the available window is 0, because all the bytes sent in the window have not received confirmation. At this time, the sliding window Can't push back. This is actually possible
Assuming that all 7 bytes in the window have been sent out, at a certain moment, two bytes of confirmation information 25 and 27 are received. It can be found that in this case, the confirmation message is not received in the order of bytes in the window. What should I do in this case?
The first thing you can know is that the two bytes of confirmation message 23 and 24 have not been received. Therefore, the window cannot be pushed forward. Suppose now that the timeout period has expired, and 23 and 24 have not received the confirmation message, what will happen ? In this case, even if the confirmation information of the two bytes of 25 and 27 has been received, the message will still be retransmitted from 23 , because the confirmation information of 23 and 24 has not been received. Therefore, after the timeout, the message will be resent from 23. Even if the confirmation message of the next byte is received, it is useless. This is a reliable transmission of the TCP protocol.
It can be seen from the above that if the bytes in the window do not receive the confirmation message in order, the bytes in the window will be resent after the timeout . It can also be seen that the reliable transmission of TCP is not very efficient, because the two bytes of confirmation information of 25 and 27 have been received, which means that these two bytes have reached the receiver accurately. Yes, but because the two bytes in front of 23 and 24 did not receive the confirmation information, after the timeout, the 25 and 27 still need to be transmitted, which causes the retransmission efficiency is not high. Is there a way to improve this efficiency?
Select retransmission
Select retransmission, as the name implies, you can select part of the message to be retransmitted instead of retransmitting all the messages in the window
How does selective retransmission work?
- To select retransmission, you need to specify the bytes to be retransmitted
- Each byte has a unique 32-bit serial number (this is in the TCP header, choosing to retransmit will specify what this 32-bit serial number is)
(It is recommended to look back at the content of the TCP header before looking at the content below, so that it will be easier to understand the content below)
For the TCP header, we actually know that it does not store the location where the specified byte is selected to be retransmitted . Each byte has a unique sequence number, so it takes a lot of space to store the sequence number of the byte to be retransmitted. Therefore, in the actual selective retransmission, this data is actually stored in the TCP option
In the TCP protocol detailed article, a simple calculation has been carried out, and I know that the TCP option has a maximum of 40 bytes . Because a sequence number occupies 4 bytes, that is to say, a maximum of 10 sequence numbers can be placed in the TCP option. Does that mean that you can only retransmit 10 bytes if you choose to retransmit?
In fact, it is not. When you understand TCP, you know that TCP packets can transmit many bytes at a time. The previous example is mainly to facilitate the understanding of TCP reliable transmission, and only the bytes that can be transmitted each time The number is very small. For actual TCP transmission, it can transmit hundreds or thousands of bytes at a time
Therefore, the sequence number here does not mean that a certain byte is selected. Because, if an error occurs, it is very likely that the entire TCP message is lost. In this case, a segment of bytes is actually lost continuously. Therefore, the retransmission is selected here, and more cases are to retransmit a segment of bytes . Passed. So the meaning of the serial number at this time is generally the boundary that needs to be retransmitted
Take an example, suppose you want to transmit 1000 3500 bytes of data, and consider 500 bytes as a TCP packet. Assuming that the TCP packet with bytes in the range of 1000 to 1500 is lost, two boundaries can be specified at this time, namely 1000 and 1500, and they are stored in the TCP option in the TCP header , which means 1000~1500 bytes. All need to be retransmitted. Therefore, at this time, the 1000 and 1500 in the TCP option do not refer to the retransmission of the bytes of the two sequence numbers of 1000 and 1500, but the retransmission of all the bytes in the range of 1000 to 1500
If the reading is helpful to you, please give me three consecutive encouragements!