TCP/IP協議族(二) HTTP報文頭解析

本篇博客咱們就來詳細的聊一下HTTP協議的經常使用頭部字段，固然咱們將其分爲請求頭和響應頭進行闡述。下方是報文頭每一個字段的格式，首先是頭部字段的名稱，如Accept，冒號後方緊跟的是該字段名所對應的值，每一個值之間有逗號分隔。若是該值須要優先級，那麼在值的後方跟上優先級q=0.8(q的值由0~1，優先級從低到高)。值與優先級中間由分號相隔。

頭部字段名：值1, 值2;q=0.8 

下方就是截取的網絡請求中Request Headers的部份內容。紅框中的Accept-Language就是頭部字段名，冒號後邊就是該字段相應的值了。以下所示： 

　　

HTTP頭部字段能夠分爲通用頭部字段，請求頭部字段，響應頭部字段以及實體頭部字段，下方會給出詳細的介紹。

 

一.通用頭部字段 （General Header Fields）

該字段在請求頭和響應頭都會使用到，下方是經常使用的通用頭部字段：

一、Cache-Control

用來操做緩存的工做機制，下方截圖響應頭中的的Cache-Control的參數爲private和max-age=10。private緩存是私有的，僅像特定用戶提供相應的緩存信息。若是是public，那麼就意味着可向任意方提供相應的緩存信息。max-age = 10表示緩存有效期爲10秒。從下方的Expires(過時時間)和Last-Modified(最後修改時間)就能夠看出，這二者之間的差值正好是10秒。

該字段還能夠對應其餘的參數：

• no-cache：若是是客戶端的話，說明客戶端不會接收緩存過的響應，要請求最新的內容。而服務器端則表示緩存服務器不能對相應的資源進行緩存。

• no-store：表示緩存不能在本地存儲。

• max-age：該參數後方會被賦值上相應的秒數，在請求頭中表示若是緩存時間沒有超過這個值就返回給我。而在響應頭中時，則表示資源在緩存服務器中緩存的最大時間。

• only-if-cached：表示客戶端僅僅請求緩存服務器上的內容，若是緩存服務器上沒有請求的內容，那麼返回 504 Gateway Timeout。

• must-revalidata：表示緩存服務器在返回資源是，必須向資源服務器確認其緩存的有效性。

• no-transform：不管請求仍是響應，都不能在傳輸的過程當中改變報文體的媒體類型。

　　

 

二、Connection

該字段能夠控制不轉發給代理服務器的首部字段以及管理持久鏈接，下方這個響應報文頭中的Connection就是用來管理持久鏈接的，其參數爲keep-alive，就是保持持久鏈接的意思。可使用close參數將其關閉。

　　

 

三、Transfer-Encoding

該字段表示報文在傳輸過程當中採用的編碼方式，在HTTP/1.1的報文傳輸過程當中僅對分塊編碼有效。下方這個截圖就是Transfer-Encoding在Response Header中的使用，後邊根的chunked(分塊)的參數，說明報文是分塊進行傳輸的。

　　

 

四、Via

該字段是爲了追蹤請求和響應報文測傳輸路徑，報文通過代理或者網關是會在Via字段添加該服務器的信息，而後再進行轉發。

　　

　　

 

二.請求頭部字段 （Request Header Fields）

顧名思義，請求頭部字段固然是在請求頭中才使用的字段。該字段用於補充請求的附加信息，客戶端信息等。接下來將給出經常使用並且比較重要的幾個請求頭部字段。

1  Accept

該字段可通知服務器用戶代理可以處理的媒體類型以及該媒體類型對應的優先級。媒體類型可以使用「type/subtype」這種形式來指定，分號後邊緊跟着的是該類型的優先級。以下所示。

　　

 

2  Accept-Encoding

該字段用來告知服務器，客戶端這邊可支持的內容編碼以及相應內容編碼的優先級, 下方就是Accept-Encoding的用法。gzip表示由文件壓縮程序gzip(GNU zip)生成的編碼格式。compress表示UNIX文件壓縮程序compress生成的編碼格式。deflate表示組合使用zlib格式以及有deflate壓縮算法生成的編碼格式。identity表示不執行壓縮或者使用一致的默認編碼格式。

　　

 

