该分享主要两部分：
1.分析https的性能瓶颈点 2.根据瓶颈点的优化方案
性能分析
https比起http的缺点主要是慢和贵，慢主要体现在未经过任何优化的https比http要慢几百毫秒，在移动端，甚至有500毫秒以上。贵主要体现在计算性能和服务器成本，服务端需要不断做加解密操作。https比http多了一层tls协议，因此这些性能问题也主要是tls的问题。关务tls的握手过程和加解密过程，可以参考阮一峰的博客，笔者看过觉得通俗易懂，更能便于理解tls的性能优化点。
1.关于ssl握手过程
http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
2.关于数字签名
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
3.关于RSA原理
http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html
po出演讲中的两张图(图片来自演讲ppt)便于理解：
由上图中，我们可以看到https中主要有四个计算环节，证书校验、非对称密钥交换、对称加解密和完整性校验。证书校验保证双方的身份的合法性，非对称秘钥交换主要用来生成保密数据的对称秘钥，完整性主要保证数据的完整性，不被篡改。
从上图的握手耗时，我们可以看到在ECDHE_RSA 非对称密钥交换握手中，其中ServerKeyExchange过程，耗时2.4毫秒，在演讲者的性能试验中，CPU的一核每秒只能处理400多次。这里补充一下这个过程耗时严重的原因，ServerKeyExchange过程其实就是使用DH算法中，服务端使用RSA算法的私钥对DH参数做数字签名，这个过程因为使用服务端的私钥加密，私钥的位数一般是远大于公钥的，因为计算复杂度很高，就会非常耗时。同样在通用的RSA非对称秘钥中，服务端同样会因为需要使用私钥去解密客户端传来pre-master key，因而同样会存在耗时严重的问题。
对于握手耗时，演讲者也给出了其他计算过程的耗时实验统计。如下图
上图统计可以看出性能最好的是AES-128-GCM，性能最差的是AES-256-CBC，但即使它性能最差，它也只需要47微秒就能处理4000个字节，性能相比来说也还能接受。
根据上面的统计可以看出，非对称密钥交换过程的耗时占据了整体耗时75%左右，而对称加密对性能影响较小。
优化方案
简化握手过程
方式一：使用Session ID。Session ID由服务器生成并返回给客户端，客户端再次发起SSL握手时会携带上Session ID，服务端拿到后会从自己的内存查找，如果找到便意味着客户端之前已经发生过完全握手，是可以信任的，然后可以直接进行简化握手。
缺点：在使用Nginx时，只支持单机多进程间共享的Session Cache。假如接入用的是一台服务器、一台Nginx的话，那ID生成和查找都在一起，肯定是可以命中的，但是大部分特别是流量比较大的接入环境都是多台机器接入，那么当用户隔了较长时间后携带Session ID发起https请求时，可能落到了其他机器上而找不到之前服务器保存的Session ID，导致请求失败。
方式二：使用分布式Session Cache，服务端会将Session ID写入全局缓存中，比如redis缓存，这样用户下次发起握手时，可以直接从全局的缓存中查找到Session ID，提高成功率。可以参考的开源库：OpenResty，BoringSSL
缺点：消耗大量缓存。
同时上述两种方式中，都需要对openssl做改造，因为OpenSSL提供了一个Session Cache的callback可以回调，但是这个回调函数是同步的。这会拖累整体服务性能。BoringSSL中实现了Session Cache的异步查找，可以参考。
方式三：使用Session Ticket，Session Ticket由服务端加密分发给用户，只要服务端的机器都使用相同的秘钥，就可以保证简化握手的成功率。
缺点：服务端需要做解密，影响性能。
Session Ticket，Session ID和Session Cache都有一个共同点，都是基于内存的，但当客户端重启，浏览器tab关闭后又打开时，会导致Session数据丢失，所以可以采用如下方式：对于安全系数要求不是很高的业务可以控制Session数据存储在App的私有路径中，并且有秘钥开关随时关闭这个功能。
异步代理耗时计算
虽然简化握手能提高很多性能，但完全握手在总的握手比例中仍然很高，有30%。所以对完全握手可以把耗时算法分离出来交给计算集群去计算，这个过程是异步的，不需要同步等待计算结果返回。即将耗时图中ServerKeyExchange过程（设计到私钥加解密的过程）异步化。
工程实现：Nginx需要改造（这部分没怎么看懂，后面去了解下Nginx的工作流程）。对OpenSSL改造，需要对OpenSSL的协议栈进行修改，主要涉及到s3_srvr.c这个文件。OpenSSL1.1.0已经支持异步事件。
写在最后
我司使用的私有协议和tls协议中，tls的性能明显不如私有协议，目前服务端对tls应该还没有做优化，可以考虑使用这个分享中异步代理的方式来提高tls的处理性能。毕竟有不少客户会切到tls协议做请求的。
