大家好，我是蓝胖子，在之前# MYSQL 是如何保证binlog 和redo log同时提交的？这篇文章里，我们可以从mysql的设计中学会如何让两个服务的调用逻辑达到最终一致性，这也是分布式事务实现方式之一。今天来看看我们能够从httpsd设计中得到哪些启发可以用于业务系统开发中。
https原理分析
首先，我们来看下https 涉及到的握手流程，在http的三次握手基础上，https还要进行tls的握手协议。在经过tls握手后，后续客户端和服务端发送的消息也就都是加密的了。我们着重要看的就是tls握手过程。tls协议目前主要现存两个版本，我们都来看看。
tls1.2
首先，来看下tls1.2 协议下的握手流程。
在了解程序逻辑究竟为何如此设计之前，要搞懂我们这样做的目的。https之所以要用tls，无非就是为了两个目的，
- 第一个目的: 让客户端能够认证服务端的身份信息，防止访问不安全的钓鱼网站。
- 第二个目的: 对服务器和客户端之间的消息进行加密，不再明文传输。
对于第一个目的，可以通过数字证书解决，CA 向服务器颁发一个证书，在一次tls握手中，服务器会向客户端发放自己的证书，客户端在得到证书后向CA验证证书的合法性，如果合法，说明服务端是经过认证的，可以信任。
验证的原理则是通过公私钥加密算法和摘要算法，CA有自己的私钥，同时CA会将自己的公钥公布出去，然后CA对服务器的证书内容进行摘要计算，再对摘要进行私钥加密，私钥加密的内容只有公钥才能解密，私钥加密的内容称为签名信息，这段签名信息同样也会包含在证书中。
客户端在得到服务端证书的时候，通过对签名信息进行解密，得到证书的摘要信息，这个时候再对证书的内容进行摘要计算，看计算结果是否和解密得到的摘要信息一致，如果证书内容没被篡改的话，相同摘要算法得到的摘要信息应该是一致。
对于第二个目的，则是可以通过加密算法，为了性能，会话加密将会采用对称加密算法，这里的关键是得到一个会话密钥，但是为了安全性，会话密钥又不能直接采用明文进行传输。
所以tls是这样做的，客户端首先会生成一个随机数A，并已明文传递给服务端，服务端也会生成一个随机数B，并且把它传递给客户端，同时还会把数字证书传给客户端。数字证书中包含了服务端的公钥信息，客户端在收到证书取出其中公钥后，会再次生成一个随机数，随机数被称作pre master key ，这个随机数会通过证书中的公钥进行加密，传递给服务端，服务端会用自己的私钥对其进行解密，因为公钥加密的信息只能私钥才能解密，所以在服务端私钥不会泄露的情况下，黑客即使截获了报文，依然不能知道pre master key的值。
接着，便是服务端和客户端用相同的计算密钥的算法，以客户端和服务端的随机数A，B和pre master key生成相同的会话密钥，用于后续的通信进行对称加密。整个过程如下图所示，可以看到密钥的产生过程经历两次RTT，才会开始进行后续的请求发送。
请求一来一回称为一次RTT
关于tls1.2的完整握手过程，我也总结一个流程图，方便大家参考，
tls1.3
在了解了tls1.2的握手过程后，我们来看看tls1.3在握手过程中有哪些优化。tls1.3 废弃了一些密钥交换算法如RSA，默认用椭圆曲线ECDHE密钥交换算法，将密钥的产生时间从两次RTT缩短至了一次RTT。
废弃RSA密钥交换算法的另一个原因在于，使用RSA密钥交换算法，如果黑客持续截获https报文，如果数字证书中的公钥对应的服务端私钥泄露，那么黑客便可以将之前的历史报文进行解密，RSA密钥交换算法不具有
前向安全性。前向安全指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏
如下图所示，客户端和服务端都各自生成自己的一对用于ECDHE计算的随机公私钥和各自的随机数， 然后将各自的公钥和随机数传给对方，之后便可以各自通过这些信息计算出相同的会话密钥。
ECDHE 密钥交换具有前向安全性，因为参与会话密钥计算的私钥每次都是随机生成的，这样即使黑客获得了当前的私钥，也不能对历史https报文进行解密。
可以看到，ECDHE密钥交换算法只交换了各自的公钥便可以计算出会话密钥，即使黑客截获了消息内容，但是只有公钥，没有私钥也不能计算出会话密钥。我将tls1.3的握手过程总结到了下面的流程图中，大家可以参考下，
im消息加密解决方案
以上是https消息加密的实现原理，如果我们也想在消息传输中进行加密和认证处理，比如在im系统中对im消息加密，那么完全可以参考https的实现原理。
我们需要为im系统做消息加密和消息防篡改的设计。
对于消息加密，参考https的交互，可以采用对称加密对后续会话内容进行对称加密，比如AES算法，加密的密钥可以采用ECDHE密钥交换算法，具有前向安全性。
对于消息防篡改，可以采用消息摘要算法，常见的摘要算法有md5，sha256，通过对加密后的报文进行摘要计算，在获取到报文的第一时间就通过对比计算出的消息摘要和报文中的消息摘要 来判断报文是否经过篡改。
更进一步，还可以设计一组只有im客户端和服务端知道的密钥，让客户端在进行摘要计算时，加上密钥，也就是通过类似hmac的消息认证算法，进行摘要计算，这样在对端接收到报文后，正常情况下，通过相同的消息认证算法和密钥会得到相同的摘要结果，如果计算的摘要结果和报文中的摘要结果不一致，那么说明报文不是从信任的客户端发来的，直接拒绝，这样便达到了消息认证的目的。
📢📢注意，在im消息系统设计时，对于消息认证我们没有去生成一个数字证书，对于https，客户端对服务端的消息认证却是通过数字证书的认证完成的。
这是因为在通信前，客户端和服务端对于彼此是未知的，它们只能通过一个已知的第三方机构CA完成这样的认证。
而我们自己写的程序就不一样，可以设计一个密钥让im客户端和im服务端程序都使用这个密钥对报文进行hmac消息认证，因为密钥只有自己的程序知道，如果得到的认证码和计算出的不一致，那么消息必然来自第三方。