3 Accept-Language

該字段用來告知服務器，客戶端可處理的天然語言集，以及對應語言集的優先級。如下方的截圖爲例，Accept-Language後方跟了三個屬性，分別是「zh-CN」, "zh;q=0.8"，「en;q=0.6」。也就是說客戶端可處理三種天然預言集，zh-CN，其優先級是1（最高）。第二種是zh ，其優先級是0.8，次之。第三個是en，優先級爲0.6，優先級在三者之間最低。

　　

 

4 Authorization

用來告知服務器用戶端的認證信息，下方就是鏈接公司內部SVN系統時須要認證時的請求頭部信息。

　　

若是你沒有填寫認證信息的話，那麼就會返回401 Unauthorized。以下所示：

　　

 

5 If-Match 與If-None-Match

上面這兩個請求頭部字段都是帶有邏輯判斷的，從上面的英文咱們不難看出二者剛好相反。二者後方都跟着串字符串，如If-Match "xcsldjh49773hce", 後邊這個字符的匹配對象是ETag(稍後會介紹)。If-Match的請求是若是後方的字符串與ETag相等則服務器端進行請求，不然不進行處理。If-None-Match是If-Match的非操做，一樣是匹配ETag, 若是Etag沒有匹配成功就處理請求，不然不處理。

 

6 If-Modified-Since與If-Unmodified-Since

If-Modified-Since也是帶有邏輯判斷的請求頭部字段，該字段後方跟的是一個日期，意思是在該日期後發生了資源更新，那麼服務器就會處理該請求。If-Unmodified-Since就是 If-Modified-Since的非操做。

　　

 

7 If-Range

if-Range字段後方也是跟的Etag, 該字段要結合着Range字段進行使用。其所表明的意思就是若是Etag匹配成功，請求的內容就按照Range字段所規定的範圍進行返回，不然返回所有的內容。用法以下所示：

If-Range: "etag_code" 

Range: bytes=1000-5000

 

8  Referer 

 其實Referer是一個錯誤的拼寫，可是一直在使用。正確的英文單詞應該是Referrer(此處可翻譯爲:來歷、來路)。Referer字段後方跟的是一個URI, 該URI就是發起請求的URI，具體以下所示：

　　

 

9  User-Agent

該字段會將請求方的瀏覽器和用戶代理名稱等信息傳達給服務器。下方就是從我當前筆記本的Chrome瀏覽器請求網絡時的User-Agent信息。

　　

 

 

三.響應頭部字段 （Request Header Fields）

聊完請求報文頭部字段後，咱們接下來來聊一下響應報文頭部字段。響應頭是由Server向Client返回響應報文中使用的頭部信息。用戶補充響應的附加信息、服務信息等。下方是幾個常見響應頭部字段。

 

1  Accept-Ranges

該字段用來告知客戶端服務器那邊是否支持範圍請求（請求部份內容，請求頭中使用Range字段）。Accept-Ranges的值爲bytes時，就說明服務器支持範圍請求，爲none時，說明服務器不支持客戶端的範圍請求。下方是博客園的頁面的加載，從下方能夠看出是支持範圍請求的，以下所示：

　　

 

2 Age

該字段告知客戶端，源服務器在多久前建立了該響應。

　　

 

3 Etag

Etag是服務器當前請求的服務器資源（圖片，HTML頁面等）所對應的一個獨有的字符串。不一樣資源間的Etag是不一樣的，當資源更新時Etag也會進行更新。

因此結合着請求頭中的If-Match等邏輯請求頭，能夠判斷當前Client端已經加載的資源在服務器端是否已經更新了。當初次請求一個資源，如圖片時，咱們能夠將其Etag進行保存，在此請求時，可放在If-None-Match後方，進行資源更新。若是服務器資源並未修改，就不對該請求作出響應。下方就是網頁中某張圖片對應着的Etag，以下所示。

　　

 

4 Location

Location字段通常與重定向結合着使用。下方是我訪問「www.baidu.com/hello」這個鏈接的響應報文。由於服務器上並無/hello這個資源路徑，因此給我重定向了error.html頁面，這個重定向的URL就存儲在Location字段中，以下所示：

　　

 

5 Server

