完整的 HTTPS 的通信

TLS握手过程：

明文----->非对称加密----->对称加密

第一步，浏览器给出TLS协议版本号、一个客户端生成的随机数1（Client  random），以及客户端支持的加密方法。（明文通讯）

第二步，服务器确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数2（Server random）。（明文通讯） 

第三步，浏览器确认数字证书有效，然后生成一个新的随机数3（Pre-master secret），并使用数字证书中的公钥加密这个随机数，发给服务器。（使用非对称加密算法） 

        浏览器确认数字证书有效：浏览器和操作系统内部内置了很多CA机构的证书，是否篡改、是否在有效期内、域名和访问的网站是否匹配。

第四步，服务端使用自己的私钥，获取客户端发来的随机数（即Premaster secret）。

        双方就都有三个一模一样的随机数，前两个是明文发送的，最后客户端生成的这个是使用证书中的公钥密文发送的。

第五步，客户端和服务器根据约定的加密方法，使用前面的三个随机数经过特定的算法，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

        对话密钥，又叫做会话密钥，其实就是讲之前通讯中的三个随机数生成一个密钥（对称加密）

三个随机数----->第三个是使用非对称加密---->相同的算法------->会话密钥

第六步：客户端和服务器都会第一次使用会话密钥加密一个消息发送给对方。 

备注：客户端收到服务端发送的Certificate 报文后首先会校验证书的合法性：

• 证书路径信任链逐级校验通过（证书确由可信 CA 认证签发）；
• 签名解密成功（确系证书持有者亲笔）；
• 从签名解析出的摘要和证书公开内容的摘要一致（证书内容完整，未被篡改）；
• 主题子域与 URL 中的 HOST 一致，综上确保访问的网站是来自预期目标服务器且非劫持或钓鱼。

 session的恢复：

        握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。

        session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。

上图中，客户端给出session ID，服务器确认该编号存在，双方就不再进行握手阶段剩余的步骤，而直接用已有的对话密钥进行加密通信。 

session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的。

        上图中，客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到sessionticket以后，解密后就不必重新生成对话密钥了。