Https优化方案与测试结果

https 优化测试

背景

https 是基于http 和 ssl（安全套接字层） 的安全传输协议，使用ssl 协议作为会话层协议。这个协议最早是由网景公司 开发，但是随着网景的没落，现在由ietf负责维护，最初的版本也已经重新冠名（re-banded）tls（安全传输层协议） 1.0（1999年）。因此现在大部分协议是基于TLS的，尽管是相似的东西。

针对https，能够保证数据更加安全，但是副作用是访问会变慢（相对于http），因为服务端增加了更多的计算，客户端和服务端之间多了一层协议协商过程。因此，我们要做的优化主要是针对这里

优化点和优化方案

大概阐述了优化的几个方向，下面我来具体的展开讨论下。如有疏漏请指正。

同时，我也整理了一份针对https 的握手过程详解，可以帮助大家科普下。

客户端优化

客户端优化是针对发起 ssl client hello 的一端进行的优化。主要有两个大的方向：

• 减少请求次数，提高效率
• 优化加密效率

规避完整握手

针对减少请求次数，主要的一个点是 SSL Session 的复用，Client Hello 请求中的 Session ID可以唯一的区分一个ssl 会话的ID。这个ID在Client Say Hello的时候被填写，

如果是第一次与server发生会话，那么Session ID可以是空。 如果之前与ssl 服务器建立过会话，而且客户端开启了Session Ticket；并且Server cache了这个Session Ticket的时候，服务端与客户端的握手就会简化，省略掉pre master 交换的过程，直接复用之前的ssl 会话

优化加密效率

这里是一个比较复杂的点，我们先来看下有哪些过程可能耗时：

• 密钥协商阶段的非对称加密
• 协商过后的针对通信的对称加密

@协商密钥阶段

密钥协商过程中，客户端的计算量相对小：

1. 生成 random1
2. 生成 pre-master （填充过的随机数）
3. 根据服务端的 random2 和自己的 random1 还有 pre-master 生成 master-secret
4. 使用服务端通知的（经过验证的）公钥加密 pre-master

这个过程中大部分是在生成随机数，只有生成 master-secret 和 使用公钥加密 是消耗cpu 的。

@加密通信阶段

再看下ssl协商之后的过程中的加密方式，因为是采用之前协商后的secret 来进行对称加密通信，因此这里的加密算法显得尤为重要，基本上协商ssl之后的过程中一直会使用这个算法在进行加密和解密。目前采用的大部分是AES 128位密钥的方式，但是在某些不支持硬件AES加速的处理器上，性能还是有一定的限制

另一种加密方式是 chacha20.

ChaCha20-Poly1305是Google所采用的一种新式加密算法，性能强大，在CPU为精简指令集的ARM平台上尤为显著（ARM v8前效果较明显），在同等配置的手机中表现是AES的4倍（ARM v8之后加入了AES指令，所以在这些平台上的设备，AES方式反而比chacha20-Poly1305方式更快，性能更好），可减少加密解密所产生的数据量进而可以改善用户体验，减少等待时间，节省电池寿命等。

因此作为一个可选的方案，chacha20 可能对于一些老旧的机型（据连荣讲，还有很多在使用arm v7 的硬件），chacha20 更具优势。

服务端优化

服务端的优化有几个方向

• 规避完全握手
• 优化加密效率
• 优化证书验证流程

因为针对的是ssl 服务端优化，所以下面结合我们常用的http server Nginx（Tenginx）来详细的讨论下优化点

规避完整握手

服务端规避完全握手也是通过回复会话的方式，但是对于如何成功命中Session ID恢复会话，有两个点：

1. 开启 session ticket
2. 配置session cache

对于1来说，服务端基本都会开启。对于ngin