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

This article introduces the knowledge of "how to optimize high-performance Nginx HTTPS to speed up HTTPS by 30%". In the operation of practical 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!

Why optimize Ngin HTTPS latency

Nginx is often used as the most common server, often used as load balancing (Load Balancer), reverse proxy (Reverse Proxy), gateway (Gateway), and so on. A properly configured Nginx server stand-alone should be able to expect to withstand requests of about 50K to 80K per second while keeping the CPU load within a controllable range.

But in many cases, load is not the primary focus of optimization. For example, for Carla search, we want users to experience the feeling of instant search every time they hit a keystroke, that is, each search request must be returned to the user end-to-end within the 100ms-200ms time, so that the user can search without "stutter" and "load". Therefore, for us, optimizing request delay is the most important optimization direction. Treasure Book of 2021Java interview

In this article, we first introduce what TLS settings in Nginx may be related to request latency and how to adjust them to maximize acceleration. Then we use an example of optimizing Carla's search Nginx server to share how to adjust Nginx TLS/SSL settings to speed up first-time search users by about 30%. We will discuss in detail what optimizations we have done at each step, the motivation and effectiveness of the optimizations. I hope I can provide help to other students who encounter similar problems.

As usual, the Nginx settings file in this article is placed in github. You are welcome to use it directly: high-performance Nginx HTTPS tuning (https://github.com/Kalasearch/high-performance-nginx-tls-tuning))

TLS handshake and delay

Many times developers will think that it is not necessary to understand the underlying and more detailed optimizations if they are not absolutely concerned about performance. This sentence is appropriate in many cases, because in many cases, the complex underlying logic must be wrapped in order to make the complexity of higher-level application development controllable. For example, if you just need to develop an APP or website, it may not be necessary to pay attention to the assembly details and how the compiler optimizes your code-after all, many optimizations on Apple or Android are done at the bottom.

So what does understanding the underlying TLS have to do with Nginx latency optimization at the application layer?

The answer is that in most cases, optimizing network latency is actually an attempt to reduce the number of data transfers between the user and the server, also known as roundtrip. Due to physical limitations, the speed of light from Beijing to Yunnan is about 20 milliseconds. If you accidentally make the data have to travel back and forth between Beijing and Yunnan many times, it is bound to be delayed.

So if you need to optimize request latency, it's helpful to know a little bit about the context of the underlying network, and in many cases it's even the key to whether you can easily understand an optimization. We won't delve into too many details of TCP or TLS mechanisms in this article, so please refer to High Performance Browser Networking if you are interested.

For example, the following figure shows what happens before you start to transfer any data if your service has HTTPS enabled.

You can see that before your user gets the data he needs, the underlying packet has already run three times back and forth between the user and your server.

Assuming that it takes 28 milliseconds for each round trip, the user has waited 224 milliseconds before starting to receive data.

At the same time, this 28 millisecond is actually a very optimistic assumption, in the domestic telecom, Unicom and mobile, as well as a variety of complex network conditions, the delay between the user and the server is even more uncontrollable. On the other hand, a web page usually requires dozens of requests, and these requests may not all be parallel, so dozens multiplied by 224 milliseconds, the page may be opened in a few seconds.

So, in principle, if possible, we need to minimize the round trip (roundtrip) between the user and the server, and in the following settings, we will discuss why this setting may help reduce round trips.

TLS settings in Nginx

So in Nginx settings, how do you adjust the parameters to reduce latency?

Turn on HTTP/2

The HTTP/2 standard is an improvement from Google's SPDY, which provides a significant performance improvement over HTTP 1.1, especially when multiple requests need to be parallel. On today's web, a web page needs dozens of requests on average. In the era of HTTP 1.1, what browsers can do is to open a few more connections (usually 6) to make parallel requests, while in HTTP 2, parallel requests can be made in one connection. HTTP 2 natively supports multiple parallel requests, so the round trip for sequentially executed requests is greatly reduced, and opening can be considered first.

If you want to see for yourself the speed difference between HTTP 1.1 and HTTP 2.0, you can try it: https://www.httpvshttps.com/. My network tests show that HTTP/2 is 66% faster than HTTP 1.1.

Turning on HTTP 2.0 in Nginx is very simple, you only need to add a http2 flag.

Listen 443 ssl;# changed to listen 443 ssl http2

If you're worried that your user is using an old client, such as Python's requests, and doesn't support HTTP 2 yet, don't worry. If the user's client does not support HTTP 2, the connection is automatically downgraded to HTTP 1.1, maintaining backward compatibility. As a result, all users using the old Client remain unaffected, while the new clients can enjoy the new features of HTTP/2.

How to confirm that your website or API has HTTP 2 enabled

Open the developer tool in Chrome and click Protocol to see the protocol used in all requests. If the value of protocol column is h3, then HTTP 2 is used.

Of course, another way is to directly use curl if there is a HTTP/2 before the returned status, that is, HTTP/2 is enabled.

➜~ curl-- http2-I https://kalasearch.cnHTTP/2 403server: Tenginecontent-type: application/xmlcontent-length: 264date: Tue, 22 Dec 2020 18:38:46 GMTx-oss-request-id: 5FE23D363ADDB93430197043x-oss-cdn-auth: successx-oss-server-time: 0x-alicdn-da-ups-status: endOs,0403via: cache13.l2et2 [148J. 0], cache10.l2ot7 [291J 0], cache4.us13 [360J 0] timing-allow-origin: * eagleid: 2ff6169816086623266688093e adjust Cipher priority

Try to pick a Cipher that updates faster to help reduce latency:

# manually enable cipher list ssl_prefer_server_ciphers on; # prefer a list of ciphers to prevent old and slow ciphersssl_ciphers' EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; enable OCSP Stapling

In China, this is probably the delay optimization that has the greatest impact on services or websites that use Let's Encrypt certificates. If OCSP Stapling is not enabled, it is sometimes necessary to verify the certificate when the user connects to your server. Because of some unknown reasons (this is not to put it bluntly), the authentication server of Let's Encrypt is not very smooth, so it can cause the problem of delay of several seconds or even more than ten seconds sometimes. This problem is particularly serious on iOS devices.

There are two ways to solve this problem:

Instead of using Let's Encrypt, you can try to replace the free DV certificate provided by Aliyun.

Turn on OCSP Stapling

If OCSP Stapling is enabled, the step of certificate verification can be omitted. Saving a roundtrip, especially a roundtrip with uncontrollable network conditions, may greatly reduce your latency.

Enabling OCSP Stapling in Nginx is also very simple, simply by setting:

How does ssl_stapling on;ssl_stapling_verify on;ssl_trusted_certificate / path/to/full_chain.pem; detect if OCSP Stapling is turned on?

You can use the following command

Openssl s_client-connect test.kalasearch.cn:443-servername kalasearch.cn-status-tlsextdebug

& 1 | grep-I "OCSP response"

To test. If the result is

OCSP response:OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response

Indicates that it has been turned on. Refer to the article about the slowness of HTTPS on iPhone

Adjust ssl_buffer_size

Sslbuffersize controls the buffer size when sending data, and the default setting is 16k. The smaller the value, the smaller the delay, while adding headers and the like makes the overhead larger, and vice versa, the greater the delay, the smaller the overhead.

So if your service is REST API or website, reducing this value will reduce latency and TTFB, but if your server is used to transfer large files, it can maintain 16k. For a discussion of this value and the more general TLS Record Size, please refer to: Best value for nginx's sslbuffersize option

If it is a website or REST API, the recommended value is 4k, but the best value for this value will obviously vary from data to data, so try a different value between 2 and 16k. It is also very easy to adjust this value in Nginx

Ssl_buffer_size 4k; enable SSL Session caching

Enabling SSL Session caching can greatly reduce the repeated validation of TLS and the roundtrip of TLS handshakes. Although session caching takes up some memory, 4000 connections can be cached with 1m of memory, which can be said to be very cost-effective. At the same time, for the vast majority of websites and services, reaching 4000 simultaneous connections itself requires a very large user base, so you can rest assured to open it.

Here ssl_session_cache is set to use 50 megabytes of memory and 4 hours of connection timeout closing time ssl_session_timeout

# Enable SSL cache to speed up for return visitorsssl_session_cache shared:SSL:50m; # speed up first time. 1m ~ = 4000 connectionsssl_session_timeout 4h; how to reduce request delay by 30% in Carla search

Carla search is a domestic Algolia, which is committed to helping developers build instant search function (instant search) quickly and make it the fastest and most easy-to-use search-as-a-service in China.

After the developer accesses, all search requests can be directly returned to the end user through Carla API. In order to give users an instant search experience, we need to return the results to the user in a very short time after each keystroke (usually from 100ms to 200ms). Therefore, each search requires less than 50 milliseconds of engine processing time and less than 200 milliseconds of end-to-end time.

We have made a movie search Demo with Douban movie data. If you are interested, you are welcome to experience instant search. Try searching "Infernal Affairs" or "A Chinese Odyssey" to experience speed and relevance: https://movies-demo.kalasearch.cn/

For a delay budget of only 100 to 200 milliseconds per request, we must take into account the delay of each step.

To simplify, the delays experienced by each search request are

Total delay = user request arriving at server (T1) + inverse processing (Nginx T2) + data center latency (T3) + server processing (Kara engine T4) + user request return (T3+T1)

In the above delay, T1 is only related to the physical distance between the user and the server, while T3 is very small (reference Jeff Dean Numbe) is negligible.

So the only things we can control are T2 and T4, that is, the processing time of the Nginx server and the engine processing time of Carla.

Nginx acts as a reverse proxy here, dealing with some security, flow control, and TLS logic, while Carla's engine is an inverted engine based on Lucene.

The first possibility we consider is: does the delay come from the Carla engine?

In the Grafana dashboard shown in the figure below, we see that, except for a few slow queries from time to time, the server processing latency of 95% of the searches is less than 20 milliseconds. Compared with the same data set, the P95 search delay of benchmark's Elastic Search engine is about 200ms, so the possibility of slow engine speed is ruled out.

In Aliyun Monitoring, we set up to send search requests to Carla servers from all over the country. We finally found that the SSL processing time is often more than 300ms, that is, in the T2 step, just dealing with TLS handshakes and other things, Nginx has used up all our request time budget.

At the same time, after checking, we found that the search speed on Apple devices was particularly slow, especially on devices visited for the first time. Therefore, our general judgment should be due to the problem of the Let's Encrypt certificate we use.

We followed the steps above to adjust the Nginx settings and summarized the steps to write this article. After adjusting the Nginx TLS setting, the SSL time has been reduced from the average 140ms to about 110ms (China Unicom and mobile test sites), and the problem of slow first access on Apple devices has disappeared.

After the adjustment, the search delay tested nationwide has been reduced to about 150 milliseconds.

That's all for "how to improve the speed of HTTPS by 30% with high-performance Nginx HTTPS tuning". 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.