來一場轟轟烈烈的HTTP協議掃盲革命

前言

最近一段時間在空閒之餘拜讀了一下《圖解HTTP協議》，收貨頗豐。之前不懂的地方在讀完這本書以後，豁然開朗。因而花了一些時間總結一下，其中我也查閱了一些其餘資料來補充進去，但願這篇文章能夠給你們帶來幫助。若是各位以爲我寫的還不錯的話，還望你們多多收藏點在支持哦！

網絡基礎

TCP/IP分層

TCP/IP體系有人把它分爲四層也有人把它分爲五層，不一樣書有着不一樣的分法。五層和四層的區別就在於五層的數據鏈路層和物理層對應着四層的網絡接口層。兩者都對，沒必要要糾結，瞭解一下便可。若是按照協議劃分的話，物理層是沒有必要單獨劃分出來的，畢竟物理層是沒有協議的。本篇文章採用的是四層結構。

名稱	做用
應用層	HTTP、FTP、DNS等協議就位於該層上，用於向用戶提供應用服務.
傳輸層	該層最主要的協議就是TCP和UDP協議，爲應用層實體提供端到端的通訊功能。
網絡層	該層的核心就是IP協議，規定了經過什麼樣子的路徑到達對方計算機，並把數據包傳送給對方。ARP、RARP協議也位於該層。
網絡接口層	負責接收IP數據包並經過網絡發送，或者從網絡上接收物理幀，抽出IP數據包，交給網絡層。該層常見的協議就是Ethernet 802.三、Token Ring 802.5。

TCP/IP通訊傳輸流

利用TCP/IP協議族進行通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，接收端則從下往應用層向上走。發送端在層與層之間傳輸數據時，每通過一層時就會打上一個該層對應的首部信息。反之，接收端在層與層傳輸數據時，每通過一層時會把對應的首部信息剔除。

TCP協議的三次握手

TCP協議位於傳輸層，其做用就是提升可靠的字節流服務。爲了能夠準確無誤地將數據送達到目標處，TCP協議採用了三次握手策略來保證其可靠性。其總體流程以下：

發送端首先會發送一個帶SYN標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶ACK標誌的數據包，表明「握手」結束。

對於TCP協議的三次握手，相信有很多小夥伴們有着這樣一個疑問。爲何必定要三次握手才能夠保證其可靠性，一次兩次不行嗎？針對這個問題，咱們舉個簡單的例子來講明一下。

場景描述：有一對好基友在高中畢業以後就失去了聯繫，十年過去了，基友甲經過某些方式弄到了基友乙的聯繫方式，準備打個電話給基友乙，敘敘舊，重燃當年撿肥皂的基情。

場景分析：場景中基友甲就是客戶端，而基友乙就是服務端。如今這麼一個問題，怎樣保證基友甲和基友乙能夠順利地重拾當年的肥皂情？從基友甲的角度來講，我得肯定我電話對面的是基友乙。從基友乙的角度來講，我得肯定我電話對面的是基友甲。只有雙方都能肯定電話那一頭就是對方，那麼這個肥皂情才能重拾。接下來咱們以這個維度去分析這三次握手。

第一次握手：基友甲撥通電話，說了一句「喂，請問是基友乙嗎？」（這就比如於客戶端發送一個帶SYN標誌的數據包給服務端）。這句話發出，基友甲還不能肯定對方就是基友乙，一樣基友乙也不能肯定對方是基友甲。

第二次握手：基友乙接起電話，說了一句「我是基友乙，請問你是哪位？」（這就比如於服務端回傳一個帶有SYN/ACK標誌的數據包，確認信息）。這句話一發出，基友甲就能夠肯定了對方是基友乙，但此時基友乙還不能肯定對方是基友甲。

第三次握手：基友甲肯定了電話另外一頭是基友乙，很是興奮，回了一句「你不認識我了嗎？我是基友甲啊」（這就比如於發送端再回傳一個帶ACK標誌的數據包）。這一句話一發出，那麼基友乙即可根據這句話確認了電話那一頭就是基友甲。此時，甲乙雙方都可互相確認是對方。知足能夠重拾肥皂情的條件，能夠開始重拾基友情。

經過咱們舉例這個肥皂情來對三次握手的分析，咱們發現只有三次握手才能保證通訊的可靠性，兩次是不能夠的保證的。但願我這個舉例能夠加深你們對三次握手的理解。

TCP的四次分手

上面咱們講了TCP的創建鏈接，鏈接以後必然就要遇到斷開鏈接的問題。TCP是須要四次分手才能斷開鏈接的。估計會有很多人不理解這個問題，一次客戶端發送斷開鏈接請求，還有一次服務端收到後回傳一個確認信息。兩次就能夠斷了，爲何還要四次？說到這裏，咱們要弄清楚一件事，TCP協議是採用的是全雙工模式，什麼叫全雙工？全雙工簡單來講就是能夠同時進行雙向的數據傳輸。所以，客戶端不只僅是發送端，也能夠是接收端。而服務端不只僅是接收端，也能夠是發送端。因此，咱們把TCP創建的鏈接拆成兩個單向鏈接。以下：

1. 客戶端是發送端，服務端是接收端。
2. 服務端是發送端，客戶端是接收端。

每一個鏈接斷開，咱們須要一個發送端發送斷開請求，接收端確認斷開請求，兩次分手。兩個鏈接即是兩次，總共就是四次分手。整個流程以下：

第一次分手：客戶端發送FIN報文段給服務端，用來斷開客戶端到服務端的鏈接。此時，客戶端處於FIN_WAIT_1狀態，即沒有數據要發送了，在等待服務端的斷開鏈接的確認。

第二次分手：服務端接受到來自客戶端的FIN報文段以後，回傳了一個ACK報文段，贊成了客戶端的斷開鏈接的請求。此時服務端進入CLOSE-WAIT狀態，等待關閉客戶端關閉鏈接。客戶端在接收到這個來自服務端回傳的ACK報文段時，客戶端關閉向服務端發送數據的鏈接，客戶端此時進行FIN_WAIT_2狀態。

第三次分手：斷開客戶端到服務端的鏈接以後，服務端發送一個FIN報文段給客戶端，請求斷開服務端到客戶端的鏈接。此時服務端進入LAST_ACK狀態，等待客戶端的確認。

