HTTP与HTTPS对访问速度（性能）的影响

1 前言

HTTPS 在保护用户隐私，防止流量劫持方面发挥着很是关键的做用，但与此同时，HTTPS 也会下降用户访问速度，增长网站服务器的计算资源消耗。

本文主要介绍 https 对用户体验的影响。

2 HTTP与HTTPS的概念和区别

（1）HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，所以加密的详细内容就须要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL代表它使用了HTTP，但HTTPS存在不一样于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通信方法，如今它被普遍用于万维网上安全敏感的通信，例如交易支付方面。

（2）超文本传输协议 (HTTP-Hypertext transfer protocol) 是一种详细规定了浏览器和万维网服务器之间互相通讯的规则，经过因特网传送万维网文档的数据传送协议。

（3）https协议须要到ca申请证书，通常免费证书不多，须要交费。

       http是超文本传输协议，信息是明文传输，https 则是具备安全性的ssl加密传输协议

       http和https使用的是彻底不一样的链接方式，用的端口也不同,前者是80,后者是443。   

       http的链接很简单,是无状态的，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 ，要比http协议安全

3 HTTPS 对访问速度的影响

在介绍速度优化策略以前，先来看下 HTTPS 对速度有什么影响。影响主要来自两方面：

1. 协议交互所增长的网络 RTT(round trip time)。
2. 加解密相关的计算耗时。

下面分别介绍一下。

3.1 网络耗时增长

因为 HTTP 和 HTTPS 都须要 DNS 解析，而且大部分状况下使用了 DNS 缓存，为了突出对比效果，忽略主域名的 DNS 解析时间。

用户使用 HTTP 协议访问http://www.baidu.com(或者 www.baidu.com) 时会有以下网络上的交互耗时：

图 1 HTTP 首个请求的网络耗时

可见，用户只须要完成 TCP 三次握手创建 TCP 链接就可以直接发送 HTTP 请求获取应用层数据，此外在整个访问过程当中也没有须要消耗计算资源的地方。

接下来看 HTTPS 的访问过程，相比 HTTP 要复杂不少，在部分场景下，使用 HTTPS 访问有可能增长 7 个 RTT。以下图：

图 2 HTTPS 首次请求对访问速度的影响

HTTPS 首次请求须要的网络耗时解释以下：

1，    三次握手创建 TCP 链接。耗时一个 RTT。

2，    使用 HTTP 发起 GET 请求，服务端返回 302 跳转到 https://www.baidu.com。须要一个 RTT 以及 302 跳转延时。

a)       大部分状况下用户不会手动输入 https://www.baidu.com 来访问 HTTPS，服务端只能返回 302 强制浏览器跳转到 https。

b)      浏览器处理 302 跳转也须要耗时。

3，    三次握手从新创建 TCP 链接。耗时一个 RTT。

a)       302 跳转到 HTTPS 服务器以后，因为端口和服务器不一样，须要从新完成三次握手，创建 TCP 链接。

4，    TLS 彻底握手阶段一。耗时至少一个 RTT。

a)       这个阶段主要是完成加密套件的协商和证书的身份认证。

b)      服务端和浏览器会协商出相同的密钥交换算法、对称加密算法、内容一致性校验算法、证书签名算法、椭圆曲线（非 ECC 算法不须要）等。

c)       浏览器获取到证书后须要校验证书的有效性，好比是否过时，是否撤销。

5，    解析 CA 站点的 DNS。耗时一个 RTT。

a)       浏览器获取到证书后，有可能须要发起 OCSP 或者 CRL 请求，查询证书状态。

b)      浏览器首先获取证书里的 CA 域名。

c)       若是没有命中缓存，浏览器须要解析 CA 域名的 DNS。

6，    三次握手创建 CA 站点的 TCP 链接。耗时一个 RTT。

a)       DNS 解析到 IP 后，须要完成三次握手创建 TCP 链接。

7，    发起 OCSP 请求，获取响应。耗时一个 RTT。

8，    彻底握手阶段二，耗时一个 RTT 及计算时间。

a)       彻底握手阶段二主要是密钥协商。

9，    彻底握手结束后，浏览器和服务器之间进行应用层（也就是 HTTP）数据传输。

固然不是每一个请求都须要增长 7 个 RTT 才能完成 HTTPS 首次请求交互。大概只有不到 0.01% 的请求才有可能须要经历上述步骤，它们须要知足以下条件：

1，    必须是首次请求。即创建 TCP 链接后发起的第一个请求，该链接上的后续请求都不须要再发生上述行为。

2，    必需要发生彻底握手，而正常状况下 80% 的请求能实现简化握手。

3，    浏览器须要开启 OCSP 或者 CRL 功能。Chrome 默认关闭了 ocsp 功能，firefox 和 IE 都默认开启。

4，    浏览器没有命中 OCSP 缓存。Ocsp 通常的更新周期是 7 天，firefox 的查询周期也是 7 天，也就说是 7 天中才会发生一次 ocsp 的查询。

5，    浏览器没有命中 CA 站点的 DNS 缓存。只有没命中 DNS 缓存的状况下才会解析 CA 的 DNS。

3.2 计算耗时增长

上节还只是简单描述了 HTTPS 关键路径上必须消耗的纯网络耗时，没有包括很是消耗 CPU 资源的计算耗时，事实上计算耗时也不小（30ms 以上），从浏览器和服务器的角度分别介绍一下：

1，    浏览器计算耗时

a)       RSA 证书签名校验，浏览器须要解密签名，计算证书哈希值。若是有多个证书链，浏览器须要校验多个证书。

b)      RSA 密钥交换时，须要使用证书公钥加密 premaster。耗时比较小，但若是手机性能比较差，可能也须要 1ms 的时间。

c)       ECC 密钥交换时，须要计算椭圆曲线的公私钥。

d)      ECC 密钥交换时，须要使用证书公钥解密获取服务端发过来的 ECC 公钥。

e)       ECC 密钥交换时，须要根据服务端公钥计算 master key。

f)       应用层数据对称加解密。

g)      应用层数据一致性校验。

2，    服务端计算耗时

a)       RSA 密钥交换时须要使用证书私钥解密 premaster。这个过程很是消耗性能。

b)      ECC 密钥交换时，须要计算椭圆曲线的公私钥。

c)       ECC 密钥交换时，须要使用证书私钥加密 ECC 的公钥。

d)      ECC 密钥交换时，须要根据浏览器公钥计算共享的 master key。

e)       应用层数据对称加解密。

f)       应用层数据一致性校验。

因为客户端的 CPU 和操做系统种类比较多，因此计算耗时不能一律而论。手机端的 HTTPS 计算会比较消耗性能，单纯计算增长的延迟至少在 50ms 以上。PC 端也会增长至少 10ms 以上的计算延迟。

服务器的性能通常比较强，但因为 RSA 证书私钥长度远大于客户端，因此服务端的计算延迟也会在 5ms 以上。