HTTP1.0

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

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

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

HTTP1.0存在的問題

無法復用連接

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

隊頭阻塞(head of line blocking)

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

HTTP1.1

HTTP1.1繼承了HTTP1.0的簡單，克服了HTTP1.0性能上的問題。

長連接

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

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

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

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

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

例如：

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

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

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

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

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

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

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

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

 

實際情況(china)：

 

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

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

HTTP2.0

二進制分幀

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

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

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

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

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

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

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

頭部壓縮

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

比如cookie，默認情況下，瀏覽器會在每次請求的時候，把cookie附在header上面發(fā)給服務(wù)器。

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

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

服務(wù)器推送

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

HTTP3.0

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

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

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

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

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

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

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

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

什么是0-RTT建連?

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

多路復用

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

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

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

加密認證的根文 — 武裝到牙齒

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

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

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

向前糾錯機制

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

向前糾錯犧牲了每個數(shù)據(jù)包可以發(fā)送數(shù)據(jù)的上限，但是帶來的提升大于丟包導致的數(shù)據(jù)重傳，因為數(shù)據(jù)重傳將會消耗更多的時間(包括確認數(shù)據(jù)包丟失，請求重傳，等待新數(shù)據(jù)包等步驟的時間消耗)。

例如：

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

問題歸納

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

沒有必要。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

找到Experimental QUIC protocol，將Default改為Enabled

 總結(jié)

HTTP 1.0

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

HTTP 1.1

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

HTTP 2.0

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

HTTP 3.0

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

基于UDP實現(xiàn)

0RTT建連

基于UDP的多路復用

加密認證的報文

向前糾錯機制