HTTP1.0

1.0的HTTP版本，是一種無狀態(tài)，無連接的應(yīng)用層協(xié)議。 HTTP1.0規(guī)定瀏覽器和服務(wù)器保持短暫的鏈接。

瀏覽器每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器處理完成以后立即斷開TCP連接(無連接)，服務(wù)器不跟蹤也每個(gè)客戶單，也不記錄過去的請(qǐng)求(無狀態(tài))。

這種無狀態(tài)性可以借助cookie/session機(jī)制來做身份認(rèn)證和狀態(tài)記錄。

HTTP1.0存在的問題

無法復(fù)用連接

每次發(fā)送請(qǐng)求，都需要進(jìn)行一次TCP連接，而TCP的連接釋放過程又是比較費(fèi)事的。這種無連接的特性會(huì)使得網(wǎng)絡(luò)的利用率變低。

隊(duì)頭阻塞(head of line blocking)

由于HTTP1.0規(guī)定下一個(gè)請(qǐng)求必須在前一個(gè)請(qǐng)求響應(yīng)到達(dá)之前才能發(fā)送，假設(shè)前一個(gè)請(qǐng)求響應(yīng)一直不到達(dá)，那么下一個(gè)請(qǐng)求就不發(fā)送，后面的請(qǐng)求就阻塞了。

HTTP1.1

HTTP1.1繼承了HTTP1.0的簡(jiǎn)單，克服了HTTP1.0性能上的問題。

長連接

HTTP1.1增加Connection字段，通過設(shè)置Keep-Alive保持HTTP連接不斷卡。避免每次客戶端與服務(wù)器請(qǐng)求都要重復(fù)建立釋放建立TCP連接。提高了網(wǎng)絡(luò)的利用率。

如果客戶端想關(guān)閉HTTP連接，可以在請(qǐng)求頭中攜帶Connection:false來告知服務(wù)器關(guān)閉請(qǐng)求。

管道化(pipelining)— 尷尬的假并行傳輸

HTTP1.1支持請(qǐng)求管道化(pipelining)。

基于HTTP1.1的長連接，使得請(qǐng)求管線化成為可能。 管線化使得請(qǐng)求能夠“并行”傳輸。

例如：

假如響應(yīng)的主體是一個(gè)html頁面，頁面中包含了很多img，這個(gè)時(shí)候keep-alive就了很大作用。能夠“并行”發(fā)送多個(gè)請(qǐng)求。(注意，這里的“并行”并不是真正意義上的并行傳輸)

需要注意的是：服務(wù)器必須按照客戶端請(qǐng)求的先后順序依次回送相應(yīng)的結(jié)果，以保證客戶端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容。

也就是說，HTTP管道化可以讓我們把先進(jìn)先出隊(duì)列從客戶端(請(qǐng)求隊(duì)列)遷移到服務(wù)端(響應(yīng)隊(duì)列)

如果，客戶端同時(shí)發(fā)了兩個(gè)請(qǐng)求分別獲取html和css，假如說服務(wù)器的css資源先準(zhǔn)備就緒，服務(wù)器也會(huì)先發(fā)送html，再發(fā)送css。 換句話來說，只有等到html響應(yīng)的資源完全傳輸完畢后，css響應(yīng)的資源才開始傳輸，不允許同時(shí)存在兩個(gè)并行的響應(yīng)。

可見，HTTP1.1還是無法解決隊(duì)頭阻塞(head of line blocking)的問題。同時(shí)“管道化”技術(shù)存在各種各樣的問題，所以很多瀏覽器要么根本不支持它，要么直接默認(rèn)關(guān)閉，并且開啟的條件很苛刻……而且好像實(shí)際也沒有什么用處。

真并行傳輸 — 瀏覽器優(yōu)化策略

HTTP1.1支持管道化，但是服務(wù)器也必須進(jìn)行逐個(gè)響應(yīng)的送回，這個(gè)是很大的一個(gè)缺陷。實(shí)際上，現(xiàn)階段的瀏覽器廠商采取了另外一種做法，它允許我們打開多個(gè)TCP的會(huì)話，也就是說，上圖我們看到的并行，其實(shí)是不同的TCP連接上的HTTP請(qǐng)求和相應(yīng)。這才是真正的并行!

很多人以為的連接數(shù)情況：

 

實(shí)際情況(china)：

 

 緩存處理 — 強(qiáng)緩存、協(xié)商緩存，啟發(fā)式緩存(新增)

