上期我们说到对称加密算法
AES DES
目前使用的几乎都是AES-GCM（DES安全性太差基本处于废弃状态）
那除了这两种还有其他的吗？
答案是有的
ChaCha20
那这种算法与AES-GCM相比有什么特别之处呢？
上图展示的是CHACHA20-Poly1305 与 AES-GCM 两种对称加密算法的加密效率。
从这张图中我们可以看到 ChaCha20的加密速度比AES快了差不多3倍左右。那为什么现在的网站打开都基本上AES-GCM呢？
仔细看图我们可以看到，这是基于ARM架构的移动端CPU的加密速度。CHACHA20虽然在移动端CPU架构上加解密速度非常快，但是在传统>的x86架构上却比AES慢。再加上支持CHACHA20的证书比较难申请的到。所以导致了现在的网站打开都基本上AES-GCM。
不过如果业务主要针对是移动端并且服务端硬件配置比较好且申请到了支持CHACHA20的证书。由于该算法在移动端加解密速度非常快。
所以能够得到较好的用户体验。（虽然从运维的角度来说应该尽量降低服务器的负载，将负载转移到用户端比较好。主要还是看如何取
舍）
关于TLS1.3
首先我们了解下正常的https请求的流程:
从图片中我们可以看到http的延迟时间大概在56ms
而https因为是在http协议上额外增加了tls协议所以延迟时间大概需要168ms（http+tls）
由此可以看出使用https确实会给网站的打开速度产生影响，最直接的就是用户打开网站速度变慢。而且当用户不小心断开之后又要重>新走完这整一套的步骤。那有什么办法可以规避这种办法呢？
session id
session id是一种用户断线重连之后能快速建立连接的一种方法。原理非常简单，当用户与服务器第一次成功完成握手之后，服务器>端生成一个session id 自身保存一份，另外一份发送给客户端。当客户端断线重连之后客户端像服务端发送session id 如果服务端发
现这个id存在。则免去繁琐的tls握手步骤 直接连接。从图中我们也看到采用这样的方式延迟时间降低了50%左右
但是方法不适合分布式架构的业务，原因在于session id 是在每一台服务器中生成的。所以当客户端重连后连接到服务器的另外一台
后端业务服务器就会因为没有id 而重新进行一次完整握手。
session ticket
session ticket的原理与session id 相同只不过session ticket 不是生成id 而是根据服务器上的ticket key 加密一个数据blob发>送给客户端，然后客户端重连时发送blob给服务器，服务器解密这个blob来判断是否是重连用户从而免去繁琐的tls握手步骤。采取这>样的方式的好处就是我们可以将session key 存储在所有的分布式后端业务服务器上。这样不管用户重连到哪一台服务器都可以通过session key来解密判断是否为重连用户。
那我们有更简单方便的方法吗？
有的，那就是tls1.3！
如上图：
tls1.3是最新的tls协议版本。
废弃了很多年老安全性差的算法并且采用了更优秀的握手机制。
tls1.3 移除了RSA握手机制，采用了(EC)HDE 握手机制（RSA与DH的优缺点在（对称加密模式在关于TLS经验小结(上)中有介绍）
移除CBC对称加密模式，采用AEAD模式（对称加密模式在关于TLS经验小结(中)中有介绍）
以及其他的特性。具体详见
其中最瞩目的莫过于新的握手协商机制
TLS1.3
TLS1.2
如上图tls1.3协议将之前tls1.2需要的步骤整合在一起，然后集中传输。减少了握手次数，从而大幅减少了延迟时间。加快了网站访问
速度，使我们再也不用去纠结不上https不安全，上了https访问速度慢的历史性问题。
总结
从之前讲的算法到握手机制。使大家对整个tls协议有了一个大概的认识。从生产环境角度来说，采用ECDH
+ECDSA+AES-GCM的 ECC证书是目前在安全性和性能上都相对平衡的一种证书种类。本站的证书就是采用了ECC证书。
关于ECC证书可以查看
在此感谢峰哥的一次知识分享让我了解到了相关的知识（文章中的一些示例图也源于峰哥的ppt）
想具体了解大佬可以访问以下博客更深入的了解
完
