[[432211]]

大家好，我是Tom哥~

今天跟大家聊聊下 HTTP協(xié)議，歡迎留言討論

互聯(lián)網(wǎng)時代，足不出戶，點點鼠標(biāo)就可以輕松了解外面的世界變化，這一切得益于網(wǎng)絡(luò)傳輸數(shù)據(jù)。

我們都知道網(wǎng)絡(luò)有7層模型，從底層到上層依次是：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應(yīng)用層。

越往上，越接近用戶習(xí)慣，更容易被用戶直觀了解。

今天講的 HTTP 協(xié)議屬于應(yīng)用層協(xié)議，也是互聯(lián)網(wǎng)廣泛使用的基礎(chǔ)協(xié)議之一。

一、 HTTP/0.9

0.9 版本是HTTP最早的版本，誕生于 1991 年，比較簡單。

1、只支持 GET 請求，沒有請求頭。每次請求都要單獨創(chuàng)建一個TCP連接，復(fù)用性差，性能不高

2、服務(wù)端響應(yīng)的數(shù)據(jù)只能是 HTML格式，服務(wù)器發(fā)送完畢，會關(guān)閉TCP連接。如果請求的頁面不存在，也不會返回任何錯誤碼。

當(dāng)時，互聯(lián)網(wǎng)剛起步，頁面展現(xiàn)形式更多是文本為主，能滿足基本需求。隨著用戶需求的多樣化，對展示形態(tài)和性能也提出了更高要求，HTTP協(xié)議也開始了慢慢的升級之路。

二、 HTTP/1.0

1996年，HTTP/1.0 發(fā)布，相比之前版本增加了很多特性。

1、請求和響應(yīng)增加了頭信息(header)，用來描述一些元數(shù)據(jù)，如：

Content-Type 讓響應(yīng)數(shù)據(jù)不只限于超文本 
Expires、Last-Modified 緩存 
Authorization 身份認(rèn)證 
Connection: keep-alive 支持長連接，但非標(biāo)準(zhǔn) 

2、請求方法，除了 GET，還增加了 POST、HEAD命令，豐富了互動方式

3、豐富了傳輸內(nèi)容的格式，有文本、圖像、視頻、二進(jìn)制文件

4、請求時增加 HTTP 協(xié)議版本，響應(yīng)端增加狀態(tài)碼。

缺點：

主要還是連接復(fù)用問題，每個TCP連接只能發(fā)送一個請求。當(dāng)數(shù)據(jù)發(fā)送完畢后，連接就會關(guān)閉。由于TCP建立連接，需要三次握手，所以性能會比較差。

為了緩解這個問題，請求頭引入一個非標(biāo)準(zhǔn)的Connection字段：Connection: keep-alive，要求服務(wù)器不要關(guān)閉TCP連接，從而達(dá)到復(fù)用效果。

當(dāng)然，這個不是標(biāo)準(zhǔn)字段，只是一個臨時方案。

三、 HTTP/1.1

1997年，HTTP/1.1 版本發(fā)布。進(jìn)一步完善了HTTP協(xié)議，也是目前最流行的版本，一直活躍至今。

1、默認(rèn)支持長連接(PersistentConnection)和請求的流水線(Pipelining)處理，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲

2、管線化技術(shù)。支持多個 HTTP 請求批量發(fā)送，不用排隊，這就解決了 HTTP 隊頭阻塞問題。但批量發(fā)送的 HTTP 請求，必須按照發(fā)送的順序返回響應(yīng)

3、流式渲染，響應(yīng)端可以不用一次返回所有數(shù)據(jù)，可以將數(shù)據(jù)拆分成多個模塊，產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊數(shù)據(jù)，這樣客戶端就可以同步對數(shù)據(jù)進(jìn)行處理，減少響應(yīng)延遲，降低白屏?xí)r間。

4、請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206(Partial Content)，這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接

