HTTP協議整理分析(你必定須要瞭解的HTTP)

HTTP協議整理分析

有興趣能夠關注個人博客 王二小的博客

認知

維基百科上解釋爲:超文本傳輸協議（英文：HyperText Transfer Protocol，縮寫：HTTP）是一種用於分佈式、協做式和超媒體信息系統的應用層協議[1]。HTTP是萬維網的數據通訊的基礎。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。經過HTTP或者HTTPS協議請求的資源由統一資源標識符（Uniform Resource Identifiers，URI）來標識。

HTTP發展歷程

1. HTTP/0.9版本，這個時候的HTTP只支持GET請求，且不支持請求頭，
2. HTTP/1.0版本，這是第一個在通信中指定版本號的HTTP協議版本，至今仍被普遍採用，特別是在代理服務器中。
3. HTTP/1.1版本，持久鏈接被默認創建，並能很好地配合代理服務器工做。還支持以管道方式在同時發送多個請求，以便下降線路負載，提升傳輸速度。
4. HTTP/2.0版本，當前版本，於2015年5月做爲互聯網標準正式發佈。

HTTP請求

HTTP請求第一步，應該是由客戶端發起一個HTTP請求，固然這個客戶端能夠是例如咱們的瀏覽器，F12調試，發起咱們的第一個請求頭信息。
假設咱們如今開始請求我本身的博客 王二小的博客

你會看到，這是幾行文本，這裏插一句，HTTP/1.1沿用的是文本類型的請求頭，HTTP/2則會使用二進制數據。
接下來，咱們分析下這個請求

• 第一行: 發送一個GET請求，地址是http://www.wedophp.com/,使用的協議是HTTP/1.1
• 第二行: 標記服務器的URL地址
• 第三行: 使用的鏈接方式，這裏的keep-alive指的是使用長鏈接，請記住啊，HTTP/1.1默認使用的就是長鏈接，什麼是長鏈接？待會在分析。
• 第四行: 用於隨報文傳送緩存指示,單位爲秒
• 第五行: 咱們知道有一個安全的鏈接HTTPS，這種頁面的請求中不容許附帶HTTP請求，一旦附帶，就會報錯，因此有這個之後，瀏覽器就會自動升級請求。
• 第六行: 本地瀏覽器的一些信息，以及IE版本。
• 第七行: 告訴服務器能夠發送哪些媒體類型
• 第八行: 告訴服務器可以發送哪些編碼方式
• 第九行: 告訴服務器可以發送哪些語言
• 第十行: 附帶本地cookie信息，每一個cookie是由一個key，一個value形式的，每一個key=>value以後都會有一個空格隔開

HTTP是如何創建鏈接的

說道如何鏈接的，咱們必需要回顧一個東西，那就是大學學到過的計算機網絡基礎，幾乎全部的大學生都應該瞭解過計算機的網絡模型，也就是咱們熟知的七層網絡模型，以下圖

可是計算機網絡中的七層模型畢竟是理想中的狀況，現實是不多有應用實現了七層模型，通常都是整合其中兩個或多個，實現一個四層或者五層的模型。

TCP/IP模型

在這裏咱們研究的是HTTP，天然要知道它所處在哪一個模型中，答案是應用層。這裏要引入一個TCP\IP的概念，你們應該知道，TCP處於傳輸層，IP屬於網絡層，而咱們這裏所探究的HTTP，實際上就是基於TCP/IP協議開發的，至於TCP/IP的網絡模型，它沒有照搬計算機網絡的七層模型，而是整合了表示層,會話層，應用層,統一爲應用層，比較有爭議的是，關於TCP/IP到底是幾層協議，目前爲止沒有定論，通常我比較習慣統稱爲四層協議，至於別人說的五層協議，其實就是數據鏈路層,物理層是否是一層有所爭議吧。如圖：

由於HTTP是基於TCP/IP開發的協議，看過HTTP協議的同窗確定都知道，有句話概述HTTP協議爲無差錯的協議，按序傳輸，未分段的數據流，這其實說的就是TCP協議。

發送一條HTTP請求會發生什麼？

當你在瀏覽器輸入一個URL的時候，有沒有想過這其中發生了什麼？

1. 獲取主機名，例如：http://www.wedophp.com
2. 經過DNS獲取服務器IP
3. 獲取端口，默認是80端口
4. 鏈接到 112.23.59.223:80服務器 （這裏實際上是TCP鏈接）
5. 經過TCP信道發送一個HTTP請求
6. 服務器讀取一個HTTP請求
7. 服務器查找所需資源並經過TCP信道返回資源
8. 關閉TCP鏈接

HTTP持久鏈接的問題

咱們每次發送一個HTTP請求，會附帶一個Proxy-connection: keep-alive,這個參數就是聲明一個持久鏈接，那麼你會問，什麼是持久鏈接？

持久鏈接，本質上是客戶端與服務器通訊的時候，創建一個持久化的TCP鏈接，這個鏈接不會隨着請求結束而關閉，一般會保持鏈接一段時間，至於保持多長時間，則根據你的服務器軟件決定，例如nginx配置文件中能夠配置。

爲何要持久鏈接？一般咱們請求一個HTML文檔，文檔中不只僅只有一個請求，包括加載的圖片，js,css，加起來的HTTP請求可能會不少，若是每次請求都去創建一個TCP鏈接，勢必會形成浪費，若是併發足夠，系統資源一定不夠用，而持久化鏈接可讓每一個用戶儘可能少的去創建TCP鏈接，從而減小服務器資源開銷。

HTTP 管道化鏈接

HTTP1.1容許在持久鏈接上可選的使用請求管道，這是相對於持久鏈接的又一性能優化。

假設請求服務器的一個HTML資源，這個HTML中包含不少JS,CSS文件，最開始的請求獲取HTML文件，而後等待服務器回傳HTML,客戶端拿到了HTML以後，開始解析，而後請求CSS,而後是JS,這個過程是線性的，也就是說客戶端發送一個HTTP請求之後，必需要等待服務器返回結果而且本身接收到完畢之後再發送第二個請求，這樣的方式有一個嚴重的問題，當第一個請求阻塞之後，客戶端始終拿不到響應報文，第二個請求也發不出去，致使嚴重的問題。

何爲管道化鏈接，如圖所示：

在響應到達以前，能夠將多條請求放入請求對列。當第一條請求經過網絡到達服務器的過程當中，第二條已經開始發送了，在高時延網絡條件下，這樣作能夠下降網絡的環回時間，提升性能。

HTTP的無狀態

何爲無狀態，《用TCP/IP進行網際互聯：第三卷 客戶端-服務器編程與應用》書中提到過，服務器所維護的與客戶端交互活動的信息稱爲狀態信息，不保存任何狀態信息的爲無狀態服務器，不然就是有狀態服務器，咱們知道HTTP自己是不保存任何用戶的狀態信息的，因此HTTP是無狀態的協議

HTTP協議如何保存用戶狀態？

對於開發比較熟悉的朋友應該知道，HTTP維護一套cookie和session體系，即用戶第一次訪問服務器的時候，服務器響應報頭一般會出現一個Set-Cookie響應頭，這裏其實就是在本地設置一個Cookie,當用戶再次訪問服務器的時候，HTTP會附帶這個Cookie過去，其實就是一個身份證樣的東西，證實我仍是剛剛那個小明，我第二次來了，這是個人身份證，服務器看到了你的身份證以後，想起來，你是小明啊，來，這是有關於你的東西，再傳遞回來。

這裏咱們先看看一個響應報文