HTTP各版本特性及區別

本文原創：fanmengyuan

HTTP 是基於 TCP/IP 協議的一個應用層協議，是現代互聯網的一個基礎協議。規定了客戶端與服務端之間的通訊格式以及所佔用的服務端口80(HTTPS是443)。

版本

HTTP 協議從開始立項到如今一共經歷了 4 個版本:

HTTP 0.9 -> HTTP 1.0 -> HTTP 1.1 -> HTTP 2
複製代碼

HTTP 0.9

HTTP 0.9 是一個最古老的版本

• 只支持GET請求方式：因爲不支持其餘請求方式，所以客戶端是沒辦法向服務端傳輸太多的信息
• 沒有請求頭概念：因此不能在請求中指定版本號，服務端也只具備返回 HTML字符串的能力
• 服務端相響應以後，當即關閉TCP鏈接

HTTP 1.0

隨着 HTTP 1.0 的發佈，這個版本:

• 請求方式新增了POST，DELETE，PUT，HEADER等方式
• 增添了請求頭和響應頭的概念，在通訊中指定了 HTTP 協議版本號，以及其餘的一些元信息 (好比: 狀態碼、權限、緩存、內容編碼)
• 擴充了傳輸內容格式，圖片、音視頻資源、二進制等均可以進行傳輸

在這個版本主要的就是對請求和響應的元信息進行了擴展，客戶端和服務端有更多的獲取當前請求的全部信息，進而更好更快的處理請求相關內容。

請求頭

一個簡單請求的頭信息

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
複製代碼

能夠看到在請求方法以後有 請求資源的位置 + 請求協議版本，以後是一些客戶端的信息配置

響應頭

一個簡單響應的頭信息(v1.0)

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
// 這是一個空行
...數據內容
複製代碼

服務端的響應頭第一個就是 請求協議版本，後面緊跟着是此次請求的狀態碼、以及狀態碼的描述，以後的內容是一些關於返回內容的描述。

Content-Type

在 HTTP 1.0 的時候，任何的資源均可以被傳輸，傳輸的格式呢也是多種多樣的，客戶端在收到響應體的內容的時候就是根據這個 Content-Type 去進行解析的。因此服務端返回時候必須帶着這個字段。

一些常見的 Content-Type 能夠參考 對照表。 這些 Content-Type 有一個總稱叫作MIME type。

關於MIME type，這裏想播插一個小插曲:

在 chrome 瀏覽器中，當跨域請求回來的數據 MIME type 同跨域標籤應有的 MIME type 不匹配時，瀏覽器會啓動 CORB 保護數據不被泄漏。被保護的數據有: html、xml、json。(eg: script、img 標籤所支持的 MIME type和他們都不一致)，因此服務端在返回資源的時候必定要對應返回正確的 Content-Type，以避免瀏覽器屏蔽返回結果。

