自學網絡協議(七):HTTPS的七次握手和九倍延時

HTTP已經慢慢淡化在互聯網協議中的作用。
因爲其作爲應用層協議,本身只是用於傳輸超文本的網絡協議,而不會提供任何安全上的保證 —— 這也使得【竊聽】和【中間人攻擊】成爲可能。

HTTP的不足導致了HTTPS的產生 —— 採用 安全套接字層 SSL保證數據傳輸的安全。不過現在隨着傳輸層安全協議的發展,我們已經用TLS取代了SSL。

HTTPS 可以看做是對 HTTP 協議的擴展,我們可以使用它在互聯網上安全地傳輸數據,然而 HTTPS 請求的發起方第一次從接收方獲取響應需要經過 4.5 倍的往返延遲(Round-Trip Time):
要知道爲什麼,我們需要先了解下另幾個相關的協議:

fg

TCP協議

應用層協議
其需要底層的傳輸協議爲其提供基本的數據傳輸功能。通常作爲HTTP的底層協議,其三次握手是爲了阻止錯誤的建立歷史連接
jt

TCP連接的雙方通過這【三次握手】確定TCP連接的初始序列號、窗口大小以及最大數據段,這樣通信雙方就能利用連接中的初始序列號保證雙方數據段的不重不漏、通過窗口大小控制流量、使用最大數據段避免IP協議對數據包的分片。


2014年提出了“TCP快啓” —— 在某些場景下通過一次通信建立TCP連接:
TCP 快啓策略使用存儲在客戶端的 TFO Cookie 與服務端快速建立連接。TCP 連接的客戶端向服務端發送 SYN 消息時會攜帶快啓選項,服務端會生成一個 Cookie 並將其發送至客戶端,客戶端會緩存該 Cookie,當其與服務端重新建立連接時,它會使用存儲的 Cookie 直接建立 TCP 連接,服務端驗證 Cookie 後會向客戶端發送 SYN 和 ACK 並開始傳輸數據,這也就能減少通信的次數。

fg

TLS

TLS 的作用是在可靠的 TCP 協議上構建安全的傳輸通道,其本身是不提供可靠性保障的,我們還是需要下層可靠的傳輸層協議。在通信雙方建立可靠的 TCP 連接之後,我們就需要通過 TLS 握手交換雙方的密鑰了

  1. 客戶端向服務端發送 Client Hello 消息,其中攜帶客戶端支持的協議版本、加密算法、壓縮算法以及客戶端生成的隨機數
  2. 服務端收到客戶端支持的協議版本、加密算法等信息後;
    1. 向客戶端發送 Server Hello 消息,並攜帶選擇特定的協議版本、加密方法、會話 ID 以及服務端生成的隨機數
    2. 向客戶端發送 Certificate 消息,即服務端的證書鏈,其中包含證書支持的域名、發行方和有效期等信息;
    3. 向客戶端發送 Server Key Exchange 消息,傳遞公鑰以及簽名等信息;
    4. 向客戶端發送可選的消息 CertificateRequest,驗證客戶端的證書;
    5. 向客戶端發送 Server Hello Done 消息,通知服務端已經發送了全部的相關信息;
  3. 客戶端收到服務端的協議版本、加密方法、會話 ID 以及證書等信息後,驗證服務端的證書;
    1. 向服務端發送 Client Key Exchange 消息,包含使用服務端公鑰加密後的隨機字符串,即預主密鑰(Pre Master Secret);
    2. 向服務端發送 Change Cipher Spec 消息,通知服務端後面的數據段會加密傳輸;
    3. 向服務端發送 Finished 消息,其中包含加密後的握手信息;
  4. 服務端收到 Change Cipher Spec 和 Finished 消息後;
    1. 向客戶端發送 Change Cipher Spec 消息,通知客戶端後面的數據段會加密傳輸;
    2. 向客戶端發送 Finished 消息,驗證客戶端的 Finished 消息並完成 TLS 握手;

TLS 握手的關鍵在於利用通信雙方生成的隨機字符串和服務端的公鑰生成一個雙方經過協商後的密鑰,通信的雙方可以使用這個對稱的密鑰加密消息防止中間人的監聽和攻擊,保證通信的安全。

在 TLS 1.2 中,我們需要 2-RTT 才能建立 TLS 連接,但是 TLS 1.3 通過優化協議,將兩次往返延遲降低至一次,大幅度減少建立 TLS 連接所需要的時間,讓客戶端可以在 1-RTT 之後就能向服務端傳輸應用層數據。

fg

HTTP協議

在已經建立好 TCP 和 TLS 通道上傳輸數據是比較簡單的事情,HTTP 協議可以直接利用下層建立的可靠的、安全的通道(TCP連接)傳輸數據。客戶端通過 TCP 的套接字接口向服務端寫入數據,服務端在接收到數據、進行處理後通過相同的途徑返回。因爲整個過程需要客戶端發送請求以及服務端返回響應。

當客戶端和服務端僅處理一次 HTTP 請求時,從 HTTP 協議本身我們已經無法進行優化。不過隨着請求的數量逐漸增加,目前流行的 HTTP/2 就可以複用已經建立的 TCP 連接減少 TCP 和 TLS 握手帶來的額外開銷。


現在“局勢”就很明瞭了:

  1. TCP 協議需要通過三次握手建立 TCP 連接保證通信的可靠性(1.5-RTT);
  2. TLS 協議會在 TCP 協議之上通過四次握手建立 TLS 連接保證通信的安全性(2-RTT);
  3. HTTP 協議會在 TCP 和 TLS 上通過一次往返發送請求並接收響應(1-RTT);
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章