7 other features of TCP [sliding window mechanism ▲]

Preface: In the previous article, we wrote about the three major characteristics of TCP, and this article will describe the other seven major characteristics of TCP!

The sliding window mechanism is to further improve the transmission efficiency under the premise of reliability

4. Sliding window mechanism

Understanding sliding windows

The way of sending and receiving: The TCP protocol needs to confirm the data before sending the next data packet, as shown in the figure:

insert image description here
As shown in the figure above, every time the sending end sends a data packet, it needs to get the confirmation response from the receiving end before sending the next data packet. Time, then to transmit N copies of data, you need to wait for N times of response time, the total transmission time: N copies of data transmission time + N copies of response transmission time

The performance of sending and receiving is low, so we can greatly improve performance by sending multiple pieces of data at a time (in fact, the waiting time of multiple segments is overlapped), as shown in the figure:

insert image description here
Sliding window is essentially batch transmission
of data. Total transmission time: N data transmission time overlaps into one time, and N response transmission time overlaps into one time, which
is equivalent to the transmission time of multiple data and the waiting time for ACK Compressed into one copy, the total waiting time is reduced, and the transmission efficiency is also high

  • window

Window size: without waiting for ACK, the maximum amount of data sent in batches is called "window size" (as shown in the figure above, it is 4000 bytes, 4 fields)

  • When sending the first four fields, you don’t need to wait for any ACK, just send it directly;
  • After receiving the first ACK, the sliding window moves backward, and continues to send the data of the fifth field, and so on;
  • In order to maintain this sliding window, the operating system kernel needs to create a sending buffer to record what data is currently unanswered; only the data that has been answered can be deleted from the buffer;
  • The larger the window, the higher the throughput of the network
  • slide:

The data within the window range is waiting for the ACK of these data (already sent out).
insert image description here
As shown in the above figure, when the sender receives the ACK of 2001, it means that the other party has received the data of 1001-2000, and immediately continue to transmit the data of 5001-6000 data, the serial numbers of the packets waiting for ACK are 2001, 3001, 4001, 5001

Dealing with packet loss

The two cases of packet loss are shown in the figure:

insert image description here
Case 1: Acknowledgment (ACK) packet loss
No additional processing is required; in this case,It doesn't matter if a partial ACK is lost, because it can be confirmed by a subsequent ACK

insert image description here
Understand the meaning of "confirmation sequence number"
Starting from the current sequence number, the previous data has been correct. As shown in
the above figure, the ACK of 1001 is lost, but the ACK of 2001 is not lost. At this time, after the sender receives 2001, it will think 1 - 1000 This data also arrives smoothly, it doesn’t matter if 1001 is lost, the ACK of 2001 can contain the information in 1001 ACK

Case 2: Packet loss

As shown in the figure below, if 1001-2000 is lost, then the next few data such as 2001-3000, 3001-4000, etc. have arrived smoothly, and the acknowledgment number of the ACK fed back by host B is always 1001; at this time, if host A finds
several consecutive The ACK is all 1001, host A knows that the data of 1001 is lost, and it will retransmit 1001.
Before retransmitting 1001, the received confirmation sequence number is
1001. The data has been received before, and the next ACK will start
retransmission here from 7001, just retransmit the lost data, other data does not need additional retransmission——fast retransmit(With timeout retransmission under sliding window)
insert image description here
"Out of order" transmission:

insert image description here

insert image description here

5. Flow control

Flow control: check and balance the sending efficiency (window size) of the sender according to the processing capability of the receiver (the rate of the sender is determined by the "remaining space size" of the receiving buffer)

The window size cannot be infinitely large, and the transmission rate is too fast, and the receiver may not be able to handle it. When
using the sliding window mechanism for data transmission, the sender sends data packets according to the actual situation, and the receiving end receives the data packets; due to the ability of the receiving end to process data packets are different, so two situations are possible:

  • If the window is too small, the sender sends a small amount of data packets, the receiver will process them quickly, and can handle more data packets; when transmitting relatively large data, it needs to wait for the sender continuously, which will cause a lot of trouble. big delay

  • If the window is too large, the sending end sends a large number of data packets, but the receiving end cannot handle so many data packets, and the link will be blocked; if these data packets that should have been received are discarded, the retransmission mechanism will be triggered