第四次分手：客戶端接收到來自服務端的FIN報文以後，回傳一個ACK報文段，贊成鏈接關閉請求。此時，客戶端進入TIME_WAIT狀態。服務端接收到來自客戶端的ACK報文段以後，便關閉服務端向客戶端發送數據的鏈接，服務端就進入了CLOSED狀態。而客戶端此時還在等待狀態，那怎麼讓客戶端也進入CLOSED狀態呢？很簡單，客戶端在等待兩個MSL時間以後，它會自動進入CLOSED狀態。

URI和URL的區別

一說到URL和URI，那真的就是老虎老鼠傻傻分不清楚，應該有很多小夥伴們會弄混它們。URL叫作統一資源定位符，而URI叫作統一資源標識符。雖說這二者名字很類似，可是區分他們確實很簡單。URL和URI咱們能夠類比成郵政編碼和收件地址。URL的範圍是要大於URI的。咱們以淘寶的例子來講，https://www.taobao.com/這個域...，而每一個商品的地址就是一個URI。

不少AJAX工具中，地址參數名稱用的是url，例如jquery中的$.ajax方法中用的就是url，可是咱們得弄清楚HTTP請求的地址是URI，而不是URL。

簡單的HTTP協議

HTTP請求方法

名稱	描述	最低支持協議版本
GET	請求服務器上的某一資源。	1.0
POST	向指定資源提交數據進行處理請求,數據包含在請求體中。	1.0
HEAD	用於確認URI的有效性及資源更新的日期時間，不返回報文主體，只返回報文文首部。	1.0
PUT	向用來傳輸文件，將文件內容放進報文主體中，保存到URI指定位置上。	1.1
DELETE	與PUT相反，請求URI刪除指定資源。	1.1
OPTIONS	查詢針對請求URI指定的資源支持的方法。	1.1
TRACE	用於追蹤路徑。發送請求時，首部字段Max-Forwards會指定一個數值，每通過一個服務器以後，該數值減1。當該數值爲0時，中止傳輸，最後接收到的服務器響應。	1.1
CONNECT	用於在與代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。	1.1

HTTP協議1.1

持久鏈接

在1.0版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接。TCP鏈接的新建成本很高，頻繁地打開關閉會極大地增長開銷，影響性能。因而在1.1版本中引入持久鏈接的方法。其特色就是任意一端沒有明確提出斷開鏈接，則保持TCP鏈接的狀態。

管道機制

在1.1版本以前，在一個TCP鏈接中，客戶端發送一個請求以後，必須等待服務器響應以後才能發送下一個請求，不能同時並行發送多個請求。1.1版本的管道機制解決這個問題，客戶端沒必要等待服務端響應以後再發送請求了，能夠並行發送多個請求。

增長HOST字段

1.0版本中，認爲每臺物理服務器對應惟一的IP地址。因此，在1.0版本中是沒有主機名這個概念的。但隨着Web技術的發展，一臺物理服務器能夠存在多個虛擬主機，他們共享同一個IP地址。爲了解決這個問題，HOST字段應運而生。

分塊傳輸編碼

在1.1版本中，在一個TCP鏈接中存在多個響應。如何區分數據包對應哪一個響應就成了問題。在1.1版本中就出現Content-Length這個字段，標記本次響應的數據長度。

例如： Content-Length: 2333
告訴客戶端本次迴應的數據長度爲2333個字節,後面的字節就不屬於此次響應

在使用Content-Length的前提條件就是得知道整個數據長度才行。所以，產生出一個數據塊的時候是不能當即傳輸給客戶端，得等全部數據產生完畢才能發送。這中間的等待時間勢必會影響性能。爲解決這個弊端，1.1版本中提出了「分塊傳輸編碼」的解決方案，在響應頭會有一個Transfer-Encoding這個字段，告訴客戶端此次響應是由數量未定的數據塊組成，每個非空數據塊都有一個16進制的數值來標記其長度。最後以長度爲0的數據塊來表示此次響應的數據發送完畢。

加入100狀態碼

隨着Web應用的複雜度不斷增長，每每服務端會加入權限控制。若是客戶端發送一個HTTP請求，請求體重帶着大量數據過來，結果服務端由於其沒有權限給它打回了。那麼這就形成無謂的開銷。100狀態碼引入以後，客戶端事先發送一個帶部分請求體的HTTP請求，若是服務端的響應碼爲100，客戶端會帶上剩餘的請求體再次發送HTTP請求。反之，則取消後續的帶有剩下的請求體的HTTP請求。

HTTP協議2.0

二進制分幀

在HTTP協議2.0中，應用層和傳輸層之間會多一個二進制分幀層。在二進制分幀層上，HTTP 2.0 會將全部傳輸的信息分割爲更小的幀,並對它們採用二進制格式的編碼 。以前HTTP1.x版本中的HTTP報文首部信息會被封裝到Headers幀，而咱們的HTTP報文主體則封裝到Data幀裏面。原先咱們是以HTTP報文爲單位傳輸的，如今HTTP報文被拆成了多個幀的形式，而且這些幀能夠亂序發送，咱們只需根據每一個幀首部的流標識符就能夠從新完成組裝。這樣極大提高了HTTP的性能。

多路複用

多路複用容許同時經過單一的 TCP 鏈接 鏈接發起多重的請求-響應消息。在 HTTP/1.1 協議中 客戶端在同一時間，針對同一域名下的請求有必定數量限制。超過限制數目的請求會被阻塞。針對這一個狀況，2.0中採用了多路複用的機制，經過單一的 HTTP/2 鏈接能夠發起多重的請求-響應報文，這樣就不用依賴多個TCP鏈接了。

首部壓縮

每次HTTP請求都會有一個請求首部，這個首部放到一些重要信息，好比Cookie、User Agent之類的字段，這些字段每次請求都是同樣的，但還必需要帶上。這就形成了一些沒必要要的浪費。2.0中就優化這一點，引入首部壓縮機制，客戶端和服務端會維護一樣一張首部信息表，每次請求只要發送索引號就能夠了，沒必要帶上請求首部上冗餘的key-value，極大地減小了沒必要要的浪費。

服務端推送

在2.0以前的版本中，服務端是屬於被動一方，只有客戶端發送請求，服務端才能發送資源。2.0協議中，服務端能夠主動地向客戶端發送資源。例如：客戶端請求一個html，裏面所須要的js和css徹底不須要客戶端解析完html以後再去請求這些內容那麼麻煩，服務端能夠在客戶端請求html的時候一塊兒回傳過來。

使用Cookie管理狀態

