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 以上。

 2/2   首页 上一页 1 2