HTTP：Hyper Text Transfer Protocol（超文本傳輸協(xié)議），是用于服務(wù)器向瀏覽器傳輸超文本的協(xié)議，其建立在TCP/IP之上，由于其簡單、快速的特點，得到廣泛應(yīng)用。小采風同學，自作主張選取部分方面，粗略的聊一聊我們不能不知道的常識。

一、HTTP的工作原理

??? HTTP協(xié)議定義web客戶端（通常為瀏覽器，以下統(tǒng)稱為瀏覽器）向服務(wù)器發(fā)送請求報文，服務(wù)器讀取請求報文內(nèi)容，定位URL中相應(yīng)資源，以響應(yīng)報文的方式傳送給瀏覽器，瀏覽器解析響應(yīng)報文中的實體數(shù)據(jù)，呈現(xiàn)出靜態(tài)和動態(tài)頁面。其工作原理如下所示：

1）瀏覽器建立連接

瀏覽器根據(jù)DNS返回的域名的IP地址和服務(wù)器端口號（默認為80），建立基于TCP的套接字連接，具體參考TCP之連接的建立與終止

2）發(fā)送HTTP請求

以請求報文的形式，包括請求行、請求頭部、空行和實體數(shù)據(jù)部分

3）服務(wù)器解析請求并發(fā)送HTTP響應(yīng)

服務(wù)器解析請求報文，定位請求資源位置，以響應(yīng)報文的方式返回，包括響應(yīng)行、響應(yīng)頭部、空行和實體數(shù)據(jù)，具體分析見下文

4）瀏覽器解析實體數(shù)據(jù)

將靜態(tài)頁面和動態(tài)頁面顯示在瀏覽器窗口

??? 在HTTP/1.0版本中，其連接建立一次，斷開一次。為解決此問題，HTTP/1.1中提出持久化連接方式，只要任意一端沒有提出斷開連接，則保持TCP連接狀態(tài)。在持久連接基礎(chǔ)上，管線化發(fā)送成為可能。管線化方式，無需等待上次請求響應(yīng)，直接發(fā)送下一次請求，如圖一所示：

圖1 ： 管線化方式發(fā)送

??? 雙方在傳送數(shù)據(jù)時，在不同的業(yè)務(wù)場景下，可選擇不同方式來提高效率。常見的有壓縮傳輸、分割傳輸?shù)姆謮K傳輸、多部分對象結(jié)合傳輸和部分內(nèi)容的范圍請求傳輸。

??? 需要注意的是，HTTP只被用來發(fā)布客戶端和服務(wù)端的應(yīng)用層命令。當進行數(shù)據(jù)傳輸時，除了在數(shù)據(jù)流的開始和結(jié)束部分，是看不到應(yīng)用層的控制信息的，如圖2所示：

圖2 ： wireshark抓包分析HTTP

二、HTTP報文結(jié)構(gòu)分析

HTTP報文分為請求報文和響應(yīng)報文，其組成包括請求首部（響應(yīng)首部）、空白行和實體數(shù)據(jù)組成?？瞻仔?，即使沒有數(shù)據(jù)也不能省略。而請求首部由請求行（響應(yīng)首部由響應(yīng)行）、請求頭部（響應(yīng)頭部）、通用首部、實體首部和其他項組成，如圖3所示：

圖3 ： 報文結(jié)構(gòu)

上圖中請求行和狀態(tài)行，是需要特別注意的。而首部的類型和種類之多，需要參考《HTTP權(quán)威指南》查閱學習。

1）請求行：方法名、路徑名和版本號組成

HTTP/1.1中有八種方法，下面一一介紹方法的使用情況：

GET：用來請求訪問已被標示的資源，資源是文本，直接返回；資源是程序，返回執(zhí)行的結(jié)果

POST ： 用來傳輸實體主體，與GET類似，但是主要目的并不是為獲取響應(yīng)的主體內(nèi)容

PUT ： 用來傳輸文件，因自身不具備驗證機制，存在安全問題，通常不使用

DELETE ： 用來刪除文件，與PUT方法相反，同樣因自身不具備驗證機制，通常不使用

HEADER： 與GET方法相同，只是不返回報文實體數(shù)據(jù)，主要用于確認URL的有效性及資源的 日期時間等

OPTIONS： 用來查詢針對請求URI指定的資源支持的方法

TRACE： 用來確認連接過程中發(fā)生的一系列操作，因容易產(chǎn)生跨站追蹤攻擊，通常不使用

CONNECT：基于SSL和TLS實現(xiàn)通信內(nèi)容加密傳輸，主要在HTTPS中使用，下文介紹

而上面的八種方法中，通常是GET和POST方法，介紹一下二者的不同，如圖4和圖5所示：

圖4 ： GET方法

圖5 ： POST方法

a）GET參數(shù)包含在URL中，以？與路徑區(qū)分，多個參數(shù)用&連接；POST參數(shù)包含在請求報文的實體數(shù)據(jù)中

b）URL的數(shù)據(jù)有長度限制，所以GET方式有限制；通常POST方式?jīng)]有長度限制

c）GET的數(shù)據(jù)在URL中，使用明文傳送，容易被獲??；POST數(shù)據(jù)也是基于明文傳送，安全性比GET好一些

2）響應(yīng)行：版本號、狀態(tài)碼

狀態(tài)碼由表示狀態(tài)的數(shù)字和原因短語組成，狀態(tài)碼分類如下圖6：

圖6 ：? 狀態(tài)碼分類

