Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "which is faster to merge HTTP requests or parallel HTTP requests". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

HTTP request process

The main process of an HTTP request is:

DNS parsing (T1)-> establishing TCP connection (T2)-> sending request (T3)-> waiting for the server to return the first byte (TTFB) (T4)-> receiving data (T5).

As shown in the figure below, a HTTP request is shown in Chrome Devtools, showing the main phase of the HTTP request. Note that the Queueing phase is the time the request is queued in the browser queue and does not count the HTTP request time.

From this process, you can see that if you merge N HTTP requests into 1, you can save (NMMI 1) * (T1+T2+T3+T4) time.

However, the actual scenario is not so ideal, and there are several loopholes in the above analysis:

Browsers cache DNS information, so DNS parsing is not required for every request.

The keep-alive feature of HTTP 1.1 enables HTTP requests to reuse existing TCP connections, so not every HTTP request requires a new TCP connection.

Browsers can send multiple HTTP requests in parallel, which may also affect the download time of resources, and the above analysis is obviously based on a scenario where there is only one HTTP request at a time.

Experimental demonstration

Let's do four sets of experiments to compare the time it takes for one HTTP request to load the merged resource and the time it takes for multiple HTTP requests to load the split resource in parallel. There were significant differences in the size of the resources used in each group of experiments.

Experimental environment:

Server: Ali Cloud ECS 1 core 2GB memory bandwidth 1m

Web server: Nginx (Gzip not enabled)

Chrome v66 stealth mode, disable caching

Client network: wifi bandwidth 20m

Experiment 1

Test files: large1.css, large2.css... Large6.css, the size of each file is 846K, which is formed by merging the first six css files. Parallel-large.html quotes large1.css, large2.css... Large6.css, combined-large.html refers to large-6in1.css, and the code is as follows:

/ / parallel-large.html Parallel Large Hello, world! / / combined-large.html Combined Large Hello, world!

Refresh the two pages 10 times respectively, and use the Network of Devtools to calculate the average loading time of CSS resources.

Note:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Large1.css, large2.css... The loading time of large6.css is calculated from the time when the HTTP request for * * resources is sent to the time when all 6 files are downloaded, as shown in the red box in figure 2.

Two html pages cannot be loaded at the same time, otherwise the bandwidth is shared by the two pages, which will affect the test results. You need to wait for one page to load before manually refreshing and loading another page.

The interval between two refreshes of the page is more than 1 minute, in order to avoid the effect of HTTP 1.1 connection reuse on the experiment.

The experimental results are as follows:

Large-6in1.csslarge1.css, large2.css... Average large6.css time (s) 5.525.3

Let's put large1.css, large2.css... Large6.css is merged into three resources: large-2in1a.css, large-2in1b.css, large-2in1c.css, each of which is 282K. These three resources are referenced in combined-large-1.html:

/ / combined-large-1.html Parallel Large 1 Hello, world!

It was tested 10 times and the average loading time was 5.20s.

The experimental results are summarized as follows:

Large-6in1.csslarge1.css, large2.css... Large6.csslarge-2in1a.css 、... Average large-2in1c.css time (s) 5.525.305.20

As can be seen from the results of experiment 1, merging and splitting resources have no significant effect on the total loading time of resources. The least time-consuming situation in the experiment is splitting into three resources (5.2s), and the most time-consuming is merging into one resource (5.52s), but the difference between the two is only 6%. Considering the randomness of the experimental environment and the fact that the number of repeated experiments is only 10, this time difference can not represent the obvious time difference among the three scenarios.

Experiment 2

Continue to increase the css file size.

Test files: xlarge1.css, xlarge2.css, xlarge3.css, 1.7m each XlargeLay 3in1.css, merged from the previous three css files, the size is 5.1m. Parallel-xlarge.html references xlarge1.css, xlarge2.css, xlarge3.css, and combined-xlarge.html refers to xlarge-3in1.css.

The test process is the same as above, and the experimental results are as follows:

Average time of xlarge-3in1.cssxlarge1.css, xlarge2.css, xlarge3.css (s) 37.7236.88

The time difference in this group of experiments is only 2%, which is even smaller, so it is impossible to show that there is a significant difference in the total loading time between merging resources and splitting resources.

In fact, ideally, the time required for both resource loading methods will tend to be the same as the size of the resource becomes larger.

Theoretically, because the transmission channel of HTTP is based on TCP connection, while TCP connection has the characteristic of slow start, it does not make full use of the network bandwidth at the beginning, and gradually occupies the available bandwidth after the slow start process. For large resources, bandwidth will always be fully utilized, so bandwidth is the bottleneck, even if more TCP connections are used, it will not lead to speed improvement. The larger the resources, the smaller the proportion of slow startup to the total download time. Most of the time, the bandwidth is fully utilized, and the total amount of data is the same (the additional Header caused by splitting the resources can be ignored in this case), the bandwidth is the same, and the transmission time is of course the same.