HTTP是一種無狀態協議，就是它不會對以前發生過的請求和響應的狀態進行管理。也就是說，沒法根據以前的狀態進行本次的請求處理。例如，咱們訪問一個須要登陸驗證的網頁，咱們登陸完成以後沒有對其登陸狀態進行管理的話，那麼每次請求新頁面都須要從新登錄一下。這樣體驗就不好。爲了解決這一尷尬，因而引入Cookie這個技術。

在沒有Cookie信息狀態下：客戶端發送一個驗證請求給服務端，服務端驗證經過以後，將驗證信息添加在Cookie中，並將其返回給客戶端。客戶端拿到這個Cookie就將其存在本地。

第二次之後（存有Cookie信息狀態）的請求：客戶端再次請求時會添加以前存在本地的Cookie發送給服務器，服務器根據Cookie帶過來的驗證信息，對其進行驗證，驗證經過直接返回數據，反之跳轉到登陸頁。

既然Cookie是存在瀏覽器端的，因此js是能夠訪問Cookie的，咱們本地也能夠用Cookie去作一些存儲的操做，下面附上js中對Cookie的操做代碼。

//寫入Cookie
function setCookie(cname, cvalue, exdays) {  
    var d = new Date();  
    d.setTime(d.getTime() + (exdays*24*60*60*1000));  
    var expires = "expires="+d.toUTCString();  
    document.cookie = cname + "=" + cvalue + "; " + expires;  
}  
//讀取Cookie
function getCookie(cname) {  
    var name = cname + "=";  
    var ca = document.cookie.split(';');  
    for(var i=0; i<ca.length; i++) {  
        var c = ca[i];  
        while (c.charAt(0)==' ') c = c.substring(1);  
        if (c.indexOf(name) != -1) return c.substring(name.length, c.length);  
    }  
    return "";  
}
//清除cookie    
function clearCookie(name) {    
    setCookie(name, "", -1);    
}

HTTP報文內的HTTP信息

HTTP報文結構

用於HTTP協議交互的信息被稱爲HTTP報文。請求端（客戶端）的HTTP報文叫作請求報文，響應端（服務器端）的叫作響應報文。HTTP報文自己是由多行（用CR+LF做換行符）數據構成的字符串文本。
HTTP報文大體可分爲請求行/響應行、報文首部和報文主體兩塊。二者由最初出現的空行（CR+LF）來劃分。關於報文首部是咱們重點須要掌握的，文章的後面咱們會有較大的篇幅去闡述，這邊就帶過。

請求報文的請求行主要三個部分組成：請求方法、URI地址和HTTP協議版本號。

例如：

POST https://segmentfault.com/api/article/draft/save HTTP/1.1

響應報文的響應行主要三個部分組成：HTTP協議版本號、HTTP狀態碼和狀態描述。

例如：

HTTP/1.1 200 OK

編碼提高傳輸速率

HTTP在傳輸數據時能夠按照數據原貌直接傳輸，但也能夠在傳輸過程當中經過編碼提高傳輸速率。經過在傳輸時編碼，能有效地處理大量的訪問請求。可是，編碼的操做須要計算機來完成，所以會消耗更多的CPU等資源。

壓縮傳輸的內容編碼

向待發送郵件內增長附件時，爲了使郵件容量變小，咱們會先用ZIP壓縮文件以後再添加附件發送。HTTP協議中有一種被稱爲內容編碼的功能也能進行相似的操做。

內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。

經常使用的內容編碼格式：

• gzip
• compress
• deflate
• identity

分割發送的分塊傳輸編碼

在本文介紹http協議1.1版本的時候，咱們就講過這些。你們能夠再次結合下面這張圖來理解整個流程。

發送多種數據的多部分對象集合

咱們發送郵件時，能夠往郵件附件裏添加圖片、視頻等數據。這個功能得益於MIME機制，它容許郵件處理文本、圖片、視頻等不一樣類型的數據。MIME採用就是多部分對象集合的方法來容納多份不一樣類型的數據。

咱們在HTTP協議框架下上傳圖片或文本文件等數據時，也採用了這個多部分對象集合的方法。

多部分對象集合包含的對象以下：

• multipart/form-data

  web表單上傳文件時使用

• multipart/byteranges
  狀態碼206響應報文包含了多個範圍的內容時使用。

例如：

content-type:multipart/form-data; boundary=WebKitFormBoundary5V53Jp7BUFBGzu9B

// 注：boundary指定劃分多部分對象集合的起止符

--WebKitFormBoundary5V53Jp7BUFBGzu9B
Content-Disposition: form-data; name="image"; filename="表二：價值觀評分表.numbers"
Content-Type: application/x-iwork-keynote-sffnumbers


--WebKitFormBoundary5V53Jp7BUFBGzu9B--


//開始的標記：--WebKitFormBoundary5V53Jp7BUFBGzu9B 
//結束的標記：--WebKitFormBoundary5V53Jp7BUFBGzu9B--

獲取部份內容的範圍請求

在很早以前互聯網技術還不是很發達的時候，好比咱們下載一個稍微大一點的遊戲得時候，若是中途遇到什麼狀況中斷了下載，就必須從新從零開始下載，那種痛在如今高速網絡的時代是沒法體會到，固然我也是沒法體會到的，由於我還很年輕，哈哈哈！爲了解決這種痛，範圍請求技術應運而生，中斷的下載即可得以恢復。

執行範圍請求時，會用到首部字段Range來指定資源的byte範圍。

1.Range:bytes=5001-10000          5001~10000字節
2.Range:bytes=5001-               從5001字節以後所有的內容
3.Range:bytes=-3000,5000-7000     從0~3000字節和5000~7000字節的多重範圍

針對這個範圍請求，咱們上面所說到響應會返回狀態碼206。其中針對多重範圍的範圍請求時，響應會在用上首部字段Content-Type:multipart/byteranges。

內容協商返回最合適的內容

在全球化的浪潮下，催生了一大批國際公司，像國際知名的視頻網站YOUTUBE，天天都有來自全球各地的網民登陸這個網站。這樣面臨了一個問題，不一樣的國家他們的語言是不同的，YOUTUBE不可能對全部人都千篇一概，都用英文，那這樣就不符合這種國際知名大公司的形象。因此YOUTUBE也不可能這麼作，可是怎麼保證不一樣國家的網民能夠對應不一樣語言的網站呢？爲解決這個問題，內容協商機制就應運而生。若是咱們使用的瀏覽器設置的語言是簡體中文，那麼咱們訪問YOUTUBE的時候，則給咱們顯示的網頁即是簡體中文的，以此類推。

內容協商機制是指客戶端和服務器端就響應資源進行交涉，而後提供客戶端最合適的資源。

