HTTP 3 便锨，它來了，QUIC（quick udp internet connection “快速 UDP 互聯(lián)網(wǎng)連接”）正如其名一樣恬砂，它就是快嘹叫。其正在標(biāo)準(zhǔn)化為新一代的互聯(lián)網(wǎng)傳輸協(xié)議。是由google提出的使用udp進(jìn)行多路并發(fā)的傳輸協(xié)議丛肢。
為什么需要QUIC
QUIC解決了什么問題呢围肥？從上世紀(jì)90年代至今，互聯(lián)網(wǎng)一直按照一成不變的模式發(fā)展著摔踱。使用ipv4進(jìn)行路由虐先，使用tcp進(jìn)行連接層面的擁塞控制，并保證其傳輸?shù)目煽啃耘煞螅褂胻ls層進(jìn)行安全加密和身份驗(yàn)證蛹批，使用http進(jìn)行應(yīng)用的數(shù)據(jù)傳輸撰洗。
這么多年的發(fā)展，這些協(xié)議只是小部分或者細(xì)節(jié)上有了改變腐芍，tcp提出了幾個(gè)新的擁塞控制算法差导，tls改變了加密方式，http層進(jìn)化出了h2猪勇。但是互聯(lián)網(wǎng)發(fā)展至今设褐，網(wǎng)絡(luò)傳輸?shù)膬?nèi)容越來越大，用戶對(duì)傳輸?shù)臅r(shí)延泣刹，帶寬提出越來越大的要求助析。
tcp雖然也在擁塞控制上提出了一些優(yōu)秀的擁塞控制算法，如BBR但是限制于其對(duì)操作系統(tǒng)內(nèi)核版本的要求椅您，tcp 的 TFO外冀，windows操作系統(tǒng)又支持不好等。導(dǎo)致想要切換成更高效的協(xié)議成本巨大掀泳。
這里列出幾個(gè)主要的矛盾雪隧。
1、協(xié)議歷史悠久導(dǎo)致中間設(shè)備僵化员舵。
2脑沿、依賴于操作系統(tǒng)的實(shí)現(xiàn)導(dǎo)致協(xié)議本身僵化。
3马僻、建立連接的握手延遲大庄拇。
4、隊(duì)頭阻塞韭邓。
QUIC概述
QUIC孕育而生丛忆，其拋開了TCP直接采用UDP，如一些擁塞算法仍秤，可靠性保證機(jī)制，不再依賴操作系統(tǒng)內(nèi)核可很，而是可以自定義诗力。
Quic 相比現(xiàn)在廣泛應(yīng)用的 http2+tcp+tls 協(xié)議有如下優(yōu)勢(shì)：
1、減少了 TCP 三次握手及 TLS 握手時(shí)間我抠。
2苇本、改進(jìn)的擁塞控制。
3菜拓、避免隊(duì)頭阻塞的多路復(fù)用瓣窄。
4、連接遷移纳鼎。
5俺夕、前向冗余糾錯(cuò)裳凸。
中間設(shè)備僵化和操作系統(tǒng)老舊
有些防火墻只允許通過 80 和 443，不放通其他端口劝贸。NAT 網(wǎng)關(guān)在轉(zhuǎn)換網(wǎng)絡(luò)地址時(shí)重寫傳輸層的頭部姨谷，有可能導(dǎo)致雙方無法使用新的傳輸格式。因?yàn)橥ㄐ艆f(xié)議棧都是固化到操作系統(tǒng)中的映九，只能通過內(nèi)核參數(shù)進(jìn)行調(diào)整梦湘，但是這樣的調(diào)整極其有限，如果想要新加協(xié)議件甥，只能重新編譯內(nèi)核捌议。而現(xiàn)實(shí)是，可能還有一些Centos5 還作為某些古董公司的線上服務(wù)器引有。另外瓣颅，windows xp 可能還是某些事業(yè)單位的辦公電腦上裝的操作系統(tǒng)，盡管xp的時(shí)代已經(jīng)過去20年了轿曙。另外TCP Fast Open 也在2013年就提出了弄捕，但是windows操作系統(tǒng)也有些不支持。
建立連接的握手延遲大
知道一個(gè)首次https網(wǎng)站的訪問都要有哪些步驟嗎导帝？dns解析需要1個(gè)RTT守谓，TCP三次握手，HTTP 302 跳轉(zhuǎn) HTTPS又需要RTT您单，TCP重新握手斋荞。TLS握手再消耗2個(gè)。解析CA的DNS（因?yàn)闉g覽器獲取到證書后虐秦，有可能需要發(fā)起 OCSP 或者 CRL 請(qǐng)求平酿，查詢證書狀態(tài)）再對(duì)CA進(jìn)行TCP握手，OCSP響應(yīng)悦陋。密鑰協(xié)商又是RTT蜈彼。當(dāng)然這種情況是最極端的，大部分情況下不是所有流程都需要走一遍的俺驶。（參考 大型網(wǎng)站的 HTTPS 實(shí)踐（二）-- HTTPS 對(duì)性能的影響）
隊(duì)頭阻塞
-
HTTP的對(duì)頭阻塞HTTP1.1 是一發(fā)一收幸逆，也就是第一個(gè)數(shù)據(jù)沒響應(yīng)之前不能發(fā)第二個(gè)請(qǐng)求。而HTTP2 的出現(xiàn)暮现，帶來了多路復(fù)用的解決方案还绘，就是將消息分為多個(gè)stream。這樣栖袋，可以多個(gè)stream同時(shí)傳送拍顷。 -
TCP的對(duì)頭阻塞一個(gè)數(shù)據(jù)包丟了，下面的數(shù)據(jù)包就是不會(huì)確認(rèn)收到塘幅，這個(gè)沒法改變昔案，因?yàn)門CP協(xié)議棧早就這樣定好了尿贫，無法改變。所以基于TCP的HTTP2 在處理4層的對(duì)頭阻塞問題上也是無能為力爱沟。 -
TLS的對(duì)頭阻塞TLS 協(xié)議都是按照 record 來處理數(shù)據(jù)的帅霜，如果一個(gè) record 中丟失了數(shù)據(jù)，也會(huì)導(dǎo)致整個(gè) record 無法正確處理呼伸。這個(gè)目前也沒有很好的解決方法身冀。
基于以上的原因，QUIC選擇了UDP括享。沒有了三次握手搂根，在應(yīng)用層面完成了傳輸?shù)目煽啃裕瑩砣刂七€有TLS的安全性铃辖。只要應(yīng)用軟件的客戶端和服務(wù)端支持就行剩愧，繞開了操作系統(tǒng)內(nèi)核版本這個(gè)硬骨頭。
QUIC核心特性
1娇斩、減去不必要的RTT
在HTTPS over TCP+TLS的時(shí)代仁卷。HTTPS需要3個(gè)RTT，在session 復(fù)用的情況下是2個(gè)RTT犬第。而QUIC做到了1RTT和會(huì)話復(fù)用的0RTT锦积。
QUIC的TLS只能使用TLS1.3，這就可以做到PSK的0RTT歉嗓。
2丰介、改進(jìn)的擁塞控制
TCP 的擁塞控制實(shí)際上包含了四個(gè)算法：慢啟動(dòng)，擁塞避免鉴分，快速重傳哮幢，快速恢復(fù)。其中TCP中擁塞控制是被編譯進(jìn)內(nèi)核中的志珍，如果想要更改就需要改變內(nèi)核參數(shù)橙垢，但是想要對(duì)已有的擁塞控制算法進(jìn)行更改就需要重新編譯內(nèi)核，Linux 4.9 中引入了基于時(shí)延的擁塞控制算法 BBR伦糯，這打破了以往是靠丟包驅(qū)動(dòng)的擁塞控制算法钢悲，但是想要在TCP中使用，就必須升級(jí)內(nèi)核至4.9以上舔株。
QUIC 協(xié)議當(dāng)前默認(rèn)使用了 TCP 協(xié)議的 Cubic 擁塞控制算法 [6]，同時(shí)也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制算法还棱。
QUIC和TCP的對(duì)比
-
可插拔：
QUIC 可以針對(duì)某個(gè)特殊場(chǎng)景使用不同的擁塞控制算法载慈，且切換十分簡(jiǎn)單。
TCP 想要切換擁塞控制算法是針對(duì)全局的珍手，要么更改內(nèi)核參數(shù)办铡，要么重新編譯內(nèi)核辞做。切換十分不便。 -
單調(diào)遞增的 Packet Number
QUIC 的數(shù)據(jù)包是單調(diào)遞增的Packet Number寡具。這幫助傳輸解決了重傳歧義秤茅，方便計(jì)算RTO，解決了TCP的隊(duì)頭阻塞童叠。因?yàn)門CP的數(shù)據(jù)是流框喳，確認(rèn)機(jī)制是 seq和ack。QUIC使用 Packet Number 代替了 TCP 的 sequence number厦坛，并且每個(gè) Packet Number 都嚴(yán)格遞增五垮，也就是說就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經(jīng)不是 N杜秸，而是一個(gè)比 N 大的值放仗。而 TCP 呢，重傳 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不變撬碟，也正是由于這個(gè)特性诞挨，引入了 Tcp 重傳的歧義問題。后面tcp引入了timestamp解決了這些問題呢蛤。
對(duì)于TCP而言惶傻，其RTO的計(jì)算方式: RTO的最佳是略大于RTT。（平滑 RTO：RFC793）由于RTT是經(jīng)常變化的顾稀，所以在計(jì)算RTO之前希望先計(jì)算出SRTT达罗。
SRTT （smoothed round-trip time） = ( α * SRTT ) + ((1 - α) * RTT)
其中α 從 0到 1（RFC 推薦 0.9），越大越平滑
RTO = min[ UBOUND, max[ LBOUND, (β * SRTT) ] ]
如 UBOUND為1分鐘静秆，LBOUND為 1 秒鐘粮揉， β從 1.3 到 2 之間
對(duì)于QUIC
