Article content overview
TCP protocol flow control
Flow control is a unique function of TCP protocol, for UDP or some other protocols, there is no flow control
Flow control , in simple terms, is that the receiver wants the sender to send data more slowly. Generally speaking, we hope that the sooner the better, but we still need to consider some practical situations. For example, the receiver cannot receive a large amount of traffic so quickly, so it is hoped that the sender's traffic will be slower. This is flow control
- Flow control means that the sender should not send too fast
- Flow control is implemented using sliding windows
There is a window field in the TCP header , which occupies 16 bits, used to indicate the amount of data that the other party is allowed to send . In this article, the basic principle of reliable transmission, an operation is performed in conjunction with the confirmation number and the window. For example, if the confirmation number is 501 and the window size is 1000, it means that the sender can send 1000 bytes of data in the range of 501 to 1500. This is the function of the window. How does the sliding window achieve flow control?
Suppose there is a sender computer and a receiver computer, from top to bottom is the timeline of interaction between them
- Suppose the sender sends a data with a serial number of 1, and the size of the sent data is 100 bytes
- The sender can also send a second time, the serial number of the data sent at this time should be 101, and it is also assumed that the size of the sent data is 100 bytes
- At this time, the receiver has received 200 bytes of data. Assuming that the receiver has sent a confirmation message at this time, the confirmation number is 201. 201 represents the sequence number of the next byte expected to be received and the confirmation message sent There is also a window size, assuming it is 300, which means that the sender is informed that it can send 300 bytes of data. The ACK in the confirmation message is marked as 1
- After the sender knows that the window size is 300, it can continue to send 300 bytes of data. First, it may send 100 bytes of data with a serial number of 201. At this time, the sender can send another 200 bytes of data.
- Assuming that the sender has sent 200 bytes of data with a serial number of 301 at this time, the receiver can confirm that it has received all the data before the serial number 601, and the window size is 0, which means that the sender can no longer send data
The above is to control the sending rate of the other party through the window size
If the receiver sends a message with a window of 0, it immediately processes the received data, and then passes it to the application layer. After a period of time, the receiver can receive the information message again. At this point, the receiver will send a message to the sender, telling it that my current window is 1000, which means I can receive 1000 bytes of data. After the sender receives this message, the sender will encapsulate the data and send the data to the receiver. This is where the receiver informs the sender that it can continue to send data by adjusting the size of the window
Consider a special case
Suppose the receiver is notifying the sender that its message with a window of 1000 is lost during transmission. What are the consequences of this situation?
For the sender : the sender will always wait, because it still thinks that the receiver’s window is 0, so it has been waiting for the receiver’s window to increase
For the receiver : the receiver has notified the sender of the message that the window has been enlarged. In theory, the sender will send the information message to the receiver after receiving the message. Therefore, the receiver will always wait
Therefore, due to the loss of the window data message, the sender and receiver will always be waiting, resulting in a deadlock situation. At this point, there may be a question, is TCP not reliable transmission? Why is this message lost?
In fact, when discussing the reliable transmission of TCP, it is mainly considered from the perspective of data. In other words, the reliable transmission of TCP is the confirmation of data. For example, the serial number and the confirmation number are used to confirm the bytes of the data. For special messages, such as the size of the window, there is actually no timeout retransmission mechanism . Therefore, the deadlock situation mentioned above will occur
Stick to timer
To deal with the deadlock situation above, you need the second timer in TCP, keep the timer
- When the sender receives a message with a window of 0, it starts the persistence timer
- Persist in the timer to send a window detection message every once in a while (used to ask whether the window has increased, so that the deadlock situation caused by the loss of the message of the sending window size can be solved)