How the protocol guarantees reliable transmission

How TCP protocol guarantees reliable transmission

First, the summary

1, confirmation and retransmission: the receiver receives the message will confirm that the sender sent a period of time after the transmission did not receive confirmation to retransmit.

2. Data check

3, data reasonable fragmentation and sequencing:

The Udp:ip datagram is larger than 1500 bytes and is larger than the MTU. This time the sender IP layer needs to be fragmented (fragmentation). Divide the datagram into pieces so that each piece is smaller than the MTU. The receiver IP layer needs to be reorganized for the datagram. This will do a lot of things, What's more, because of the characteristics of UDP, when a piece of data transmission is lost, the reception is not able to reorganize the datagram. Causes the entire UDP datagram to be discarded.

TCP is properly fragmented by the MTU, and the receiver caches data that is not ordered, reordering it and handing it over to the application layer.

4, Flow control: When the receiving party is too late to process the sender's data, can prompt the sender to reduce the rate of transmission, to prevent packet loss.

5, congestion control: When the network congestion, reduce the transmission of data.

Second, sliding window

The above general said TCP guarantees reliable transmission mechanism, the following is how to use sliding window to achieve.

Why use sliding windows

Because the sender expects to continue sending other segments of the message before receiving confirmation. For example, a message of number 1-3 is sent before the confirmation of the NO. 0 message, which improves the channel utilization. However, it is possible to think that the 0-4 sent out may be re-transmitted, so a buffer is needed to maintain the messages, so there is a window.

RTT: Round Trip time.

What's the window?

Receive window:

The "Receive window" size depends on the application (such as the tomcat:8080 Port's listening process), system, and hardware limitations. In the figure, the receive window is 31~50, and the size is 20.

In the Receive window, the black represents the data that was received, and the white represents the data that was not received.

When the data on the left side of the window is received, such as 27, it is discarded as this part has been delivered to the host;

When the data is received on the left side of the window, such as 52, it is discarded because it is not yet in its turn;

When receiving data from a received window, such as 32, discard;

When you receive data from a window that is not received, such as 35, the cache is in the window.

Send window:

The size of the Send window Swnd=min (rwnd,cwnd). Rwnd is the receive window, CWnd for congestion control, which can be understood temporarily as swnd= Rwnd = 20.

The figure is divided into four sections, where P1 to P3 is the Send window.

Tips: The Send window is in bytes. In order to facilitate the drawing, the picture is shown in the same way as the message unit. But this does not affect understanding.

Third, re-transmission and confirmation

When to send confirmation: This is a complex strategy. Here we simply assume that each message receives a confirmation.

How to confirm (cumulative confirmation):

Scenario 1: Send ack=31 (why this is also sent, this confirmation can be used in the back of the congestion control)

Scenario 2: Send Ack=34, and set the left edge of the receive window to 34 and the right edge to 53

The benefits of the cumulative acknowledgment: In case 1 the ack=31 than the description received 32 and 33 simple; Cons: You may want to retransmit the data that you have already received.

What to do when the sender receives confirmation:

Scenario 1: Receive ack=31, do nothing, or continue to send content in the available window, such as 42~50

Case 2: Received ack=34, the left edge of the Send Window window is set to 34, the right edge is set to 53

When to retransmit: Because each message has a timeout counter, the timeout is re-transmitted. The choice of timeout retransmission time is also a strategy.

TCP Cache and Window relationships: Windows are part of the cache.

Send cache = Send window + P3 part to the right

Receive cache = Receive Window + part confirmed but the host has not finished processing data.

Iv. Flow Control

A graph stream, simply means that the receiving end processing is not over, the window is reduced, and the window value to tell the sender side.

　　

When the window value is 0, and the receiver restores the window value, but the acknowledgment is lost, it enters the deadlock situation which waits for each other. So if the window value is 0, the sender will open a continuous counter and ask the receiver each time.

V. Congestion control

Swnd=min (Rwnd,cwnd), CWnd is the size of the congested window.

Slow start and congestion avoidance

Ssthresh: A parameter that is referenced when handling congestion. The initial value in the example is 16 and later becomes 12.

When the cwnd> Ssthresh,cwnd in the slow-start method exponential growth;

When the cwnd< Ssthresh,cwnd is linearly increased with the method of congestion avoidance.

A few points worth noting

1 is the change of CWnd with the transmission turn, each one of the RTT even round.

2 timeouts can be thought of as congestion.

Fast retransmission and fast recovery: an enhanced version of the previous algorithm

Fast retransmission: Received 3 of the same confirmation immediately retransmission, not equal to the timeout;

Fast recovery: CWnd does not start again from 1.

How the protocol guarantees reliable transmission