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消息中的隨隨機數三個隨機數通過一個秘鑰導出器最終生成一個對稱秘鑰。一個偽隨機可能不完全是偽隨機，但是三個偽隨機加起來可能十分接近偽隨機數，