一、HTTP基礎

1.1 HTTP定義

HTTP協議（HyperTextTransferProtocol，超文本傳輸協議）是用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。

1.2 HTTP發展史

1.3 HTTP1.0

早先1.0的HTTP版本，是一種無狀態、無連接的應用層協議。

HTTP1.0規定瀏覽器和服務器保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器處理完成后立即斷開TCP連接（無連接），服務器不跟蹤每個客戶端也不記錄過去的請求（無狀態）。

這種無狀態性可以借助cookie/session機制來做身份認證和狀態記錄。而下面兩個問題就比較麻煩了。

首先，無連接的特性導致最大的性能缺陷就是無法復用連接。每次發送請求的時候，都需要進行一次TCP的連接，而TCP的連接釋放過程又是比較費事的。這種無連接的特性會使得網絡的利用率非常低。

其次就是隊頭阻塞（head of line blocking）。由于HTTP1.0規定下一個請求必須在前一個請求響應到達之前才能發送。假設前一個請求響應一直不到達，那么下一個請求就不發送，同樣的后面的請求也給阻塞了。

為了解決這些問題，HTTP1.1出現了。

1.4 HTTP的基本優化方向

影響一個 HTTP 網絡請求的因素主要有兩個：帶寬和延遲。

帶寬：如果說我們還停留在撥號上網的階段，帶寬可能會成為一個比較嚴重影響請求的問題，但是現在網絡基礎建設已經使得帶寬得到極大的提升，我們不再會擔心由帶寬而影響網速，那么就只剩下延遲了。

延遲：

• 瀏覽器阻塞（HOL blocking）：瀏覽器會因為一些原因阻塞請求。瀏覽器對于同一個域名，同時只能有 4 個連接（這個根據瀏覽器內核不同可能會有所差異），超過瀏覽器最大連接數限制，后續請求就會被阻塞。

• DNS 查詢（DNS Lookup）：瀏覽器需要知道目標服務器的 IP 才能建立連接。將域名解析為 IP 的這個系統就是 DNS。這個通常可以利用DNS緩存結果來達到減少這個時間的目的。

• 建立連接（Initial connection）：HTTP 是基于 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的建立連接，但是這些連接無法復用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大。

二、HTTP1.0和HTTP1.1的一些區別

HTTP1.0最早在網頁中使用是在1996年，那個時候只是使用一些較為簡單的網頁上和網絡請求上，而HTTP1.1則在1999年才開始廣泛應用于現在的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最為廣泛的HTTP協議。 主要區別主要體現在：

對于HTTP1.1，不僅繼承了HTTP1.0簡單的特點，還克服了諸多HTTP1.0性能上的問題。

首先是長連接，HTTP1.1增加了一個Connection字段，通過設置Keep-Alive可以保持HTTP連接不斷開，避免了每次客戶端與服務器請求都要重復建立釋放建立TCP連接，提高了網絡的利用率。如果客戶端想關閉HTTP連接，可以在請求頭中攜帶Connection: false來告知服務器關閉請求。

其次，是HTTP1.1支持請求管道化（pipelining）。基于HTTP1.1的長連接，使得請求管道化成為可能。管線化使得請求能夠“并行”傳輸。舉個例子來說，假如響應的主體是一個html頁面，頁面中包含了很多img，這個時候keep-alive就起了很大的作用，能夠進行“并行”發送多個請求。（注意這里的“并行”并不是真正意義上的并行傳輸，具體解釋如下。）

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

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

HTTP 1.1

如圖所示，客戶端同時發了兩個請求分別來獲取html和css，假如說服務器的css資源先準備就緒，服務器也會先發送html再發送css。

換句話來說，只有等到html響應的資源完全傳輸完畢后，css響應的資源才能開始傳輸。也就是說，不允許同時存在兩個并行的響應。

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

那我們在谷歌控制臺看到的并行請求又是怎么一回事呢？

如圖所示，綠色部分代表請求發起到服務器響應的一個等待時間，而藍色部分表示資源的下載時間。按照理論來說，HTTP響應理應當是前一個響應的資源下載完了，下一個響應的資源才能開始下載。而這里卻出現了響應資源下載并行的情況。這又是為什么呢？

其實，雖然HTTP1.1支持管道化，但是服務器也必須進行逐個響應的送回，這個是很大的一個缺陷。實際上，現階段的瀏覽器廠商采取了另外一種做法，它允許我們打開多個TCP的會話。也就是說，上圖我們看到的并行，其實是不同的TCP連接上的HTTP請求和響應。這也就是我們所熟悉的瀏覽器對同域下并行加載6~8個資源的限制。而這，才是真正的并行！

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

HTTPS與HTTP的一些區別

• HTTPS協議需要到CA申請證書，一般免費證書很少，需要交費。
• HTTP協議運行在TCP之上，所有傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸的內容都經過加密的。
• HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
• HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。

HTTP 2.0 vs HTTP 1.0 性能

HTTP 2.0 的出現，相比于 HTTP 1.x ，大幅度的提升了 web 性能。

這是 Akamai 公司建立的一個官方的演示，用以說明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同時請求 379 張圖片，從Load time 的對比可以看出 HTTP/2 在速度上的優勢。

三、HTTP 1.1 和 HTTP 2.0 區別

后面我們將通過幾個方面來說說HTTP 2.0 和 HTTP1.1 區別，并且和你解釋下其中的原理。

3.1 二進制分幀

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

