Quic協議介紹和淺析
一，Quic全稱是什麼？
QUIC 全稱 Quick UDP Internet Connection, 是Google制定的一種基於 UDP 協議的低時延網際網路應用層協議。
二，Quic的優勢和應用場景
1，為什麼需要Quic：
- 近三十年來，tcp協議發展得非常緩慢
- 很多網路中間層，比如防火牆、閘道器等，都強依賴於tcp指定的各類規則，所以tcp的修改很容易由於這些中間環節的存在而受到干擾。
- tcp是由作業系統在核心層面實現的， 導致tcp的迭代受限於作業系統的升級。
2，Quic 相比現在廣泛應用的 tls+http+tcp 協議有如下優勢 ：
- 減少了 TCP 三次握手及 TLS 握手時間。
- 改進的擁塞控制。
- 避免隊頭阻塞。
3，應用場景
- 弱網環境的時候能夠提升 20% 以上的訪問速度。
- 頻繁切換網路的情況下，不會斷線，不需要重連，使用者無任何感知。
三，Quic協議原理
1，0RTT 建連
先宣告一點，如果一對使用QUIC進行加密通訊的雙方此前從來沒有通訊過，0RTT是不可能的。
所以第一次C和S建連還是會走正常的tls握手流程，但過了一會兒或者一段時間後，C又想和S通訊，此時C已經有了剛剛和S協商出來的金鑰（可能是存在記憶體or外存）。C就會利用剛剛的金鑰K1來和S加密首次資料，在第二個RTT期間，S會和C協商出新的金鑰K2，作為接下來的通訊金鑰。
2，沒有歧義的重傳
TCP 重傳的 包 的 sequence number 和原始的 包 的 Sequence Number 是保持不變的，也正是由於這個特性，引入了 Tcp 重傳的歧義問題。
超時事件 RTO 發生後，客戶端發起重傳，然後接收到了 Ack 資料。由於Sequence Number一樣，這個 Ack 到底是原始請求的響應還是重傳請求的響應呢？這就間接導致了RTT計算的歧義。
Quic 使用 Packet Number 代替了 TCP 的 sequence number，並且每個 Packet Number 都嚴格遞增，也就是說就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經不是 N，而是一個比 N 大的值，這就解決了RTT計算的歧義問題。
3，保證包的順序
QUIC 引入了一個叫 Stream Offset 的概念。
假設 Packet N 丟失了，發起重傳，重傳的 Packet Number 是 N+2，但是它的 Stream 的 Offset 依然是 x，這樣就算 Packet N + 2 是後到的，依然可以將 Stream x 和 Stream x+y 按照順序組織起來。
4，解決ack delay
TCP 的 RTT 計算：
Quic的RTT計算：
5，隊頭阻塞
拿http2舉例，
http2 在一個 TCP 連線上同時傳送 4 個 請求。其中 請求1 已經正確到達，並被應用層讀取。但是 請求2 的第三個 tcp包丟失了，為了保證資料的順序，需要傳送端重傳第 3 個包才能通知應用層讀取接下去的資料，雖然這個時候 請求3 和 請求4 的全部資料已經到達了接收端，但都被阻塞住了。
Quic基於UDP，各個請求之間相互獨立，比如 請求2 丟了一個 Pakcet，不會影響 請求3 和 請求4，不存在 TCP 隊頭阻塞。
四，Quic和http3
QUIC 協議最初是由Google發起的專案，後面慢慢成為了 HTTP/2-encrypted-over-UDP 協議。
當 IETF 開始進行協議標準化工作時，協議被分為兩層：傳輸部分和 HTTP 部分。這個想法的初衷是考慮到該傳輸協議也可用於傳輸其他資料，而不僅僅用於 HTTP 協議。
社群中大家使用 iQUIC 和 gQUIC 這樣的非正式名稱來引用這些不同版本的協議，以便將IETF 和 Google提出的QUIC 協議分開。
通過 iQUIC 傳送 HTTP 請求的協議被稱為HTTP-over-QUIC，即HTTP3。
五，參考資料
- 下一代通訊協議：Quic
- QUIC協議是如何做到0RTT加密傳輸的
- Web伺服器快速啟用QUIC協議
- QUIC協議原理分析
- QUIC在騰訊的實踐及效能優化
- 七牛雲 QUIC 推流方案如何實現直播 0 卡頓
- 當我們在討論http隊頭阻塞時，我們在討論什麼？
- QUIC官方文件
- QUIC協議規範https://www.wolfcstech.com/2017/01/13/QUIC%E5%8D%8F%E8%AE%AE%E8%A7%84%E8%8C%83/