TCP reliable transmission, flow control, congestion control, the essence of TCP is all here

  [[334785]]

Table of contents

• Packet capture process and TCP packet header
• Reliable transmission
• The concept of window leads to the receiving window rwnd and the sending window cwnd
• Flow control example to illustrate the specific TCP flow control process
• Congestion control Slow start and congestion avoidance algorithms Fast retransmission and fast recovery algorithms
• The difference between flow control and congestion control

Packet capture process and TCP packet header

Wireshark is used to capture packets. The two most commonly used curl and ping commands are used to demonstrate the packet capture situation and start packet capture.

 ## First visit my own website homepage
 curl https://zengzhiqin.kuaizhan.com
 ## Check the address of my own website again
 ping https://zengzhiqin.kuaizhan.com

Wireshark performs conditional filtering based on the address obtained by the ping command, and obtains the packets obtained by the above two commands, mainly TCP (https is based on the TCP protocol) and ICMP (ping command is based on the ICMP protocol) protocol packets, as shown in the following figure:

Packet capture analysis

TCP header data one-to-one correspondence

TCP Header

Reliable transmission

TCP implements four methods for reliable transmission:

• check
• Serial number
• confirm
• Retransmission

The first and second mechanisms are explained in detail in another article on my official account. Here I will mainly talk about the third and fourth mechanisms.

The purpose of reliable transmission is to ensure that all data sent by the sender can be received completely and in order by the receiver.

Just like Miyamoto Musashi's motto "Line up, one by one", use the dumbest method to solve the most difficult problem. Since you want to be reliable, then confirm one by one. As long as you don't tell me that you have received it, then I will keep resending it.

How reliable transport works: the stop-and-wait protocol

Reliable and unreliable solutions

I divided it into four pictures. The vertical line represents the timeline. RTT represents the round-trip time for the data packet to be sent and the confirmation packet to be sent back. They are analyzed in the case of "no error, hello, me, and everyone is ok", "send timeout or failure", "confirmation timeout" and "confirmation loss". Through this confirmation and retransmission mechanism, TCP can achieve reliable transmission, which is the implementation method of points 3 and 4. One thing you need to know is that the retransmission action is a spontaneous behavior of the sender, and the receiver does not need to notify it to retransmit.

Introduction of the concept of window

The above method is really good. It uses the simplest method to solve the problem of reliable transmission. However, the network is so busy all the time. I wait for you to confirm that Miyamoto Musashi's big move will be thrown out and landed one section at a time. It's too late.

The biggest problem with the above stop-and-wait protocol is that the channel utilization is too low.

Stop waiting for transmission

The RTT time is determined by the network conditions and cannot be saved. T2 is generally fixed. From the formula, we can see that if we want to improve the channel utilization, we can only start with T1.

Pipeline transmission

The sender can send multiple packets continuously without stopping each time to wait for confirmation before continuing. The TCP window is the origin of the continuous sending of these packets, as shown in the following figure:

Sliding Window

Since you as the sender can use window technology in order to avoid sending packets one by one, then I as the receiver must also learn it, that is, not to confirm one by one, but to accumulate confirmations instead.

Receiver cumulative confirmation method

Receive window rwnd and send window cwnd

There are two windows involved here:

The receiver window (rwnd) is the size of the receive buffer value set by the receiver according to its own capacity. It reflects the receiver's receiving capacity and is used for flow control.

The congestion window (cwnd) is the network window value set by the sender according to the degree of network congestion. The sending window = min (rwnd, cwnd), which is the minimum value of the receiving window and the congestion window, is used for congestion control.

The window data structure is as follows:

Window data structure

In fact, something that seems so profound is actually so simple when you think about it step by step. I can only sigh, "Ah, smart humans" (just being naughty, hahaha).

Flow Control

It was mentioned above that the utilization rate of the channel can be increased through the window. Then how to set the size of the window, how big to set it, and what else can the window be used for?

If the sender sends too fast, the receiver will not have time to receive it and the packet will be lost. This is definitely not okay. If someone sends me a lot of red packets, I don’t want to lose even one.

Segmented transmission

The purpose of flow control is to allow the sender to dynamically adjust the sending frequency according to the network conditions so that the receiver can receive the message in time.

TCP uses a sliding window mechanism to implement flow control. The sender's send window changes dynamically, depending on the window size of the segment returned by the receiver, which may be a data segment or an acknowledgment message, because the TCP packet header has window information. Let's take a look at the window data in this picture:

Let's take an example to illustrate the specific TCP flow control process.

Host A sends data to host B. When establishing a connection, host B tells A: "Brother, my rwnd = 400 bytes". Assuming that each segment is 100 bytes and the initial sequence number is 1, the three-way flow control communication process is as follows:

Let's take an example to illustrate the specific TCP flow control process.

In this figure, rwnd=0 at the end. This situation continues until the receiver vacates a new receiving buffer. Then B will actively send his new rwnd to A. When the 0 window notification is received, A will wait for the receiver's new rwnd notification. In order to prevent the new rwnd from being lost, many previous articles have analyzed this situation. In order to solve the problem of packet timeout and failure to receive confirmation, a retransmission is set after a period of waiting. The four-wave process is set to wait for 2MSL time before the sender closes. These times are all counted by setting timers to solve the deadlock caused by packet loss. Similarly, in order to solve the deadlock caused by the loss of new rwnd, the sender will start the timer as long as it receives the 0 window notification. If the time is up, it will resend a 0 window detection message, and the receiver will reply to the current receiving window.

Crazy Trial

Congestion Control

The best network time in my neighborhood is 3-6 p.m., 10-12 a.m., and 3-5 p.m. These are the times when I play King of Glory most smoothly. During the network peak hours from 8 p.m. to 11 p.m., I would come to my senses and stand at the fountain every time I got stuck (really happy).

Imagine that the network is already bad, and you pour so many data packets into the network at once. All the packets time out, and then they are resent when the timeout comes. This vicious cycle makes the already poor network even worse. Therefore, TCP needs to learn to be smart and perform congestion control. The purpose of congestion control is to prevent too much data from being injected into the network, which will cause the network to be blocked and prevent the packets from reaching the receiving end.

The role of congestion control

There are four congestion control algorithms:

1. Slow Start
2. Congestion Avoidance
3. Fast Retransmission
4. Fast recovery

Slow start and congestion avoidance algorithms

Slow start and congestion avoidance algorithms

A transmission round refers to the time RTT from sending a batch of segments to receiving confirmation.

Slow start is exponential growth, and it keeps testing the network status. If it is healthy, it will keep growing exponentially. When the ssthresh value is reached, this is the slow start round limit, and it starts to grow linearly. If it keeps growing until the network is congested, it will drop off a cliff overnight and return to the pre-liberation period. Starting from 1, the new ssthresh value is lowered to half of the original congestion value and starts to grow exponentially again, and it changes dynamically like this.

Fast retransmission and fast recovery algorithms

Fast retransmission and fast recovery algorithms

From the figure, we can see that the front part of this algorithm is consistent with the slow start congestion avoidance algorithm. The main thing is to adjust the cliff-like reduction of the sending rate. Starting from 0 is too inefficient. If a boyfriend and girlfriend are sending WeChat messages, they will be tormented.

The congestion window cwnd increases exponentially each time when a confirmation message is received. For example, A sends segments 1, 23, 4, 5, and 6, and segment 2 is lost. 1345 are all received. So every time segment 345 is received, a confirmation message confirming the receipt of segment 1 is sent to A, asking him to send segment 2 (this was mentioned in the previous article). This algorithm is to retransmit segment 2 immediately after receiving three confirmations before the timeout timer of segment 2 expires. The receiver is urging for more, and the arrival of the next three confirmation packets indicates that the network is strong, which means you are lost. Therefore, fast retransmission is performed or the new ssthresh value is lowered to half of the original congestion value and starts exponential growth again. This is generally used now. The above method is eliminated because it is too inefficient.

The difference between flow control and congestion control

Traffic control is a point-to-point problem, one-to-one. If the receiver's data is not received in time, then the sender can be directly found as the culprit, mainly because the receiver is not able to receive the sender's data in time;

Congestion control is many-to-one. When one receiver encounters network congestion on multiple senders, the receiver cannot find the specific sender, mainly because the network is congested and the sender's data is delayed in reaching the receiver.

To put it simply, congestion control means traffic jams on the road, and flow control means insufficient parking spaces in parking lots.

I have been writing this article for several days. I feel that there are a lot of conceptual things. I have tried my best to write it in a chatty and relaxed tone. It rained in Beijing today. The trees on both sides of Wudaokou were lush and green. I looked up and saw the leaves tearing the sky into pieces. Mao Buyi's low and sexy voice sang "Along the Mountain Journey" in my headphones. I walked in the heart of this city with an umbrella, looking forward to the future.