(The size of the first window is determined according to the size of the link bandwidth), send data packets, the receiving end receives these data packets, and returns a confirmation response packet, telling the sending end how many data packets it wants to receive next time (new window size), after the sender receives the acknowledgment packet, it will send data packets with this window size

  • The receiving end puts the buffer size that it can receive into the "window size" field in the TCP header, and notifies the
    sending end through the ACK end
  • The larger the window size field, the higher the throughput of the network
  • Once the receiving end finds that its buffer is almost full, it will set the window size to a smaller value and notify the sending end
  • After the sender receives this window, it will slow down its sending speed
  • If the receiver buffer is full, the window will be set to 0; at this time, the sender will no longer send data, but it needs to send
    a window detection data segment periodically, so that the receiver can tell the sender the window size

As shown below:

insert image description here
Illustration:

  • Suppose the initial window size is 4000, and the sender sends 4 data packets, which are 1-1000, 1001-2000, 2001-3000 and 3001-4000
  • The receiving end receives data packets, after receiving 1-1000 data packets, set the window size to 3000, and tell the sending end that it can only process 3 data packets now, please send 3 data packets next time
  • The sender receives the acknowledgment packet, checks that the receiver returns a window size of 3000, and knows that the receiver has processed 1 data packet; then continue to send: 1001-2000, 2001-3000 and 3001-4000
  • After the receiver receives it, the buffer can only process 2 data packets, and the third data packet 3001-4000 sent has not been processed; this means that the receiver can only process 2 data packets at this time, and the third data packet still need to resend
  • When the window is 0, the sender will suspend sending and send a probe message regularly; because the data in the receiving buffer may be taken away at any time, once it is taken away, new data can be received (the size of the sliding window is dynamically changed of )

Window detection:

6. Congestion control (safety mechanism)

Congestion control is to consider the degree of congestion on the network transmission path

Although TCP has the big killer of sliding window, it can send a large amount of data efficiently and reliably; but if a large amount of data is sent at the beginning stage, it may still cause problems; because there are many computers on the network, the current network status may be It is already relatively congested, and sending a large amount of data rashly without knowing the current network status is likely to make things worse.
Therefore, TCP introduces a slow start mechanism to send a small amount of data first, explore the path, and find out the current network congestion status. Then decide how fast to transfer data

insert image description here

Line increase product subtraction (sum formula increases, product formula decreases)

The growth rate of the congestion window like the one above is exponential. "Slow start" just refers to the slow start at the beginning, but the growth rate is very fast. The specific growth is as follows:

​ At the beginning, it grows exponentially from 1, and starts to grow linearly after reaching the threshold. If there is network congestion, it will directly decrease to the initial value, and then grow exponentially again to reach the new threshold (the new threshold is half the size of the last blocking window), Linear growth again until the network is blocked, and this dynamic transformation cycle has been

Why change dynamically? ?
The congestion of the network is changing rapidly, and we need to make dynamic adjustments according to the actual situation of the network at any time (adapt to the changing process of the network at any time)
(mathematical derivation)
insert image description here
insert image description here

7. Delayed response (efficiency mechanism)

The purpose is to improve efficiency, and try to return a reasonable but relatively large window on the basis of flow control

As we mentioned earlier, after the sender sends data, the host receiving the data needs to return an ACK response. If it returns immediately at this time, the window may be relatively small (because only part of the data in the buffer has been processed), so TCP uses a delayed response. mechanism, for example:

No delayed response:
There is a supermarket, assuming that the stock of instant noodles can store up to 100 boxes, 80 boxes are already in stock, and 20 boxes are free; the next
morning, the delivery guy comes to ask: "Boss, how many noodles do you need tomorrow? "
Boss: "You can send up to 20 boxes."

With delayed answer:
Early the next morning, the delivery boy came to ask: "Boss, how much noodles do you need tomorrow?"
Boss: "I will call at night to tell you how much you need.
" , you can send up to 10 boxes the next day)

Delayed response is actually to make the sending time of ACK later (without affecting the reliability). During the
delayed time, the application will be provided with more opportunities to consume data. When the time is up, when sending ACK again, The resulting window size (the remaining space in the receive buffer will be larger)

The larger the window, the greater the network throughput and the higher the transmission efficiency; our goal is to maximize the transmission efficiency while ensuring that the network is not congested

Q: Can all packets be delayed?

Certainly not
.
1. Quantity limit: Respond once every N packets (N is generally 2)
2. Time limit: Respond once when the maximum delay time is exceeded (the time is generally 200 ms, and the waiting time for delayed response cannot exceed the timeout limit transmission time, otherwise it will be retransmitted)

