圖解HTTP二：簡單的 HTTP 協議

2.1 HTTP 協議用於客戶端和服務器端之間的通信

HTTP 協議和 TCP/IP 協議族內的其他衆多的協議相同，用於客戶端和服務器之間的通信，而用 HTTP 協議能夠明確區分哪端是客戶端，哪端是服務器端。

2.2 通過請求和響應的交換達成通信

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

請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。

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

2.3 HTTP 是不保存狀態的協議

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

使用 HTTP 協議，每當有新的請求發送時，就會有對應的新響應產生。協議本身並不保留之前一切的請求或響應報文的信息。這是爲了更快地處理大量事務，確保協議的可伸縮性。

2.4　請求 URI 定位資源

HTTP 協議使用 URI 定位互聯網上的資源。正是因爲 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。當客戶端請求訪問資源而發送請求時， URI 需要將作爲請求報文中的請求 URI 包含在內。指定請求 URI 的方式有很多。

2.5　告知服務器意圖的 HTTP 方法

• GET ：GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。
• POST ：POST方法用來傳輸實體的主體。
• PUT：PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然後保存到請求 URI 指定的位置。
• HEAD：HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用於確認 URI 的有效性及資源更新的日期時間等。
• DELETE：DELETE 方法用來刪除文件，是與 PUT 相反的方法。 DELETE 方法按請求 URI 刪除指定的資源。
• OPTIONS：OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。
• CONNECT：CONNECT 方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行 TCP 通信。主要使用SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密後經網絡隧道傳輸。
• TRACE：TRACE 方法是讓 Web 服務器端將之前的請求通信環回給客戶端的方法。

2.6 持久連接節省通信量

2.6.1　持久連接

持久連接（HTTP Persistent Connections，也稱爲 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態。

持久連接旨在建立 1 次 TCP 連接後進行多次請求和響應的交互

持久連接的好處在於減少了 TCP 連接的重複建立和斷開所造成的額外開銷，減輕了服務器端的負載。另外，減少開銷的那部分時間，使 HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了。

2.7.2　管線化

持久連接使得多數請求以管線化（pipelining）方式發送成爲可能。從前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。這樣就能夠做到同時並行發送多個請求，而不需要一個接一個地等待響應了。

不等待響應，直接發送下一個請求

比如，當請求一個包含 10 張圖片的 HTML Web 頁面，與挨個連接相比，用持久連接可以讓請求更快結束。而管線化技術則比持久連接還要快。請求數越多，時間差就越明顯。

2.8　使用 Cookie 的狀態管理

HTTP 是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。也就是說，無法根據之前的狀態進行本次的請求處理。

假設要求登錄認證的 Web 頁面本身無法進行狀態的管理（不記錄已登錄的狀態），那麼每次跳轉新頁面不是要再次登錄，就是要在每次請求報文中附加參數來管理登錄狀態。保留無狀態協議這個特徵的同時又要解決類似的矛盾問題，於是引入了 Cookie 技術。
Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。服務器端發現客戶端發送過來的 Cookie 後，會去檢查究竟是從哪一個客戶端發來的連接請求，然後對比服務器上的記錄，最後得到之前的狀態信息。

沒有 Cookie 信息狀態下的請求

第 2 次以後（存有 Cookie 信息狀態）的請求

上圖展示了發生 Cookie 交互的情景， HTTP 請求報文和響應報文的內容如下。

1. 請求報文（沒有 Cookie 信息的狀態）

GET /reader/ HTTP/1.1
Host: hackr.jp
*首部字段內沒有Cookie的相關信息

2. 響應報文（服務器端生成 Cookie 信息）

HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed,
10-Oct-12 07:12:20 GMT＞
Content-Type: text/plain; charset=UTF-8

3. 請求報文（自動發送保存着的 Cookie 信息）

GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724