請求報文某些首部字段做爲判斷的基準,以下：

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language

內容協商技術有如下三種類型：

• 服務器驅動協商 （由服務器端進行內容協商的方式）
• 客戶端驅動協商 （由客戶端進行內容協商的方式）
• 透明協商 （由服務器端和客戶端各自進行內容協商的方式）

返回結果的HTTP狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。藉助狀態碼，用戶能夠知道服務器端是正常處理了請求，仍是出現了錯誤。這裏咱們列舉常見的HTTP狀態碼，其餘感興趣的能夠本身去查閱。這裏咱們附上完整的HTTP狀態碼的地址：https://developer.mozilla.org...

1XX

100 Continue （繼續）

客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者若是請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。

101 Switching Protocols （切換協議）

服務器已經理解了客戶端的請求，並將經過Upgrade 消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade 消息頭中定義的那些協議。

2XX

200 OK (成功)

表示從客戶端發來的請求在服務器端被正常處理了

204 No Content （無內容）

服務器成功處理了請求，但在返回的響應報文不含任何實體內容。好比：頁面上有一個a標籤，它的href屬性設置的是http-204.html，點擊a標籤，正常狀況下會跳轉到http-204.html。可是，若是http-204.html的響應碼是204，則頁面不跳轉，停留在當前頁。

206 Partial Content（部份內容）

該狀態碼在前面範圍請求的時候提到過，它表示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定範圍的實體內容。

3XX

301 Moved Permanently （永久重定向）

該狀態碼錶示請求的資源已被分配了新的URI，之後應使用資源如今所指的URI。響應報文的首部字段會用location字段來標記新的URI。

302 Found （臨時重定向）

該狀態碼錶示本次請求的資源被臨時分配了新的URI。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。一樣，在響應報文的首部字段location中也會標記本次被分配到的新的URI。

303 See Other （查看其它位置）

該狀態碼錶示對應當前請求的響應能夠在另外一個URI上被找到，並且客戶端應當採用GET的方式訪問那個資源。這裏須要注意到的一點就是，303明確說明須要用GET方法獲取。跟上面同樣，在響應報文的首部字段location中也會標記本次被分配到的新的URI。

304 Not Modified （未修改）

該狀態碼錶示所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端一般會緩存訪問過的資源，經過提供一個頭信息指出客戶端但願只返回在指定日期以後修改的資源。

307 Temporary Redirect （臨時重定向）

跟302 Found的含義是同樣的。爲何會有307的出現？願意在於當303標準雖然禁止POST變成GET,可是實際狀況卻常常發生，而307會嚴格遵照標準，不會把POST變成GET。在POST重定向中會頗有用。

4XX

400 Bad Request （錯誤請求）

該狀態碼錶示因爲包含語法錯誤，當前請求沒法被服務器理解，需從新修改再次發送請求。在開發過程當中，你們把400概括到前端的問題，而後後端不理不睬的。這樣劃分是不對的，這裏語法錯誤大多數狀況下並非前端寫的有問題，而是前端某些字段類型與後端沒有協同好，好比後端接受的是Long類型或者Date，而前端傳的String。又或者前端用json傳給後端，後端沒有作解析json的操做。這些問題不少狀況下是先後端沒有協同好形成的，而不是單純是前端的問題。

401 Unauthorized （未受權）

該狀態碼錶示當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的WWW-Authenticate信息頭用以詢問用戶信息。

403 Forbidden （已禁止）

該狀態碼錶示對請求資源的訪問被服務器拒絕了。這種在爬蟲過程當中最多見，對方發現你正在爬他們網站的數據，而後對你的IP進行限制，就會形成403.

404 Not Found（未找到）

該狀態碼錶示服務器上沒有找到請求的資源。這個你們常常會遇到，好比說手抖啦，打錯字母或者你訪問的網站被封啦之類的。

405 Method Not Allowed（方法禁用）

該狀態碼錶示請求行中指定的請求方法不能被用於請求相應的資源。該響應報文必須返回一個Allow頭信息用以表示出當前資源可以接受的請求方法的列表。

5XX

500 Internal Server Error（服務器內部錯誤）

該狀態碼錶示服務器在執行請求時發生了錯誤，能夠是代碼存在bug或者某些臨時性的故障。

503 Service Unavailable（服務不可用）

該狀態碼錶示服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。

HTTP首部

前面在提到HTTP報文的結構時，咱們說過HTTP報文首部是很是重要的一塊，將單獨拎出來大篇幅地區講它。這裏咱們將重點講這個問題。

首先咱們要肯定報文首部構成，報文首部能夠請求首部（請求頭）和響應首部（響應頭）。其中，請求首部可拆分爲請求首部字段、通用首部字段、實體首部字段、其餘拓展首部字段，而響應首部可拆分紅響應首部字段、通用首部字段、實體首部字段、其餘拓展首部字段。由上咱們能夠得出：

報文首部=請求首部字段/響應首部字段+通用首部字段+實體首部字段+其餘拓展首部字段

下面咱們將從請求首部字段、響應首部字段、通用首部字段、實體首部字段這四個部分入手，因爲字段過多，咱們只挑選其中比較常見的首部字段進行闡述。完整版的HTTP首部能夠自行查看，附上地址：https://developer.mozilla.org...

請求首部字段

Accept

該字段用於指定客戶端接受哪些類型的信息。

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

上一個例子中的q=來額外表示權重值，用（;）進行分割。q的取值範圍爲0~1（可精確到小數點後3位），且1爲最大值。不指定權重q值時，默認權重爲q=1.0。另外，能夠用（*）做爲通配符，指定任意類型信息。

Accept-Charset

該字段用於用於指定客戶端接受的字符集。

Accept-Charset:iso-8859-15,unicode-1-1;q=0.8

這裏的q跟Accept的q的效果一致，再也不贅述。通配符（*）也一樣一致。

Accept-Encoding

用於指定客戶端可接受的內容編碼。

Accept-encoding:gzip, deflate;q=0.9, br

這裏一樣能夠用q來表示其優先級,與Accept相同。另外，通配符（*）一樣一致。

Accept-Language

用於指定客戶端可接受的天然語言集（指中文或英文等）。

Accept-Language:zh-CN,zh;q=0.9,en;q=0.8

權重值q跟Accept一致，通配符（*）也一致。

Authorization

主要用於證實客戶端有權查看某個資源。一般，想要經過服務器認證的用戶代理會在接收到返回的401狀態碼響應後，會首部字段Authorization加入請求中。

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Expect

