We are dedicated to sharing backend technology (high concurrency architecture, middleware, Linux, TCP/IP, HTTP, MySQL, Redis), Python and other original dry products and interview guide!

The TCP/IP protocol is a very important protocol, and it is a very important protocol. When the interviewer asks you, can you explain how TCP ensures reliable transmission?

TCP is a protocol that provides reliable delivery. That is, data transmitted over a TCP connection is error-free, not lost, not duplicated, and arrives in sequence. TCP ensures data transmission reliability through the following features:

  • Serial number and acknowledgement acknowledgement
  • Timeout retransmission control
  • Connection management
  • Sliding window control
  • Flow control
  • Congestion control

We discussed several mechanisms for TCP reliability: sequence number and acknowledgement acknowledgement, timeout retransmission control, connection management, and sliding window control

In this article we continue to discuss two other mechanisms for TCP reliability: flow control and congestion control

TCP protocol on the article there are several, we can also look at:

  • A thorough understanding of TCP three – time handshake, four – time wave process and principle
  • Interviewer: Tell me the difference between UDP and TCP and the application scenario
  • How to ensure the reliability of TCP protocol sliding window, timeout retransmission, sequence number confirmation reply signal

Difference between congestion control and flow control

  • Flow control is applied to the receiver, which controls the speed of the sender so that the receiver can receive the packet in time to prevent the loss of the packet.

  • Congestion control Congestion control prevents too much data from being injected into the network and prevents the network from being overloaded

Flow control

The so-called flow control, is to let the sender do not send too fast, so that the receiver can receive in time

Assuming no flow control, the sender sends data according to their own actual situation, if send too fast, to receive buffer at the receiving end soon filled, at this time the sender if continue to send data, the receiver processing not to come over, then the receiver will be ditched ought to have received data, send this triggers the retransmission mechanism, Therefore, network traffic is wasted.

Therefore, TCP needs to provide a mechanism for the sender to control the amount of data sent according to the actual receiving capability of the receiver. This is called flow control.

TCP uses sliding window to realize flow control mechanism, and sliding window size is through the TCP header window size field to inform each other.

Let’s revisit the TCP header:

In the TCP header information, there is a 16-bit field window size, the content of the window size is actually the remaining size of the receiving end to receive data buffer. The larger the number, the larger the residual space of the receiving buffer, the greater the throughput of the network. However, when the receiver is facing a data overflow in the receive buffer, the window size is set to a smaller value, telling the sender to control the amount of data it sends. After receiving the window change indication of the receiving end, the sender will adjust the amount of data sent, thus forming a complete flow control.

The specific operations of traffic control are as follows: When receiving ACK packets, the receiver fills in its immediate window size RWND (Receiver Window) and sends the ACK packets together. The sender changes the sending speed according to the size of the window in the ACK packet.

Take a look at the diagram below, which shows the general process of TCP traffic control:

As shown in the figure above, host B, after receiving a packet with serial number 1-1000, sends an ACK to the sender and tells the sender that its window size is 3000, which means that the sender can send 3000 bytes of data. After receiving the instruction, host A continues to send data until host B receives data segment 3001-4000 and its receiving buffer is full. Host B’s return window size is 0, so host A wants to stop sending data.

This is a process that prevents the sender from sending too much data at once for the receiver to process.

Another question arises: when can the sender continue sending data after it has stopped sending it? After the receiver finishes processing the buffer and sends a packet notification for window updates, the sender can continue to send data according to the window size. However, if the sender does not receive the notification of window update within the retransmission timeout period or the window update package is lost, it cannot communicate normally, what can be done?

TCP has a persistence timer for each connection. As soon as one side of the TCP connection receives a zero window notification from the other, a persistent timer is started. If the duration of the timer expires, a zero window control data segment is sent (this data segment contains only one byte), and the party receiving this message segment resets the duration timer.

Therefore, the sender will periodically send a window detection data segment to the receiver in order to obtain the latest window size information.

In this way, the whole process of TCP flow control is completed.

Congestion control

What is congestion

We all know that resources in computer networks are limited. In a certain period of time, the demand for network resources exceeds the available part of the network, and the network performance deteriorates due to congestion. Generally speaking, too many packets are sent and the device on the network cannot process them, resulting in network performance deterioration.

Why does TCP perform congestion control

A router on a network has a packet processing queue. If the router receives too many packets and cannot process them all at once, the packet processing queue becomes too long. At this point, the router discards the newly received data packets unconditionally. In this case, the upper-layer TCP protocol retransmits the packets that are lost on the network, and the router discards the retransmitted packets. As a result, the network performance deteriorates sharply and the network breaks down. Therefore, TCP needs to control the number of packets sent to avoid the degradation of network performance.

Congestion control principle

With TCP’s sliding window control, even if no longer in a “segment” as a unit, but in a “window” as a unit to send confirmation reply signal, so the sending host can continuously send a large number of packets. However, if a large number of packets are sent at the beginning of the communication, the network can also crash.

In congestion control, the sender maintains a state variable called congestion window CWND (Congestion Window). The size of the congestion window depends on the level of congestion on the network and changes dynamically. The sending window is set to the minimum value of the congestion window and the receiving window to avoid sending data that is larger than the receiving window.

Congestion control uses two important algorithms: slow start algorithm and congestion avoidance algorithm.

