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

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

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

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

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

通信請求和響應實例：

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

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

2.響應報文中的內容：

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

三.HTTP 是不保存狀態的協議:

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

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

四.請求 URI 定位資源：

HTTP 協議使用 URI 定位互聯網上的資源。正是因為 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。

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

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

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

1.GET ：獲取資源

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

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

2.POST：傳輸實體主體

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

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

3.PUT：傳輸文件

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

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

// 響應1的意思其實是請求執行成功了，但無數據返回

4.HEAD：獲得報文首部

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

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

5.DELETE：刪除文件

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

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

6.OPTIONS：詢問支持的方法

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

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

7.TRACE：追蹤路徑

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

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

8.CONNECT：要求用隧道協議連接代理

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

CONNECT 方法的格式如下所示

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

總結：

五.持久連接節省通信量

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

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

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

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

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