This article is taken from my public account [Sun Wukong, Don’t talk nonsense]

Following on from the TCP three-way handshake, what are the possible communication problems that occur when the frog and turtle start chatting?

matting

In the previous article, we mentioned “sending capability” and “receiving capability.” In terms of these two abilities, the previous article talked about how to determine whether the other person has these abilities during the handshake.

However, in the process of communication, the two abilities need to be quantitatively divided. For example: A has the ability to send 60 units at A time; B has the ability to send, it can send 10 units at a time.

In the process of communication, there is a need for media (for example, between people to speak, need air as a medium; You can’t have a conversation in a vacuum. The medium has the ability to transmit, and there are quantitative divisions (for example, sound travels more slowly in water than in air).

For the sake of simplicity, there are two points:

  1. In our Story, the medium is a conduit.
  2. The units of transmit, receive, and transmit capabilities are not static, they change in real time.

With that in mind, let’s take a look at the possible communication problems encountered by the “little Frog” and “little Turtle” in Story mode.

Story mode

Greater than the reception capacity of the other party

In the process of communication, everyone’s receptivity is different. This leads to a common communication problem: the sender’s sending unit is greater than the receiver’s receiving capacity. The diagram below:

In the figure above, the little Frog has a receiving capacity of 40 units, the Little Turtle has a sending capacity of 100 units, and the pipe has a transmission capacity of 1,000 units. At this point, “little Turtle” sent a 100 unit to “little Frog”, at this time the size of the send is too big for “little Frog” to receive.

What should I do when I meet this problem?

It’s easy to do — try to dynamically inform each other of your current receiving capacity when transmitting data.

In TCP transmission, the solution to this situation is called “flow control.” For this, the following sections will be technical. Now continue our Story mode.

There is not enough pipeline capacity

Suppose the frog and the turtle have agreed to a resolution of the above minor disagreement, sending each other as much data as the other can accept each time. But there are still problems:

In the process of communication between the two, there is the existence of transmission medium (pipeline). The transmission capacity of the pipeline is uncertain and may be smaller than the agreed size of the transmission unit. The diagram below:

In the diagram above, the frog receives 120 units of data and the turtle sends 100 units of data, and they have agreed to send 90 units of data. However, the pipeline transmission capacity at this time is only 50 units, and the communication at this time is not successful.

What should I do when I encounter this problem?

In TCP transmission, the solution to this situation is called “slow start.” The technical details will not be discussed here, but the solution is to try to transfer data from a very small unit value at the beginning, since it is not clear what real-time piped capacity is. Later in the transmission process, the unit value of transmitted data is gradually doubled. In the event of failure, immediately reduce the transfer unit value.

Technical description of TCP blocking

End of Story mode. Now analyze the detailed process of flow control and slow start from a technical point of view.

Flow control

Traffic control is a mechanism to prevent the sender from sending too much data to the receiver. Otherwise, the receiver may not be able to process because it is busy, overloaded, or buffered. For flow control, each side of a TCP connection advertises its own receive window (RWND), which contains information about the size of the buffer space that can hold data. The details are as follows:

The reception window (RWND) here is the unit value of reception capability mentioned in the Story.

Note that when the connection is first established, both ends send RWND using their system’s default Settings. This means that, in some cases, we can consider trying to optimize Web network performance by changing the RWND value of the system.

Slow start scheme

Despite TCP’s flow control mechanisms, congestion crashes still surfaced in the mid-to-late 1980s. Flow control does prevent the sender from sending too much data to the receiver, but there is no mechanism to prevent either end from sending too much data to the underlying network (the pipes in the Story). In other words, neither the sender nor the receiver knows what bandwidth is available when the connection is established, so an estimation mechanism is needed and then the speed has to change dynamically in response to changing conditions in the network.

The idea behind slow starts is that the server initializes a new congestion window (CWND) variable over a TCP connection, setting its value to a system-set conservative value (initcwnd in Linux).

Congestion window size (CWND) : Limit on the amount of data a sender can send before receiving an ACK from a client.Copy the code

The CWND variable here can be understood as the transport capacity of the pipes in the Story.

A rule runs through the slow start process: the maximum amount of data that can be transferred between the client and server (without ACK confirmation) is the minimum value of RWND and CWND variables. This rule is translated into the Story: the transmission unit between “little frog” and “little turtle” takes the minimum of each other’s receiving capacity units and pipeline transmission capacity.

The sender does not advertise the CWND variable, that is, the sender and the receiver do not exchange this value, and the CWND variable is the sender’s private variable. So how do the server and client determine the optimal value for the congestion window size? After all, the state of the network is changing all the time. It would be nice if the window size for each connection could be determined algorithmically rather than manually.

The solution is slow start, that is, increase the window size after the group is confirmed, and start slowly! See the diagram below:

Initially, the value of CWND was only one TCP segment. In April 1999, RFC 2581 increased this to four TCP segments. In April 2013, RFC 6928 increased this again to 10 TCP segments.

The maximum amount of data transferred by a new TCP connection is the minimum between RWND and CWND. The server can actually send four TCP segments to the client (referring to RFC 2581 for this number) and then must stop for confirmation. After that, for each ACK received, the slow-start algorithm tells the server that it can add one TCP segment to its CWND window. Each time you receive an ACK, you can send two more packets. This stage of a TCP connection is often referred to as the “exponential growth” stage (as shown above), because both the client and the server are rapidly converging towards the effective bandwidth of the network path between them.

Why is it so important to know that we have a slow start when building browser applications? Because many application layer protocols, including HTTP, run on top of TCP, every TCP connection must go through a slow start phase, regardless of bandwidth. In other words, we can’t use the maximum bandwidth of the connection right away!

Instead, we start with a relatively small window of congestion and double it (exponentially) with each round trip.

Slow start Restart

In addition to adjusting the transmission speed of new connections, TCP also implements the SLOW-start Restart (SSR) mechanism. This mechanism resets the connection’s congestion window after the connection has been idle for a certain amount of time. Simply because network conditions may change at the same time as the connection is idle, you should reset the congestion window back to a “safe” default to avoid congestion.

There is no doubt that SSR can have a significant impact on long-cycle TCP connections that are suddenly idle, such as HTTP keep-alive connections.

Optimization Suggestions

Disable the SSR

As mentioned in the previous section, SSR can have a significant impact on long-cycle TCP connections that are suddenly idle, such as HTTP keep-alive connections. Therefore, we recommend that SSR be disabled on the server.

Increases the initial blocking window

The problem of a slow start causing the client and server to take hundreds of ms to reach near maximum speed is not significant for large streaming services, because the slow start time can be spread over the entire transmission cycle.

However, for many HTTP connections, especially those that are transient and burst, it is common to terminate before the maximum window request is reached. In other words, the performance of many Web applications is often constrained by round-trip times between the server and the client. This is because slow starts limit the throughput available, which is detrimental for small file transfers.

At this point, consider increasing TCP’s initial congestion window.

A larger initial congestion window allows TCP to transfer more data on the first round trip, and the subsequent speed increase is significant. This is also a particularly critical optimization for sudden ephemeral connections.

conclusion

Tuning TCP performance enables maximum throughput and minimum latency between the server and client. In conjunction with the previous TCP three-way handshake article, we have briefly covered some of the optimization details on TCP.

Of course, faster performance optimization is an issue worth considering, and how our application establishes or uses TCP connections is another:

• Fast isn’t fast don’t send anything, send as little as you can (eliminate unnecessary data transfers).

• We can’t make data travel faster, but we can make them travel shorter distances (CDN).

Front-end performance optimization series:

(a) : start with the TCP three-way handshake

(two) : for the blocking of TCP transmission process

(3) : optimization of HTTP protocol

(IV) picture optimization

(v) : browser cache strategy

(vi) : How does the browser work?

(vii) : Webpack performance optimization