新夢想幹貨——網絡情緣之傳說中的HTTP協議(一)

在新夢想動態的前面三篇文章：

<網絡情緣之如何上網的>

<網絡情緣之TCP的三次握手和四次分手>

<網絡情緣之TCP的分包處理>

裏我們都說提到一個詞HTTP，

今天我們來看看傳說中的HTTP協議吧。

自打有了互聯網，每天開始看新聞，看朋友圈，刷微博等等，HTTP都起着非常關鍵的作用，大部分的數據都是靠HTTP協議送到你的面前的。So，HTTP有着怎麼樣的前世今生呢？

HTTP協議是誰？

HTTP協議全名：Hyper Text Transfer Protocol。

中文名字：超文本傳輸協議。

他基於TCP的應用層協議，它不關心數據傳輸的細節，主要是用來規定客戶端和服務端的數據傳輸格式，最初是用來向客戶端傳輸HTML頁面的內容。默認端口是80。目前主流的協議版本是HTTP1.1。

扒一扒HTTP協議的歷史：

1、HTTP/0.9版本 出生年份：1991年

非常簡單的一個版本，只有一個get命令，服務器向客戶端響應一個HTML頁面，只能是文本格式的。就是說你看到的頁面全是字，沒有圖片和視頻。

2、HTTP/1.0版本 出生年份：1996年

這個版本就強大許多了，你上網的時候可以看到圖片和視頻了。這是因爲該版本的協議增加了Content-Type字段，允許數據包body部分的內容可以是任何數據類型。服務器在響應數據時必段告訴客戶端數據類型是什麼格式的，這纔是content-type存在的意義。

Content-type的字段值有很多，這些都是數據返回的類型，這些數據類型總稱爲MIME type，每個值包括一級類型和二級類型，之間用斜槓分隔。

常用的有以下這些：

請求的方式增加了post和head。也規定了字符集(charset)、響應狀態碼、權限。但是他有一個大的缺點：每請求一次數據就要TCP創建一次連接（上一篇說過HTTP協議採用TCP連接方式），傳輸完就斷開。如果一個網頁有100張圖的話，那TCP得握手100次，想想手都要斷了。

所以有些爲了避免這個問題，就在請求的時候使用connection:keep-alive字段，來要求服務器不要關閉連接。服務器響應的時候，同樣會有這樣的字段回覆。

3、HTTP/1.1版本 出生年份：1997年

這個版本的協議也是當前主流的協議版本了。

作爲現代人的你，還在用10年前的東西，是不是覺得前輩們的技術很強大。

該版本最大的優點就是增加了持久化連接，也就是說TCP連接完後，先不關閉，可以被多個請求重複使用。直到客戶端或者服務器發現數據交互完成，不需要了再來進行連接關閉。

這裏提個問題，請問：現在的主流瀏覽器針對同一個域名最多允許的持久化連接是多少個呢？

雖然現在可以多個請求使用一個連接了，但是勢必就要搞清楚不同的數據包是哪個響應的。所以在這裏又增加了content-length字段，告訴客戶端這個響應的數據是多少字節。如果超過這個數字了，那就是下一個請求的響應數據了。

4、HTTP /2 出生年份：2015年

爲啥不叫2.0，因爲標準委員會不打算再發布子版本了，如果有下一個新版本那他的名字將是HTTP/3。嗯，有點任性了啊。

HTTP/2很強大，增加了很多新技能，爲了以後做的準備，這裏就不都詳細介紹了。就簡單介紹一個詞：“多工(Multiplexing)”。

HTTP/2允許客戶端和服務器同時發送多個請求或響應，而且還不要求按順序一一對應，這麼做的目的是爲了避免阻塞。

就比如你和朋友一起去餐館喫飯，同時跟你進餐廳的有好幾桌人，這些桌都點了餐，那廚師如果一桌一桌的來炒菜的話，估計有些桌的人得拍桌子走人了。這時廚師會同一個時間掌勺兩三個鍋，而且如果有些桌的菜比較難處理的話，那廚師會先炒出兩三個菜，然後炒完其他比較簡單的菜再回來繼續炒原先桌的菜了。這樣既安撫了你們，也解決了其它桌的問題。

HTTP/2的雙工就是這樣的：服務器可能會同時收到A和B兩個請求，服務器先處理A請求，如果A請求比較難處理的話，服務器會把已經處理過的A請求數據發給客戶端，然後來處理B請求，完了以後再回頭處理A請求。

好了，下週繼續！