可見，雖然HTTP2.0的協議和HTTP1.x協議之間的規范完全不同了，但是實際上HTTP2.0并沒有改變HTTP1.x的語義。
簡單來說，HTTP2.0只是把原來HTTP1.x的header和body部分用frame重新封裝了一層而已。

3.2 多路復用

下面是幾個概念：

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

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

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

舉個例子，每個請求是一個數據流，數據流以消息的方式發送，而消息又分為多個幀，幀頭部記錄著stream id用來標識所屬的數據流，不同屬的幀可以在連接中隨機混雜在一起。接收方可以根據stream id將幀再歸屬到各自不同的請求當中去。

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

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

多路復用允許單一的 HTTP/2 連接同時發起多重的請求-響應消息。看個例子：

整個訪問流程第一次請求index.html頁面,之后瀏覽器會去請求style.css和scripts.js的文件。左邊的圖是順序加載兩個個文件的，右邊則是并行加載兩個文件。

我們知道HTTP底層其實依賴的是TCP協議，那問題是在同一個連接里面同時發生兩個請求響應著是怎么做到的？

首先你要知道，TCP連接相當于兩根管道（一個用于服務器到客戶端，一個用于客戶端到服務器），管道里面數據傳輸是通過字節碼傳輸，傳輸是有序的，每個字節都是一個一個來傳輸。

例如客戶端要向服務器發送Hello、World兩個單詞，只能是先發送Hello再發送World，沒辦法同時發送這兩個單詞。不然服務器收到的可能就是HWeolrllod（注意是穿插著發過去了，但是順序還是不會亂）。這樣服務器就懵b了。

接上面的問題，能否同時發送Hello和World兩個單詞能，當然也是可以的，可以將數據拆成包，給每個包打上標簽。發的時候是這樣的①H ②W ①e ②o ①l ②r ①l ②l ①o ②d。這樣到了服務器，服務器根據標簽把兩個單詞區分開來。實際的發送效果如下圖：

HTTP 性能優化的__關鍵并不在于高帶寬，而是低延遲__。TCP 連接會隨著時間進行自我「調諧」，起初會限制連接的最大速度，如果數據成功傳輸，會隨著時間的推移提高傳輸的速度。這種調諧則被稱為 TCP 慢啟動。由于這種原因，讓原本就具有突發性和短時性的 HTTP 連接變的十分低效。

HTTP/2 通過讓所有數據流共用同一個連接，可以更有效地使用 TCP 連接，讓高帶寬也能真正的服務于 HTTP 的性能提升。

總結下：多路復用技術：單連接多資源的方式，減少服務端的鏈接壓力,內存占用更少,連接吞吐量更大；由于減少TCP 慢啟動時間，提高傳輸的速度

3.3 首部壓縮

為什么要壓縮？在 HTTP/1 中，HTTP 請求和響應都是由「狀態行、請求 / 響應頭部、消息主體」三部分組成。一般而言，消息主體都會經過 gzip 壓縮，或者本身傳輸的就是壓縮過后的二進制文件（例如圖片、音頻），但狀態行和頭部卻沒有經過任何壓縮，直接以純文本傳輸。

隨著 Web 功能越來越復雜，每個頁面產生的請求數也越來越多，導致消耗在頭部的流量越來越多，尤其是每次都要傳輸 UserAgent、Cookie 這類不會頻繁變動的內容，完全是一種浪費。

我們再用通俗的語言解釋下，壓縮的原理。頭部壓縮需要在支持 HTTP/2 的瀏覽器和服務端之間:

• 維護一份相同的靜態字典（Static Table），包含常見的頭部名稱，以及特別常見的頭部名稱與值的組合；
• 維護一份相同的動態字典（Dynamic Table），可以動態的添加內容；
• 支持基于靜態哈夫曼碼表的哈夫曼編碼（Huffman Coding）；

靜態字典的作用有兩個：

• 對于完全匹配的頭部鍵值對，例如 “:method :GET”，可以直接使用一個字符表示；
• 對于頭部名稱可以匹配的鍵值對，例如 “cookie :xxxxxxx”，可以將名稱使用一個字符表示。

HTTP/2 中的靜態字典如下（以下只截取了部分）：

同時，瀏覽器和服務端都可以向動態字典中添加鍵值對，之后這個鍵值對就可以使用一個字符表示了。需要注意的是，動態字典上下文有關，需要為每個 HTTP/2 連接維護不同的字典。在傳輸過程中使用，使用字符代替鍵值對大大減少傳輸的數據量。

3.4 HTTP2支持服務器推送

服務端推送是一種在客戶端請求之前發送數據的機制。當代網頁使用了許多資源:HTML、樣式表、腳本、圖片等等。在HTTP/1.x中這些資源每一個都必須明確地請求。這可能是一個很慢的過程。瀏覽器從獲取HTML開始，然后在它解析和評估頁面的時候，增量地獲取更多的資源。因為服務器必須等待瀏覽器做每一個請求，網絡經常是空閑的和未充分使用的。

為了改善延遲，HTTP/2引入了server push，它允許服務端推送資源給瀏覽器，在瀏覽器明確地請求之前。一個服務器經常知道一個頁面需要很多附加資源，在它響應瀏覽器第一個請求的時候，可以開始推送這些資源。這允許服務端去完全充分地利用一個可能空閑的網絡，改善頁面加載時間。

3.5HTTP/2采用二進制格式而非文本格式

見 3.1 二進制分幀

參考：https://www.hollischuang.com/archives/2066

總結

以上是生活随笔為你收集整理的http1.0 http1.1 http2 之间的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。