QUIC協定對比 TCP/UDP 協定

QUIC協定是HTTP3引入的，所以需要了解HTTP的版本迭代。

HTTP1.x

隊頭阻塞：下個請求必須在前一個請求返回後才能發出，導致頻寬無法被充分利用，後續請求被阻塞（HTTP 1.1 嘗試使用流水線（Pipelining）技術，但先天 FIFO（先進先出）機制導致當前請求的執行依賴於上一個請求執行的完成，容易引起隊頭阻塞，並沒有從根本上解決問題）
協定開銷大：header裡攜帶的內容過大，且不能壓縮，增加了傳輸的成本
傳輸不安全：採用文字形式傳輸，所有傳輸的內容都是明文，且使用者端和伺服器端都無法驗證對方的身份，這在一定程度上無法保證資料的安全性
單向請求：只能單向請求，使用者端請求什麼，伺服器返回什麼
HTTP 1.0 和 HTTP 1.1 的區別：

HTTP 1.0：僅支援保持短暫的TCP連線（連線無法複用）；不支援斷點續傳；前一個請求響應到達之後下一個請求才能傳送，存在隊頭阻塞
HTTP 1.1：預設支援長連線（請求可複用TCP連線）；支援斷點續傳（通過在 Header 設定引數）；優化了快取控制策略；管道化，可以一次傳送多個請求，但是響應仍是順序返回，仍然無法解決隊頭阻塞的問題；新增錯誤狀態碼通知；請求訊息和響應訊息都支援Host頭域

HTTP2

解決 HTTP1.x 的一些問題，但是解決不了底層 TCP 協定層面上的隊頭阻塞問題。

二進位制傳輸：二進位制格式傳輸資料解析起來比文字更高效
多路複用：重新定義底層 http 語意對映，允許同一個連線上使用請求和響應雙向資料流。同一域名只需佔用一個 TCP 連線，通過資料流（Stream）以幀為基本協定單位，避免了因頻繁建立連線產生的延遲，減少了記憶體消耗，提升了使用效能，並行請求，且慢的請求或先傳送的請求不會阻塞其他請求的返回
Header壓縮：減少請求中的冗餘資料，降低開銷
伺服器端可以主動推播：提前給使用者端推播必要的資源，這樣就可以相對減少一點延遲時間
流優先順序：資料傳輸優先順序可控，使網站可以實現更靈活和強大的頁面控制
可重置：能在不中斷 TCP 連線的情況下停止資料的傳送

缺點：HTTP 2中，多個請求在一個TCP管道中的，出現了丟包時，HTTP 2的表現反倒不如HTTP 1.1了。因為 TCP 為了保證可靠傳輸，有個特別的「丟包重傳」機制，丟失的包必須要等待重新傳輸確認，HTTP 2出現丟包時，整個 TCP 都要開始等待重傳，那麼就會阻塞該TCP連線中的所有請求。而對於 HTTP 1.1 來說，可以開啟多個 TCP 連線，出現這種情況反到只會影響其中一個連線，剩餘的 TCP 連線還可以正常傳輸資料

HTTP3

HTTP 是建立在 TCP 協定之上，所有 HTTP 協定的瓶頸及其優化技巧都是基於 TCP 協定本身的特性，HTTP2 雖然實現了多路複用，底層 TCP 協定層面上的問題並沒有解決（HTTP 2.0 同一域名下只需要使用一個 TCP 連線。但是如果這個連線出現了丟包，會導致整個 TCP 都要開始等待重傳，後面的所有資料都被阻塞了），而 HTTP3 的 QUIC 就是為解決 HTTP2 的 TCP 問題而生。

TCP和UDP回顧

1、TCP 是什麼

TCP：全稱為傳輸控制協定，是一種面向連線的、可靠的、基於位元組流的傳輸層通訊協定，由 IETF 的 RFC 793 定義。TCP 是面向連線的、可靠的流協定。

