接圖解HTTP之——簡單的HTTP協議（一）

1.5告知伺服器意圖的 HTTP 方法

下面，我們介紹 HTTP/1.1 中可使用的方法。 GET ：獲取資源 GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經伺服器 端解析後返回響應內容。也就是說，如果請求的資源是文字，那就保 持原樣返回；如果是像 CGI（Common Gateway Interface，通用閘道器接 口）那樣的程式，則返回經過執行後的輸出結果。

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

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

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

1 響應的意思其實是請求執行成功了，但無資料返回。——譯者注

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

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

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

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

CONNECT：要求用隧道協議連線代理 CONNECT 方法要求在與代理伺服器通訊時建立隧道，實現用隧道協 議進行 TCP 通訊。主要使用 SSL（Secure Sockets Layer，安全套接 層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容 加 密後經網路隧道傳輸。 CONNECT 方法的格式如下所示。

1.6 使用方法下達命令 

向請求 URI 指定的資源傳送請求報文時，採用稱為方法的命令。 方法的作用在於，可以指定請求的資源按期望產生某種行為。方法中 有 GET、POST 和 HEAD 等。

下表列出了 HTTP/1.0 和 HTTP/1.1 支援的方法。另外，方法名區分大 小寫，注意要用大寫字母。

在這裡列舉的眾多方法中，LINK 和 UNLINK 已被 HTTP/1.1 廢棄，不 再支援。

1.7 持久連線節省通訊量 

以當年的通訊情況來說，因為都是些容量很小的文字傳輸，所以即使 這樣也沒有多大問題。可隨著 HTTP 的普及，文件中包含大量圖片的 情況多了起來。 比如，使用瀏覽器瀏覽一個包含多張圖片的 HTML頁面時，在傳送 請求訪問 HTML頁面資源的同時，也會請求該 HTML頁面裡包含的 其他資源。因此，每次的請求都會造成無謂的 TCP 連線建立和斷 開，增加通訊量的開銷。

1.7.1持久連線 

為解決上述 TCP 連線的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久連線（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連線的特點是，只要任意一端 沒有明確提出斷開連線，則保持 TCP 連線狀態。

持久連線的好處在於減少了 TCP 連線的重複建立和斷開所造成的額 外開銷，減輕了伺服器端的負載。另外，減少開銷的那部分時間，使 HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相 應提高了。 在 HTTP/1.1 中，所有的連線預設都是持久連線，但在 HTTP/1.0 內並 未標準化。雖然有一部分伺服器通過非標準的手段實現了持久連線， 但伺服器端不一定能夠支援持久連線。毫無疑問，除了伺服器端，客 戶端也需要支援持久連線。

1.7.2 管線化 

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

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

1.8 使用 Cookie 的狀態管理 

HTTP 是無狀態協議，它不對之前發生過的請求和響應的狀態進行管 理。也就是說，無法根據之前的狀態進行本次的請求處理。 假設要求登入認證的 Web 頁面本身無法進行狀態的管理（不記錄已 登入的狀態），那麼每次跳轉新頁面不是要再次登入，就是要在每次 請求報文中附加引數來管理登入狀態。 不可否認，無狀態協議當然也有它的優點。由於不必儲存狀態，自然 可減少伺服器的 CPU 及記憶體資源的消耗。從另一側面來說，也正是 因為 HTTP 協議本身是非常簡單的，所以才會被應用在各種場景裡。

保留無狀態協議這個特徵的同時又要解決類似的矛盾問題，於是引入 了 Cookie 技術。Cookie 技術通過在請求和響應報文中寫入 Cookie 信 息來控制客戶端的狀態。 Cookie 會根據從伺服器端傳送的響應報文內的一個叫做 Set-Cookie 的 首部欄位資訊，通知客戶端儲存 Cookie。當下次客戶端再往該伺服器 傳送請求時，客戶端會自動在請求報文中加入 Cookie 值後傳送出 去。 伺服器端發現客戶端傳送過來的 Cookie 後，會去檢查究竟是從哪一 個客戶端發來的連線請求，然後對比伺服器上的記錄，最後得到之前 的狀態資訊。

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

有關請求報文和響應報文內 Cookie 對應的首部欄位，請參考之後 的章節。