用於指按期望條件，並告知服務器只有在知足此指望條件的狀況下才能妥善地處理請求。HTTP/1.1只規範了一個指望條件，即：

Expect: 100-continue

服務器會返回狀態碼100或者狀態碼417，返回100表示請求頭中的指望條件能夠獲得知足，而417則表示不能知足請求頭的指望條件。

From

用於告知服務器發送請求的用戶代理的實際用戶的電子郵件地址。好比說：若是你在運行一個機器人代理程序（好比爬蟲），那麼 Form 首部應該隨請求一塊兒發送，這樣的話，在服務器遇到問題的時候，例如機器人代理髮送了過量的、不但願收到的或者不合法的請求，站點管理員能夠聯繫到你。

From: webmaster@example.org

Host

指明瞭服務器的域名（用於區分虛擬主機），以及（可選的）服務器監聽的TCP端口號。端口號是可選的，若是未指定端口，則會自動調用被請求服務器的默認端口號。

Host: developer.cdn.mozilla.net

If-Match

形如If-xxx這樣樣式的請求首部字段，都是條件請求。服務器接收到附帶條件的請求後，只有判斷指定條件爲真時，纔會執行請求。

If-Match，它會告知服務器匹配資源所用的ETag值，服務器會比對If-Match的字段值和資源的ETag值，僅當二者一致時，纔會執行請求。ETag 之間的比較使用的是強比較算法，即只有在每個字節都相同的狀況下，才能夠認爲兩個文件是相同的。在 ETag 前面添加 W/ 前綴表示能夠採用相對寬鬆的算法。

If-None-Match,它與If-Match功能正好相反。

If-Match

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-Match: W/"67ab43", "54ed21", "7892dd"
If-Match: *

If-None-Match

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-None-Match: W/"67ab43", "54ed21", "7892dd"
If-None-Match: *

If-Modified-Since/If-Unmodified-Since

If-Modified-Since,服務器只在所請求的資源在 If-Modified-Since 給定的日期時間以後對內容進行過修改的狀況下才會將資源返回，狀態碼爲200。若是未經修改，那麼返回一個不帶有消息主體的 304 響應，而在 Last-Modified 首部中會帶有上次修改時間。

If-Unmodified-Since,它與If-Modified-Since做用相反

If-Modified-Since

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

If-Unmodified-Since

If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT

If-Range

該字段與Range字段配合使用，If-Range字段值中的條件獲得知足時，Range 頭字段纔會起做用，同時服務器回覆狀態碼206（部份內容）以及返回Range字段指定的內容。反之沒有獲得知足，服務器則將會返回狀態碼200，並返回完整的請求資源。

If-Range: Wed, 21 Oct 2015 07:28:00 GMT

Max-Forwards

前面在講到TRACE方法時，咱們講到了Max-Forwards字段。使用HTTP協議通訊時，請求可能會通過多個代理服務器。途中，若是代理服務器因爲某些緣由致使請求轉發失敗，中間咱們是不知道是哪臺代理服務器失敗了。而設置Max-Forwards字段以後，每通過一臺代理服務器，Max-Forwards便會減1，到0以後便不會進行轉發，而是直接返回響應。這樣咱們就能夠輕鬆排查出是哪臺代理服務器出問題了。

Proxy-Authorization

這個字段的做用跟Authorization是同樣的，他們之間的區別在於Proxy-Authorization用於客戶端與代理服務器之間的認證，而Authorization是用於客戶端和服務器之間的認證

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Range

該字段用於只獲取部分資源的範圍請求，Range字段指定了其範圍。成功處理範圍請求，則返回狀態碼 206 （部份內容）。若指定範圍超出邊界，則返回狀態碼416 Range Not Satisfiable （範圍沒法知足）。範圍合法但沒有成功處理，則返回狀態碼200，並響應所有資源。

Range: bytes=200-1000, 2000-6576, 19000-

Referer

當前請求頁面的來源頁面的地址，即表示當前頁面是經過此來源頁面裏的連接進入的。

Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript

TE

該字段用於告知服務器客戶端可以處理響應的傳輸編碼方式及相對優先級。這裏不要跟Accept-Encoding弄混， TE是用於傳輸編碼，而Accept-Encoding用於內容編碼。

TE: trailers, deflate;q=0.5

User-Agent

發起請求的瀏覽器或者用戶代理軟件的應用類型、操做系統、軟件開發商以及版本號等。

User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36
Name

響應首部字段

Accept-Ranges

用於告知客戶端服務器是否能處理範圍請求，若能，則定義範圍請求的單位。取值有兩種none和bytes。

Accept-Ranges: bytes   //範圍請求單位爲bytes
Accept-Ranges: none    //不支持範圍請求

Age

當緩存服務器用本身的緩存的資源去響應請求時，用該頭部標識該資源在緩存服務器緩存的時長，單位爲秒。

Age:600

ETag

服務器分配給每份資源的惟一標識符。當資源更新時，ETag也會相應更新。ETag分爲強ETag和弱ETag。

Etag:"33a64df551425fcc55e4d42a148795d9f25f89d4"  //不管實體發生多麼細微的變化都會改變其值。

ETag: W/"0815"  //只有資源發生了根本改變，產生差別時才改變ETag值。字段值最開始處附加W/

Location

指定須要將頁面從新定向至的地址，通常在響應碼爲3xx的響應中才會有意義。

Location:http//www.haimaiche.com/index.html

Retry-After

告知客戶端應該在多久以後再次發送請求。主要配合503 Service Unavailable 或者3XX Redirect響應一塊兒使用。取值能夠是具體的日期時間也能夠是建立響應後的秒數。

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120

Server

包含服務器所用到的軟件相關信息。

Server: Apache/2.4.1 (Unix)

Vary

用於控制緩存。從代理服務器接收到服務器返回包含Vary指定項的響應以後，若再要進行緩存，僅對請求中含有相同Vary指定首部字段的請求返回緩存。即便對相同資源發起請求，但因爲Vary指定的首部字段不相同，也必需要從源服務器從新獲取資源。

Vary:Accept-Language

註解：
當代理服務器接收到帶有Vary首部字段指定獲取資源的請求時，若是使用的Accept-Language字段的值相同時，則直接從緩存返回響應。反之，則須要先從源服務器端獲取資源後才能做爲響應返回。

WWW-Authenticate

定義了使用何種驗證方式去獲取對資源的鏈接。

WWW-Authenticate: Basic realm="Access to the staging site"

通用首部字段

Cache-Control

指定指令，用於控制緩存行爲。指令能夠多選，中間用」,「分割。