此外，HTTP1.1還加入了緩存處理(強(qiáng)緩存和協(xié)商緩存)，新的字段如cache-control，支持?jǐn)帱c(diǎn)傳輸，以及增加了Host字段(使得一個(gè)服務(wù)器能夠用來創(chuàng)建多個(gè)Web站點(diǎn))

HTTP2.0

二進(jìn)制分幀

HTTP2.0通過在應(yīng)用層和傳輸層之間增加一個(gè)二進(jìn)制分層幀，突破了HTTP1.1的性能限制，改進(jìn)傳輸性能。

多路復(fù)用(鏈接共享)— 真并行傳輸

• 流(stream)：已建立連接上的雙向字節(jié)流。
• 消息：與邏輯消息對(duì)應(yīng)的完整的一系列數(shù)據(jù)幀。
• 幀(frame)：HTTP2.0通信的最小單位，每個(gè)幀包含頭部，至少也會(huì)標(biāo)識(shí)出當(dāng)前所屬的流(stream_id)

所有HTTP2.0通信都在一個(gè)TCP鏈接上完成，這個(gè)鏈接可以承載任意流量的雙向數(shù)據(jù)流。

每個(gè)數(shù)據(jù)流以消息的形式發(fā)送，而消息由一或多個(gè)幀組成。這些幀可以亂序發(fā)送，然后再根據(jù)每個(gè)幀頭部的流標(biāo)識(shí)符(Stream_id)重新封裝。

多路復(fù)用(連接共享)可能會(huì)導(dǎo)致關(guān)鍵字被阻塞，HTTP2.0里每個(gè)數(shù)據(jù)流都可以設(shè)置優(yōu)先級(jí)和依賴，優(yōu)先級(jí)高的數(shù)據(jù)流會(huì)被服務(wù)器優(yōu)先處理和返回客戶端，數(shù)據(jù)流還可以依賴其他的子數(shù)據(jù)流。

可見，HTTP2.0實(shí)現(xiàn)了真正的并行傳輸，它能夠在一個(gè)TCP上進(jìn)行任意數(shù)量的HTTP請(qǐng)求。而這個(gè)強(qiáng)大的功能基于“二級(jí)制分幀”的特性。

頭部壓縮

在HTTP1.X中，頭部元數(shù)據(jù)都是以純文本的形式發(fā)送的，通常會(huì)給每個(gè)請(qǐng)求增加500-8000字節(jié)的負(fù)荷。

比如cookie，默認(rèn)情況下，瀏覽器會(huì)在每次請(qǐng)求的時(shí)候，把cookie附在header上面發(fā)給服務(wù)器。

HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header_files表，既避免重復(fù)header的傳輸，又減少了需要傳輸?shù)拇笮　?/p>

高效的壓縮算法可以很大的壓縮header，減少發(fā)送包的數(shù)量從而降低延遲。

服務(wù)器推送

服務(wù)器除了最初請(qǐng)求的響應(yīng)外，服務(wù)器還可以額外向客戶端推送資源，而無需客戶端明確的需求。

HTTP3.0

Google搞了一個(gè)基于UDP協(xié)議的QUIC協(xié)議，并且使用在了HTTP/3上， HTTP/3之前的名稱為HTTP-over-QUIC。

早期Quic協(xié)議，存在IETF和Google兩個(gè)版本，直到它被證實(shí)命名為HTTP3.0

IETF的QUIC工作小組創(chuàng)造了QUIC傳輸協(xié)議。QUIC是一個(gè)使用UDP來替代TCP的協(xié)議。最初的時(shí)候，Google開始助力QUIC，其后QUIC更多地被叫做“HTTP/2-encrypted-over-UDP “。

社區(qū)中的人們已經(jīng)使用非正式名稱如iQUIC和gQUIC來指代這些不同版本的協(xié)議，以將QUIC協(xié)議與IETF和Google分開(因?yàn)樗鼈冊(cè)诩?xì)節(jié)上差異很大)。通過“iQUIC”發(fā)送HTTP的協(xié)議被稱為“HQ”(HTTP-over-QUIC)很長一段時(shí)間。

2018年11月7日，Litespeed的Dmitri宣布他們和Facebook已經(jīng)成功地完成了兩個(gè)HTTP/3實(shí)現(xiàn)之間的第一次互操作。Mike Bihop在該主題的HTTPBIS會(huì)話中的后續(xù)介紹可以在這里看到。會(huì)議結(jié)束時(shí)達(dá)成共識(shí)稱新名稱是HTTP/3!