5、增加 Host 頭，實現(xiàn)了虛擬主機技術(shù)，將一臺服務(wù)器分成若干個主機，這樣就可以在一臺服務(wù)器上部署多個網(wǎng)站了。通過配置 Host 的域名和端口號，即可支持多個 HTTP 服務(wù)

6、頭部增加一些緩存字段，如 E-Tag、Cache-Control 等

7、新增了24個錯誤狀態(tài)響應(yīng)碼，如 409(Conflict)表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突;410(Gone)表示服務(wù)器上的某個資源被永久性的刪除。

小結(jié)：

請求和響應(yīng)成對出現(xiàn)，順序串行。如果按QPS來理解的話，最大的并發(fā)數(shù)只能是 1

四、 HTTP/2

HTTP/2 誕生于 2015 年，最大特點是基于二進(jìn)制的特性，對 HTTP 傳輸效率進(jìn)行了深度優(yōu)化。

新增了哪些特性?

1、二進(jìn)制幀

HTTP/2 將一個 HTTP 請求劃分為 3 個部分：二進(jìn)制幀、消息、數(shù)據(jù)流

• 幀：一段二進(jìn)制數(shù)據(jù)，是 HTTP/2 傳輸?shù)淖钚挝?/li>
• 消息：邏輯上的 HTTP 消息，比如請求、響應(yīng)等，由一或多個幀組成
• 數(shù)據(jù)流：連接中的一個虛擬信道，可以同時承載一條或多條消息，支持雙向承載

一個TCP連接上，承載著雙向消息，一條消息包含多個二進(jìn)制幀，每個幀都有唯一標(biāo)識，來自不同數(shù)據(jù)流的幀可以交錯發(fā)送，然后再根據(jù)每個幀頭的數(shù)據(jù)流標(biāo)識符重新組裝，這樣就實現(xiàn)了數(shù)據(jù)傳輸。

2、多路復(fù)用

HTTP/1.1 中的 KeepAlive 長連接雖然可以傳輸很多請求，但它的吞吐量很低，因為在發(fā)出請求等待響應(yīng)的那段時間里，這個長連接不能做任何事!而 HTTP/2 通過 Stream 這一設(shè)計，允許請求并發(fā)傳輸。因此，HTTP/1.1 時代 Chrome 通過 6 個連接訪問頁面的速度，遠(yuǎn)遠(yuǎn)比不上 HTTP/2 單連接的速度。

HTTP/2 的并發(fā)性能比 HTTP/1.1 通過 TCP 連接實現(xiàn)并發(fā)要高。這是因為，當(dāng) HTTP/2 實現(xiàn) 100 個并發(fā) Stream 時，只經(jīng)歷 1 次 TCP 握手、1 次 TCP 慢啟動以及 1 次 TLS 握手，但 100 個 TCP 連接會把上述 3 個過程都放大 100 倍!

3、頭部壓縮

HTTP/1.1 的頭部字段包含大量信息，而且每次請求都得帶上，占用了大量的帶寬。

HTTP/2 靜態(tài)表僅用一個數(shù)字來表示，其中，映射數(shù)字與字符串對應(yīng)關(guān)系的表格，被寫死在 HTTP/2 實現(xiàn)框架中。這樣的編碼效率非常高，

什么是靜態(tài)表呢?HTTP/2 將 61 個高頻出現(xiàn)的頭部，比如描述瀏覽器的 User-Agent、GET 或 POST 方法、返回的 200 SUCCESS 響應(yīng)等，分別對應(yīng) 1 個數(shù)字再構(gòu)造出 ”字典“，并寫入 HTTP/2 客戶端與服務(wù)端，用索引號表示重復(fù)的字符串，可以達(dá)到 50%~90% 的高壓縮率。

4、請求優(yōu)先級

