HTTP/3

TCP創建鏈接時間

最先你們使用TCP來運輸HTTP，TCP想必你們很熟悉了，須要三次握手，創建了TCP虛擬通道，那麼這三次握手須要幾個RTT（Round Trip Time的縮寫，通俗地說，就是通訊一來一回的時間）時間呢？

 

 

 

一去 （SYN）

二回 （SYN+ACK）

三去 （ACK）

至關於一個半來回，故TCP鏈接的時間 = 1.5 RTT 。

 

HTTP交易時間

這意味着，用戶在瀏覽器裏輸入的網址URL，直到時間流逝了1.5RTT以後，TCP纔開始運輸HTTP Request，瀏覽器收到服務器的HTTP Response，又要等待的時間爲：

一去（HTTP Request）

二回 （HTTP Responses）

故HTTP的交易時間 = 1 RTT

HTTP通訊時間總和 = TCP鏈接時間 + HTTP交易時間 = 1.5 RTT + 1 RTT = 2.5 RTT

 

安全加密通訊

隨着互聯網的爆發式增加，人類發現徹底明文傳輸的HTTP通訊很不安全。作爲OSI七層參考模型的現實實現的TCP/IP協議，在設計之初沒有考慮安全加密的環節。

互聯網先驅Netscape公司，創造性發明瞭SSL（Secure Socket Layer），SSL位於TCP與HTTP之間，作爲HTTP的安全供應商，全權負責HTTP的安全加密工做。

IP / TCP / SSL / [HTTP]

各個通訊模塊之間的站位如上所示，將HTTP用[ ]括起來，表示HTTP被SSL安全加密了。

隨着SSL的名氣攀升，互聯網標準化組織IETF，以爲SSL是一個好東西，就拿來用了。 

但SSL最初只是用於加密HTTP的，IETF以爲這是一個硬傷，爲何不能用來作爲全部應用層協議的安全供應商呢？來傳輸郵件、文件、新聞等等。實現這一點很簡單，只要在協議裏增長一個Application Protocol 類型字段。

在Application Protocol 有一個類型是「IP」, 意味着TLS不只能夠運輸應用層協議如HTTP、FTP，還能夠運輸IP，這就是Cisco Any Connect的應用場景。

 

TLS (Transport Layer Security)

因而，IETF在SSL 3.0版本的基礎上，從新設計並命名了這個協議，其全新的名字爲TLS，最初的版本爲1.0版本。從其名字就能夠看出，其核心使命就是保證傳輸層的安全。各個通訊部門成員的佔位與SSL佔位一致：

IP / TCP / TLS / [HTTP]

到目前爲止，瀏覽器支持的TLS版本爲TLS 1.0、1.一、1.2，固然版本越高越成熟、越安全。

 

HTTPS

一般將TLS安全保護的HTTP通訊，稱之爲HTTPS，以區別於沒有TLS安全防禦的HTTP明文通訊。

 

來看看自從引入了TLS安全防禦，看看HTTPS通訊的RTT增長到了多少？

TLS 1.2

以1.2 版本爲例，看看HTTPS通訊一共要消耗幾個RTT時間？

1. 瀏覽器給服務器發送的Client Hello消息（一去）

2. 服務器給瀏覽器發送的Server Hello消息（二回）

3. 瀏覽器給服務器發送的Key Exchange消息（三去）

雙方的HTTP通訊將使用TLS加密了。一共花費了1.5個RTT時間。

HTTPS通訊時間總和 = TCP鏈接時間 + TLS 鏈接時間 + HTTP交易時間 = 1.5 RTT + 1.5 RTT + 1 RTT = 4 RTT

 

若是瀏覽器與服務器物理距離很近，RTT < 10 ms，即便4 RTT最大也不過40 ms的時間，用戶壓根感受不到慢。

若是瀏覽器與服務器相隔上萬千米，一個RTT時間一般在200ms以上，4RTT時間一般在1秒以上，用戶會明顯感受到網速慢了。

 

HTTP 1.x

瀏覽器從服務器獲取的一個頁面，一般由不少資源連接所組成。

