Doing an operation in the company country, PM always complains that the access speed is too slow after going online, which affects the operation effect. However, from the front-end perspective, I have done the following optimizations: css, js merge compression, image compression, sprite images, and static resources are all on CDN. But it is still very slow. It is really confusing. Through the timeline analysis of chrome, it is found that some requests are really slow, but most of the time is spent in the stalled stage. As shown below:
The specific reasons are analyzed below.
What is stalled? Here's an easier-to-understand explanation:
Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation.Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome’s maximum six TCP connection per origin rule.
That is, the time difference between when the TCP connection is established and when the data can actually be transmitted. Let us first analyze why the TCP connection takes so long to be used? I used Wireshark to capture packets and found (as shown in the figure below) that there are multiple retransmissions during the TCP connection process, and the connection is reset by the client until the maximum number of retransmissions is reached.
Why does retransmission occur?
The sender waits for an ACK for the byte-range sent to the client and when not received, resends the packets, after a particular interval. After a certain number of retries, the host is considered to be “down” and the sender gives up and tears down the TCP connection.
After the TCP three-way handshake, after the sender sends the data, if it cannot receive the server ACK packet for a period of time (different operating systems have different time periods), it will re-send at a certain time interval (the time interval generally increases exponentially). The time from the start of retransmission to the correct response of the receiver is the stalled phase. If the retransmission exceeds a certain number of times (5 times in the Windows system), the sender considers that the TCP connection has been down and needs to re-establish the connection. Contrast the following, the http request process without retransmission. As shown below:
To sum up: the detection process of the TCP connection in the stalled stage, if the detection is successful, it will continue to use the TCP connection to send data, and if the detection fails, the TCP connection will be re-established. Therefore, the stalled stage is too long, which is often caused by packet loss, which also means that there is a problem with the network or server.