Detailed Explanation of the Cooperative Working Mechanism Between TCP Receive Window and Send Window

1. Problem Description

In network interviews, interviewers often ask: "Please explain in detail how the TCP receive window and send window work together, and how the sender adjusts its sending behavior based on the receive window?" This question tests a deep understanding of the core mechanism of TCP flow control. Many students know these two concepts, but the details of their dynamic cooperation and the process of how to avoid sending data too fast, which can cause the receiver's buffer to overflow, are not clear.

2. Core Definitions and Background

First, we need to clarify two core definitions, which are the foundation for understanding all subsequent cooperative work.

• Receive Window: This is a flow control tool for the receiver. In the header of each TCP segment it sends, the receiver informs the sender via the "window size" field: "How many free bytes remain in my receive buffer that can be used to store the data you send." This value defines the available space from the receiver's perspective. Its size changes dynamically, depending on the speed at which the application process reads data from the receive buffer.
• Send Window: This is a data structure maintained by the sender, representing "the maximum number of bytes of data I can send without receiving an acknowledgment." The send window is the sender's local mapping and interpretation of the receive window. At any given moment, the sender will only send data located within the "send window."

Their relationship can be summarized as: The receive window is the 'authorization,' and the send window is the 'execution.' The size of the send window is constrained by two factors: 1) the receive window size advertised by the receiver; and 2) the congestion window size determined by network congestion conditions. The actual size of the send window is the smaller of these two values. This knowledge point mainly focuses on flow control, so we assume there is no network congestion, and the send window size equals the receive window size.

3. Step-by-Step Analysis of the Cooperative Working Mechanism

Let's simulate a complete process, from connection establishment to data sending, and then to window adjustment.

Step 1: Connection Establishment and Initial Synchronization

1. During the TCP three-way handshake phase, the client (sender) and server (receiver) exchange their initial receive window sizes in the SYN and SYN-ACK segments.
2. Assume the server advertises its initial receive window rwnd = 4096 bytes in the SYN-ACK segment. This means the server tells the client: "My buffer currently has 4096 bytes free."
3. Upon receiving this, the client initializes its send window based on this value. Assume the client's data sequence number starts from 1. Then, the initial state of the client's send window is:
   • Send Window Left Boundary: Points to the sequence number of the next data byte to be sent, initially 1.
   • Send Window Right Boundary: Left boundary + rwnd = 1 + 4096 = 4097.
   • Usable Window: The entire 4096 bytes are available because no data is in flight yet.

Step 2: Data Sending and Acknowledgment Reception

1. The client starts sending data. Suppose it sends a data segment of 1024 bytes with sequence numbers 1-1024. After sending, this data enters the "sent but unacknowledged" state.
2. The client's send window state is updated:
   • Window Left Boundary: Still 1 (because 1-1024 is not yet acknowledged).
   • Sent but Unacknowledged: 1-1024.
   • Usable Window: Shrinks to data between 1025 and 4097, i.e., 3072 bytes (4096-1024).
3. The server receives this 1024 bytes of data and stores it in the receive buffer. Assume the server's application process hasn't had time to read any data yet, so the free space in the receive buffer decreases by 1024 bytes.
4. The server needs to send an acknowledgment (ACK) to the client. This acknowledgment segment contains two key pieces of information:
   • Acknowledgment Number: 1025. This means "I have correctly received all data before sequence number 1025, and I expect you to start sending from 1025."
   • New Receive Window Size: rwnd = 3072 bytes (4096 - 1024). This tells the client: "My buffer now has 3072 bytes free."

Step 3: Window Sliding and Adjusting Sending Behavior

1. The client receives the server's ACK segment (ACK=1025, rwnd=3072). The client performs the following operations:
   • Slide Window Left Boundary: Move the send window's left boundary from 1 to 1025. This means data with sequence numbers 1-1024 has been acknowledged and can be removed from the "sent but unacknowledged" list.
   • Update Send Window Size: Replace the old receive window value with the newly received rwnd=3072.
   • Calculate New Send Window: New left boundary (1025) + new receive window (3072) = new right boundary (4097). Note: At this point, the right boundary does not move, but the "map" inside the window is updated.
   • Recalculate Usable Window: Because the left boundary has slid and the sent but unacknowledged data is cleared, the entire data from 1025 to 4097 (3072 bytes) becomes the "usable window" again.
2. At this moment, the client's sending behavior is "allowed" to continue sending up to 3072 bytes of new data because the receiver explicitly stated it can handle that much.

Step 4: Receiver Processes Data, Window Expands

1. The server's application process starts working and reads the just-received 1024 bytes of data from the receive buffer.
2. The server's receive buffer thus frees up 1024 bytes, and the free size recovers from 3072 bytes to 4096 bytes.
3. The next time the server needs to send data or an acknowledgment to the client (possibly a piggybacked ACK), it will fill the window field in the TCP header with the new rwnd = 4096.
4. Upon receiving this new window advertisement, the client will update its send window's right boundary to 5121 (1025 + 4096), thereby "expanding" the usable window and allowing more data to be sent.

4. Key Interactions and Handling Extreme Cases

There are several key points in the cooperative work that require special understanding:

• Zero Window and Window Probing: If the server's application process reads extremely slowly and the receive buffer becomes full, it will advertise rwnd = 0 in an ACK. The client, upon receiving a zero-window advertisement, must immediately stop sending data. To prevent both parties from waiting permanently (the server waiting for the application to read, the client waiting for a window update), TCP sets up a persist timer. When the sender is blocked due to a zero window, it starts this timer and periodically sends a "window probe" segment with only 1 byte of data to the receiver. This triggers the receiver to reply with its latest rwnd, allowing transmission to resume promptly when the receiver's buffer has free space.
• Silly Window Syndrome: If the receiver advertises a very small window each time (e.g., 1 byte), and the sender immediately sends 1 byte of data, network efficiency becomes extremely low, with much bandwidth used for headers. TCP avoids this problem through the receiver's "window update delay" (typically waiting until the window reaches at least the MSS or half the buffer before updating) and the sender's Nagle algorithm.

5. Summary

The cooperative work of the TCP receive window and send window is the essence of flow control, achieving "end-to-end" rate matching. The process can be summarized as:

1. Receiver-Driven: The receiver continuously advertises its current receiving capability (rwnd) to the sender through the window field in ACK segments.
2. Sender Follows: The sender strictly maintains a "send window" locally based on the rwnd value advertised by the receiver and only sends data within that window.
3. Dynamic Sliding: When sent data is acknowledged, the window's left boundary slides forward; when a new, larger rwnd advertisement is received, the window's right boundary may expand to the right. The size of the usable window changes dynamically accordingly.
4. Controlled Flow: This mechanism ensures that the sender's data injection rate never exceeds the receiver's application-layer data processing rate, thereby preventing receiver buffer overflow and achieving reliable, ordered, and lossless byte stream transmission.