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 会话
优化加密效率
这里是一个比较复杂的点,我们先来看下有哪些过程可能耗时:
- 密钥协商阶段的非对称加密
- 协商过后的针对通信的对称加密
@协商密钥阶段
密钥协商过程中,客户端的计算量相对小:
- 生成 random1
- 生成 pre-master (填充过的随机数)
- 根据服务端的 random2 和自己的 random1 还有 pre-master 生成 master-secret
- 使用服务端通知的(经过验证的)公钥加密 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 serve