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

Preface

HTTPS plays a key role in protecting users' privacy and preventing traffic hijacking, but at the same time, HTTPS will also reduce the speed of user access and increase the consumption of computing resources on the website server. This paper mainly introduces the influence of HTTPS on performance.

The influence of HTTPS on access Speed

Before introducing the speed optimization strategy, let's take a look at the impact of HTTPS on speed. The impact mainly comes from two aspects: the increased network RTT (round trip time) caused by protocol interaction and the time-consuming computation related to encryption and decryption. Let's introduce each of them.

1 increase in network time

Since both HTTP and HTTPS require DNS resolution, and DNS cache is used in most cases, the DNS resolution time of the primary domain name is ignored in order to highlight the comparison effect.

When a user accesses http://www.baidu.com( or www.baidu.com using the HTTP protocol, the interaction on the network takes time as follows:

Figure 1 time consuming of the network for the first request of HTTP

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 in the whole access process.

Next, let's take a look at the access process of HTTPS. It is much more complicated than HTTP. In some scenarios, it is possible to add 7 RTT to access using HTTPS. As shown below:

Figure 2 impact of HTTPS first request on access speed

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

A three-way handshake establishes a TCP connection. It takes a RTT.

The GET request is initiated using HTTP, and the server returns 302 to jump to https://www.baidu.com. A RTT and 302 jump delay are required.

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

It also takes time for the browser to process the 302 jump.

Re-establish the TCP connection with a three-way handshake. It takes a RTT.

After jumping to the HTTPS server, the three-way handshake needs to be re-completed to establish a TCP connection due to the different port and server.

TLS full handshake phase one. Takes at least one RTT.

This stage is mainly to complete the negotiation of the encryption suite and the identity authentication of the certificate.

The server and the browser will negotiate the same key exchange algorithm, symmetric encryption algorithm, content consistency verification algorithm, certificate signature algorithm, elliptic curve (non-ECC algorithm is not required) and so on.

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

Parse the DNS of the CA site. It takes a RTT.

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

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

If the cache is not hit, the browser needs to resolve the DNS of the CA domain name.

Establish a TCP connection to the CA site with a three-way handshake. It takes a RTT.

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

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

The second stage of complete handshake takes a RTT and computing time.

The second stage of complete handshake is mainly key negotiation.

After the full handshake, the application layer (that is, HTTP) data transfer occurs between the browser and the server.

Of course, not every request requires seven additional RTT to complete the first HTTPS request interaction. Probably 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 the first request. That is, the first request initiated after the establishment of a TCP connection, and the above behavior does not need to occur for subsequent requests on the connection.

A full handshake must occur, and 80% of requests normally achieve a simplified handshake.

Browsers need to enable OCSP or CRL functions. Chrome turns off OCSP by default, and both Firefox and IE are enabled 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, that is, OCSP queries occur only once in 7 days.

The browser did not hit the DNS cache of the CA site. The DNS of CA will be parsed only if the DNS cache is missed.

2 the calculation time is increased.

The previous section only briefly describes the pure network time that must be consumed on the critical path of HTTPS, excluding the calculation time that consumes CPU resources very much. In fact, the calculation time is not small (above 30ms). Let's introduce it from the perspective of browser and server:

Browser calculation takes time

RSA certificate signature verification, the browser needs to decrypt the signature and calculate the certificate hash value. If there is more than one certificate chain, the browser needs to verify multiple certificates.

For RSA key exchange, you need to use the certificate public key to encrypt premaster. It takes less time, but if the performance of the phone is poor, it may also take 1ms time.

In ECC key exchange, the public and private keys of the elliptic curve need to be calculated.

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

In ECC key exchange, the master key needs to be calculated according to the server public key.

Symmetric encryption and decryption of application layer data.

Application layer data consistency check.

Server computing is time-consuming

RSA key exchange requires the use of a certificate private key to decrypt premaster. This process consumes very much performance.

In ECC key exchange, the public and private keys of the elliptic curve need to be calculated.

For ECC key exchange, the public key of the ECC needs to be encrypted with the certificate private key.

In ECC key exchange, the shared master key needs to be calculated according to the browser public key.

Symmetric encryption and decryption of application layer data.

Application layer data consistency check.

Because there are many kinds of CPU and operating systems on the client side, the computing time can not be generalized. HTTPS computing on mobile phones consumes more performance, and the latency of computing alone is at least above 50ms. The PC side will also increase the calculation delay at least above 10ms.

The performance of the server is generally strong, but because the length of the private key of the RSA certificate is much longer than that of the client, the computing delay of the server will also be higher than 5ms. Total knot

HTTPS not only ensures data security, but also has some impact on service performance. In this paper, we focus on the impact of HTTPS on service performance in terms of network time consumption and encryption and decryption. In the next series of articles, we will bring you Baidu's methods and experience in reducing the impact of HTTPS on performance.

The article is compiled from Baidu HTTPS Technical Joint team.

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.