In the previous section, we introduced the TCP protocol. In this part, we will introduce how TCP achieves reliable transmission.
Reliable Transmission of TCP
1. Sliding window
In the previous section, when we introduced the header of the TCP segment, we said that in the "window" part, the content of the "window" is the total amount of bytes of data sent/received (the window is in bytes).
Sender A has a send window , and receiver B has a receive window . The "window" in the head must cooperate with the "confirmation number" to determine which data to send and which data to receive.
Now suppose that A has received the confirmation segment from B, in which the window is 20 (bytes) and the confirmation number is 31 (this indicates that the next sequence number that B expects to receive is 31, and the data before the sequence number 31 has been received), A constructs its own sending window, as shown below:
Let's now discuss A's send window:
In the case of not receiving confirmation from B, A can continuously send all the data in the window. Any data that has been sent will temporarily retain a copy for use in retransmission over time .
The position of the sending window is determined by the positions of the leading edge of the window and the trailing edge of the window.
Trailing edge: The rear part (left) of the trailing edge in the above figure indicates that it has been sent and an acknowledgment has been received. These data are no longer kept copies.
There are two cases of trailing edge change: do not move (no new acknowledgment number (>31)) and move forward (receive new acknowledgment number). The trailing edge does not move backwards because the received acknowledgment cannot be undone.
Leading edge: The front part (right) of the leading edge in the figure above represents data that is not allowed to be sent.
There are three frontier changes:
Move forward: the usual case after receiving a new ack (>31)
Still: No confirmation received; a new confirmation number (35) is received, but the window value is reduced to 15, and the position of the leading edge is still at 50.
Shrink: The window value becomes smaller. For example, the new confirmation number above is 35, but the window value becomes 10, then the position of the leading edge is 45. However, the TCP standard strongly discourages this.
The movement of the rear edge and the leading edge just shows the characteristics of the window sliding.
Next, we will use an example to introduce the characteristics of the sliding window in detail.
Assume that A has sent data with serial numbers 31 to 41 in the window (indicated by the small black boxes), indicating that it has been sent but has not received an acknowledgement. The data from 42 to 50 is allowed to be sent but has not been sent yet. As shown below.
In the above figure, three pointers are needed to describe the state of the send window: P1, P2, and P3. The part smaller than P1 is the part that has been sent and the confirmation is received, and the part larger than P3 is not allowed to be sent.
P3 - P1 = A's send window (notification window)
P2 - P1 = number of bytes sent but not yet acknowledged.
P3 - P2 = number of bytes allowed to be sent but not yet sent (available window or valid window)
Let's talk about B's receive window. Look at the picture below.
The sequence numbers (31~50) in the B receiving window are allowed to receive. In the picture above, the data for 32, 33 is received, but the data for 31 is not received (maybe lost, maybe stuck in the network). And B can only send the highest number as the confirmation number among the data received in sequence. Since the 31st has not been received , the confirmation message sent by B is still 31 , not 32 or 33.
Now suppose that B receives data No. 31, and hands the data from 31 to 33 to the application, and then B will delete these data. Then move the receiving window forward by 3 sequence numbers, and send the confirmation number 34 to A at the same time, and the window is only 20.
At this time, the picture after the A and B windows are moved is as follows:
A has received the confirmation number 34 sent by B, the window value of 20, so P1 is moved to 34, and P3 is moved to 53. But the P2 pointer did not move.
And we can see that B also received 37, 38, 40. However, these data do not arrive in order, so they can only be temporarily stored in the receiving window .
Then, after A continues to send the data of serial numbers 42~53, the pointer P2 moves forward and coincides with P3. As shown below:
The sequence number in the window has been used up. But have not received confirmation from B yet. If A has not received an acknowledgment after a period of time, it can only retransmit this part of the data over time until B receives the acknowledgment position.
If A receives the confirmation number and falls within the sending window, then A can slide the window forward and send new data.
2. Send/Receive Buffer
The sender's application process writes the byte stream into the TCP send buffer; the receiver's application process reads the byte stream from the TCP's receive buffer. The following diagram illustrates the relationship between TCP buffers and windows:
Let's look at (a) first:
You can see the data size in Send Cache > Application > Send Window .
Send the cache and store it temporarily:
1: The application passes the data to TCP to be sent.
2: TCP has sent but not received acknowledgment data.
The application must control the rate of writing to the cache, not too fast, otherwise the sending cache will have no space to store data. (I/Obuffer)
Take another look at figure (b):
The receive buffer is used to temporarily store:
1: Data that arrived in order but has not been read by the receiving application
2: Data arriving out of order
If a received packet is detected with errors, it is discarded. If the application does not have time to read the received data, the receive buffer will eventually fill up, reducing the receive window to zero. Conversely, if the application can read the received data from the receive buffer in time, the receive window can be increased, but cannot exceed the receive buffer size. (b) also points out that the next byte number expected to be received, this byte number is also the confirmation number in the header of the message segment from the receiver to the sender.