0-RTT — QUIC協(xié)議相比HTTP2.0的最大優(yōu)勢(shì)

緩存當(dāng)前會(huì)話的上下文，下次恢復(fù)會(huì)話的時(shí)候，只需要將之前的緩存?zhèn)鬟f給服務(wù)器，驗(yàn)證通過，就可以進(jìn)行傳輸了。

0-RTT建連可以說是QUIC相比HTTP2最大的性能優(yōu)勢(shì)。

什么是0-RTT建連?

• 傳輸層0-RTT就能建立連接
• 加密層0-RTT就能建立加密連接

多路復(fù)用

QUIC基于UDP，一個(gè)連接上的多個(gè)stream之間沒有依賴，即使丟包，只需要重發(fā)丟失的包即可，不需要重傳整個(gè)連接。

更好的移動(dòng)端表現(xiàn)

QUIC在移動(dòng)端的表現(xiàn)比TCP好，因?yàn)門CP是基于IP識(shí)別連接，而QUIC是通過ID識(shí)別鏈接。 無論網(wǎng)絡(luò)環(huán)境如何變化，只要ID不便，就能迅速重新連上。

加密認(rèn)證的根文 — 武裝到牙齒

TCP協(xié)議頭沒有經(jīng)過任何加密和認(rèn)證，在傳輸過程中很容易被中間網(wǎng)絡(luò)設(shè)備篡改、注入和竊聽。

QUIC的packet可以說武裝到了牙齒，除了個(gè)別報(bào)文，比如PUBLIC_RESET和CHLO，所有報(bào)文頭部都是經(jīng)過認(rèn)證的，報(bào)文Body都是經(jīng)過加密的。

所以只要對(duì) QUIC 做任何更改，接收端都能及時(shí)發(fā)現(xiàn)，有效地降低了安全風(fēng)險(xiǎn)。

向前糾錯(cuò)機(jī)制

QUIC協(xié)議有一個(gè)非常獨(dú)特的特性，稱為向前糾錯(cuò)(Foward Error Connec，F(xiàn)EC)，每個(gè)數(shù)據(jù)包除了它本身的內(nèi)容之外還包括了其他數(shù)據(jù)包的數(shù)據(jù)，因此少量的丟包可以通過其他包的冗余數(shù)據(jù)直接組裝而無需重傳。

向前糾錯(cuò)犧牲了每個(gè)數(shù)據(jù)包可以發(fā)送數(shù)據(jù)的上限，但是帶來的提升大于丟包導(dǎo)致的數(shù)據(jù)重傳，因?yàn)閿?shù)據(jù)重傳將會(huì)消耗更多的時(shí)間(包括確認(rèn)數(shù)據(jù)包丟失，請(qǐng)求重傳，等待新數(shù)據(jù)包等步驟的時(shí)間消耗)。

例如：

• 我總共發(fā)送三個(gè)包，協(xié)議會(huì)算出這個(gè)三個(gè)包的異或值并單獨(dú)發(fā)出一個(gè)校驗(yàn)包，也就是總共發(fā)出了四個(gè)包。
• 當(dāng)其中出現(xiàn)了非校驗(yàn)包丟失的情況，可以通過另外三個(gè)包計(jì)算出丟失的數(shù)據(jù)包的內(nèi)容。
• 當(dāng)然這種技術(shù)只能使用在丟失一個(gè)包的情況下，如果出現(xiàn)丟失多個(gè)包，就不能使用糾錯(cuò)機(jī)制了，只能使用重傳的方式了。

問題歸納

HTTP1.1的合并請(qǐng)求(如CSSsprites)是否適用于HTTP2.0

沒有必要。

在頭部壓縮技術(shù)中，客戶端和服務(wù)器均會(huì)維護(hù)兩份相同的靜態(tài)字典和動(dòng)態(tài)字典。

在靜態(tài)字典中，包含了常見的頭部名稱與值的組合。靜態(tài)字典在首次請(qǐng)求時(shí)可以使用。那么現(xiàn)在頭部的字段就可以被簡(jiǎn)寫成靜態(tài)字典中相應(yīng)字段的index。

而動(dòng)態(tài)字典跟連接的上下文相關(guān)，每個(gè)HTTP/2連接維護(hù)的動(dòng)態(tài)字典不盡相同。動(dòng)態(tài)字典可以在連接不停地進(jìn)行更新。

