摘要：響應報文基本上由協(xié)議版本狀態(tài)碼表示請求成功或失敗的數(shù)字代碼用以解釋狀態(tài)碼的原因短語可選的響應首部字段以及實體主體構成。

一.HTTP 協(xié)議用于客戶端和服務器端之間的通信

客戶端和服務器的定義：請求訪問文本或圖像等資源的一端稱為客戶端，而提供資源響應的一 端稱為服務器端。在兩臺計算機之間使用 HTTP 協(xié)議通信時，在一條通信線路上必定有 一端是客戶端，另一端則是服務器端。

二.通過請求和響應的交換達成：

HTTP 協(xié)議規(guī)定，請求從客戶端發(fā)出，最后服務器端響應該請求并返回。換句話說，肯定是先從客戶端開始建立通信的，服務器端在沒有接收到請求之前不會發(fā)送響應。

通信請求和響應實例：

1.請求報文中的內(nèi)容(意思是：請求訪問某臺 HTTP 服務器上的 /index.htm 頁面資源)：
GET /index.htm
HTTP/1.1 Host: hackr.jp

.
（起始行開頭的GET表示請求訪問服務器的類型，稱為方法 （method）;字符串 /index.htm 指明了請求訪問的資源對象， 也叫做請求 URI（request-URI）; HTTP/1.1，即 HTTP 的版本號，用來提示客戶端使用的 HTTP 協(xié)議功能。 請求報文是由請求方法、請求 URI、協(xié)議版本、可選的請求首部字段和內(nèi)容實體構成的。）

2.響應報文中的內(nèi)容：

（在起始行開頭的 HTTP/1.1 表示服務器對應的 HTTP 版本。 緊挨著的 200 OK 表示請求的處理結果的狀態(tài)碼（status code）和原因 短語（reason-phrase）。下一行顯示了創(chuàng)建響應的日期時間，是首部 字段（header field）內(nèi)的一個屬性。 接著以一空行分隔，之后的內(nèi)容稱為資源實體的主體（entity body）。響應報文基本上由協(xié)議版本、狀態(tài)碼（表示請求成功或失敗的數(shù)字代碼）、用以解釋狀態(tài)碼的原因短語、可選的響應首部字段以及實體主體構成。）

三.HTTP 是不保存狀態(tài)的協(xié)議:

HTTP 是一種不保存狀態(tài)，即無狀態(tài)（stateless）協(xié)議。HTTP 協(xié)議自 身不對請求和響應之間的通信狀態(tài)進行保存。

作用：為了更快地處理大量事務，確保協(xié)議的可伸縮性，而特意把 HTTP 協(xié)議設計成如此簡單的。
局限：隨著 Web 的不斷發(fā)展，因無狀態(tài)而導致業(yè)務處理變得棘手的情況增多了。比如，用戶登錄到一家購物網(wǎng)站，即使他跳轉(zhuǎn)到該站的其他頁面后，也需要能繼續(xù)保持登錄狀態(tài)。
解決方案：HTTP/1.1 雖然是無狀態(tài)協(xié)議，但為了實現(xiàn)期望的保持狀態(tài)功能，于是引入了 Cookie 技術（后面文章會詳談）。有了 Cookie 再用 HTTP 協(xié)議通信，就可以管理狀態(tài)了。

四.請求 URI 定位資源：

HTTP 協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源。正是因為 URI 的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到。

圖：以 http://hackr .jp/index.htm 作為請求的例子

除此之外，如果不是訪問特定資源而是對服務器本身發(fā)起請求，可以 用一個 * 來代替請求 URI。下面這個例子是查詢 HTTP 服務器端支持 的 HTTP 方法種類。

五.告知服務器意圖的 HTTP 方法

1.GET ：獲取資源

GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經(jīng)服務器端解析后返回響應內(nèi)容。也就是說，如果請求的資源是文本，那就保持原樣返回；如果是像 CGI（Common Gateway Interface，通用網(wǎng)關接口）那樣的程序，則返回經(jīng)過執(zhí)行后的輸出結果。

使用 GET 方法的請求-響應的例子:

2.POST：傳輸實體主體

