自从把博客系统换成 Wordpress 以后，又是缓存，又是精简，又是各种替换，为了优化网站的速度不可不谓花了一番心思，然而在 iPhone 上，我的网站的打开速度却依然时快时慢。在之前两个月里，我一直认为是服务器的性能问题所致。直到有一天我看到并且为网站部署了 OCSP Stapling。

为什么偏偏在 iPhone 上就打开慢？

你可能已经注意到我使用了「打开」而非「加载」，如果你调用 iPhone 上 Safari 的开发者模式查看一个网页的 Handshake 时间，你就会发现一个不容忽视的 1 秒，至于这一秒都花在了哪里，我们先来看看 OCSP 究竟是什么。

OCSP 的概念

先从 SSL 证书的有效期说起

曾经我有一个困惑，为什么没有永久有效的 SSL 证书？难道是单纯因为商业原因？其实并不是，主要原因是为了安全。每次签发机构（CA）签发 SSL 证书时，CA 都会为这个 SSL 证书生成一个私钥。就像家里任何一把钥匙一样，HTTPS 证书的私钥有丢失、泄露的风险，当网站的私钥丢失时，网站应该向证书 CA 申请将他们的证书加入到证书吊销列表（CRL）里。当用户访问 https 站点时，浏览器会自动向 CA 请求吊销列表，如果用户访问的站点提供的证书在 CRL 里，浏览器就不信任这个证书，因为私钥泄漏后，攻击者可能拥有同样的证书。

所以，如果证书永久有效，随着越来越多的私钥丢失，吊销列表也越来越大（因为只有加进去的，没有剔出去的），这既给 CA 的服务器增加流量压力，也会增加浏览器需要下载的数据量。而一旦有效期只有一年或几年，那么CA就可以将那些已经过期了的证书从 CRL 里剔除，因为反正浏览器也不信任过期证书。这种问题也就随之消失，于是，今天看到的证书，有效期都随着安全等级的提高而加长，但除非自签，没有永久有效的证书。

这和 OCSP 有什么关系？

OCSP 即 Oline Certificate Status Protocol，是用于替代 CRL 的协议，解决了一些 CRL 协议存在的问题，以下信息来译自 Wikipedia：

OCSP 响应通常比典型的 CRL 响应更小，这意味着对于客户端和服务器更小的网络负担。

OCSP 响应中需要解析的数据更少，因此客户端需要的运行库比解析典型的 CRL 响应更少更简单

OCSP 中，服务器可以记录主机在何时验证过特定的证书，由于请求不强制加密，相关信息可能被第三方获取。

简单来说，OCSP 做的就是 CRL 的事——验证这个网站的 https 证书是否处于被吊销的状态。

所以为什么打开慢？

我们搭建个人网站时大都没有很高的预算，例如我的网站原本托管在免费的 Github Pages 上，预算能省则省，更别提动辄几千一年的 SSL 证书了。于是你看到的非商业性质的个人网站大都采用了免费的 Let’s Encrypt 证书。而 Let’s Encrypt 的 OCSP 服务器 ocsp.int-x3.letsencrypt.org 线路非常垃圾，实测中部地区联通 traceroute 以供参考：

可以看到服务器在香港，线路却绕美国。这导致 一个很简单的 OCSP 查询请求需要 1 秒的时间来返回结果。这意味着无论你的服务器性能有多强，网络延迟有多低，只要部署的证书是 Let’s Encrypt，网站在 iPhone 上的加载时间就绝对不会快过一秒。这还不是最坏的情况，因为各种莫名其妙的原因，Let’s Encrypt 的 OCSP 服务器域名会时不时的被 GFW 通过 DNS 污染等方式阻断，这就导致客户端在一部分时间里根本无法查询 OCSP。

但为什么只有 iPhone 会加载慢呢？