也就是說，原本完整的HTTP報(bào)文頭部的鍵值或字段，由于字典的存在，現(xiàn)在可以轉(zhuǎn)換成索引index，在相應(yīng)的端再進(jìn)行查找還原，也就起到了壓縮的作用。

所以，同一個(gè)鏈接上產(chǎn)生的請(qǐng)求和響應(yīng)越多，動(dòng)態(tài)字典累積得越全，頭部壓縮的效果也就越好，所以針對(duì)HTTP/2網(wǎng)站，最佳實(shí)踐是不要合并資源。

另外，HTTP2.0多路復(fù)用，使得請(qǐng)求可以并行傳輸，而HTTP1.1合并請(qǐng)求的一個(gè)原因也是為了防止過多的HTTP請(qǐng)求帶來的阻塞問題。而現(xiàn)在HTTP2.0已經(jīng)能夠并行傳輸了，所以合并請(qǐng)求也就沒有必要了。

為什么要有HTTP3.0：HTTP/2底層TCP的局限帶來的問題

由于HTTP/2使用了多路復(fù)用，一般來說，同一個(gè)域名下只需要使用一個(gè)TCP鏈接，但當(dāng)這個(gè)連接中出現(xiàn)了丟包的情況，就會(huì)導(dǎo)致HTTP/2的表現(xiàn)情況反倒不如HTTP/2了。

原因是： 在出現(xiàn)丟包的額情況下，整個(gè)TCP都要開始等待重傳，導(dǎo)致后面的所有數(shù)據(jù)都被阻塞。

但是對(duì)于HTTP/1.1來說，可以開啟多個(gè)TCP連接，出現(xiàn)這種情況只會(huì)影響其中一個(gè)連接，剩余的TCP鏈接還可以正常傳輸數(shù)據(jù)。

由于修改TCP協(xié)議是不可能完成的任務(wù)。

如何在Chrome中啟用 QUIC 協(xié)議

MTF在資源服務(wù)器和內(nèi)容分發(fā)節(jié)點(diǎn)都已經(jīng)啟用了 HTTP3.0 協(xié)議，根據(jù) 用戶瀏覽器 向下兼容，強(qiáng)烈建議您在Chrome瀏覽器開啟實(shí)驗(yàn)性QUICK協(xié)議支持，體驗(yàn)加速效果：

在瀏覽器地址欄：輸入chrome://flags

找到Experimental QUIC protocol，將Default改為Enabled

 總結(jié)

HTTP 1.0

• 無狀態(tài)，無連接
• 短連接：每次發(fā)送請(qǐng)求都要重新建立tcp請(qǐng)求，即三次握手，非常浪費(fèi)性能
• 無host頭域，也就是http請(qǐng)求頭里的host，
• 不允許斷點(diǎn)續(xù)傳，而且不能只傳輸對(duì)象的一部分，要求傳輸整個(gè)對(duì)象

HTTP 1.1

• 長連接，流水線，使用connection:keep-alive使用長連接
• 請(qǐng)求管道化
• 增加緩存處理(新的字段如cache-control)
• 增加Host字段，支持?jǐn)帱c(diǎn)傳輸?shù)?/li>
• 由于長連接會(huì)給服務(wù)器造成壓力

HTTP 2.0

• 二進(jìn)制分幀
• 頭部壓縮，雙方各自維護(hù)一個(gè)header的索引表，使得不需要直接發(fā)送值，通過發(fā)送key縮減頭部大小
• 多路復(fù)用(或連接共享)，使用多個(gè)stream，每個(gè)stream又分幀傳輸，使得一個(gè)tcp連接能夠處理多個(gè)http請(qǐng)求
• 服務(wù)器推送(Sever push)

HTTP 3.0

• 基于google的QUIC協(xié)議，而quic協(xié)議是使用udp實(shí)現(xiàn)的
• 減少了tcp三次握手時(shí)間，以及tls握手時(shí)間
• 解決了http 2.0中前一個(gè)stream丟包導(dǎo)致后一個(gè)stream被阻塞的問題
• 優(yōu)化了重傳策略，重傳包和原包的編號(hào)不同，降低后續(xù)重傳計(jì)算的消耗
• 連接遷移，不再用tcp四元組確定一個(gè)連接，而是用一個(gè)64位隨機(jī)數(shù)來確定這個(gè)連接
• 更合適的流量控制

基于UDP實(shí)現(xiàn)

0RTT建連

基于UDP的多路復(fù)用

加密認(rèn)證的報(bào)文

向前糾錯(cuò)機(jī)制