HTTPS practices for large websites (II)-Impact of HTTPS on performance and https practices

HTTPS practices for large websites (II)-Impact of HTTPS on performance and https practices
Preface

HTTPSIt plays a critical role in protecting user privacy and preventing traffic hijacking. However, HTTPS also reduces user access speeds and increases the computing resource consumption of website servers.

This article describes the impact of https on user experience.

Influence of HTTPS on access speed

Before introducing the speed optimization policy, let's take a look at the effect of HTTPS on the speed. There are two main impacts:

The added network RTT (round trip time) for protocol interaction ).
Computing duration related to encryption and decryption.

The following is a brief introduction.

2.1 increase in network time consumption

Because 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 to highlight the comparison effect.

When users access http://www.baidu.com (or www.baidu.com) Over HTTP, there will be time consumption for interaction on the following network:

It can be seen that you only need to complete three TCP handshakes to establish a TCP connection to directly send an HTTP request to obtain the application layer data. In addition, there is no need to consume computing resources throughout the access process.

Next, let's look at the HTTPS access process, which is much more complicated than HTTP. In some scenarios, using HTTPS access may increase by 7 RTTs. For example:

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

1. Three-way handshake to establish a TCP connection. The time consumed is one RTT.

2, using HTTP to initiate a GET request, the server returns 302 jump to the https://www.baidu.com. An RTT and 302 jump latency are required.

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

B) It also takes time for the browser to process 302 redirection.

3. Three-way handshake to re-establish the TCP connection. The time consumed is one RTT.

A) After 302 is redirected to the HTTPS server, because the port is different from the server, you need to complete three new handshakes to establish a TCP connection.

4. TLS full handshake Phase 1. At least one RTT is consumed.

A) At this stage, the cipher suite negotiation and certificate identity authentication are completed.

B) the server and the browser negotiate the same key exchange algorithm, symmetric encryption algorithm, content Consistency Verification Algorithm, certificate signature algorithm, and elliptic curve (not required by the non-ECC algorithm.

C) after obtaining the certificate, the browser needs to verify the validity of the certificate, such as whether the certificate has expired and whether it has been revoked.

5. Resolve the DNS of the CA Site. The time consumed is one RTT.

A) after obtaining the certificate, the browser may need to initiate an OCSP or CRL request 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 the DNS of the CA domain name.

6. Three handshakes are used to establish a TCP connection to the CA Site. The time consumed is one RTT.

A) after the DNS is resolved to the IP address, you need to complete three handshakes to establish a TCP connection.

7. Initiate an OCSP request to obtain the response. The time consumed is one RTT.

8. Full handshake stage 2, which consumes an RTT and computing time.

A) In the full handshake phase, key negotiation is the main function.

9. After the handshake is complete, the browser and the server transmit data at the application layer (that is, HTTP.

Of course, not every request requires 7 RTTs to complete the first HTTPS request interaction. Only less than 0.01% of requests may need to go through the above steps. They must meet the following conditions:

1. It must be the first request. That is, the first request initiated after a TCP connection is established. Subsequent requests on the connection do not need to perform the above actions.

2. A full handshake is required, while a 80% request can simplify the handshake normally.

3. the browser must enable the OCSP or CRL function. Chrome disables ocsp by default, and firefox and IE are both enabled by default.

4. the browser does not hit the OCSP cache. Generally, the Ocsp update period is 7 days, and the firefox query period is also 7 days. That is to say, an ocsp query occurs only in 7 days.

5. the browser does not hit the DNS cache of the CA Site. The DNS of the CA is resolved only when the DNS cache is not hit.

2.2 increase in computing time consumption
The previous section briefly describes the time consumed by the HTTPS Key Path for pure network, excluding the time consumed for computing that consumes a lot of CPU resources. In fact, the computing time is not small (more than 30 ms ), from the perspective of browsers and servers:

1. browser computing time consumption

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

B) When performing RSA key exchange, you must use the certificate public key to encrypt the premaster. It takes a relatively small amount of time, but if the phone performance is poor, it may take 1 ms.

C. Calculate the public/private key of the elliptic curve during ECC key exchange.

D) When performing ECC Key Exchange, use the certificate public key to decrypt and obtain the ECC public key sent from the server.

E) for ECC key Exchange, the master key must be calculated based on the public key of the server.

F) symmetric data encryption and decryption at the application layer.

G) data consistency check at the application layer.

2. server computing time consumption

A) You must use the certificate private key to decrypt the premaster during RSA key exchange. This process consumes a lot of performance.

B) The public/private key of the elliptic curve must be calculated during ECC key exchange.

C) When performing ECC key exchange, you must use the certificate private key to encrypt the public key of the ECC.
D) The shared master key must be calculated based on the public key of the browser during ECC key exchange.

E) symmetric data encryption and decryption at the application layer.

F) data consistency check at the application layer.

Because the client has many CPU and operating system types, the computing duration cannot be generalized. HTTPS computing on the mobile phone end consumes a lot of performance, and the latency of computing alone is at least 50 ms. The PC end also increases the computing Latency by at least 10 ms.

The server performance is generally strong, but the length of the RSA certificate private key is much larger than that of the client, so the computing latency of the server is more than 5 ms.

HTTPS practices for large websites (III)-Protocol-and configuration-Based Optimization

HTTPS practices for large websites (IV)-practices outside the protocol layer

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.