雖然用 GET 方法也可以傳輸實體的主體，但一般不用 GET 方法進行傳輸，而是用 POST 方法。雖說 POST 的功能與 GET 很相似，但 POST 的主要目的并不是獲取響應的主體內(nèi)容,而是告知其響應結果。

使用 POST 方法的請求·響應的例子

3.PUT：傳輸文件

就像 FTP 協(xié)議的文件上傳一樣，要求在請求報文的主體中包含文件內(nèi)容，然后保存到請求 URI 指定的位置。但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人都可以 上傳文件 , 存在安全性問題，因此一般的 Web 網(wǎng)站不使用該方法。若 配合 Web 應用程序的驗證機制，或架構設計采用 REST（REpresentational State Transfer，表征狀態(tài)轉(zhuǎn)移）標準的同類 Web 網(wǎng)站，就可能會開放使用 PUT 方法。

使用 PUT 方法的請求·響應的例子：

// 響應1的意思其實是請求執(zhí)行成功了，但無數(shù)據(jù)返回

4.HEAD：獲得報文首部

HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用于確認 URI 的有效性及資源更新的日期時間等。

使用 HEAD 方法的請求·響應的例子：

5.DELETE：刪除文件

DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按 請求 URI 刪除指定的資源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機制，所以一般的 Web 網(wǎng)站也不使用 DELETE 方法。當配合 Web 應用 程序的驗證機制，或遵守 REST 標準時還是有可能會開放使用的。

使用 DELETE 方法的請求·響應的例子：

6.OPTIONS：詢問支持的方法

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

使用 OPTIONS 方法的請求·響應的例子：

7.TRACE：追蹤路徑

TRACE 方法是讓 Web 服務器端將之前的請求通信環(huán)回給客戶端的方法。發(fā)送請求時，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個服務器端就將該數(shù)字減 1，當數(shù)值剛好減到 0 時，就停止繼續(xù)傳輸，最后接收到請求的服務器端則返回狀態(tài)碼 200 OK 的響應。 客戶端通過 TRACE 方法可以查詢發(fā)送出去的請求是怎樣被加工修改 / 篡改的。這是因為，請求想要連接到源目標服務器可能會通過代理 中轉(zhuǎn)，TRACE 方法就是用來確認連接過程中發(fā)生的一系列操作。 但是，TRACE 方法本來就不怎么常用，再加上它容易引發(fā) XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會用到了。

使用 TRACE 方法的請求·響應的例子：

8.CONNECT：要求用隧道協(xié)議連接代理

CONNECT 方法要求在與代理服務器通信時建立隧道，實現(xiàn)用隧道協(xié)議進行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡隧道傳輸。

CONNECT 方法的格式如下所示

使用 CONNECT 方法的請求·響應的例子：

總結：

五.持久連接節(jié)省通信量

1.短連接：HTTP 協(xié)議的初始版本中，每進行一次 HTTP 通信就要斷開一次 TCP 連接。

2.持久連接的特點是:只要任意一端 沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。
持久連接的好處:減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載。另外，減少開銷的那部分時間，使 HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了。

3.管線化：持久連接使得多數(shù)請求以管線化（pipelining）方式發(fā)送成為可能。從前發(fā)送請求后需等待并收到響應，才能發(fā)送下一個請求。管線化技術出現(xiàn)后，不用等待響應亦可直接發(fā)送下一個請求。而管線化技術則比持久連接還要快。請求數(shù)越多，時間差就越明顯

六.Cookie 技術
1.引入原由：HTTP協(xié)議保留無狀態(tài)協(xié)議這個特征的同時又要解決類似的矛盾問題，于是引入了 Cookie 技術。
2.工作原理：Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態(tài)。Cookie 會根據(jù)從 端發(fā)送的響應報文內(nèi)的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發(fā)送請求時，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出去。服務器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會去檢查究竟是從哪一個客戶端發(fā)來的連接請求，然后對比服務器上的記錄，最后得到之前的狀態(tài)信息。
3.圖例：
發(fā)生 Cookie 交互的情景：

HTTP請求報文和響應報文的內(nèi)容如下：