How does TCP perform flow control?

We all know that TCP is a reliable, connection-oriented transport layer protocol. We always hope that TCP can transmit data as quickly as possible. If there is such a situation that the sender sends data very quickly and the receiver has exhausted its resources and has no time to receive it, then the excess data will be discarded, which violates the principle of TCP reliability.

[[269367]]

Therefore, it is necessary to introduce a method of flow control: to prevent the sender from sending too fast, so that the receiver can receive the data smoothly without causing congestion of the network link.

Ideas

Following this idea: let the sender not send too fast. Then let the receiver control the sender's data size, and notify the sender how much space is left to receive data each time it responds. Of course, the actual interaction is not that simple, it just provides a way of thinking. Using this idea, the sliding window method was born.

Sliding Window

The sliding window is like a window that tells the sender the size of the data that can be sent. It can also be said that the window marks the size of the receiver's buffer. The window size also indicates how much data can be sent at a time, and this window can slide, hence the name sliding window.

How to tell the sender the window size?

How to inform the sender of the window size? Do we need to resend a packet of data to tell the other party? This is obviously unreasonable. We can use the confirmation response packet cleverly. Having a confirmation response packet is not enough. What if it is the first interaction? Therefore, we need to inform the other party during the three-way handshake. (rwnd means receiving window)

In the original confirmation response strategy, each time data is sent, an Ack response is required. The next data segment will be sent only after receiving the Ack. What if the sender does not receive the Ack response? This method is too inefficient. With the use of a sliding window, data can be sent multiple times as long as it does not exceed the other party's window size. This greatly improves efficiency.

Sliding Window Details

1. The receiver indicates the size of the buffer it can receive in the "window size" field in the TCP header and notifies the sender through Ack.
2. The window size is the maximum value that the sender can send, which means that no Ack response is required and data can be sent multiple times, provided that the total amount of data sent does not exceed the window size.
3. A large window size indicates a high network throughput.
4. The operating system kernel maintains a receive buffer, and only data after the Ack response can be deleted from the buffer.
5. Once the receiver finds that its buffer is almost full, it will notify the other party that its window is a smaller value.
6. If the receiver finds that its buffer is full, it will set the window size to 0. At this time, the sender will no longer send data, but it needs to send a window probe data segment regularly so that the receiver can tell the sender the window size. (For this point, let's focus on why it is necessary to send window probes regularly. You can imagine that if the receiver's buffer is full, then it informs the sender through Ack that the window size is 0. The sender will no longer send data to the receiver, and the receiver will not be able to tell the other party that its buffer can receive data, which will cause a "stuck" situation.)

Examples

A sends data to B. When the connection is established, B tells A: "My receiving window rwnd = 400 (bytes). Note: The capital ACK above the arrow in the figure represents the confirmation bit ACK in the header, and the lowercase ack represents the value of the confirmation field.

The above process is as follows:

1. A sent data numbers 1 to 100 and can send 300 bytes
2. A sent data numbers 101 to 200 and can send 200 bytes
3. A sent data sequence numbers 201 to 300, but lost the data
4. B sends an ACK and notifies A that it is allowed to send bytes from sequence number 201 to 500,300.
5. A sent data numbers 301 to 400 and can send 100 bytes
6. A sent data sequence numbers 401 to 500 and cannot send data anymore
7. A times out and retransmits old data, but cannot send new data
8. B sends an ACK and notifies A that it is allowed to send 100 bytes from sequence number 501 to 600.
9. A sent data sequence numbers 501 to 600 and cannot send data anymore
10. B sends an ACK and notifies A that it is not allowed to send data.