前言：本文只讲Https实现的流程。
现在有一个场景：一个人A要其他人B,C,D交流，但是A希望的是他和B交流不会被C,D知道;自然与C的交流也不愿意被B,D知道。
于是乎，人们想出了第一个方法，就是在A和B,C,D交流的时候分别都产生一个公钥，传送给B,C,D，双方都根据这个公钥加密解密对话。这样的话，交流的时候大家就可以通过公钥去解析对话，得到各自要说的话，但是这个想法很快就被否决了，因为传送公钥的过程并不安全，可能出现中间人，在公钥传送过程，被拦截并被别人篡改对话，最后返回给A，这样的A得到对话就是被篡改过了。
后来，人们想了另一个办法，就是非对称加密算法，简而言之，通过非对称加密算法生成一个私钥和一个公钥，只要B,C,D是用公钥加密的数据，A这边都能通过私钥来做解密（对于非对称加密算法来说,用私钥加密的数据，都能用公钥进行解密，而用公钥加密的数据，只能用私钥进行解密），这样就可以实现B,C,D传送到A都能安全（B->A），因为中间人没有私钥就不能对传输数据进行解密然后重新加密给A。（注意：这个时候A->B,C，D端的传输是不安全的，因为所有人都能获得公钥）但是这样就有一个问题出来，还是跟第一个方法一样，我们怎么确保公钥的传输过程是安全的呢？
这个时候，A,B,C,D商量着说：要不这样办吧，把E找来，他比较值得信任，他生产一个公钥（证书）出来，并且在上面盖章说明这个公钥是他生成，如果上面的盖章变了，则说明这个公钥也不能被使用了。
因此流程就变成这样：
A->E申请一个证书，并事前存放在A那，而B在交流前则会在本地存有一个ca盖章库，在B与A交流的时候，A就把ca发送给B，B收到后就开始检查ca的内容，和检查ca上盖章是否和B本地上盖章库一致，如果一致，则B则又通过ca与自己产生随机数（密钥）加密得到数据发送到A，告诉A，B端确认通过；然后A端接收信息后用本地存的私钥进行解密，若成功则告诉B端成功。至此，A-B端开始真正数据解析。
当你明白以上的流程，我们就这些转换成https的真正的流程。此时A就是我们的服务器，B,C,D就是一个个客户端。
最后总结：https的流程大致就是如此，在这里需理解到利用第三方机构的证书来保证通信传输的安全性，但我们也需知道在开始通信的前两步也是不安全的，直到第三步通信后。
在https虽然经过了加密，但https并不是真正的安全，比如一些大公司，通过控制入口，将请求中的证书进行替换，也就是证书劫持，将本地证书给替换掉，当你发出请求时，实际上用的是公司的证书，与外部服务器进行通信，然后再把请求返回给你。