HTTP 3.0
TCP基礎的問題
TCP的 握手/斷開耗時
多條TCP連接競爭頻寬
Header阻塞(HOLB)
開發原因
完整的安全傳輸，TCP(1.5 RTT) + TLS1.2/1.3 (1~2 RTT)， 傳輸前至少就必須花費 3~4 RTT (Round Trip Time)。
連線遺失封包問題 (head-of-line blocking , HOLB)。
不繼續修改 TCP 原因主要是中間設備僵化，無法快速的支持與採用。
原名 HTTP-over-QUIC
後由 IETF 更名成 HTTP/3。
UDP 作為基礎傳輸層
使用 QUIC 協議，由 Google 提出。
基於中間設備仍主要支持 TCP 和 UDP，因此選擇了 UDP 作為基礎傳輸層。
主要優勢
Reduce connection establishment latency (減少建立連線所需的時間)
Improved congestion control (增進網路網路壅塞控管)
Multiplexing without head-of-line blocking (多路複用避免 HOLB)
Forward error correction (前向錯誤修正)
connection migration (移動中wifi與4G網路切換不需重新建立連線)
連線建立
QUIC 有效降低了 RTT 耗費
主要分為兩種：
初始交握 - 1 RTT
第一次交握時，同時做金鑰交換並保存(cache)。
最終與重複交握 - 0 RTT
只要用之前cache的金鑰做連接通過之後，就可以直接開始傳輸了。
但避免在傳輸時被破解(compromise)，為了前向保密的安全性，使用服務端產生的公鑰與客戶端產生的短期金鑰，產生新的前向保密金鑰，達到安全性。
多路複用
支持同一個連線，使用 Stream frames 進行多個 Stream 資料傳輸，由於基於UDP 為傳輸層，當其一 Stream 封包遺失時，只會影響自己，避免發生 head-of-line blocking。
封包遺失恢復
為了避免 TCP 發生的重傳岐異問題，使用新的編號機制來編排封包且嚴格遞增，
若發生少量封包遺失時，則可以依據其他封包資料重新組裝不需重傳，降低了 RTT 的耗費。
連線遷移
一般 TCP 為基礎的連線，手機上wifi 網路切換不同 3G、4G 時會發生連線失效，
QUIC 採用獨特的 Connection ID 設計，若發生斷開重連，即使IP不同，仍可透過 ID 來識別，恢復連線。
Last updated