該響應字段代表了服務器端使用的服務器型號，下方是博客園某張圖片的響應頭，使用的Web服務器是Tengine, Tengin是淘寶發起的Web服務器項目，是基於Nginx的，關於Tengin的相關內容，請自行Google吧。

　　

 

6 Vary 

Vary可對緩存進行控制，經過該字段，源服務器會向代理服務器傳達關於本地緩存使用方法的命令。下方就是Vary的使用，Vary後方的參數是Accept-Encoding。其意思是返回的緩存要以Accept-Encoding爲準。當請求的Accept-Encoding的參數與緩存內容的Accept-Encoding參數一致時就返回緩存內容，不然就請求源服務器。

　　

 

7 WWW-Authenticate

該字段用於HTTP的訪問認證，在狀態碼401 Unauthorized中確定帶有此字段，該字段用來指定客戶端的認證方案（Basic或者Digest）。參數realm的字符串是爲了辨別請求URL指定資源所受到的保護策略。以下所示：

　　

 

 

4、實體頭部字段（Content Header Fields）

 接下來咱們就來聊聊常見的實體頭部字段，實體頭部字段是報文實體所使用的頭部，用來補充與報文實體相關的信息。

1  Allow

該字段用於服務器通知客戶端服務器這邊所支持的全部請求方法（GET、POST等）。若是服務器找不到客戶端請求中所提到的方法的話，就會返回405 Method Not Allowed，於此同時還會把全部能支持的HTTP方法寫入到首部字段Allow後返回。

Allow : GET, POST, HEAD, PUT, DELETE 

 

2 Content-Encoding

該字段用來講明報文實體的編碼方式，下方這段報文頭中的Content-Encoding的參數爲gzip，說明是使用gzip對報文實體進行壓縮的。

　　

 

3 Content-Language

該字段表示報文實體使用的天然語言，使用方式以下所示：

Content-Language: zh-CN

 

4 Content-Length

顧名思義，該字段用來指定報文實體的字節長度，以下所示：

　　

 

5 Content-MD5

該字段中存儲的是報文實體進行MD5加密而後再使用Base64進行編碼的字符串。客戶端收到響應報文後，能夠對報文實體進行MD5加密，而後再對其進行Base64編碼，而後與Content-MD5中的字符串進行比較來肯定報文是否進行修改，能夠說這是一個簡單的驗籤功能。可是此方法並不能肯定報文是否被修改了，由於Content-MD5這個值也有可能被篡改。

 

5、Cookie相關的頭部字段

由於HTTP協議自己是無狀態的，在Web站點中使用Cookie來管理服務器與客戶端之間的狀態。解析來我就來介紹一下Cookie相關的頭部字段。

 

一、Set-Cookie

響應報文中會使用到該字段。當服務器準備開始管理客戶端的狀態時，會事先告知其各類信息。下方字段是登陸知乎時所返回的所要設置的Cookie信息。接下來咱們就要對這串Cookie信息進行解析。

• 鍵值對：在 Set-Cookie字段中，「 z_co=Mi4……」這就是要存入Cookie中的信息，固然能夠是多個鍵值對，中間使用逗號進行分割便可。

• Domain：而後是Domain屬性，由下方不難看出， Domain中存儲的就是Cookie適用對象的域名，若不指定Domain的值，那麼默認就是建立Cookie的服務器的域名。

• expire：該字段屬性的值是一個時間，也就是 Cookie的有效期，若不指定該屬性的值，默認就是當前會話有效，關閉瀏覽器Cookie即失效。

• httponly：設置該屬性的目的是讓 JavaScript腳本沒法獲取Cookie，其主要目的是防止跨站腳本攻擊對Cookie信息的竊取。

• path： 用於限制指定 Cookie的發送範圍的文件目錄。

• Secure：僅在 HTTPS安全通訊時纔會發送Cookie。

　　

 

2.Cookie

請求報文頭中會使用該字段，用於將本地存儲的Cookie信息發送給服務端。下方就是知乎上每次請求文章所帶有的Cookie信息，固然下方只是部分信息，可是咱們仍是從中能夠找到以前咱們存儲的「z_co=Mi4……」這個鍵值對的。

　　

 

其餘比較常見並且比較簡單的頭部字段就不作過多贅述了，今天博客就先到這兒吧。