Page 79 - Web性能权威指南
P. 79
4.7.6 证书链的长度
验证信任链需要浏览器遍历链条中的每个节点，从站点证书开始递归验证父证书，
直至信任的根证书。因此，优化的首要工作就是检查服务器在握手时没有忘记包含
所有中间证书。如果忘记了包含中间证书，虽然很多浏览器可以正常工作，但它们
会暂停验证并自己获取中间证书，验证之后再继续。此时很可能需要进行新 DNS 查
找、建立 TCP 连接、发送 HTTP GET 请求，导致握手多花几百 ms 时间。
浏览器怎么知道到哪里去找证书呢？子证书中通常包含父证书的 URL。
另一方面，还要确保信任链中不包含不必要的证书！或更一般化地讲，应该确保证
书链的长度最小。我们在 4.2 节“TLS 握手”中介绍过，服务器证书是在握手期间
发送的，而发送证书使用的很可能是一个处于 2.2.2 节“慢启动”算法初始阶段的
新 TCP 连接。如果证书链长度超过了 TCP 的初始拥塞窗口（图 4-11），那我们无意
间就会让握手多了一次往返：证书长度超过拥塞窗口，从而导致服务器停下来等待
客户端的 ACK 消息。
图 4-11：WireShark 的截图显示的 5323 字节的 TLS 证书链
图 4-11 所示的证书链超过了 5 KB，也超过了大多数旧版本浏览器的初始拥塞窗口
大小，因此会在握手期间增加一次额外的往返。对此，可以通过增大拥塞窗口来解
决，参见 2.2.2 节最后的“增大 TCP 的初始拥塞窗口”部分。此外，就是要看一看
能否减少要发送的证书大小了。
• 尽量减少中间证书颁发机构的数量。理想情况下，发送的证书链应该只包含两个
证书：站点证书和中间证书颁发机构的证书。把这一条作为选择证书颁发机构的
标准。第三个证书，也就是根证书颁发机构的证书，已经包含在浏览器内置的信
任名单中了，不用发送。
• 很多站点会在证书链中包含根证书颁发机构的证书，这是完全没有必要的。如果浏
览器的信任名单中没有该根证书，那说明它是不被信任的，即便发送它也无济于事。
传输层安全（TLS） ｜ 61
