HTTP學習筆記-HTTP協議(一)

HTTP報文結構

HTTP報文是HTTP協議交互的信息，報文自己是由多行（用CR+LF做換行符）數據構成的字符串文本。

報文首部通常包含請求行（請求報文）、狀態行（響應報文）、首部字段、其餘字段等，其中首部字段又分爲請求首部字段、響應首部字段、通用首部字段、實體首部字段，除此以外報文首部可能還會包含X-Frame-Options、X-XSS-Protection等一些其餘字段。

報文首部和報文實體之間用空行（CR+LF）來劃分。一個報文一般不必定要有報文實體。

下面咱們來看一看請求報文和響應報文的實例。

請求報文

請求報文由請求方法、URI、協議版本、可選的請求首部字段以及實體內容構成，請求方法、URI、協議版本共同組成了請求行，而實體內容並非每個請求報文都有。

響應報文

響應報文由協議版本、狀態碼、解釋狀態碼的緣由短語、可選的響應首部字段以及實體內容構成，協議版本、狀態碼、解釋狀態碼的緣由短語共同組成了狀態行。

關於狀態碼的詳細說明能夠戳個人另外一篇學習筆記，返回結果的HTTP狀態碼。

無狀態（stateless）協議

HTTP協議是一種不保存狀態的協議，即無狀態（stateless）協議。新的請求發送就會有新的響應產生，協議自己不保留以前的請求或響應報文信息。可是隨着業務的發展，不少場景需求中都須要掌握以前報文中的信息，例如電商購物網站，登陸以後跳轉到該站其餘頁面，也須要保持登陸。HTTP/1.1自己是無狀態協議，因而爲了知足業務需求，網景通訊公司開發來了Cookie並制定了標準，這套標準進行擴展以後的產物就是咱們如今經常使用的管理服務器和客戶端以前狀態的Cookie。

使用Cookie狀態管理

Cookie會根據從服務器端發送的響應報文內的Set-Cookie首部字段通知客戶端保存Cookie。下次客戶端再往該服務器發送請求的時候，客戶端會自動在請求報文中加入Cookie值後發送出去。如圖：

對應的HTTP請求報文和響應報文內容以下：

• 第 1 步：請求報文

GET /a/1190000005370221 HTTP/1.1
Host: example.com

此時，首部字段內沒有Cookie的相關信息。

• 第 2 步：在響應中添加Cookie返回

HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 08:23:37 GMT
Server: Apache
<Set-Cookie: sid=1342077140220000; path=/; expires=Wed,10-Oct-12 07:12:20 GMT>
Content-Type: text/plain; charset=UTF-8

響應報文中有着服務端生成的Cookie信息。

• 第 3 步：請求報文中添加Cookie後再發送

GET /b/1190000005370221 HTTP/1.1
Host: example.com
Cookie: sid=1342077140220000

請求中自動發送保存着的Cookie信息。

爲Cookie服務的首部字段

首部字段名	說明	首部類型
Set-Cookie	開始狀態管理所使用的Cookie信息	響應首部字段
Cookie	服務器收到的Cookie信息	請求首部字段

Set-Cookie

<Set-Cookie: sid=1342077140220000; path=/; expires=Wed,10-Oct-12 07:12:20 GMT; domain=.example.com>

Set-Cookie字段屬性：

屬性	說明
NAME=VALUE	賦予Cookie的名稱和其值（必須）
expires=DATE	Cookie的有效期（默認爲瀏覽器關閉前爲止）
path=PATH	將服務器上的文件目錄做爲Cookie的適用對象（默認爲文檔所在的文件目錄）
domain=域名	做爲Cookie適用對象的域名（默認爲建立Cookie服務器的域名）
Secure	僅在HTTPS安全通訊時纔會發送Cookie
HttpOnly	加以限制，使Cookie不能被JavaScript腳本訪問

Cookie

Cookie: sid=1342077140220000

首部字段Cookie會告知服務器，當客戶端想得到HTTP狀態管理支持時，就會在請求中包含從服務器接收到的Cookie。接收到多個Cookie時，一樣能夠以多個Cookie形式發送。

持久鏈接

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接，如圖：

當瀏覽多圖的網站時，請求各類圖片以及其餘資源，將會重複上面這個過程，這會形成無謂的開銷。

爲解決TCP鏈接的問題，持久鏈接的方案應運而生了，持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，就保持TCP的鏈接狀態。

而後客戶端和服務器端在創建一次TCP鏈接後的屢次請求和響應就變成以下圖所示意的那樣：

持久鏈接減小了TCP重複創建和斷開所形成的額外開銷，減小的重複創建和斷開的這部分時間，使HTTP請求和響應能更早的結束，這樣頁面的顯示速度也就快了。

在HTTP/1.1中，全部鏈接都是持久鏈接。客戶端會在持久鏈接上連續發送請求。當客戶端想斷開鏈接時，則指定Connection爲Close。

參考

《圖解HTTP》《HTTP權威指南》