SSL（“Secure Sockets Layer” 安全套接层）/TLS（“Transport Layer Security” 传输层安全协议）的基本思路采用的是公钥加密算法，原理：
客户端向服务器发送获取公钥的请求，服务端生成公钥和私钥，将公钥返回给客户端（这儿过程中请求和返回数据都是明文）；下次客户端发送请求用公钥加密，服务端用私钥解密客户端的请求数据
在这个过程中将存在两个问题:
1、如何保证公钥不会被篡改？
将公钥放在数字证书中，只要数字证书没有被篡改就公钥就安全。
2、如何减少每次请求的时长（每一次请求都需要先获取公钥）？
每一次对话，客户端与服务端约定好对话密钥，对话密钥是对称加密的，运算速度会非常的快，用它加密请求信息。
服务器的公钥将只用于获取对话密钥本身，以减少加密算法所消耗的时长。
SSL/TLS协议的基本过程：（1、2两步又称为握手阶段）
1. 客户端向服务端索要公钥、验证公钥的合法性
2. 双方约定对话密钥
3. 双方通过对话密钥进行信息加密
握手阶段的详细过程
一、客户端首次请求（Client Hello）
第一步是客户端向服务端发送Client Hello消息，消息内容：
支持的协议版本号（SSL Version）
客户端生成的随机数（Client Random1）
客户端支持的加密套件（Support Ciphers）比如：RSA加密算法、DH加密算法
支持的压缩算法
支持的一些SSL/TLS扩展 （sever_name等）
SSL Version，用于服务端验证支持的协议版本号。 Client Random1，随机数用于后面对话密钥的生成。 Support Ciphers，用于服务端选择支持的加密算法。 压缩算法，用于压缩的算法。
客户端请求中原本是不包括服务器域名的，也就是说，理论上只能包含一个服务器，对于支持多个虚拟机的服务器来说，这并不方便，不能知道向哪个服务器请求证书。为了解决这个问题，在Client Hello报文中了，扩展信息中，增加了sever_name这个扩展信息，通过域名进行区分。
二、服务器回应（Sever Hello、Certificate、Server Key Exchange、Server Hello Done）
服务端收到客户端的请求之后向客户端返回数据：
确定加密通信使用的通信版本
服务端生成的随机数（Sever Random）
确定双方使用的加密算法和压缩算法
支持的一些SSL/TLS扩展
服务器发送Sever Hello后，向客户端发送证书信息（Certificate）
服务器证书（Certificate）
服务器发送Certificate后，开始发送sever key exchange，向客户端发送生成密钥的信息。这个发送只限于使用DH算法（DH算法生成的密钥是由客户端参数和服务端参数根据规则计算得出），如果是RSA算法不需要发送此请求。
服务器DH参数（Sever Key Exchange）
当服务器发送Sever Hello Done，表明所有的参数发送完成。
PS：此为单向验证，若是双向验证，需要在Sever Hello Done之前发送Certificate Request，表示需要客户端提供证书，内容为：
客户端应当提供的证书类型
服务端可以接受的证书列表
三、客户端回应（Client Key Exchange、 Change Chiper Spec、Encrypted Handshake Message）
客户端接收到服务器的证书之后，将对接收到的证书进行校验，若发现证书不是可信机构颁发或者域名不正确、证书已过期，将由客户端进行选择是否继续。若证书没有问题向服务端发送消息：
客户端Client Key Exchange生成的一个随机数（Pre Master Secret）
客户端传输改变通知（Change Chiper Spec）
客户端第一个加密报文（Encrypted Handshake Message）
Client Key Exchange生成一个随机数，如果采用的是RSA加密方式则取出证书中的公钥，生成随机数。如果采用的是DH算法则使用双发的DH加密参数和规则生成随机数。Change Chiper Spec，通知服务端以后报文按照协商的加密方式传输。Encrypted Handshake Message，通过前两次的随机数以及最后一次的随机数（Pre Master Secret）使用确定的加密算法生成对话密钥 （Session Secret），使用对话密钥加密报文。
PS：如果是双向认证，客户端还会Certificate和Certificate Verify报文。Certificate是客户端的证书，Certificate Verify是客户端拥有的所有握手过程中的签名信息。服务端对证书以及信息进行确认，如果发现证书和信息有误则终止SSL/TLS连接。
四、服务端最后回应（New Session Ticket, Change Chiper Spec, Encrypted Handshake Message）
服务端收到客户端的加密报文之后进行解密和校验，若成功生成一个session ticket（解释见下文）。然后作出回应：
服务端传输改变通知（Change Chiper Spec）
服务端第一个加密报文（Encrypted Handshake Message）
Change Chiper Spec与客户端发送的含义一致，通知客户端。 Encrypted Handshake Message与客户端发送的第一报文含义一致，用于客户端进行报文验证。
客户端确定密钥以及验证成功之后，整个握手过程就基本完成，以后的报文都是通过协商好的密钥进行加密。
会话恢复（session ID 和 session ticket）
session ID
Session Identifier（会话标识符），是 TLS 握手中生成的 Session ID。服务端可以将 Session ID 协商后的信息存起来，浏览器也可以保存 Session ID，并在后续的 ClientHello 握手中带上它，如果服务端能找到与之匹配的信息，就可以完成一次快速握手。
session ticket
Session Identifier 机制有一些弊端，例如：1）负载均衡中，多机之间往往没有同步 Session 信息，如果客户端两次请求没有落在同一台机器上就无法找到匹配的信息；2）服务端存储 Session ID 对应的信息不好控制失效时间，太短起不到作用，太长又占用服务端大量资源。
而 Session Ticket（会话记录单）可以解决这些问题，Session Ticket 是用只有服务端知道的安全密钥加密过的会话信息，最终保存在浏览器端。浏览器如果在 ClientHello 时带上了 Session Ticket，只要服务器能成功解密就可以完成快速握手。
简单的描述了下会话恢复，SSL/TLS优化请参考这篇文章
参考资料