面向連線（存在三次握手）
只能進行對等的資料傳輸
面向位元組流（TCP 不像 UDP 一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以位元組流方式進行傳輸）
可靠傳輸（依靠 TCP 的段編號以及確認序號）
擁塞控制（網路出現擁塞的時候，TCP 能夠減小向網路注入資料的速率和數量，緩解擁塞）
提供全雙工通訊（通訊雙方的應用程式在任何時候都能傳送資料）
存在隊頭阻塞（使用序列號來標識資料的順序，資料必須按照順序處理）

2、UDP 是什麼？

UDP：全稱為使用者資料包協定，與 TCP 協定一樣用於處理封包，是一種面向無連線不可靠的協定。關注把資料包文傳輸出去，不關心是否安全到達。

面向無連線（不需要三次握手）
支援一對多，多對多，多對一
不可靠（原因：通訊都不需要建立連線、沒有擁塞控制所以網路條件不好的情況下可能會導致丟包）
傳輸資料高效

QUIC 對比 TCP/UDP 的優缺點

QUIC 協定是 Google 提出的一套基於 UDP 的開源協定，它彙集了 TCP和 UDP 的優點，傳輸高效並且可靠。

1、QUIC 的優點

（1）迭代更新快

TCP 和 UDP 協定是作業系統核心實現的，部署進度慢。QUIC直接基於使用者端實現，能實現快速迭代更新

（2）沒有隊頭阻塞的多路複用

TCP 使用序列號來標識資料的順序，資料必須按照順序處理，可能會造成隊頭阻塞。HTTP2 支援多路複用，但是由於強制使用 TLS，還存在一個 TLS 協定層面的隊頭阻塞，QUIC 最基本的傳輸單元是 Packet，不會超過 MTU 的大小，整個加密和認證過程都是基於 Packet 的，不會跨越多個 Packet。這樣就能避免 TLS 協定存在的隊頭阻塞。Stream 之間相互獨立，比如 Stream2 丟了一個 Pakcet，不會影響 Stream3 和 Stream4，所以也不存在 TCP 隊頭阻塞。

（3）握手更迅速

TCP需三次握手才能建立連線，有等待時延，如果用了TLS加密，還會進一步增加時延。QUIC採用了類似於TCP Fast Open的設計，在之前已經連線過的情況下可以無需握手，直接開始傳送資料，連線建立時延為0

（4）向前錯誤更正

QUIC和TCP一個主要的核心區別就是：TCP採用重傳機制，而QUIC採用糾錯機制。如果發生丟包的話，TCP首先需要一個等待延時來判斷髮生了丟包，然後再啟動重傳機制，在此期間會對連線造成一定的阻塞（並且TCP視窗是緩慢增大的，Web這種突發性快速連線情況下視窗會相對較小），從而影響傳輸時間。而QUIC採用了一種腦洞極大的向前錯誤更正（FEC）方案，類似於RAID5，將N個包的校驗和（互斥或）建立一個單獨的封包傳送，這樣如果在這N個包中丟了一個包可以直接恢復出來，完全不需要重傳，有利於保證高速性，N可以根據網路狀況動態調整

（5）連線保持

TCP 連線是由四元組標識的（源 IP，源埠，目的 IP，目的埠），當其中一項發生改變，都需要重新建立和伺服器端的 TCP 連線。QUIC 連線不再以 IP 及埠四元組標識，而是以一個 64 位的亂數作為 ID 來標識，這樣就算 IP 或者埠發生變化時，只要 ID 不變，這條連線依然維持著。這就意味著：在IP地址和埠變化的情況下（比如從Wi-Fi切換到流量），可以無需重新建立連線，繼續通訊

（6）加密技術比TLS效能好，同時具有各種攻擊防禦策略。

（7）能實現證書壓縮，減少證書傳輸量，針對包頭進行驗證等。

2、QUIC 的不足

（1）QUIC 基於 UDP ，目前很多網路運營商會降低 UDP 包的優先順序，使得 UDP 丟包率特別高

（2）支援的瀏覽器少

QUIC協定 對比 TCP/UDP 協定