TCP (sliding window, flow control)

 

We discussed the acknowledge response strategy earlier , For each data segment sent , Give one ACK Confirm response , received ACK Then send the next data segment .

There is a big disadvantage in doing so , It's just poor performance , Especially when the data round-trip time is long .

The sliding window

Since the performance of this one send one receive method is low , So we send multiple pieces of data at a time , It can greatly improve the performance ( In fact, it overlaps the waiting time of multiple segments ）

• Window size refers to the maximum value that can continue to send data without waiting for an acknowledgement . The window size in the above figure is 4000 Bytes ( Four sections ).
• When sending the first four segments , There's no need to wait for any ACK, Direct transmission ;
• Got the first one ACK after , Slide the window back , Continue to send the data of the fifth segment ; By analogy ;
• The operating system kernel maintains this sliding window , It needs to be opened up Send buffer To record what data is not answered ; Only confirm the data that has been answered , To delete from the buffer ;

•   The greater the window , The higher the throughput of the network

So if there is packet loss , How to retransmit ? There are two situations to discuss here .
Situation 1 ： The packet has arrived ,ACK Lost

In this case , part ACK It doesn't matter if you lose it , Because it can be through subsequent ACK Confirm ;

ACK=6001 The meaning of , Not telling the host A I have received 5001-6000 Data between , It tells the host A I have received 0-6000 Between the .

Situation two ： Packet loss

• When a message segment is lost , The sender will always receive 1001 In this way ACK, It's like reminding the sender " What I want is 1001" equally
• If the sending host receives the same message three times in a row "1001" Such a response , The corresponding data will be 1001 -2000 To resend ;
• At this time, the receiver receives 1001 after , Return again ACK Namely 7001 了 ( because 2001 - 7000) In fact, the receiving end has already received , It is placed in the receive buffer of the receiving operating system kernel

This mechanism is called " High speed retransmission control "( Also called " Fast retransmission "）

flow control

The speed of data processing at the receiving end is limited . If the sender sends too fast , This causes the buffer at the receiving end to be full , At this time, if the sender continues to send , It will cause packet loss , Then it causes a series of chain reactions such as packet loss and retransmission
therefore TCP Support according to the processing capacity of the receiving end , To determine the sending speed of the sender . This mechanism is called flow control （Flow Control）

• The receiver puts the size of the buffer it can receive into TCP In the first part " Window size " Field , adopt ACK The sending end is informed by the sending end ;
• The larger the window size field , The higher the throughput of the network ;
• Once the receiver finds that its buffer is almost full , It will set the window size to a smaller value and inform the sender ;
• After the sender receives this window , It will slow down your sending speed ;
• If the receiving buffer is full , Will set the window to 0; At this time, the sender no longer sends data , However, a window probe data segment needs to be sent periodically , Make the receiving end tell the sending end the window size .

  There is no need to pass it around

（ See the courseware for details ）

  Used to review ：https://blog.csdn.net/dangzhangjing97/article/details/81008836?

Delay response

If the host receiving the data immediately returns ACK The reply , At this time, the return window may be smaller

• Assume that the receiver buffer is 1M. Once received 500K The data of ; If you answer immediately , The returned window is 500K;
• But in fact, the processing speed of the processing end may be very fast , 10ms Put... In 500K Data is consumed from the buffer ;
• under these circumstances , The receiving end processing is far from reaching its limit , Even if the window is a little bigger , Can handle it ;
• If the receiver waits a little while before answering , Such as waiting for 200ms Answer again , Then the window size returned at this time is 1M

Remember that , The greater the window , The greater the network throughput , The higher the transmission efficiency . Our goal is to improve the transmission efficiency as much as possible without congestion

Can all packets delay the response ? Certainly not

• Quantitative restriction : every other N Just one response per packet ;
• The time limit : Answer once when the maximum delay time is exceeded

Specific number and timeout , Depending on the operating system ; commonly N take 2, The timeout time is taken as 200ms

Take a reply

Performance optimization for delay response

On the basis of delayed response , We found that , In many cases , The client server is also in the application layer " Send and receive " Of . It means that the client says to the server "How are you", The server will also give a reply to the client "Fine, thank you";
So at this point ACK You can take a ride , And server response "Fine, thank you" Back to the client together