大型網站https實踐（下）

用戶只需要完成TCP三次握手建立TCP連接就能夠直接發送HTTP請求獲取應用層數據，此外在整個訪問過程中也沒有需要消耗計算資源的地方。

接下來看HTTPS的訪問過程，相比HTTP要復雜很多，在部分場景下，使用HTTPS訪問有可能增加7個RTT。

HTTPS首次請求需要的網絡耗時解釋如下：

1，三次握手建立TCP連接。耗時壹個RTT。

2，使用HTTP發起GET請求，服務端返回302跳轉到www.baidu.com。需要壹個RTT以及302跳轉延時。

a)大部分情況下用戶不會手動輸入www.baidu.com來訪問HTTPS，服務端只能返回302強制瀏覽器跳轉到https。

b)瀏覽器處理302跳轉也需要耗時。

3，三次握手重新建立TCP連接。耗時壹個RTT。

a)302跳轉到HTTPS服務器之後，由於端口和服務器不同，需要重新完成三次握手，建立TCP連接。

4，TLS完全握手階段壹。耗時至少壹個RTT。

a)這個階段主要是完成加密套件的協商和證書的身份認證。

b)服務端和瀏覽器會協商出相同的密鑰交換算法、對稱加密算法、內容壹致性校驗算法、證書簽名算法、橢圓曲線(非ECC算法不需要)等。

c)瀏覽器獲取到證書後需要校驗證書的有效性，比如是否過期，是否撤銷。

5，解析CA站點的DNS。耗時壹個RTT。

a)瀏覽器獲取到證書後，有可能需要發起OCSP或者CRL請求，查詢證書狀態。

b)瀏覽器首先獲取證書裏的CA域名。

c)如果沒有命中緩存，瀏覽器需要解析CA域名的DNS。

6，三次握手建立CA站點的TCP連接。耗時壹個RTT。

a)DNS解析到IP後，需要完成三次握手建立TCP連接。

7，發起OCSP請求，獲取響應。耗時壹個RTT。

8，完全握手階段二，耗時壹個RTT及計算時間。

a)完全握手階段二主要是密鑰協商。

9，完全握手結束後，瀏覽器和服務器之間進行應用層(也就是HTTP)數據傳輸。

當然不是每個請求都需要增加7個RTT才能完成HTTPS首次請求交互。大概只有不到0.01%的請求才有可能需要經歷上述步驟，它們需要滿足如下條件：

1，必須是首次請求。即建立TCP連接後發起的第壹個請求，該連接上的後續請求都不需要再發生上述行為。

2，必須要發生完全握手，而正常情況下80%的請求能實現簡化握手。

3，瀏覽器需要開啟OCSP或者CRL功能。Chrome默認關閉了ocsp功能，firefox和IE都默認開啟。

4，瀏覽器沒有命中OCSP緩存。Ocsp壹般的更新周期是7天，firefox的查詢周期也是7天，也就說是7天中才會發生壹次ocsp的查詢。

5，瀏覽器沒有命中CA站點的DNS緩存。只有沒命中DNS緩存的情況下才會解析CA的DNS。

以上就是小編對大型網站https實踐的解析。