筆者遇到的問題是在 chrome v76 版本以後，跨域圖片資源當請求回來的數據 Content-Type 不是 image/*，圖片會被攔截，頁面不展現圖片。

特性

• 無狀態：服務器不跟蹤不記錄請求過的狀態
• 無鏈接：瀏覽器每次請求都須要創建tcp鏈接

無狀態

對於無狀態的特性能夠藉助cookie/session機制來作身份認證和狀態記錄

無鏈接

無鏈接致使的性能缺陷有兩種：

• 沒法複用鏈接
  每次發送請求，都須要進行一次tcp鏈接（即3次握手4次揮手），使得網絡的利用率很是低
• 隊頭阻塞
  HTTP 1.0 規定在前一個請求響應到達以後下一個請求才能發送，若是前一個阻塞，後面的請求也給阻塞的

HTTP 1.1

HTTP 1.1 是在 1.0 發佈以後的半年就推出了，完善了 1.0 版本。目前也還有不少的互聯網項目基於 HTTP 1.1 在向外提供服務。

特性

• 長鏈接：新增Connection字段，能夠設置keep-alive值保持鏈接不斷開
• 管道化：基於上面長鏈接的基礎，管道化能夠不等第一個請求響應繼續發送後面的請求，但響應的順序仍是按照請求的順序返回
• 緩存處理：新增字段cache-control
• 斷點傳輸

長鏈接

HTTP 1.1默認保持長鏈接，數據傳輸完成保持tcp鏈接不斷開,繼續用這個通道傳輸數據

管道化

基於長鏈接的基礎，咱們先看沒有管道化請求響應：

tcp沒有斷開，用的同一個通道

請求1 > 響應1 --> 請求2 > 響應2 --> 請求3 > 響應3
複製代碼

管道化的請求響應：

請求1 --> 請求2 --> 請求3 > 響應1 --> 響應2 --> 響應3
複製代碼

即便服務器先準備好響應2,也是按照請求順序先返回響應1

雖然管道化，能夠一次發送多個請求，可是響應還是順序返回，仍然沒法解決隊頭阻塞的問題

緩存處理

當瀏覽器請求資源時，先看是否有緩存的資源，若是有緩存，直接取，不會再發請求，若是沒有緩存，則發送請求。 經過設置字段cache-control來控制緩存。

斷點傳輸

在上傳/下載資源時，若是資源過大，將其分割爲多個部分，分別上傳/下載，若是遇到網絡故障，能夠從已經上傳/下載好的地方繼續請求，不用從頭開始，提升效率

HTTP 2

特性:

• 二進制分幀
• 多路複用： 在共享TCP連接的基礎上同時發送請求和響應
• 頭部壓縮
• 服務器推送：服務器能夠額外的向客戶端推送資源，而無需客戶端明確的請求

二進制分幀

HTTP 1.x 的解析是基於文本，HTTP 2以後將全部傳輸的信息分割爲更小的消息和幀，並對它們採用二進制格式的編碼，提升傳輸效率

多路複用

在共享TCP連接的基礎上同時發送請求和響應，基於二進制分幀，在同一域名下全部訪問都是從同一個tcp鏈接中走，http消息被分解爲獨立的幀，亂序發送，服務端根據標識符和首部將消息從新組裝起來。

頭部壓縮

因爲 HTTP 是無狀態的，每個請求都須要頭部信息標識此次請求相關信息，因此會形成傳輸不少重複的信息，當請求數量增大的時候，消耗的資源就會慢慢積累上去。因此 HTTP 2 能夠維護一個頭部信息字典，差量進行更新頭信息，減小頭部信息傳輸佔用的資源，詳見 HTTP/2 頭部壓縮技術介紹。

HTTPS 和 HTTP

• HTTPS 協議須要申請證書
• HTTP 和 HTTPS 使用端口不同，前者是80，後者是443
• HTTP 協議運行在 TCP 之上，全部傳輸的內容都是明文，HTTPS 運行在 SSL/TLS 之上，SSL/TLS運行在TCP之上，全部傳輸的內容都通過加密的
• HTTPS 能夠有效的防止運營商劫持

結尾

雖然在2015年，HTTP 2 就發佈了，可是目前互聯網的服務中，使用 HTTP 1.x 版本的服務不在少數，其中可能很大的一個緣由是在當前的主流瀏覽器好比 chrome、Firefox 它們只支持基於 TLS 部署的 HTTP 2 協議，也就是說須要你的網站先升級爲 HTTPS 才能夠。然而 HTTPS 是須要申請證書的。

固然若是你的網站已經升級過 HTTPS 了，那麼想升級 HTTP 2 就很是容易了。前端服務利器nginx能幫你作這全部，詳見 Open Source NGINX 1.9.5 Released with HTTP/2 Support

參考文章

• www.ruanyifeng.com/blog/2016/0…
• imququ.com/post/header…
• cloud.tencent.com/developer/n…
• www.cnblogs.com/Leo_wl/p/10…