TCP reliability guarantee mechanism

TCP reliability guarantee mechanism

Preface

We often say that UDP is an unreliable communication protocol, and the later developed TCP has made up for the unreliability of UDP. Then, what does TCP rely on to ensure its reliability?

0X10 serial number, confirmation response, timeout retransmission

When the receiver receives the message, it will confirm, and if the sender does not confirm after a period of time, it will retransmit

0X11 window control and high-speed retransmission control/fast retransmission (repeat confirmation response)

TCP will use window control to increase the transmission speed, which means that within a window size, you don’t have to wait for a response to send the next segment of data . The window size is the maximum value that can continue to send data without waiting for confirmation.
If the data segment 1001-2000 is lost , Every time the subsequent data is transmitted, the confirmation response will continuously send a response with the serial number 1001, indicating that I want to receive the data starting from 1001. If the sender receives the same response three times, it will immediately retransmit the
receiving window:Insert picture description here
"Receive The size of the "window" depends on the application (for example tomcat: port 8080 monitoring process), system, and hardware limitations. In the figure, the receiving window is 31-50, and the size is 20.
  In the receiving window, the black ones indicate the received data, and the white ones indicate the unreceived data.
  When receiving the data on the left side of the window, such as 27, it is discarded because this part has been delivered to the host;
  when receiving the data on the left side of the window, such as 52, it is discarded because it is not yet its turn;
  when it is received The data in the window, such as 32, is discarded;
  when the data in the window that has not been received, such as 35, is buffered in the window.

Send window
Insert picture description here

0X13 congestion control

If the window is large and the sender continuously sends a large amount of data, it may cause network congestion. In order to prevent this situation, TCP has designed congestion control

Slow start: Define the congestion window, set the window size to 1 at the beginning, and then set the congestion window size*2 every time a confirmation response is received (after a rtt)

Congestion avoidance: Set the slow start threshold . Congestion avoidance means that when the size of the congestion window reaches this threshold, the value of the congestion window no longer rises exponentially, but increases incrementally (every confirmation response/each rtt, congestion window size+1), To avoid congestion

Regarding the timeout retransmission of the message segment as congestion , once a timeout retransmission occurs, we need to first set the threshold to half of the current window size, and set the window size to the initial value 1, and then re-enter the slow start process

Fast retransmission: When encountering 3 repeated confirmation responses (high-speed retransmission control), it means that 3 message segments have been received, but the previous segment is lost, and it will be retransmitted immediately.

Then, the first threshold is set to half of the current window size, then the congestion window size to the slow start threshold +3 size

In this way, in TCP communication, the throughput of the network is gradually increasing, and as congestion reduces the throughput, and then enters the process of slowly increasing, the network will not be easily paralyzed.
Insert picture description here

0X14 flow control

Simply put, when the receiver cannot handle it, it shrinks the window and tells the sender the value of the window. Insert picture description here
Deadlock:
When the sender receives a response with a window of 0 , the sender stops sending and waits for the receiver's download. An answer. But if the response whose window is not 0 is lost during the transmission process , the sender has been waiting, and the receiver thinks that the sender has received the response and waits to receive new data, so the two parties wait for each other, resulting in a deadlock

In order to avoid deadlock, TCP uses a continuous timer , which is started every time the sender receives a zero-window response . As soon as the time is up, it will actively send a message to ask the recipient of the window size. If the receiver still returns to the zero window, reset the timer and continue to wait; if the window is not 0, it means that the response message is lost. At this time, reset the sending window and start sending.

Guess you like

Origin blog.csdn.net/rjszz1314/article/details/104302507