应用层编解码调优思路——TLS/SSL性能优化

说起应用层协议优化，我们首先想到的一般是使用HTTPS代替HTTP，即TLS/SSL协议来保障应用层消息安全。不过针对一些图片网站，在权衡安全与性能后选择了后者，所以还在使用HTTP。

实际上TLS/SSL是由一系列加密算法及规范组成，对于性能优化我们从两个切入点来看，分别是如何选择加密算法以及加密时的密钥是如何传递的。

先来说下对加密算法的选择，目前主流的对称加密算法是AES（Advanced Encryption Standard），它在网站访问和压缩软件中均有被使用到，这也是我们首选的对称加密算法。AES 只支持 3 种不同的密钥长度，分别是 128 位、192 位和 256 位，它们的安全性依次升高，运算时间也更长。

那么只有数百比特的密钥，是如何对任意长度的明文加密呢？主流对称算法会将原始明文分成等长的多组明文，再分别用密钥生成密文，最后把它们拼接在一起形成最终密文。对于拼接方式上，为了防止攻击者发现分组后的规律，我们对每组密钥做随机变换。不同的分组模式也会影响 AES 算法的性能，GCM 模式能够充分利用多核 CPU 的并行计算能力，所以 AES_GCM 是我们的首选。

再来看下加密时的密钥是如何传递的，对于密钥传递宗旨是不能别轻易泄露。通常TCP三次握手后才能传递公钥TLS 建立会话的第 1 个步骤是在握手阶段协商出密钥。

由于密码学的演进越来越快，主流的密钥协商算法也在不断演变，比如早期的RSA密钥协商算法：当我们部署 TLS 证书到服务器上时，证书中包含一对公私钥，公钥会在握手阶段传递给客户端，RSA密钥协商算法会在客户端生成密钥的种子参数，并使用服务器的公钥加密后再传给服务器。由于公钥加密的消息仅能通过私钥解密，这样服务器解密后，双方就得到了相同的密钥，再用它加密应用消息。

不过这个算法最大的问题是一旦服务器的私钥泄露，过去被攻击者截获的所有 TLS 通讯密文都会被破解。为解决这个问题我们使用了DH密钥协商算法，DH每次握手都生成不同的对称密钥，因此能够实现前向保密。具体工作流程如下：服务器和客户端各自独立生成随机的数字作为私钥，根据公开的算法计算出各自的公钥并通过未加密的 TLS 握手发给对方，根据对方的公钥和自己的私钥，双方运算后能够获得相同的数字，这就得到了密钥。

不过由于DH算法的计算速度很慢，诞生了ECDH密钥交换算法，实现用更少的计算量计算出公钥以及最终的密钥，这也是当下广为使用的密钥协商算法。

在提升密钥协商算法性能的同时，另一个调优思路是减少协商次数。主要包括以下几种方式：

1. 保持连接减少连接次数：可以利用开启长连接实现。在请求头中加入 Connection: keep-alive。

2. 服务器缓存session密钥：优点是可以用sessionId快速校验并建立加密通讯；缺点是当 N 台服务器通过负载均衡提供 TLS 服务时，命中率低下。

3. 客户端的session ticket 持久化：服务器把密钥加密后作为 ticket 票据发给客户端，由客户端缓存密文并对session ticket 做持久化。

4. 升级版本到TLS1.3：它将 TLS 握手时间从 2 个 RTT 降为 1 个 RTT，并且它限制了目前已经不再安全的算法。

除此之外，对于证书方面，我们可以去掉证书链中的根证书，因为证书链太长可能会导致多一个RTT；我们还可以将算法分离、使用硬件加速卡代理计算，可以极大减轻接入层压力。

参考：

陶辉《系统性能调优必知必会》、《Web协议详解与抓包实战》

阮一峰《图解SSL/TLS协议》

欢迎你来我的公众号“才浅的每日python”和我一起讨论，也欢迎你来催更扯淡。日拱一卒，下一篇文不见不散。