8. Piggybacking (efficiency mechanism)

On the basis of delayed response, the mechanism introduced to further improve the efficiency of program operation

In many cases, the communication mode between the client and the server is generally the Request-Response mode, that is, "one question and one answer"
as shown in the figure:

insert image description here
Note:
The SYN and ACK in the middle of the three-way handshake are determined by the kernel, and do not involve different timings. In
the process of the four waved hands mentioned above, the ACK is determined by the kernel, and the FIN (close method) sent is determined by the application code.

9. Sticky package problem

Strictly speaking, the sticky packet problem is not a mechanism of TCP itself, but a common problem of byte stream transmission.
Sticky packets refer to application layer data packets, which makes it easy to read half of the application layer when data is processed. data pack

Byte stream-oriented: refers to reading one byte at a time, or reading two bytes at a time, or reading N bytes at a time

Example: When both parties establish a connection, they need to send data with different structures within a period of time after the connection. For example, after the connection, there are several structures

  • "How are you"
  • "Good P"

How many bytes to read is a complete application layer datagram. This is not clear. If you read one Chinese character at a time, it is "good"; if you read three Chinese characters at a time, it
is "good P".
Not the same, the final meaning is also very different; to read application layer data, you should not only read half a package

How to avoid sticky package problem?

In the final analysis, it is a sentence, clear the boundary between two packets.
The TCP protocol itself does not help you distinguish the application layer data packets. Relatively speaking, the UDP protocol does not have this problem (the UDP protocol is sent and received in units of data packets)

  • Way 1 - use delimiter

For example, the above answer is changed to "good P;"

Use a semicolon; as a separator between two packets, read the data until the semicolon; it is considered a complete application layer data packet application
layer protocol, which is determined by the programmer himself, as long as the separator is not consistent with the text Just conflict**

  • Method 2 - Specify the length of the packet

For example, the above use case is changed to "4 How are you? 3 Ps"

​First read the first four bytes to get the length of the packet 3; continue to read 3 Chinese characters, then read a complete packet

The HTTP protocol is based on the TCP application layer protocol, and it will handle the problem of sticky packets by itself. The above two methods are used: .
For
GET requests , the separator is a blank line.
For POST requests , Content-length is used to specify the length of the packet

Thinking: Is there a "sticky packet problem" for the UDP protocol?

  • For UDP, if the upper layer has not delivered data, the UDP packet length is still there. At the same time, UDP delivers data to the application layer one by one
    ; there is a clear data boundary
  • From the perspective of the application layer, when using UDP, either receive a complete UDP message or not receive it; there
    will be no "half" situation

10. Keep alive mechanism

When the two parties establish an interactive connection, there is not always data interaction. Some connections will actively release the connection after the data interaction is completed, and some will not. Then during a long period of time without data interaction, both sides of the interaction may fail. Various accidents such as power failure, crash, abnormal restart, or disconnection of the intermediate routing network for no reason, NAT timeout, etc.

In these "abnormal situations", TCP will have some special handling
examples for connections:
1. Process crash: In this case, the TCP connection will normally wave four times (as long as the process exits, it will automatically close the relevant files)
2. Host shutdown (shutdown according to the process): When shutting down, the process will be forced to be killed first, and four waved hands will be performed during the process of killing the process
3. Host power off/network cable disconnected:

  • a) The receiver is powered off.
    When the peer tries to send a message, there will be no ACK - then a timeout retransmission will be triggered - after a certain number of retransmissions, the connection will be reset - the connection will be abandoned
  • b) The sender is powered off
    . The peer is trying to receive the message. For the receiver, the sender does not know when the sender will send it. Does it just keep waiting?
    Solutionheartbeat packet TCP communication parties, even in the process of no data interaction, will regularly transmit a "heartbeat packet" that has no data business meaning to each other, just to prove "I am alive". After receiving the heartbeat packet from the other party, it can be considered that the other end is "hanging"

TCPSummary

The reason why TCP is complicated is that it must ensure reliability while improving performance as much as possible

insert image description here
Reliability:
checksum, sequence number,
confirmation response, timeout retransmission,
connection management, flow control, congestion control

Improve performance:
sliding window, fast retransmission
delayed acknowledgment, piggyback acknowledgment

Others:
timers (timeout retransmission timer, keep-alive timer, TIME_WAIT timer, etc.)

insert image description here

Guess you like

Origin blog.csdn.net/m0_47988201/article/details/122735834