由于采用多路復(fù)用，多個請求會同時產(chǎn)生多個數(shù)據(jù)流，數(shù)據(jù)流中有一個優(yōu)先級的標(biāo)識，服務(wù)端根據(jù)這個標(biāo)識決定響應(yīng)的優(yōu)先順序。

流 ID 不能重用，只能順序遞增，客戶端發(fā)起的 ID 是奇數(shù)，服務(wù)器端發(fā)起的 ID 是偶數(shù);

5、服務(wù)器端推送

HTTP/1.1 不支持服務(wù)器主動推送消息，因此當(dāng)客戶端需要獲取通知時，只能通過定時器不斷地輪詢拉取消息。HTTP/2 的消息推送結(jié)束了無效率的定時拉取，節(jié)約了大量帶寬和服務(wù)器資源。

例如：HTTP/1.1 中請求一個頁面時，瀏覽器會先發(fā)送一個 HTTP 請求，然后得到響應(yīng)的 HTML 內(nèi)容并開始解析，如果發(fā)現(xiàn)有<script src="xxxx.js">標(biāo)簽，則會再次發(fā)起 HTTP 請求獲取對應(yīng)的 JS 內(nèi)容。而 HTTP/2 可以在返回 HTML 的同時，將需要用到的 JS、CSS 等內(nèi)容一并返回給客戶端，當(dāng)瀏覽器解析到對應(yīng)標(biāo)簽時，也就不需要再次發(fā)起請求了。

小結(jié)：

通過二進(jìn)制幀流模式，打破之前的”請求 - 應(yīng)答“串行模式，單個TCP連接上支持并發(fā)請求、響應(yīng)，多路復(fù)用大大提升了網(wǎng)絡(luò)吞吐量。

HTTP/2 作為升級版，為了與之前的版本保持兼容，對頭字段、狀態(tài)碼、請求方法等信息都保留不變，降低了學(xué)習(xí)成本，同時上層應(yīng)用也可以做到無縫兼容。

小提示：

做軟件架構(gòu)也是一樣，設(shè)計接口規(guī)范時一定要慎之又慎，盡量預(yù)留很長一段時間的擴展，后續(xù)更多是對里面的邏輯優(yōu)化重構(gòu)，對外黑盒，無需感知。

為什么是 HTTP/2 ，而不是HTTP/2.0 ？

HTTP/2 工作組特別給出了解釋，以前的1.0、1.1 容易讓人誤解，實際使用中難以區(qū)分，所以，決定后續(xù)的版本不在使用小版本，一律采用大版本。

所以，接下來，你只會看到 HTTP/2 、HTTP/3 ...

關(guān)于加密

為了滿足安全性，HTTP/2分別支持”加密“和”明文“，定義兩個字符串標(biāo)識符：“h2”表示加密的 HTTP/2，“h2c”表示明文的 HTTP/2，多出的那個字母“c”的意思是“clear text”。

五、 HTTP/3

HTTP/2 雖然使用“幀”、“流”“多路復(fù)用”，沒有了“隊頭阻塞”，但這些優(yōu)化技巧都是在應(yīng)用層里，而在底層，也就是 TCP 協(xié)議里，還是會發(fā)生“隊頭阻塞”。

HTTP/2 把多個請求 - 響應(yīng)分解成流，交給 TCP 后，TCP 會再拆成更小的段（segment）依次發(fā)送。如果網(wǎng)絡(luò)不好時，會發(fā)生丟包。

TCP為了保證可靠性傳輸，會有丟包重傳機制。這樣，其他的包即使已經(jīng)收到了，也只能放在緩沖區(qū)里，這樣就又出現(xiàn)了隊頭阻塞，這是TCP協(xié)議固有的。

為了解決這個問題，Google推出了QUIC協(xié)議，讓 HTTP 跑在 QUIC 上而不是 TCP 上，這個新版本，我們稱之為 HTTP/3

HTTP/3 目前還處于草案階段，離正式發(fā)布還有段時間，我們拭目以待...