你的 https 请求偶尔会慢几拍？也许你需要看看 OCSP stapling

你的 https 请求偶尔会慢几拍？也许你需要看看 OCSP stapling

导读

1.1 读完本文，您将收获：

1. 连接速度更快、更稳定的web项目。

1.2 本文面向人群。

1. 服务器在海外
2. 使用诸如 letsencrypt 之类 OCSP 服务器访问慢的 ssl
3. 服务器使用 nginx 或 caddy 做网页服务器。

正文

1. OCSP概述

1.1 概念

OCSP：在线证书状态协议（Online Certificate Status Protocol），被用于检验证书合法性。

浏览器访问从输入域名按下回车开始到服务器开始返回数据，中间包含步骤：

1. DNS 查询
2. 建立 TCP 连接
3. SSL证书安全校验（OCSP）

1.2 未优化

OCSP是由客户端（浏览器）发起的。

浏览器会直接请求第三方 CA 来获取证书的状态，如果服务端设置的 ssl 证书 网络不稳定或者 速度过慢，则会严重降低 HTTPS 性能，还存在隐私安全问题。

1.3 优化思路

OCSP Stapling：OCSP由服务器发起。

服务器直接获取 OCSP 查询结果，并随证书一起发送给客户端，让客户端跳过自己去寻求验证的过程，提高 TLS 握手效率，从而提高 HTTPS 性能。

2. OCSP 优化详解

2.1 查询 OCSP 状态

https://www.ssllabs.com/ssltest/analyze.html
访问这个网站，并输入自己的域名，点击submit（可能需要等待2~5分钟完成解析）
等待解析完成之后，在较靠站点末尾的地方，找到图示信息。图示中并没有开启 OCSP 。

2.3 Nginx 优化

本文直接以 Letsencrypt 为例进行详解，如果没有证书的，想了解如何安装并使用 Letsencrypt ，请点击这里了解详情

到这一步，默认您已经成功使用了 Letsencrypt ，假设您的域名是abc.xyz，此时您可以成功访问 https://abc.xyz

2.3.1 我们到服务器，输入一下命令

sudo cat /etc/letsencrypt/live/abc.xyz/fullchain.pem
sudo cat /etc/letsencrypt/live/abc.xyz/privkey.pem
sudo cat /etc/letsencrypt/live/abc.xyz/chain.pem

如果成功打印出来，说明，Letsencrypt 配置正确。否则，请参照上方链接自行配置。

前两个是用来配置 ssl 的，由 Letsencrypt 自动帮我们管理，最后一个chain.pem是即将要使用的。

2.3.2 我们打开 nginx 对应网站的配置文件

例：

sudo vim /etc/nginx/sites-enabled/abc.xyz

找到这些信息，（都是 Letsencrypt 自动帮我们配好的）

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/abc.xyz/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/abc.xyz/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

在下边增加三行：
修改结果如下：

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/abc.xyz/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/abc.xyz/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/abc.xyz/chain.pem;

2.3.3 保存退出并重启 nginx

sudo nginx -s reload

2.3.4 再查询一下 OCSP

到这里就优化成功了。
如果看到下边还有 ERROR ，请参照 Canddy 优化继续配置。

2.4 Canddy优化

Caddy Server 是默认打开了这个设置，那为什么还有问题？可以看看 SSL 报告：

显示虽然开启但是过期，这是由于服务器在国内，而需要请求的 Let’s Encrypt OCSP 服务器被墙了。既然这样有一个解决方法是修改服务器的 hosts 文件，可以用众测平台（比如：http://ping.chinaz.com/ocsp.int-x3.letsencrypt.org）获取到 ocsp.int-x3.letsencrypt.org 对应的多个服务器 IP，然后找到你的服务器可访问的，开启自己服务器上 host 的 multi on，写入多条记录即可。

完成配置后，来看看更新后的 SSL 报告，状态 Yes，一切正常。

尾记

1. 问题如何被发现

源自 Mixin 团队最新推出的一个接受打赏的服务 Donate 的优化。Donate 用户一般会在自己的文章中粘贴赞赏按钮图片和对应链接，但往往用户点击后浏览器并没有立即跳转，
停顿的好几秒体验是很差的。

考虑到服务器在国外，首先怀疑的就是是否由于延迟过高或请求返回过大导致。但实际测试也就 300ms 左右，尽管如此，我们还是先上了 Cloudflare 的 CDN 加速，果然停顿数秒不跳转的问题就不存在了。

那么就这样了吗？No，考虑到还有在国内的服务器，如果上 Cloudflare 反而效果不佳，找到根本原因然后解决才合理。我们发现在首次打开时尽管请求返回数据很少也会出现几秒卡顿，之后的多次请求就正常，于是才意识到应该是 SSL 连接出了问题。

搜索后不难找到 OCSP Stapling 相关的介绍，一个很容易被忽视但又很重要的 Config，简单实测了多个网站无一开启，所以这也是这篇文章会存在的原因。

2. 如何快速测试是否存在问题

使用 Chrome 的无痕模式，打开 Console 切换到 Network Tab，当你第一次（这个是重点）打开一个网址，发现请求的 Timing 中，Connection Start 下 SSL 和 Initial connection 消耗时间接近且异常久时就需要注意了。

3. 其他

这只是 SSL 的一个优化配置，效果虽然明显但是毕竟有限，物理硬伤比如国外用户访问国内的服务器，连接本身就慢些，要追求更快的速度该上 CDN 的还是得上。

欢迎有其他牛逼操作的大佬留言讨论，一起讨论技术，一起开发 Mixin 机器人。