TLS加密通信，
开始使用协商的秘钥进行加密通信
1、服务器也可以要求验证客户端，即实现双向的验证，
2、会话缓存握手过程，为了建立握手的速度，减少协议带来的性能方面的降低和资源方面的消耗，TLS协议有两类会话缓存机制，分别是会话session ID 和会话记录session titcket 。
Session ID有服务器端支持，协议中的标准字段，因此基本的所有服务都支持，服务区段保存会话 ID 以及协商的通信信息， Nginx中的IM内存约保存4000个session ID机器相关的信息，占服务器资源较多。 另一种就是Session ticket需要服务器和客户端都支持，术语一个扩展字段，将协商的通信信息加密之后发送给客户端保存，秘钥只有服务器知道，占用服务器的资源最少。这两者对比，主要是保存协商信息位置的不同，类似http中session与从cookie。二者都存在的情况下，（nginx实现）优先使用session_ticket
握手过程如下：
（1）会话标识SessionID
如果客户端和服务器之间之前建立了连接，服务器会在握手成功之后返回SessionID ,并且保存默认的参数在服务器中
如果客户端再次需要和该服务器建立连接，则在Client_hello中 session_id中携带记录信息，发送给服务器。
服务器根据收到的session Id 检索缓存的记录，如果没有检索到缓存过期，则按照正常的握手进程进行。
如果检索到对应点缓存激励，则返回change_cipher_spec与 encrypted_handshake_message信息，两个信息作用类似，encrypted_handshack_messag是到当前通信参数与 master_sercet的hash值。但是如果客户能够验证通过服务器加密数据，则客户端同样发送change_spec和encrypted_handshake_message信息。服务器验证数据通过，则握手建立连接成功，开始进行征程的数据加密通信。
（2）会话记录session_ticket
如果客户端和服务器支架之前建立可连接，服务器会在new_session_ticket数据中携带加密的session_ticket信息，客户端保存。
如果客户端再次需要和服务器建立连接，则在client_hello 中扩展字段session_ticket中携带加密信息，一起发送给服务器，服务器解密session_ticket数据，如果解密失败按照正常的握手进行。
如果解密成功，session-ticket则返回 change_cipher_spec和encrypted_handshake_message信息，两个信息作用于session Id中类似。
如果客户端能工验证通过服务器加密数据，则客户端同样发送change_cipher_spec和encrypted_handshake_message信息。
服务器验证数据通过，则我哦手建立成功，开始进行正常的数据加密通信。
3、重新连接
重新建立连接，就是放弃之前建立的连接，（TLS连接） 从新进行身份认证和秘钥写上个的过程，特点是不需要断开当前的数据传输就可以重新身份认证，更新秘钥和算法，因此服务端存储和缓存的信息都可以保存，
服务器端重新建立一般情况是客户端访问受保护的数据发生，基本过程如下：
客户端和服务端建立了有效TLS连接 ，并开始通信。
客户端访问受保护的信息
服务器端返回helo-request信息
客户端收到hello_request 信息之后发送client-helo 信息，开始建立连接
（4）秘钥计算
涉及的参数 random client random_server Pre_master Master sercet key material 计算秘钥时，服务器和客户端都具体有这些基本的信息 ，计算流程如下：
客户端使用RSA或者Diffe-Hellman等加密算法生成Pre-Master
Pre-Master结合Random sercet 和Random-server 两个随机数进行迭代生成 ker material 下面是详细的内容解释：
PreMaster sercet 前面两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在 Client hello 阶段，客户端会发送一份加密套件列表和当前支持的TLS协议的版本号给服务端 ，而且使用的是明文传输，如果握手数据包被破解之后，攻击者很可能篡改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解，所以服务端要对密文中解密出来的对 PerMaster 版本号跟之前的Client hello阶段版本号进行对比， 如果版本号变低，则说明数据被篡改，则立即日内至发送任何消息。
不管是客户端还是服务器端都要使用随机数，这样生成的随机秘钥每次都会不一样，对于RAS秘钥来说，pre-master-key 本身就是一个随机数，再加上helo消息中的随随机数三个随机数通过一个秘钥导出器最终生成一个对称秘钥。一个伪随机可能不完全是伪随机，但是三个伪随机加起来可能十分接近伪随机数，