服務器給瀏覽器推送的第一個頁面，頁面裏一般嵌入了圖片資源文本連接、以及動態頁面資源連接、或第三方網站的連接資源，還須要瀏覽器根據這些文本連接內容，去連接所對應的服務器，繼續下載連接所對應的內容。

瀏覽器一般採用的流程是，從新創建一個TCP鏈接、TLS鏈接、HTTP交易。

這又是一個漫長的4RTT等待過程，用戶看到瀏覽器完整頁面的時間爲

完整頁面加載時間 = 4RTT *2 = 8RTT

 

HTTP /2

天然有人會問，既然第一次頁面與第二次頁面都是同一個網站服務器，爲什麼第二次頁面要從新創建一個TCP鏈接，一個TLS鏈接？

若是重用第一個TCP鏈接，那麼就少了1.5 RTT + 1.5 RTT = 3 RTT的時間。

這是一個好主意，就是用戶的多個HTTP Request請求，使用同一個邏輯通道進行運輸，這樣會大大減小從新創建鏈接所花費的時間。

可是，這樣會帶來一個反作用，多個HTTP流使用同一個TCP鏈接，遵照同一個流量狀態控制。只要第一個HTTP流遭遇到擁塞，剩下的HTTP流壓根無法發出去，這就是頭部阻塞（Head of line Blocking）。

 

IP / UDP / QUIC

QUIC協議集成了TCP可靠傳輸機制、TLS安全加密、HTTP /2 流量複用技術，其頁面的加載時間爲2.5 RTT時間。

此外，完成QUIC交易的鏈接的Session ID會緩存在瀏覽器內存裏，若是用戶再次打開該頁面，無需創建TLS鏈接，直接使用緩存Session ID 對應的加密參數，服務器能夠根據Session ID在緩存裏查找對應的加密參數，並完成加密。

換句話說，重連TLS鏈接是一個0 RTT 事件，用戶所要等待的頁面加載事件 = HTTP交易事件 = 1 RTT。

 

HTTP /3

這一次IETF又以爲QUIC是一個好東西，可是但願QUIC不只能夠運輸HTTP，還能夠運輸其它協議，把QUIC與HTTP分離，最終各合夥人的佔位以下所示：

IP / UDP / QUIC / HTTP

這樣總體的頁面加載時間爲2 RTT。

 

TLS 1.3

IETF的QUIC標準集成了TLS 1.3版本，1.3版本更簡練，創建TLS鏈接再也不須要1.5 RTT，而只須要1 RTT，是由於瀏覽器第一次就把本身的密鑰交換的素材發給服務器，這樣就節省了第三次消息，少了0.5個RTT時間。

頁面的總體加載時間 = TLS 1.3鏈接時間 + HTTP交易時間 = 1RTT + 1RTT = 2 RTT

重連頁面的加載時間 = HTTP交易時間 = 1 RTT

上文協議的進化過程就是人類與RTT鬥爭史，目標是減小用戶等待頁面加載時間、同時保證用戶看到的頁面安全，沒有在傳輸過程當中被偷窺、篡改。

 

HTTP /3所帶來的挑戰

99%+以上的手機移動終端、電腦終端，都使用私有IP，都須要NAT設備來完成私有IP與全球IP的轉換。這意味着NAT設備一般會記憶用戶的通訊狀態，一旦用戶完成了通訊，NAT設備會釋放這些記憶。

對於基於TCP的HTTP、HTTPS傳輸，NAT設備能夠根據TCP報文頭的SYN / FIN狀態位，知道通訊何時開始，何時結束，對應記憶的開始、記憶的結束。

可是基於UDP傳輸的HTTP/3，NAT設備收到流量會知道鏈接何時開始，可是卻沒法知道流量何時結束。

NAT設備的記憶若是短於用戶會話時間，則用戶會話會中斷。

NAT設備的記憶若是大大長於用戶會話時間，則意味着NAT設備的端口資源會白白被佔用！

最直接的解決方案是，在QUIC的頭部模仿TCP的SYN/FIN狀態，讓沿途的NAT設備知道會話何時開始、何時結束。但這須要升級全球全部的NAT設備的軟件