OCSP 协议有一个很要命的问题：用 https 的人越来越多，验证证书有效性的需求自然会越来越大，OCSP 服务器难道硬扛访问量？当然不是，不同浏览器都会有不同的 OCSP 验证超时时间，超时就先默认证书有效继续进行访问。但是有些"「注重用户体验」 的浏览器，比如 Chrome，自己在浏览器内部做了个本地列表，通过每次浏览器更新实现列表更新。直接查本地的列表速度就非常快了，当然也不存在什么 CA 的 OCSP 服务器被屏蔽的问题。缺点是并非实时更新。但并非所有浏览器都是所谓「注重用户体验」的浏览器，比如 Safari 就默认开启 OCSP 验证。自然无法避免这种中国特色的问题。Chrome 在全球有超过 70% 的市占率，而受 Chromium 开源项目的影响，国内一众「安全」「极速」浏览器都不存在这种问题，这几乎覆盖了国内桌面端所有用户群体。而苹果要求包括 Chrome 在内的所有 iOS 应用都要使用 Webkit 内核，这直接干死了所有的 iPhone 用户。

怎么解决？

总不可能要求所有 iPhone 用户都自己关掉 OCSP 吧？那么解决方法就是——换证书。怎么可能，要是我真换了证书你也就看不到这篇文章了。虽然换证书，比如 Trust Asia 证书的确可以解决问题。但我不想因为换一个证书而告别 Let’s Encrypt 自动续期和支持泛域名的特性。

终于可以谈到 OCSP Stapling 了，即 OCSP 封装，想要开启 OCSP Stapling 非常简单：首先到亚洲诚信提供的 https 检测服务检测自己的证书链是否完整，若是不完整则修复证书链后将修复好的证书重新部署，完成操作后在 Nginx 配置里加上如下两行：

1
2

ssl_stapling on; 
ssl_stapling_verify on;

然后重启 Nginx 服务，大功告成。由于我自己使用的是 Nginx，Apache 请自行搜索相关方法。

然后，iPhone 用户也能愉快的访问你的网站而无需忍受恼人的 GFW 干扰 Let’s Encrypt 的 OCSP 服务器。

那么效果如何呢？

可以看到，开启 OCSP Stapling 后，查询验证结果所需要的时间大幅缩短，反映到网站打开速度上是非常明显的感知。

什么东西这么牛逼？

OCSP 封装，顾名思义，即服务器缓存 OCSP 服务器的验证结果，并且在与客户端 SSL 握手时直接发送缓存结果。

OCSP装订，是TLS证书状态查询扩展，作为在线证书状态协议的替代方法对X.509证书状态进行查询，服务器在TLS握手时发送事先缓存的OCSP响应，用户只要验证该响应的时效性而不用再向数字证书认证机构(CA)发送请求，可以加快握手速度。

我的服务器线路虽然亦非很好，但比 Let’s Encrypt 的弟中弟线路好到不知道哪里去了。开启 OCSP Stapling 后，客户端只需要验证服务器事先缓存的 OCSP 查询结果的有效性，免去了向“神优化”的服务器发请求的痛苦，速度自然会快上一大截，在有 OCSP 强制验证的浏览器上初次打开网页的效果尤为明显，统计数据显示，在开启 OCSP Stapling 后，新访客量明显有所提高，大概是拜 OCSP Stapling 节省的大量握手时间所赐。

为什么不默认开启 OCSP Stapling？

听上去 OCSP Stapling 简直就是完美的万金油优化——每个网站都开启 OCSP Stapling，既提升用户的访问体验，也为 OCSP 服务器减轻负担。那为什么新的 Nginx 配置文件不默认开启 OCSP Stapling 呢？其实这是一个很简单的问题。

• 不是所有网站都有 SSL 证书
• OCSP Stapling 并非在所有情况下都能提供更好的访问体验
• 现存方案中 OCSP 并不是唯一的证书验证方案
• 引入新功能时通常是需要谨慎的，Nginx 用户群体非常复杂，不同用户不同需求

参考

1. 为什么https证书要设有有效期？
2. 找不到了
3. Wikipedia
4. 玩个机吧

头图来自：KeyCDN