Experiment 3

Reduce the css file size.

Test files: medium1.css, medium2.css... Medium6.css, with a size of 56.4K, is a combination of the first six css files, with a size of 9.4K per file. Parallel-medium.html quotes medium1.css, medium2.css... Medium6.css, combined-medium.html refers to medium-6in1.css.

The experimental results are as follows:

Medium-6in1.cssmedium1.css, medium2.css... Medium6.css mean time (ms) 34.8746.24

Notice that the unit becomes ms

The time difference of experiment 3 is 33%, although the numerical difference is only 12ms. Without much analysis, let's go on to experiment 4.

Experiment 4

Continue to reduce the css file size to tens of bytes.

Test files: small1.css, small2.css... Small6.css, the size of each file is 173B, which is formed by merging the first six css files. Parallel-medium.html quotes small1.css, small2.css... Small6.css, combined-medium.html refers to small-6in1.css.

The experimental results are as follows:

Small-6in1.csssmall1.css, small2.css... Small6.css mean time (ms) 20.3335

The time difference in experiment 4 was 72%.

According to experiment 3 and experiment 4, it is found that the loading time of merging resources and splitting resources is obviously different when the volume of resources is very small. Figures 3 and 4 are screenshots of a test result in experiment 4. When the size of the resource is small, the download time of the data (shown in the blue part of the horizontal column in the figure) accounts for a small proportion of the total time. The key factors that affect the loading time of the resource are DNS parsing (T1), TCP connection establishment (T2), sending request (T3) and waiting for the server to return the first byte (TTFB) (T4). However, the establishment of multiple HTTP connections at the same time itself has additional resource consumption, and the DNS query time of each HTTP and the establishment time of TCP connections also have certain randomness, which leads to a significant increase in the possibility of a HTTP time-consuming when resources are requested concurrently. As shown in figure 3, small1.css load time is the shortest (16ms), small5.css load time is the longest (32ms), the difference is double, but the calculation time is based on all resources have been loaded, in this case, using multiple HTTP requests at the same time will lead to greater time inhomogeneity and uncertainty, the result is often slower than using a HTTP request to load merged resources.

A more complex situation

Must it be faster to merge resources for small files?

In fact, not necessarily, in some cases, merging small files may significantly increase the resource loading time.

Tell me more about the theory. In order to improve the transmission efficiency, the sender does not have to wait until the receiver receives the acknowledgement reply (ACK) before sending the next message every time the sender sends a packet. TCP introduces the concept of "window". The window size refers to the * value that can continue to send data without waiting for an acknowledgement reply. For example, the window size is 4 MSS (the * data segments that Maximum Segment Size,TCP packets can transmit at a time), indicating that four consecutive segments can be sent without waiting for an acknowledgment from the receiver, that is, The transmission of four message segments was completed in one network round trip (round-trip). As shown in the following figure (MSS is 1, window size is 4), 1-4000 data is sent continuously without waiting for a confirmation reply, and similarly, 4001-8000 is also sent continuously. Please note that this is just an ideal schematic diagram, and the actual situation is more complicated than here.

In the slow start phase, TCP maintains a congestion window variable, which is equal to the size of the congestion window. In the slow start phase, the size of the congestion window doubles with each network round trip. For example, suppose the initial size of the congestion window is 1, and the size of the congestion window changes to: 1, 2, 4, 8. This is shown in the following figure.

In the actual network, the initial value of the congestion window is generally 10, so the size of the congestion window changes as follows: 10, 20, and 40. The value of MSS depends on the network topology and hardware equipment. The MSS value in Ethernet is generally 1460 bytes, and the data size transmitted by each message segment is equal to MSS calculation (the actual situation can be less than MSS value). After the first network round trip, the transmitted * * data is 14.6K. After the second time, it was (102.20) 1.46 = 43.8K, and after the third time, it was (10202040) 1.46 = 102.2K.

According to the above theoretical introduction, in experiment 4, no matter merging resources or splitting resources, they are all transmitted in one network round trip. However, in experiment 3, the split resource size is 9.4K, which can be transferred in one network round trip, while the merged resource size is 56.4K, which requires three network round trips to complete the transmission. If the network delay is very large (for example, 1s), the bandwidth is not the bottleneck, and two more network round trips will lead to an increase of 1s in time, so the loss of merging resources may outweigh the gain. The reason why experiment 3 did not produce this result is that the network delay in the experiment is about 10ms, which is too small to have a significant impact on the results.

This is the end of "which is faster to merge HTTP requests or parallel HTTP requests". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.