Http3 / quic performance test and supporting components


Http3 / quic performance test and supporting components


In recent years, many articles about quic have been published, but a problem has been found. These articles are introducing what quic or http3 is, as well as its advantages and mechanisms, and boasting it to the sky. However, it is estimated that people who are interested in doing some tests will find that the performance of this highly praised thing is actually not as good as http1 1. What’s going on?

Recently, I have been working on quic or http3. I have been writing such an article to give a disguised answer to people who have the same questions as me.


The test is very simple. It is divided into two machines, both in the same LAN. The server uses the quic branch version of nginx, nginx quic. The client uses h2load (supporting http3 version) as the benchmark tool. At the server, NETEM module is used to manipulate the network conditions and simulate different network environments. The request has no request body, and the response body is the nginx default 612 byte home page file. Let’s take a brief look at the test results:

The parameters of h2load are as follows: – t 10 – C 100 – N 1000 – M 100, that is, 10 threads, 100 connections and 1000 requests. Each connection can process 100 requests at the same time.

HTTP version delay Packet loss rate Repetition rate Packet damage rate result
HTTP1.1 The total time is 406.49ms, 24601.15 req / s QPS, and 21.30mb/s transmission per second
HTTP3 The total time is 611.90ms, 16342.59 req / s QPS, and 12.98mb/s transmission per second
HTTP1.1 100ms+-10 The total time is 1.90s, 5275.52 req / s QPS, and 4.57mb/s transmission per second
HTTP3 100ms+-10 The total time is 3.65ms, 2740.22 req / s QPS, and 2.18mb/s transmission per second
HTTP1.1 30% The total time is 33.64s, 297.28 req / s QPS, 263.60kb/s transmission per second
HTTP3 30% Total time: 19.82s, 504.45 req / s, QPS, 447.31kb/s, transmission per second
HTTP1.1 70% The total time is 443.55ms, 23065.39 req / s QPS, and 19.97mb/s transmission per second
HTTP3 70% The total time is 419.98ms, 23810.43 req / s QPS, and 18.92mb/s transmission per second
HTTP1.1 20% The total time is 14.46s, 691.61 req / s QPS, 613.27kb/s transmission per second
HTTP3 20% The total time is 4.12s, 2424.55 req / s QPS, and 1.93mb/s transmission per second
HTTP1.1 100ms+-10 30% Total time: 30.64s, 326.42req/s, QPS, 289.44kb/s, transmission per second
HTTP3 100ms+-10 30% The total time is 17.16s, 582.89 req / s QPS, 474.19kb/s transmission per second
HTTP1.1 30% 70% The total time is 2.03s, 4914.90 req / s QPS, and 4.26mb/s transmission per second
HTTP3 30% 70% The total time is 3.06s, 3264.89 req / s QPS, and 2.59mb/s transmission per second
HTTP1.1 30% 20% Slow to no result
HTTP3 30% 20% Total time: 15.09s, 662.75req/s, QPS, 539.16kb/s, transmission per second

In this test result, I give typical values. Of course, I have resized these values to see the results. From this result, we can see the following conclusions:

  1. Increasing the delay alone will not lead to the performance of http3 better than http1 1.
  2. The increase of packet loss rate will make http3 to http1 The performance advantages of 1 are significantly increased.
  3. Improve packet repetition rate separately http3 vs. http1 1 has only a slight advantage in performance.
  4. Increasing the packet damage rate alone will significantly improve the impact of http3 on http1 1 performance advantages.
  5. Delays and other factors will not have a greater impact on the overall results.
  6. Packet repetition rate and packet damage rate (or packet loss rate) are a pair of items. Packet loss or damage leads to the reduction of available packets, but the repetition rate makes up for this loss, resulting in a tendency towards http1 1 better.

From the above conclusions, we can see that http3 is not better than http1 at any time 1. However, for weak networks with high packet loss rate and packet loss, quic or http3 has obvious advantages, thanks to its FEC mechanism and connection multiplexing mechanism. However, in life, there are many weak network environments, such as subway stations, elevators, some buildings, and some towns with incomplete network coverage. Therefore, quic is more of a strategy for the overall network.

Therefore, it is unwise to upgrade all requests to HTTP 3 version using the default configuration of nginx quic, because normally HTTP 1.0 The performance advantage of 1 is invisible. This introduces the components in the next section.


From the above conclusion, we find that it is not wise to upgrade every request, so we have this nginx module to automatically control the version upgrade——ngx_http_autoquic_module

This module will decide whether to upgrade the HTTP version to the http3 version according to the network status of TCP. Judge whether to downgrade to http1 according to the statistics of quic Version 1. Since the downgrade is not as smooth as the upgrade, a switch is added to the downgrade so that the user can choose whether to allow the downgrade.

At present, for browsers, it can well support up and down levels. However, for many clients, whether to upgrade or downgrade depends on the processing logic of the HTTP library used by the client.

Thank you for reading and look forward to your comments.