(1) Slow start algorithm: The idea of slow start algorithm is not to send a large amount of data at the beginning, but to test the congestion degree of the network first, that is to say, gradually increase the size of the congestion window from small to large. In the slow algorithm, the CWND is doubled after each transmission turn. For example, the sender starts with CWND =1 (the number of segments is used as a unit of window size for ease of understanding) and then doubles the CWND with each transmission turn, e.g. 1, 2, 4, 8… Exponential growth So, slow start here does not mean that the congested window grows slowly, but rather that the data in the large window is transferred slowly in the first place.

Of course, the size of CWND cannot continue to grow exponentially, or it would soon grow to the point where the network would crash. So, after a certain period of time or conditions, we have to switch to congestion avoidance algorithm to send data.

(2) Congestion avoidance algorithm: Congestion avoidance algorithm also gradually increases the size of CWND, but adopts linear growth rather than exponential growth like slow start algorithm. In particular, the size of CWND is increased by one after each transfer turn. If network congestion is found, the ssTHRESH size is reset as described above (multiplication is reduced to 1/2) and the slow start algorithm is restarted from CWND =1.

Combination of slow start algorithm and congestion avoidance algorithm:

Q: How do slow start algorithms and congestion avoidance algorithms work together in congestion control?

As mentioned above, the size of CWND under the slow start algorithm increases exponentially, so CWND cannot be allowed to grow arbitrarily. Therefore, we introduce a slow start threshold (SSthRESH) to control the growth of CWND.

Ssthresh is used to:

  • When CWND < SSTHRESH, the slow start algorithm is used.
  • When CWND > SSTHRESH, congestion avoidance algorithm is used instead.
  • When CWND = SSTHRESH, slow start with congestion avoidance algorithm random

Another question is how is this SSthresh set up? TCP/IP specifies that ssthRESH should be set to half the size of the sending window (not less than 2) whenever congestion occurs in the network (no acknowledgement is received on time), no matter in the slow start or congestion avoidance phase.

As shown in the figure above, the general flow of congestion control is as follows:

  • Initially set ssTHRESH to 16, start slow start and add congestion window CWND until CWND =16 stops slow start and starts congestion avoidance algorithm.
  • Use the congestion avoidance algorithm to linearly increase CWND until CWND =24, when the network becomes congested (ACK confirmation signal does not arrive in time), set SSTHRESH to half of the original ssTHRESH =12, and set CWND to 1.
  • Restart the slow start until CWND reaches SSTHRESH =12, then execute the congestion avoidance algorithm for addition augmentation until network congestion is encountered, and tune SSTHRESH to one and a half of the original.
  • In this way, the CWND is calculated dynamically to achieve congestion control.

Fast retransmission VS timeout retransmission

The principle of TCP reliable transmission is timeout retransmission mechanism, and the retransmission mechanism has two kinds: timeout retransmission and fast retransmission

  • TCP timeout retransmission mechanism, combining with the above said slow start and congestion avoidance is used after sending the data to start the countdown, if within the retransmission timeout doesn’t receive an ACK from the receiver to perform the above process of multiplicative decrease (set sstresh half) and start slow start algorithm, to send data.

  • TCP fast retransmission allows the sender to perform the multiplication reduction process after receiving three consecutive repeated acknowledgements without waiting for the retransmission timeout period. This requires the receiver to send repeated acknowledgements as soon as it receives a segment that is out of order so that the sender can know that the segment is missing as soon as possible, rather than waiting for pickup acknowledgements when it sends data.

The schematic diagram of TCP fast retransmission is as follows:

As shown in the figure, the sender does not need to wait for the confirmation of each data segment before continuing to send, but sends data in A window unit. Therefore, even if the 1001-2000 serial number data segment sent by host A is lost, Host A will continue to send the remaining window size data, and host B finds that the 1001-2000 data is lost. Each time it receives A packet with another serial number, it returns an ACK with serial number 2000 to notify host A. When host A receives ACK with serial number 2000 for three times until it loses the 1001-2000 packet, it needs to retransmit the 1001-2000 packet. In order to achieve the purpose of fast retransmission even before the retransmission timeout period

Fast recovery

Fast recovery algorithm is used in conjunction with fast retransmission algorithm.

Fast recovery refers to the slow restart of the TCP timeout retransmission mechanism, in which the sender receives three repeated acknowledgments quickly and considers that the network is not congested. Therefore, in the multiplication reduction process (sSTRESH is set to half of the original), the “congestion avoidance” is started instead of the slow restart of the TCP timeout retransmission mechanism

conclusion

This article summarizes two important mechanisms of TCP for transport reliability:

  • Traffic control controls the sending speed of the sender so that the receiver can receive the packet in time, preventing packet loss.
  • Congestion control prevents excessive data from being injected into the network and prevents overload of routers or links on the network, resulting in data loss. This ensures the reliability of TCP transmission. With the addition of another article on how TCP reliability is guaranteed: sliding Windows, timeout retransmissions, and sequence number confirmation acknowledgments, the mechanism of TCP reliability is summarized.

Have a harvest?

If you get anything out of it

  • You can forward + like, so that more people can see this article, but also give me a big encouragement!
  • Pay attention to my original public account: code Nongfuge, focus on sharing back-end technology original dry goods articles

Get back to 1024 for a selection of back-end technology and architecture ebooks