HTTP 3.0

TCP基礎的問題

1. TCP的 握手/斷開耗時

2. 多條TCP連接競爭頻寬

3. Header阻塞(HOLB)

開發原因

1. 完整的安全傳輸，TCP(1.5 RTT) + TLS1.2/1.3 (1~2 RTT)， 傳輸前至少就必須花費 3~4 RTT (Round Trip Time)。

2. 連線遺失封包問題 (head-of-line blocking , HOLB)。

3. 不繼續修改 TCP 原因主要是中間設備僵化，無法快速的支持與採用。

原名 HTTP-over-QUIC

後由 IETF 更名成 HTTP/3。

UDP 作為基礎傳輸層

使用 QUIC 協議，由 Google 提出。

基於中間設備仍主要支持 TCP 和 UDP，因此選擇了 UDP 作為基礎傳輸層。

主要優勢

1. Reduce connection establishment latency (減少建立連線所需的時間)

2. Improved congestion control (增進網路網路壅塞控管)

3. Multiplexing without head-of-line blocking (多路複用避免 HOLB)

4. Forward error correction (前向錯誤修正)

5. connection migration (移動中wifi與4G網路切換不需重新建立連線)

連線建立

QUIC 有效降低了 RTT 耗費

主要分為兩種：

1. 初始交握 - 1 RTT

第一次交握時，同時做金鑰交換並保存(cache)。

1. 最終與重複交握 - 0 RTT

只要用之前cache的金鑰做連接通過之後，就可以直接開始傳輸了。

但避免在傳輸時被破解(compromise)，為了前向保密的安全性，使用服務端產生的公鑰與客戶端產生的短期金鑰，產生新的前向保密金鑰，達到安全性。

多路複用

支持同一個連線，使用 Stream frames 進行多個 Stream 資料傳輸，由於基於UDP 為傳輸層，當其一 Stream 封包遺失時，只會影響自己，避免發生 head-of-line blocking。

封包遺失恢復

為了避免 TCP 發生的重傳岐異問題，使用新的編號機制來編排封包且嚴格遞增，

若發生少量封包遺失時，則可以依據其他封包資料重新組裝不需重傳，降低了 RTT 的耗費。

連線遷移

一般 TCP 為基礎的連線，手機上wifi 網路切換不同 3G、4G 時會發生連線失效，

QUIC 採用獨特的 Connection ID 設計，若發生斷開重連，即使IP不同，仍可透過 ID 來識別，恢復連線。