HTTPS的主要缺點是需要設置連接，每次新的TLS連續都需要握手，以便創建共享的加密密鑰，這個握手過程在標准TCP的握手過程之上還需要兩個額外的來回過程，用這樣一個高延時的連接，在網站第一個字節傳輸之前需要三個來回就讓人感覺這個網站有點慢。
TLS有幾個特征可以用來消除額外的來回，比如重用一個會話session，兩個標准會話重用機制是 session IDs (RFC 5246) 和 session tickets (RFC 5077)，使用其中一個技術，一個客戶端可以重用之前創建的會話，這個會話是之前和服務器進行握手成功的，這樣可以減少一次來回過程。
基於SessionID的會話重用適合現代所有瀏覽器，FireFox和Chrome還支持 session tickets，服務器端的支持也廣泛使用，nginx, Apache, HAProxy, IIS等等都支持session ID 和session ticket。
Session ID重用
重用一個加密的會話是很容易，前提是客戶端和服務器端都保存了會話key，通過每個連接給出的唯一標識，服務器知道一個進來的連接是否已經在之前創建過，如果服務器在會話中也已經有會話key，它就能重用。
Session ID需要服務器保存會話狀態如會話key等，這樣下次連接才能復用，這就需要服務器保存很多狀態信息，耗費了大量內存。
Session ID共享復用在Apache中可以通過SSLSessionCache 配置，在nginx可以通過ssl_session_cache設置。
Session ticket重用
在會話ticket復用中，服務器不用為每個session保存狀態，它用一個blob數據保存狀態，然后將它發給客戶端用來維護后來連接，會話ticket允許服務器將其存儲狀態委托給客戶端，類似HTTP cookie一樣。
一個會話ticket是一個加密的數據blob，其中包含需要重用的TLS連接信息，如會話key等，它一般是使用ticket key加密，因為ticket key服務器端也知道，在初始握手中服務器發送一個會話ticket到客戶端，存儲到客戶端本地，當重用會話時，客戶端發送會話ticket到服務器，服務器解密然后重用會話。
Session Ticket的安全考慮
會話ticket有潛在的安全問題，一些TLS加密組件如ECDHE-RSA-AES128-SHA256提供一個安全屬性成為向前安全forward secrecy，如果黑客獲得了服務器的證書私鑰，他們也不能獲得會話來破解。
使用TLS 會話ticket，偷竊了ticket key1后不會允許黑客來解密先前的會話，這是的ticket key非常有價值，為了保持向前安全forward secrecy, ticket key應該經常輪換。
會話ticket重用在Apache中可以用SSLTicketKeyDefault 配置，在nginx中使用ssl_session_tickets，它們都沒有自動輪換ticket key的自動機制，只能通過重啟apache nginx來重新加載或創建新的隨機key。
負載平衡
使用負載平衡器時，這些復用技術會遇到挑戰，對於一個服務器復用一個連接，它需要先前會話的key，如果先前會話在其他服務器上，新的服務器必須得到原來會話的key。
這個問題被CloudFlare 和 Twitter使用系統產生一個集中統一的key來解決，ticket key被一個集中的統一的服務器定期創建，安全地發給所有服務器，實現會話ticket共享需要你的架構有一個定制系統的抉擇。
總結
降低創建一個連接的來回過程使得網站加載速度提高，對於使用HTTPS的網站，會話存儲可以用於提高連接創建的速度，而正確的實現方式，才能讓頁面加載時間更漂亮的縮短，特別是在有負載平衡的場合 。
喜歡這篇文章？歡迎打賞~~