Cache-Control: no-cache, no-store, must-revalidate

緩存請求指令

指令	參數	說明
no-cache	無	強制向源服務器再次驗證
no-store	無	不緩存請求或響應的任何內容
no-transform	無	代理不可更改媒體類型
only-if-cached	無	從緩存獲取資源
max-age=<seconds>	必需	響應的最大Age值
max-stale[=<seconds>]	可省略	接受已過時的響應
min-fresh=<seconds>	必需	指望在指定時間內的響應仍有效

緩存響應指令

指令	參數	說明
no-cache	無	緩存前必須先確認其有效性
no-store	無	不緩存請求或響應的任何內容
no-transform	無	代理不可更改媒體類型
public	無	可向任意方提供響應的緩存
private	無	僅向特定用戶返回響應
must-revalidate	無	可緩存但必須再向源服務器進行確認
proxy-revalidate	無	要求中間緩存服務器對緩存的響應有效性再進行確認
max-age=<seconds>	必需	響應的最大Age值
s-maxage=<seconds>	必需	公共緩存服務器響應的最大Age值

Connection

決定當前的事務完成後，是否會關閉網絡鏈接。Http協議1.1以後默認都是keep-alive（持久鏈接），1.0則是close（非持久鏈接）。

Connection: keep-alive
Connection: close

Date

標明HTTP報文的建立日期和時間。

Date: Wed, 21 Oct 2015 07:28:00 GMT

Pragma

用來向後兼容只支持 HTTP/1.0 協議的緩存服務器

Pragma: no-cache   //惟一形式

Trailer

容許發送方在分塊發送的消息後面添加額外的元信息，經常使用於分塊傳輸編碼中。

HTTP/1.1 200 OK 
Content-Type: text/plain
... 
Transfer-Encoding: chunked
Trailer: Expires
...(報文主體)...
0
Expires: Wed, 21 Oct 2015 07:28:00 GMT

以上用例中，指定首部字段Trailer的值爲Expires，在報文主體以後（分塊長度0以後）出現首部字段Expires。

Transfer-Encoding

規定了報文主體時採用的編碼方式。

Transfer-Encoding: chunked

Via

用於追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。報文通過代理或網關時，會先在首部字段Via中附加該服務器的信息，而後再進行轉發。常常和TRACE方法一塊兒使用。

Via: 1.0 fred, 1.1 p.example.net

Warning

用於告知用戶一些與緩存相關的問題的警告。

Warning: <警告碼> <警告的主機:端口號> <警告爲別把> [<日期時間（可選）>]
Warning: 112 gw.hacker.jp:8080  "cache down" " Wed, 21 Oct 2015 07:28:00 GMT"

警告碼錶

警告碼	警告內容	說明
110	Response is Stale	由緩存服務器提供的響應已過時（設置的失效時間已過）。
111	Revalidation Failed	因爲沒法訪問服務器，響應驗證失敗。
112	Disconnected Operation	緩存服務器斷開鏈接。
113	Heuristic Expiration	若是緩存服務器採用啓發式方法，將緩存的有效時間設定爲24小時，而在該響應的年齡超過24小時時發送。
199	Miscellaneous Warning	任意的警告信息。
214	Transformation Applied	由代理服務器添加，若是它對返回的展示內容進行了任何轉換，好比改變了內容編碼、媒體類型等。
299	Miscellaneous Warning	因爲沒法訪問服務器，響應驗證失敗。

實體首部字段

Allow

告訴客戶端資源所支持的HTTP方法。

Allow: GET, POST, HEAD

Content-Encoding

告知客戶端服務器對實體主體部分選用的內容編碼方式。

Content-Encoding: gzip

Content-Language

告知客戶端，實體主體使用的天然語言。

Content-Language: zh-CN

Content-Length

代表實體主體部分的大小，單位是字節。

Content-Length:15000

Content-Location

表示返回的數據對應的URI，主要用於指定要訪問的資源通過內容協商後的結果的URI。

Content-Location:http://www.hacker.jp/index.html

Content-Range

主要用於範圍請求，告知客戶端當前發送部分的內容範圍以及整個實體大小。

Content-Range: bytes 200-1000/67589

Content-Type

代表實體主體內對象的媒體類型。

Content-Type: text/html; charset=utf-8

Expires

將資源的失效日期告訴客戶端。緩存服務器在接收到含有首部字段Expires的響應後，在Expires指定時間以前，響應的副本會一直被保存。反之，緩存服務器會向源服務器請求資源。當Cache-Control有指定max-age或者s-maxage指令時，Expires則會被忽略。

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Last-Modified

代表資源最終的修改時間。

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

其餘拓展首部字段

Set-Cookie

用來由服務器端向客戶端發送cookie

Set-Cookie: id=a3fWa;Domain=somecompany.co.uk; Path=/ Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Domain：指定Cookie能夠發送的主機名
Path：限定能夠發送Cookie的路徑
Expires：指定Cookie的有效期
Max-Age：多少秒以後Cookie失效，ie8及其如下不支持這個屬性，Max-Age優先級大於Expires
Secure：僅在HTTPS安全通訊時纔會發送Cookie
HttpOnly：使js沒法獲取Cookie

Cookie

含有先前由服務器經過Set-Cookie首部投放並存儲到客戶端的Cookie。

Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;

DNT

位於HTTP請求首部。全稱Do Not Track。表示拒絕被精準廣告追蹤的一種方法。

DNT:0;//贊成目標站點追蹤用戶我的信息。
DNT:1;//不一樣意目標站點追蹤用戶我的信息。

X-Frame-Options

主要位於HTTP響應首部，用於控制網站內容在其餘Web網站的Frame標籤內的顯示問題。 其主要目的是爲了防止點擊劫持（clickjacking）攻擊。

有如下三個取值：

• DENY：表示該頁面不容許在 frame 中展現，即使是在相同域名的頁面中嵌套也不容許。
• SAMEORIGIN：表示該頁面能夠在相同域名頁面的 frame 中展現。
• ALLOW-FROM uri：表示該頁面能夠在指定來源的 frame 中展現。

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM http://caibaojian.com/

X-XSS-Protection

當檢測到跨站腳本攻擊 (XSS)時，瀏覽器將中止加載頁面。針對現代瀏覽器，會選擇更強大的Content-Security-Policy。關於Content-Security-Policy可參考阮一峯老師的這篇文章《Content Security Policy 入門教程》