狀態(tài)碼種類繁多，有60多種，具體參考狀態(tài)碼查詢，常見的有12種，介紹如下：

200 OK ： 表示瀏覽器發(fā)來的請求在服務(wù)器端被正常處理了

204 No Content ： 表示瀏覽器發(fā)來的請求被服務(wù)器正常處理了，但是返回的響應(yīng)報文中不包含實體數(shù)據(jù)，及瀏覽器的頁面不更新

206 Partial Content ： 服務(wù)器僅返回指定范文中的數(shù)據(jù)，即上文中的部分內(nèi)容范圍傳輸方式

301 Moved Peramanently ： 永久性重定向，即該請求資源被重新分配了URI

302 Found ： 暫時性重定向，即該請求的資源被被分配新的URI，希望本次使用新的URI

304 Not Found ： 瀏覽器發(fā)送帶有附帶條件的請求，但因發(fā)生條件不滿足的情況，服務(wù)器端不返回

400 Bad Request ： 表示請求報文中存在語法錯誤

401 Unauthorized ： 第一次請求，表示需要通過HTTP認證；若經(jīng)過第一次請求，仍然出現(xiàn)表示認證失敗

403 Forbidden ： 表示請求的資源被服務(wù)器拒絕了

404 Not Found ： 表示服務(wù)器無法找到相應(yīng)的資源，也可以表示服務(wù)端拒絕請求且不想說明原因

500 Internal Server Error ： 表示服務(wù)器在執(zhí)行請求時發(fā)生錯誤

503 Service Unavailable ： 表示服務(wù)器暫時處于超負載或正在進行停機維護

事務(wù)具有兩面性，HTTP的簡單也帶來了相應(yīng)的問題，其是一種無狀態(tài)的不安全的協(xié)議，針對這兩種劣勢，小采風和大家一起繼續(xù)往下看：

三、Cookie與Session

HTTP是一種無狀態(tài)協(xié)議，不能管理之前的請求和響應(yīng)間的狀態(tài)。為解決此問題，引入Cookie機制，通過在請求和響應(yīng)報文中增加Cookie信息來管理狀態(tài)，cookie字段就是上文報文結(jié)構(gòu)中的其他項里，如下圖7所示：

圖7 ： Cookie機制工作原理

Session是服務(wù)器為瀏覽器請求建立的程序。服務(wù)器根據(jù)請求報文中sid來標示該訪問的Session，如果沒有，則重新生成，并在響應(yīng)報文中重新添加sid，cookie與session的區(qū)別如下：

a）cookie在瀏覽器端，session在服務(wù)器端

b）cookie不安全，容易被利用進行cookie欺騙

c）session可以設(shè)置超時時間，一旦超時，重新建立

關(guān)于其具體的工作機制，參考cookie和session的區(qū)別詳解?

四、HTTPS（通常在瀏覽器端看到有加鎖符號）

HTTP存在的不足有：

a）瀏覽器和服務(wù)器互相不認證，可能遭遇偽裝

b）通信的傳輸數(shù)據(jù)使用明文傳輸，容易被截獲修改

c）數(shù)據(jù)的完整性無法保證，中途被人篡改也不知道

??? HTTPS是如何彌補HTTP在安全方面的不足呢？HTTPS不是應(yīng)用層新的協(xié)議，而是通過SSL和TSL代替HTTP的通信協(xié)議接口。通常，HTTP直接與TCP進行通信，而HTTPS中，HTTP先與SSL進行通信，后與TCP進行通信。SSL是目前應(yīng)用最廣泛的網(wǎng)絡(luò)安全技術(shù)。

??? 在介紹SSL解決HTTP安全性問題之前，我們先來了解一下加密方法。

??? 通常，加密算法是大家都知道的，但是加密和解密的密鑰是不知道的。一旦加密和解密密鑰泄露，存在安全性問題。共享密鑰加密方式，也稱為對稱密鑰加密方式，瀏覽器和服務(wù)器加密和解密使用相同的密鑰。可是，密鑰該如何傳輸呢？傳輸中間被攻擊，則安全性沒有保證。

??? 人類似乎天生就是來解決問題的。公開密鑰加密方式，也稱為非對稱加密方式。服務(wù)器，擁有一對存在一定關(guān)系的公開密鑰和私有密鑰。服務(wù)器將公開密鑰傳送給瀏覽器，瀏覽器使用收到的公開密鑰進行加密，即使中間收到攻擊，也因為沒有解密密鑰，即私有密鑰，無法解密。服務(wù)器收到加密數(shù)據(jù)后，使用私有密鑰成功解密。

??? 公開密鑰加密方式，處理速度相比于共享密鑰加密方式比較慢。

??? HTTPS中，SSL充分結(jié)合兩者優(yōu)勢，利用公開密鑰加密方式傳輸后面使用的共享密鑰加密解密的密鑰，然后瀏覽器和服務(wù)器使用共享密鑰進行加密解密處理，如圖8所示：

圖8 ： HTTPS中的混合密鑰加密方式

??????? HTTPS相比于HTTP，處理速度要慢2到200倍。主要速度影響在，

a）通信處理：HTTP與TCP之間加上SSL之后，通信量會增加很多

b）加密解密：消耗服務(wù)器和瀏覽器端硬件資源，造成較大負載

??? 所以，并不是所有的均使用HTTPS，敏感信息使用HTTPS，非敏感信息使用HTTP。

近日來，小采風沉迷在協(xié)議的迷亂中不能自拔，未來，會近一步推出協(xié)議類系列文章，歡迎各位看官關(guān)注哦！