📚 课程目录第1章 OCSP协议基础与性能瓶颈分析

1. OCSP协议基础与性能瓶颈分析

各位同学，咱们今天聊聊OCSP。说实话，这个协议看起来简单，但真正把它跑出高性能，坑可不少。我最早接触OCSP是在一个金融CA项目里，那时候响应器一上生产就跪，用户TLS握手动不动就卡两三秒——嗯，从那以后我就开始认真研究这玩意儿了。

OCSP全称是Online Certificate Status Protocol，说白了就是在线查证书状态的协议。RFC 6960定义了它的核心流程：客户端拿着证书，问响应器“这证书吊销没？”，响应器回答“好”、“坏”或者“我不知道”。

但这里有个关键点——OCSP响应必须做数字签名。为什么？因为响应要在网络上传输，你不签名，中间人随便改个“good”就能骗过客户端。我见过有人为了省性能把签名去掉，结果被安全审计直接打回。

核心消息结构：

你想想看，TLS握手时客户端拿到服务器证书，第一件事就是查它有没有被吊销。以前的做法是下载CRL（证书吊销列表），但那玩意儿动不动就几MB，下载一次握手就废了。

OCSP的出现就是为了解决这个问题。客户端在握手过程中，直接向OCSP响应器发起查询，拿到一个轻量级的响应（通常几百字节）。但这里有个性能陷阱——同步查询会阻塞握手。

我记得有一次帮客户排查问题，发现他们的TLS握手平均耗时800ms，其中OCSP查询占了600ms。为什么？因为响应器扛不住并发，请求排队了。

我的建议：生产环境一定要用OCSP Stapling。让服务器自己定期去拉OCSP响应，握手时直接带上，客户端不用再额外查询。这样能把OCSP延迟从握手关键路径上拿掉。

好了，咱们进入正题。OCSP响应器的性能瓶颈，我归纳下来就三个：签名计算、数据库查询、网络I/O。下面一个一个说。

很多人觉得签名不就是一次RSA操作吗？能有多慢？但你要知道，OCSP响应器每秒可能要处理几万次请求，每次都要做一次签名。RSA-2048签名在普通CPU上大概要1-2ms，听起来不多，但并发上来就炸了。

我曾经在一个项目中做过压测：单核CPU，RSA-2048签名，QPS到2000时CPU直接100%，响应延迟从5ms飙升到500ms。后来换成ECDSA，同样的QPS，CPU只用了30%。

注意：别为了性能盲目上ECDSA。有些老客户端不支持ECDSA签名的OCSP响应，你得做好降级策略。我见过一个案例，全切ECDSA后，部分银行客户端直接报错，最后不得不保留RSA兼容。

签名再快，如果数据库查不到数据也是白搭。OCSP响应器需要实时查询证书状态，这个查询路径通常是：

这里最大的坑是数据库连接池耗尽。我调优过一个系统，数据库连接池只有50个，但OCSP响应器开了200个线程。结果呢？150个线程在等连接，请求全部排队，延迟直线上升。

另一个常见问题是慢查询。如果证书表没有对序列号建索引，或者索引类型不对（比如用了字符串索引而不是二进制索引），一次查询可能从微秒级变成毫秒级。

我的经验：把证书序列号存成BINARY类型，建唯一索引。查询时直接按二进制匹配，比字符串匹配快一个数量级。另外，考虑用Redis做缓存层，把热点证书的状态缓存起来，数据库查询次数能减少80%以上。

网络I/O的问题往往被忽视，因为大家总觉得“网络是别人的事”。但OCSP响应器作为在线服务，网络处理能力直接决定了它能扛多少并发。

传统的阻塞I/O模型，一个连接一个线程，线程多了上下文切换开销巨大。我见过一个部署在8核机器上的OCSP响应器，开了500个线程，结果CPU有40%花在线程切换上，真正干活的只有60%。

非阻塞I/O（比如epoll、kqueue）能解决这个问题。用事件驱动模型，一个线程可以处理几千个连接。我后来把那个系统改成基于epoll的异步模型，同样的硬件，QPS从5000提升到了30000。

还有一个容易被忽略的点——TCP连接复用。OCSP请求通常很小，如果每次查询都新建TCP连接，三次握手的开销比业务处理还大。建议客户端使用HTTP Keep-Alive，或者直接用HTTP/2的多路复用。

说了这么多，其实我想表达一个观点：调优之前先测量。不要凭感觉去优化，一定要拿到数据再动手。

我个人的习惯是，先做一轮压测，记录三个指标：

然后根据瓶颈分布，决定先优化哪个环节。一般来说，数据库查询是最容易出效果的地方，签名计算次之，网络I/O往往需要改架构。

本章小结：