知識架構
第五部分HTTP請求方法根據現在常用方法做了調整，與原書部分有部分區別
客戶端與服務器端之間的通信
HTTP 協議是一種用於客戶端和服務器之間的通信的協議。
發送請求資源的一端稱為客戶端，提供資源響應的一端稱為服務器端。
兩臺計算機之間使用HTTP 協議通信時，在一條通信線路上必定有一端是客戶端，另一端則是服務器端。
實際情況，兩臺計算機作為客戶端和服務器端的角色有可能會互換。但就僅從一條通信路線來說，服務器端和客戶端的角色是確定的， 而用 HTTP 協議能夠明確區分哪端是客戶端， 哪端是服務器端。
由請求與響應進行交換達成通信
HTTP 協議規定， 請求從客戶端發出， 最後服務器端響應該請求並返回。 換句話說， 肯定是先從客戶端開始建立通信的， 服務器端在沒有接收到請求之前不會發送響應。
請求報文
響應報文
無狀態的協議
HTTP 是一種不保存狀態， 即無狀態（stateless） 協議HTTP 協議自身不對請求和響應之間的通信狀態進行保存。 也就是說在 HTTP 這個級別， 協議對於發送過的請求或響應都不做持久化處理。
使用 HTTP 協議， 每當有新的請求發送時， 就會有對應的新響應產生。 協議本身並不保留之前一切的請求或響應報文的信息。
隨著 Web 的不斷髮展， 因無狀態而導致業務處理變得棘手的情況增多了。 比如，用戶登錄到一家購物網站， 即使他跳轉到該站的其他頁面後，也需要能繼續保持登錄狀態。針對這個實例網，站為了能夠掌握是誰送出的請求， 需要保存用戶的狀態。於是引入了 Cookie 技術。 有了 Cookie 再用 HTTP 協議通信， 就可以管理狀態了。
請求URI定位資源
HTTP 協議使用 URI 定位互聯網上的資源。正是因為 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。
當客戶端請求訪問資源而發送請求時，在請求報文中的指定請求 URI。指定請求 URI 的方式有很多。
URI為完整的請求URI
GET HTTP/1.1
在首部字段Host中寫明網絡域名或IP地址
GET /index.htm HTTP/1.1
Host:www.tizhenkeji.com
除此之外， 如果不是訪問特定資源而是對服務器本身發起請求，可以用一個 * 來代替請求URI。下面這個例子是查詢 HTTP 服務器端支持的 HTTP 方法種類。
OPTIONS * HTTP/1.1
HTTP請求方法
要了解HTTP請求方法，我們可藉助抓包工具Httpwatch，來加深瞭解。Httpwatch是一個專門用來抓取web報文的瀏覽器抓包插件。
HTTP 請求可以使用多種請求方法。常用的主要為GET、POST，一般使用的還包括：HEAD、OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
GET：獲取資源
請求指定的頁面信息，並返回實體主體。我們平常通過瀏覽器登陸網站時，大部分的請求都是使用GET方法，比如我們在瀏覽器輸入欄輸入訪問百度首頁。整個訪問過程通過HTTPWATCH抓包發現，整個過程包括12個請求，都採用GET方法。
也就是說，GET方法更多的是在客戶端申請提出訪問服務器資源的請求，所以我們在通過瀏覽器瀏覽網站時候，大部分的行為都是希望訪問服務器的某些資源，這也就是為什麼幾乎所有請求都是GET方法。如下圖，客戶端表示我想訪問服務器的某個資源，通過GET方法來請求。
POST：傳輸實體主體
POST 的主要目的並不是獲取響應的主體內容，而是向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。如下圖所示，客戶端表示，我要給服務器提交表單，或者上傳文件的請求，此時常採用POST方法。
採用POST請求時，數據被包含在請求體中。如我們訪問百度首頁後，我們需要登陸自己註冊的百度賬號，在輸入用戶名、密碼後，點擊登陸按鈕就是一個POST請求，輸入驗證碼，提交驗證碼也是一個POST請求，下圖就是在登陸過程中，一個提交登陸，一個提交驗證碼的兩個POST請求。
POST請求會導致新的資源的建立和/或已有資源的修改，如我們登陸成功百度後，頁面會重新建立許多GET請求，瀏覽器頁面會顯示許多新的資源。
登陸前是下圖頁面。
在最後提交驗證碼，登陸成功後是下圖頁面。
資源重新建立後，頁面顯示如下。
PUT：傳輸文件
PUT方法用來傳輸文件。 就像 FTP 協議的文件上傳一樣， 要求在請求報文的主體中包含文件內容，然後保存到請求 URI 指定的位置。但是，鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人都可以上傳文件，存在安全性問題，因此一般的 Web 網站不使用該方法
HEAD 獲得報文首部
類似於 GET 請求，只不過返回的響應中沒有具體的內容，用於獲取報頭。用於確認URI 的有效性及資源更新的日期時間等。
DELETE
DELETE 方法用來刪除文件，請求服務器刪除指定的頁面， 是與 PUT 相反的方法。 DELETE 方法按請求 URI 刪除指定的資源。但是， HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機制， 所以一般的 Web 網站也不使用 DELETE 方法
TRACE
追蹤路徑 ，回顯服務器收到的請求，主要用於測試或診斷。
CONNECT
要求用隧道協議連接代理，HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器。
PATCH
是對 PUT 方法的補充，用來對已知資源進行局部更新 。
OPTIONS
詢問支持的方法，允許客戶端查看服務器的性能。
為節省通信量而推出的持久鏈接
HTTP 協議的初始版本中， 每進行一次 HTTP 通信就要斷開一次 TCP連接。
以當年的通信情況來說， 因為都是些容量很小的文本傳輸， 所以即使這樣也沒有多大問題。 可隨著 HTTP 的普及， 文檔中包含大量圖片的情況多了起來。 比如，使用瀏覽器瀏覽一個包含多張圖片的 HTML頁面時， 在發送請求訪問 HTML頁面資源的同時， 也會請求該 HTML頁面裡包含的其他資源。 因此， 每次的請求都會造成無謂的 TCP 連接建立和斷開， 增加通信量的開銷。
為解決上述TCP 連接的問題， HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接（HTTP Persistent Connections， 也稱為 HTTP keep-alive 或HTTP connection reuse） 的方法。 持久連接的特點是， 只要任意一端沒有明確提出斷開連接， 則保持 TCP 連接狀態。
持久連接旨在建立 1 次 TCP 連接後進行多次請求和響應的交互持久連接的好處在於減少了 TCP 連接的重複建立和斷開所造成的額外開銷，減輕了服務器端的負載。 另外， 減少開銷的那部分時間，使HTTP請求和響應能夠更早地結束， 這樣 Web 頁面的顯示速度也就相應提高了。
在HTTP/1.1 中，所有的連接默認都是持久連接， 但在 HTTP/1.0 內並未標準化。 雖然有一部分服務器通過非標準的手段實現了持久連接，但服務器端不一定能夠支持持久連接。 毫無疑問， 除了服務器端， 客戶端也需要支持持久連接。持久連接使得多數請求以管線化（pipelining） 方式發送成為可能。 從前發送請求後需等待並收到響應， 才能發送下一個請求。 管線化技術出現後， 不用等待響應亦可直接發送下一個請求。這樣就能夠做到同時並行發送多個請求， 而不需要一個接一個地等待響應了。
比如，當請求一個包含 10 張圖片的 HTML Web 頁面， 與挨個連接相比，用持久連接可以讓請求更快結束。 而管線化技術則比持久連接還要快。請求數越多，時間差就越明顯。
使用cookie狀態管理
HTTP 是無狀態協議， 它不對之前發生過的請求和響應的狀態進行管理。 也就是說， 無法根據之前的狀態進行本次的請求處理。假設要求登錄認證的 Web 頁面本身無法進行狀態的管理（不記錄已登錄的狀態） ， 那麼每次跳轉新頁面不是要再次登錄， 就是要在每次請求報文中附加參數來管理登錄狀態。
不可否認， 無狀態協議當然也有它的優點。 由於不必保存狀態， 自然可減少服務器的 CPU 及內存資源的消耗。 從另一側面來說， 也正是因為 HTTP 協議本身是非常簡單的， 所以才會被應用在各種場景裡。
圖： 如果讓服務器管理全部客戶端狀態則會成為負擔
保留無狀態協議這個特徵的同時又要解決類似的矛盾問題， 於是引入了 Cookie 技術。 Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息， 通知客戶端保存 Cookie。 當下次客戶端再往該服務器發送請求時， 客戶端會自動在請求報文中加入 Cookie 值後發送出去。
服務器端發現客戶端發送過來的 Cookie 後， 會去檢查究竟是從哪一個客戶端發來的連接請求， 然後對比服務器上的記錄， 最後得到之前的狀態信息。
沒有 Cookie 信息狀態下的請求
第 2 次以後（存有 Cookie 信息狀態） 的請求
上圖展示了發生 Cookie 交互的情景， HTTP 請求報文和響應報文的內容如下。1. 請求報文（沒有 Cookie 信息的狀態）2. 響應報文（服務器端生成 Cookie 信息）3. 請求報文（自動發送保存著的 Cookie 信息）
閱讀更多 正書屋 的文章
