HTTP 3 ，它來(lái)了，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解決了什么問(wèn)題呢？從上世紀(jì)90年代至今，互聯(lián)網(wǎng)一直按照一成不變的模式發(fā)展著。使用ipv4進(jìn)行路由，使用tcp進(jìn)行連接層面的擁塞控制，并保證其傳輸?shù)目煽啃?，使用tls層進(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)容越來(lái)越大，用戶(hù)對(duì)傳輸?shù)臅r(shí)延，帶寬提出越來(lái)越大的要求。
tcp雖然也在擁塞控制上提出了一些優(yōu)秀的擁塞控制算法，如BBR但是限制于其對(duì)操作系統(tǒng)內(nèi)核版本的要求，tcp 的 TFO，windows操作系統(tǒng)又支持不好等。導(dǎo)致想要切換成更高效的協(xié)議成本巨大。
這里列出幾個(gè)主要的矛盾。
1、協(xié)議歷史悠久導(dǎo)致中間設(shè)備僵化。
2、依賴(lài)于操作系統(tǒng)的實(shí)現(xiàn)導(dǎo)致協(xié)議本身僵化。
3、建立連接的握手延遲大。
4、隊(duì)頭阻塞。
QUIC概述
QUIC孕育而生，其拋開(kāi)了TCP直接采用UDP，如一些擁塞算法，可靠性保證機(jī)制，不再依賴(lài)操作系統(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)老舊
有些防火墻只允許通過(guò) 80 和 443，不放通其他端口。NAT 網(wǎng)關(guān)在轉(zhuǎn)換網(wǎng)絡(luò)地址時(shí)重寫(xiě)傳輸層的頭部，有可能導(dǎo)致雙方無(wú)法使用新的傳輸格式。因?yàn)橥ㄐ艆f(xié)議棧都是固化到操作系統(tǒng)中的，只能通過(guò)內(nèi)核參數(shù)進(jìn)行調(diào)整，但是這樣的調(diào)整極其有限，如果想要新加協(xié)議，只能重新編譯內(nèi)核。而現(xiàn)實(shí)是，可能還有一些Centos5 還作為某些古董公司的線(xiàn)上服務(wù)器。另外，windows xp 可能還是某些事業(yè)單位的辦公電腦上裝的操作系統(tǒng)，盡管xp的時(shí)代已經(jīng)過(guò)去20年了。另外TCP Fast Open 也在2013年就提出了，但是windows操作系統(tǒng)也有些不支持。
建立連接的握手延遲大
知道一個(gè)首次https網(wǎng)站的訪問(wèn)都要有哪些步驟嗎？dns解析需要1個(gè)RTT，TCP三次握手，HTTP 302 跳轉(zhuǎn) HTTPS又需要RTT，TCP重新握手。TLS握手再消耗2個(gè)。解析CA的DNS（因?yàn)闉g覽器獲取到證書(shū)后，有可能需要發(fā)起 OCSP 或者 CRL 請(qǐng)求，查詢(xún)證書(shū)狀態(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ù)沒(méi)響應(yīng)之前不能發(fā)第二個(gè)請(qǐng)求。而HTTP2 的出現(xiàn)，帶來(lái)了多路復(fù)用的解決方案，就是將消息分為多個(gè)stream。這樣，可以多個(gè)stream同時(shí)傳送。 -
TCP的對(duì)頭阻塞一個(gè)數(shù)據(jù)包丟了，下面的數(shù)據(jù)包就是不會(huì)確認(rèn)收到，這個(gè)沒(méi)法改變，因?yàn)門(mén)CP協(xié)議棧早就這樣定好了，無(wú)法改變。所以基于TCP的HTTP2 在處理4層的對(duì)頭阻塞問(wèn)題上也是無(wú)能為力。 -
TLS的對(duì)頭阻塞TLS 協(xié)議都是按照 record 來(lái)處理數(shù)據(jù)的，如果一個(gè) record 中丟失了數(shù)據(jù)，也會(huì)導(dǎo)致整個(gè) record 無(wú)法正確處理。這個(gè)目前也沒(méi)有很好的解決方法。
基于以上的原因，QUIC選擇了UDP。沒(méi)有了三次握手，在應(yīng)用層面完成了傳輸?shù)目煽啃?，擁塞控制還有TLS的安全性。只要應(yīng)用軟件的客戶(hù)端和服務(wù)端支持就行，繞開(kāi)了操作系統(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ì)話(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)門(mén)CP的數(shù)據(jù)是流，確認(rèn)機(jī)制是 seq和ack。QUIC使用 Packet Number 代替了 TCP 的 sequence number，并且每個(gè) Packet Number 都嚴(yán)格遞增，也就是說(shuō)就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經(jīng)不是 N，而是一個(gè)比 N 大的值。而 TCP 呢，重傳 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不變，也正是由于這個(gè)特性，引入了 Tcp 重傳的歧義問(wèn)題。后面tcp引入了timestamp解決了這些問(wèn)題。
對(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
