HTTPS雜記

互動過程

主要缺點

• 網路耗時（比HTTP多了互動次數）。

• 加解密耗時。

• 比HTTP慢幾百毫秒以上，頁面載入時間增加了50%，增加10%到20%的耗電

耗時分析

1. 可能瀏覽器需要由http跳轉到https的耗時，使用者使用http需要服務端返回302強制跳轉https。

2. 接著經過某種機制多次互動協商得到通訊金鑰，並且還會對證照的身份認證。

3. 可能瀏覽器需要到證照機構查詢證照狀態。

4. 可能還需要到DNS去解析出證照機構的IP。

5. 瀏覽器驗證證照合法性需要耗時。

6. 協商金鑰過程中服務端和客戶端都需要進行多次加解密運算雜湊運算，需要耗時。

完全握手優化

1. 非同步耗時的對稱加解密演算法，比如RSA，使用其他的專門的計算叢集或硬體加速。

2. 對稱加密耗時少，無需非同步化，選擇耗時少的演算法。

簡化握手

1. 對於已經完全握手過的客戶端可以將session id傳到伺服器，伺服器在記憶體中尋找是否已可信任。但叢集中存在session管理的問題，可用ip hash繫結客戶端也可以通過分散式快取解決。

2. 類似的還可以用session ticket機制，客戶端傳過來，服務端能解密成功即可信任。session ticket不存在管理問題，只要每臺伺服器都配置成相同金鑰，即不管發到哪臺都能解密成功。

-------------推薦閱讀------------

我的2017文章彙總——機器學習篇

我的2017文章彙總——Java及中介軟體

我的2017文章彙總——深度學習篇

我的2017文章彙總——JDK原始碼篇

我的2017文章彙總——自然語言處理篇

我的2017文章彙總——Java併發篇

------------------廣告時間----------------

公眾號的選單已分為“分散式”、“機器學習”、“深度學習”、“NLP”、“Java深度”、“Java併發核心”、“JDK原始碼”、“Tomcat核心”等，可能有一款適合你的胃口。

鄙人的新書《Tomcat核心設計剖析》已經在京東銷售了，有需要的朋友可以購買。感謝各位朋友。

為什麼寫《Tomcat核心設計剖析》

歡迎關注：