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

This article is to share with you about the impact of HTTPS on performance. Xiaobian thinks it is quite practical, so share it with you to learn. I hope you can gain something after reading this article. Let's not say much. Let's take a look at it together with Xiaobian.

HTTPS Impact on Performance

preface

HTTPS plays a critical role in protecting user privacy and preventing traffic hijacking, but at the same time, HTTPS also slows down user access and increases the computing resource consumption of website servers.

This article focuses on the impact of https on the user experience.

HTTPS impact on access speed

Before we talk about speed optimization strategies, let's take a look at how HTTPS affects speed. The impact mainly comes from two aspects:

The network RTT(round trip time) added by protocol interaction.

Encryption and decryption are computationally time-consuming.

Let's introduce them separately below.

Increased network time

Since HTTP and HTTPS both require DNS resolution and use DNS caching in most cases, the DNS resolution time of the primary domain name is ignored for comparison purposes.

When users visit http://www.baidu.com(or www.baidu.com) using HTTP protocol, they will have the following interaction time on the network:

Figure 1: Network Time for HTTP First Request

It can be seen that users only need to complete the TCP three-way handshake to establish a TCP connection to directly send HTTP requests to obtain application layer data. In addition, there is no need to consume computing resources during the entire access process.

Next, look at the HTTPS access process, which is much more complicated than HTTP. In some scenarios, using HTTPS access may increase 7 RTTs. As shown below:

Figure 2: The impact of HTTPS first-time requests on access speed

The network time required for an HTTPS first request is explained as follows:

Three-way handshake establishes TCP connection. It takes one RTT.

Use HTTP to initiate a GET request, and the server returns 302 to jump to https://www.example.com. www.baidu.com It requires an RTT and a 302 hop delay.

In most cases, users will not manually enter www.baidu.com to access HTTPS, and the server can only return 302 to force the browser to jump to https.

It also takes time for browsers to process 302 jumps.

Three-way handshake re-establishes TCP connection. It takes one RTT.

302 After jumping to the HTTPS server, because the port and server are different, you need to complete the three-way handshake again and establish the TCP connection.

TLS full handshake phase 1. It takes at least one RTT.

This phase is mainly to complete the negotiation of encryption suite and identity authentication of certificates.

The server and browser negotiate the same key exchange algorithm, symmetric encryption algorithm, content consistency check algorithm, certificate signature algorithm, elliptic curve (not required for non-ECC algorithms), etc.

After the browser obtains the certificate, it needs to verify the validity of the certificate, such as whether it expires or whether it is revoked.

Resolve DNS for CA sites. It takes one RTT.

After the browser obtains the certificate, it may need to initiate an OCSP or CRL request to query the certificate status.

The browser first obtains the CA domain name in the certificate.

If there is no cache hit, the browser needs to resolve the DNS for the CA domain name.

A three-way handshake establishes a TCP connection to the CA site. It takes one RTT.

After DNS resolution to IP, you need to complete the three-way handshake to establish a TCP connection.

Initiate an OCSP request to get a response. It takes one RTT.

Phase 2 of the full handshake takes one RTT and computation time.

The second stage of full handshake is mainly key agreement.

After the full handshake, application-layer (i.e. HTTP) data transfer takes place between browser and server.

Of course, not every request needs to add 7 RTTs to complete the HTTPS first request interaction. Less than 0.01% of requests are likely to go through the above steps, and they need to meet the following conditions:

It must be a first time request. That is, the first request initiated after the TCP connection is established, and subsequent requests on the connection do not need to occur.

A full handshake must occur, and normally 80% of requests can be handled with a simplified handshake.

Browsers need to have OCSP or CRL enabled. Chrome has ocsp turned off by default, Firefox and IE are turned on by default.

The browser did not hit the OCSP cache. The general update cycle of OCSP is 7 days, and the query cycle of Firefox is also 7 days, which means that the query of OCSP will occur once in 7 days.

The browser did not hit the DNS cache of the CA site. The DNS of the CA is resolved only if the DNS cache misses.

2.2 Increased computation time

The above section only briefly describes the pure network time that must be consumed on the HTTPS critical path, not including the computation time that consumes CPU resources. In fact, the computation time is not small (more than 30ms). From the perspective of the browser and the server, it is introduced separately:

Browser calculation time

RSA certificate signature verification, browser needs to decrypt signature, calculate certificate hash value. If there are multiple certificate chains, the browser needs to verify multiple certificates.

RSA key exchange requires the premaster to be encrypted with a certificate public key. It takes less time, but if the phone performance is poor, it may also take 1 ms.

ECC key exchange requires computing the public and private keys of elliptic curves.

ECC key exchange, you need to use the certificate public key decryption to obtain the ECC public key sent by the server.

When exchanging ECC keys, the master key needs to be calculated according to the public key of the server.

Symmetric encryption and decryption of application layer data.

Application-level data consistency check.

server-side computation time

RSA key exchange requires decryption of the premaster using the certificate private key. This process is very performance-intensive.

ECC key exchange requires computing the public and private keys of elliptic curves.

ECC key exchange requires the use of certificate private key encryption ECC public key.

ECC key exchange requires calculating the shared master key based on the browser public key.

Symmetric encryption and decryption of application layer data.

Application-level data consistency check.

Due to the variety of CPUs and operating systems on the client side, the calculation time cannot be generalized. HTTPS computing on the mobile phone will consume performance, and the delay added by pure computing will be at least 50 ms. The PC side also adds at least 10ms of computation delay.

The server performance is generally strong, but because the RSA certificate private key length is much larger than the client, so the server calculation delay will be more than 5 ms.

The above is what impact HTTPS has on performance, Xiaobian believes that some knowledge points may be seen or used in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.