X-XSS-Protection: 0  //禁止XSS過濾。
X-XSS-Protection: 1  //啓用XSS過濾（一般瀏覽器是默認的）。若是檢測到跨站腳本攻擊，瀏覽器將清除頁面（刪除不安全的部分）。
X-XSS-Protection: 1; mode=block //啓用XSS過濾。 若是檢測到攻擊，瀏覽器將不會清除頁面，而是阻止頁面加載。
X-XSS-Protection: 1; report=<reporting-uri> //啓用XSS過濾。 若是檢測到跨站腳本攻擊，瀏覽器將清除頁面並使用CSP report-uri指令的功能發送違規報告。

確認Web安全的HTTPS

說到HTTPS，相信你們都很熟悉，什麼是HTTPS?說白了就是HTTP的安全版，在HTTP層面上加入了安全控制。下面咱們要說說HTTP有哪些安全問題？HTTPS又是如何保證安全的。

HTTP缺點

通訊使用明文可能會被竊聽

因爲HTTP自己不具有加密的功能，因此HTTP報文都是以明文的方式發送的。而整個互聯網那些網絡設備都不多是你我的的，這就不能排除某個環節中遭到惡意窺探的行爲。

即便你人爲地在發送以前的採用對稱加密算法加密了，且不說影響效率，接收方每次都須要解密一下。這樣能夠真的保證其安全嗎？答案是不能保證的。接收方想要解密密文首先得知道這採用什麼方式加密的或者密鑰又是啥？這個是須要發送方給接收方的，而這個發送密鑰或者加密方式的過程依舊是處於被竊聽的危險中，因此僅僅靠加密數據是沒法保證其安全性的。

不驗證通訊方的身份就有可能遭遇假裝

HTTP協議是不會對通訊方進行確認的。不管誰發送過來的請求都會返回響應。這就可能存在有假裝的客戶端或者服務器，一些本有權限控制的資源遭到盜取。Dos攻擊就是利用HTTP協議不進行通訊方確認的漏洞，發送海量無心義請求，超出服務器的負荷，致使服務器奔潰宕機。

沒法證實報文完整性，可能已遭篡改

前面咱們說到互聯網上網絡設備因爲不屬於你我的的，很難保證他人會不會劫取你的信息並進行篡改。致使服務器傳送給客戶端的文件和客戶端實際接收到的文件不能保證一致。

HTTP通訊過程

第一步： 客戶端發送一段包含有客戶端支持的SSL/TLS協議版本、可支持加密組件（使用的加密算法以及密鑰長度等）報文給服務器。
第二步： 服務器會根據客戶端支持的SSL/TLS協議版本以及其支持的加密中選擇一種，做爲後續通訊過程當中所使用的SSL/TLS協議以及加密組件，並放在報文中告知客戶端。
第三步： 以後服務器會再發送一段報文，其中包含公開密鑰證書。與公鑰相配對的私鑰則留在服務器本身那。
第四步： 客戶端拿到公開密鑰的證書以後，會向頒發數字認證證書的機構確認其合法性。若合法，則會根據與服務器協商肯定的加密組件，隨機生成一個密鑰，而這個密鑰將用於後續報文的加密。並將生成好的密鑰用服務器給的公鑰進行加密，併發送給服務器。
第五步： 服務器拿到客戶端加密過得密鑰以後，會用以前留在本身那的私鑰去解密獲取到密鑰。
第五步： 客戶端與服務器之間通訊的報文都會用到這個密鑰進行加密。

上面的過程第一次讀可能沒法理解，如今在從新總結一下。整個HTTPS通訊大致能夠分爲三個階段：

1.協商決定加密組件
2.肯定加密解密密鑰
3.客戶端與服務器開始報文通訊

這裏咱們理清楚一點，最終用來加密解密的密鑰並非由服務器生成的，而是客戶端生成的。其中部分細節咱們在後續會講到。

HTTP+加密+認證+完整性保護=HTTPS

首先咱們弄要弄清楚一件事，HTTPS並不是應用層的一種新協議。只是HTTP通訊接口部分用SSL或者TLS協議代替而已。原先HTTP協議直接和TCP協議對接，而HTTPS則是HTTP先與SSL/TLS通訊,再由SSL/TLS和TCP通訊。

加密

前面咱們說到HTTP是採用明文傳輸的，這就免不了你的信息會被他人窺探。即便是採用對稱加密算法，沒法保證你在發送密鑰的過程當中不被他人竊取到。換句話說咱們保證了密鑰的安全傳輸，那麼整個通訊過程就不怕被窺探到了。HTTPS採用了非對稱加密的方式，用公鑰去加密，用私鑰去解密。服務器把公鑰交給客戶端去加密通訊密鑰，而後再用本身的私鑰去解密就可獲取到通訊密鑰。常見的非對稱加密算法就是RSA，有興趣的小夥們能夠自行了解一下，這裏再也不贅述。

上面提到了非對稱算法感受是個好東西，服務器和客戶端通訊的報文采用非對稱加密算法不就完了，幹嗎還要繞一個彎，採用非對稱加密+對稱加密的組合。HTTPS這樣設計是有其緣由的，非對稱加密算法看似很美好，可是其對CPU和內存的開銷太大。有人作過實驗，在加解密同等數量的文件下，非對稱算法的開銷是對稱算法的1000倍以上。因而可知，這個非對稱算法是多影響性能。性能這個問題，就算能夠忍受，非對稱算法有一個致命的缺點就是加密內容的長度不得超過公鑰長度，經常使用的公鑰長度是2048位，也就是256個字節，也就意味着加密的密文的大小不能超過256個字節。這個就太坑爹了，如今網絡上的圖片隨隨便便就是幾千字節，這個就真的不能忍了。若是這樣你都能忍，那你是真的diao，是在下輸了。

認證

前面說到HTTP整個過程當中，你的報文是能夠被劫取到的，因此在發送公鑰的過程當中很難保證其不被掉包。爲了保證密鑰的合法性，HTTPS採用了數字證書這個概念。整個數字證書認證流程是這樣子的：

首先服務器的運營人員會想權威的第三方數字證書認證機構申請公開密鑰。數字證書認證機構在判明申請者的身份以後，對已申請的公開密鑰作數字簽名的操做，並把這個數字簽名分配給這個公開密鑰，並將已簽名過的公開密鑰放在公鑰證書裏面。客戶端拿到這個公鑰證書以後，向數字證書認證機構提出驗證公鑰證書上數字簽名的請求，以確認公開密鑰的真實性。

有了第三方的數字證書驗證機構，咱們就能夠保證了公開密鑰不被他人惡意篡改。

