Http的演進
Http在1.1版本之前具有無狀態的特點，每次請求都需要透過TCP三次握手四次揮手與伺服器重新建立連線。比如某個客戶端在短時間多次請求同一個資源，伺服器並不能區別是否已經響應過使用者請求，所以每次需要重新響應請求、耗費不必要的時間和流量。為了節省資源消耗，Http也進行了發展和演進，透過持久連線的方法來進行連線複用。
Http的1.0版本
第一個版本的Http是Http0.9,組成極其簡單，只允許客戶端傳送Get這一種請求，且不支援請求頭。由於沒有協議頭，因此Http0.9協議只支援一種內容，即純文字。不過網頁依然支援用html語言格式化，同時無法插入圖片。
http的第二個版本為1.0版本，也是第一個在通訊中指定版本號的Http版本，至今依然被廣泛採用。相對於Http0.9版本，Http1.0版本增加了如下主要特性：
（1） 請求與響應支援頭部欄位
（2） 響應物件以一個響應狀態行開始。
（3） 響應物件不只限於超文字。
（4） 開始支援客戶端透過Post方法向web伺服器提交資料，支援GET、Head、Post方法
（5） 支援長連線，但預設使用短連線，快取機制，以及身份認證。
（6） 請求行必須在尾部新增協議版本欄位（Http1.0），必須包含頭部訊息。
http請求訪問的資源不再侷限上一個版本的Html格式，可以根據Content-Type設定訪問的格式；同時也開始支援Cache。當客戶端在規定時間內訪問同一URL資源時，直接訪問Cache即可。
http請求訪問的資源不再侷限上一個版本的Html格式，可以根據Content-Type設定訪問的格式；同時也開始支援Cache。當客戶端在規定時間內訪問同一URL資源時，直接訪問Cache即可。
MIME型別的每個值包括一級型別和二級型別，之間用斜槓分隔。除了預定義的型別，廠商也可以自定義型別，例如下面是一個自定義型別的例子：
application/vnd.debian.binary-package
上面的自定義MIME型別表明傳送的是Debian系統的二進位制資料包。
MIME型別值還可以在尾部使用分號、新增引數，下面是一個新增引數的例子：
Content-type: text/html;charset=utf-8
上面的型別值表面Http報文中的報文中的內容是文字網頁資料，並且文字編碼為utf-8
客戶端在傳送請求時可以使用Accept頭部欄位宣告自己可以接受哪些資料格式。下面是一個Accept的例子：
Accept: */*
上面的Accept頭部欄位表明客戶端宣告自己可以接受來自服務端的任何格式的資料。
由於文字資料傳送的時候往往可以透過壓縮大大節省頻寬，因此Http1.0版本協議可以支援把資料壓縮後傳送，其報文Content-Encoding頭部用於說明資料的壓縮格式。
http的1.1版本
Http1.1版本引入了許多關鍵技術：持久連線、管道機制、分塊傳輸編碼、位元組範圍請求等。
持久連線：即下層的TCP連線預設不關閉，可以被多個請求複用。
管道機制：在同一個tcp連線裡允許多個請求同時傳送，但是伺服器還是按照順序依次處理。（類似於前端同時傳送兩個請求給後端）
http1.1新增了put、patch、options、delete等多種請求方法。
http1.1版本客戶端請求的頭部資訊新增了host欄位，用來指定伺服器的域名，還加了一個新的狀態碼100.（比如404之類的）
分塊傳輸編碼：該機制允許服務端將資料分成多個部分傳送到客戶端。普通的伺服器響應會將響應資料的長度透過Content-Length欄位告訴客戶端。它主要是用Transfer-Encoding欄位
Transfer-Encoding:chunked
每個分塊包含十六進位制的長度值和資料，其中長度值獨佔一行。長度不包括分塊長度和（\r\n）的長度，也不包括分塊資料後面結尾（\r\n）的長度。
最後一個分塊的長度值必須為0，對應的分塊資料沒有內容，表示所有的body資料傳輸完成。
Http的2.0版本
它是一個二進位制協議，傳輸效率明顯提高，但是這樣需要客戶端和服務端都要引入新的二進位制編碼和解碼的機制。
Protobuf，各位可以去了解一下。
好了，感興趣的話，可以看看寶寶之前的部落格嗎0.0
參考文獻：java高併發核心程式設計 Nio、netty、redis、zookeeper 作者：尼恩