HTTP1.0

1.0的HTTP版本，是一種無狀態，無連接的應用層協議。 HTTP1.0規定瀏覽器和服務器保持短暫的鏈接。

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

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

HTTP1.0存在的問題

無法復用連接

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

隊頭阻塞(head of line blocking)

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

HTTP1.1

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

長連接

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

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

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

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

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

例如：

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

需要注意的是：服務器必須按照客戶端請求的先后順序依次回送相應的結果，以保證客戶端能夠區分出每次請求的響應內容。

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

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

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

真并行傳輸 — 瀏覽器優化策略

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

很多人以為的連接數情況：

 

實際情況(china)：

 

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

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

HTTP2.0

二進制分幀

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

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

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

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

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

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

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

頭部壓縮

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

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

HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header_files表，既避免重復header的傳輸，又減少了需要傳輸的大小。

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

服務器推送

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

HTTP3.0

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

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

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

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

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

0-RTT — QUIC協議相比HTTP2.0的最大優勢

緩存當前會話的上下文，下次恢復會話的時候，只需要將之前的緩存傳遞給服務器，驗證通過，就可以進行傳輸了。

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

什么是0-RTT建連?

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

多路復用

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

更好的移動端表現

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

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

TCP協議頭沒有經過任何加密和認證，在傳輸過程中很容易被中間網絡設備篡改、注入和竊聽。

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

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

向前糾錯機制

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

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

例如：

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

問題歸納

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

沒有必要。

在頭部壓縮技術中，客戶端和服務器均會維護兩份相同的靜態字典和動態字典。

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

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

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

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

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

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

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

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

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

由于修改TCP協議是不可能完成的任務。

如何在Chrome中啟用 QUIC 協議

MTF在資源服務器和內容分發節點都已經啟用了 HTTP3.0 協議，根據 用戶瀏覽器 向下兼容，強烈建議您在Chrome瀏覽器開啟實驗性QUICK協議支持，體驗加速效果：

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

找到Experimental QUIC protocol，將Default改為Enabled

 總結

HTTP 1.0

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

HTTP 1.1

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

HTTP 2.0

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

HTTP 3.0

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

基于UDP實現

0RTT建連

基于UDP的多路復用

加密認證的報文

向前糾錯機制