完整性保護

有了加密和認證足以保證通訊報文能夠不被他人看到，但咱們報文是能夠被他人截取到進行篡改的。好比完整的信息是這樣子的「我不要你作個人女友了，我要你作個人老婆」，這原本是一句很是浪漫的話，要是被破壞了只傳了「我不要你作個人女友了」，接收方還不知道這個信息是被篡改過得，那麼就出大事了，這對小情侶就拜拜了，一段好姻緣就這麼被破壞了。爲了世界和平，咱們還保護報文的完整性。HTTPS使用了MAC算法來保證其完整性。發送方發送報文會帶有一個由MAC算法得出的一個MAC值。接受方拿到報文以後會根據密鑰和MAC算法再算出一個MAC值，與傳過來的MAC值進行比對，若一致則沒有遭受篡改，這樣就能夠知道報文有沒有被篡改過。

HTTPS相比較HTTP的缺點

HTTPS相比較HTTP並非各個方面都強於HTTP的。如果這樣，那咱們如今怕是見不到採用HTTP協議的網站了。HTTPS相比較HTTP主要有三個缺點：

速度慢

本來HTTP直接和TCP進行通訊，如今中間出現了一個第三者SSL/TLS，勢必會形成處理的通訊量變大，拖累速度。

CPU及內存等資源的消耗大

頻繁地加解密，毫無疑問就須要更多CPU和內存等資源的支持，致使負載加強。

要錢

要進行HTTPS通訊，證書是必不可少的，這個得向認證機構購買的，人認證機構不可能白給你的，收取點費用也是理所固然的。前面兩個爲了安全仍是能夠接受的，這個緣由我我的以爲是一些網站不使用HTTPS的主要緣由，畢竟談錢傷感情嘛。固然窮逼不表明沒有活路，總有一些大神在默默地拯救着咱們這羣窮屌絲，《Let's Encrypt，免費好用的 HTTPS 證書》 。另外再幫別人打個小廣告，《給網站戴上「安全套」》，請記住個人名字，我叫雷鋒！

確認訪問用戶身份的認證

隨着Web技術的發展，愈來愈多的網站都更加地精細化，有些內容或者操做只有特定的用戶才能看見或者操做。此時，就須要驗證坐在計算機前面的那我的是否是屬於那些特定用戶，下面咱們就說說HTTP使用的認證方式。

BASIC認證

流程1： 當客戶端訪問的資源須要BASIC認證時，服務器會返回401，並在響應頭添加首部字段WWW-Authenticate，該字段包含驗證方式（BASIC）以及realm（告訴客戶端要訪問的資源屬於服務器衆多區域中的哪一片區域裏， 若是未指定realm, 客戶端一般顯示一個格式化的主機名來替代。）
流程2： 客戶端接收到狀態碼401以後，就會根據響應頭中的WWW-Authenticate指定的認證方式（BASIC）把用戶名和密碼用冒號（:）進行鏈接，而後再Base64編碼處理，最後塞到請求頭首部字段Authorization中發送給服務器。

舉個栗子：

用戶名：admin  密碼：123456

admin:123456    =>  YWRtaW46MTIzNDU2

Authorization: BASIC  YWRtaW46MTIzNDU2

流程3： 服務器接收到含有首部字段Authorization的請求以後，對其認證信息進行確認。經過，則返回其請求的資源。

BASIC認證僅僅作了Base64編碼，並未進行進行加密處理，頗有可能會被他人竊聽盜取，安全性太差。

DIGEST認證

流程1： 當客戶端訪問的資源須要DIGEST認證時，服務器會返回401，響應頭部比Basic模式複雜，WWW-Authenticate: Digest realm=」myTomcat」,qop="auth",nonce="xxxxxxxxxxx",opaque="xxxxxxxx" 。其中qop的auth表示鑑別方式；nonce是隨機字符串；opaque服務端指定的值，客戶端須要原值返回。
流程2： 瀏覽器彈出對話框讓用戶輸入用戶名和密碼，瀏覽器對用戶名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合後進行MD5運算，把計算獲得的摘要信息發送給服務端。請求頭部相似以下，Authorization: Digest username="xxxxx",realm="myTomcat",qop="auth",nonce="xxxxx",uri="xxxx",cnonce="xxxxxx",nc=00000001,response="xxxxxxxxx",opaque="xxxxxxxxx" 。其中username是用戶名；cnonce是客戶端生成的隨機字符串；nc是運行認證的次數；response就是最終計算獲得的摘要。
流程3：服務端web容器獲取HTTP報文頭部相關認證信息，從中獲取到username，根據username獲取對應的密碼，一樣對用戶名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合進行MD5運算，計算結果和response進行比較，若是一致則認證成功並返回相關資源。

DIGEST認證相比BASIC認證沒有將密碼傳輸出去，在安全性上要比BASIC認證提升不少。可是要是攻擊者截取你的報文即可以用報文首部字段Authorization的值假裝起來向服務器發起請求。

SSL客戶端驗證

前面咱們說到HTTPS的時候，是服務器做爲發送證書的一方，而客戶端做爲接受證書驗證證書的一方。這裏，正好二者角色對調了一下，通話密鑰的生成方在服務器端，而不是客戶端。通常不會獨立使用，而是和表單驗證配合使用。SSL客戶端驗證用來驗證客戶端計算機，而表單驗證則用來驗證坐在計算機前的人。

基於表單驗證

目前主流的網站都是用的是表單驗證的方式。它的原理很簡單，客戶端提交帶有用戶名和密碼的表單交給後臺，後臺會生成一個特定的SessionId放在響應頭字段Set-Cookie中，客戶端接受到以後存儲到本地Cookie。以後的請求，都會把Cookie帶上，服務器便會根據Cookie裏面存的SessionId去識別用戶。

總結

這篇文章是在閱讀完《圖解HTTP協議》這本書以後做的的一篇總結性文章。HTTP協議咱們重點要掌握的是TCP/IP模型、HTTP的通訊過程、HTTP狀態碼、HTTP首部、HTTPS的原理、HTTP和HTTPS的各自優點。其中HTTP狀態碼和HTTP首部是本文的重中之重，文章花了大量篇幅去講解這兩塊。還有HTTPS，如今愈來愈多的網站開始採用這個協議，因此掌握HTTPS必不可少。但願這篇文章能夠幫助那些對HTTP協議還很模糊的小夥伴們能夠加深對HTTP協議的理解，本文不足之處歡迎留言指出。最後寫博客不易，還望小夥伴們多多點贊收藏支持！