HTTPS practices for large Web sites (ii) Impact of--HTTPS on performance

Objective

HTTPSIt plays a key role in protecting user privacy and preventing traffic hijacking, but at the same time, HTTPS can reduce user access speed and increase computing resource consumption of the website server.

This article mainly describes the impact of HTTPS on the user experience.

The effect of HTTPS on access speed

Before introducing the speed optimization strategy, let's look at the effect of HTTPS on speed. The impact comes from two main aspects:

The network RTT (round trip Time) added by the protocol interaction.
The computation time of the encryption and decryption related.

Here's a look at each.

2.1 Network time-consuming increase

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

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

It can be seen that the user only needs to complete the TCP three handshake to establish a TCP connection to send HTTP requests directly to get application layer data, and there is no need to consume computing resources throughout the visit.

Next look at the HTTPS access process, compared to HTTP is much more complex, in some scenarios, using HTTPS access may increase 7 RTT. Such as:

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

1, three handshake to establish a TCP connection. Time consuming a RTT.

2, using HTTP to initiate a GET request, the server returned 302 jump to https://www.baidu.com. Requires a RTT and 302 jump delay.

A) In most cases the user does not manually enter https://www.baidu.com to access HTTPS, and the server can only return 302 to force the browser to jump to HTTPS.

b) Browser processing 302 jump also takes time.

3, three handshake re-establishes the TCP connection. Time consuming a RTT.

A) 302 after jumping to the HTTPS server, due to different ports and servers, a three-time handshake is required to establish a TCP connection.

4, TLS full handshake phase one. Time consuming at least one RTT.

A) This phase is primarily the completion of cryptographic suite negotiation and certification of authentication.

b) The server and browser will negotiate the same key exchange algorithm, symmetric encryption algorithm, content consistency check algorithm, certificate signature algorithm, Elliptic curve (non-ECC algorithm does not need) and so on.

c) The validity of the certificate required by the browser after obtaining it, such as whether it has expired or revoked.

5, resolves the DNS for the CA site. Time consuming a RTT.

A) After the browser obtains the certificate, it may be necessary to initiate OCSP or CRL requests to query the certificate status.

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

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

6, three times the handshake establishes a TCP connection to the CA site. Time consuming a RTT.

A) after DNS resolves to IP, it is necessary to complete the three handshake to establish a TCP connection.

7, initiate the OCSP request and get the response. Time consuming a RTT.

8, full handshake phase two, time consuming a RTT and calculation times.

A) Full handshake phase Two is primarily key negotiation.

9, after the full handshake, the application layer (i.e. HTTP) data transfer between the browser and the server.

Of course not every request requires an additional 7 RTT to complete the HTTPS first request interaction. Only less than 0.01% of requests are likely to undergo these steps, and they need to meet the following criteria:

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

2, a full handshake must occur, while 80% of the requests under normal circumstances can achieve a simplified handshake.

3, the browser needs to turn on OCSP or CRL functionality. Chrome turns off the OCSP feature by default, and Firefox and IE are turned on by default.

4, the browser does not hit the OCSP cache. The general update period for OCSP is 7 days, and the query period for Firefox is 7 days, which means that the OCSP query will occur in 7 days.

5, the browser does not hit the DNS cache of the CA site. The DNS of the CA is resolved only if the DNS cache is in a dead state.

2.2 Calculation time-consuming increase
The last section simply describes the time consuming the pure network that must be consumed on the HTTPS critical path, does not include CPU-intensive computation time-consuming, in fact, the computation time is not small (more than 30ms), from the browser and server perspective, respectively:

1, browser calculation time-consuming

A) RSA certificate signature Verification, the browser needs to decrypt the signature, calculate the certificate hash value. If there are multiple certificate chains, the browser needs to validate multiple certificates.

b) RSA key exchange requires the use of the certificate public key encryption Premaster. Time consuming is small, but if the phone performance is poor, it may also take 1ms.

c) ECC key exchange, you need to calculate the public private key of the elliptic curve.

d) ECC key Exchange requires the use of the certificate public key to decrypt the ECC public key that is sent by the server.

e) ECC key exchange requires that master key be computed based on the server's public key.

f) Application layer data symmetry and decryption.

g) Application layer data consistency check.

2, service-side calculation time-consuming

A) RSA key exchange requires the use of the certificate private key to decrypt the premaster. This process is very performance-intensive.

b) When ECC key exchange, it is necessary to calculate the public private key of elliptic curve.

c) ECC key Exchange requires the use of the certificate private key to encrypt the ECC public key.
d) for ECC key exchange, the shared master key needs to be computed based on the browser's public key.

e) Application layer data symmetric plus decryption.

f) Application layer data consistency check.

Because the CPU and operating system of the client are quite different, the computation time is not generalize. The HTTPS calculation on the mobile phone will compare the consumption performance, the simple calculation increases the delay at least above 50ms. The PC side also increases the calculation delay by at least 10ms.

Server performance is generally strong, but because the RSA certificate private key length is much larger than the client, so the computing latency of the service side will be more than 5ms.

HTTPS practice for large Web sites (iii)--optimization based on protocol and configuration

HTTPS practice for large Web sites (iv)--practices outside the protocol layer

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

HTTPS practices for large Web sites (ii) Impact of--HTTPS on performance