前言：

從本篇開始，正式介紹HTTP的協議，力圖簡潔和有效羅列出HTTP協議的核心知識點。

1. HTTP協議概念

2. HTTP通過請求URI來定位資源

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

4. HTTP通過持久連接來節省通信量

5. HTTP管線化（支持并發發送請求）

1、HTTP協議概念

HTTP協議：

HTTP協議和 TCP/IP 協議族內的其他眾多的協議相同，用于客戶端和服務器之間的通信。

客戶端&服務器端：

• 1、請求訪問文本或圖像等資源的一端稱為客戶端，而提供資源響應的一端稱為服務器端。在兩臺計算機之間使用 HTTP 協議通信時，在一條通信線路上必定有一端是客戶端，另一端則是服務器端。
• 2、有時候，按實際情況，兩臺計算機作為客戶端和服務器端的角色有可能會互換。但就僅從一條通信路線來說，服務器端和客戶端的角色是確定的，而用 HTTP 協議能夠明確區分哪端是客戶端，哪端是服務器端。

圖示如下：

HTTP 是不保存狀態的協議：

HTTP協議是一種不保存狀態，即無狀態（stateless）協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別，協議對于發送過的請求或響應都不做持久化處理。

2、通過請求URI來定位資源

當客戶端請求訪問資源而發送請求時，URI需要將作為請求報文中請求URI包含在內。指定請求URI的方式有很多。

3、告知服務器意圖的HTTP方法

下面，我們概要介紹 HTTP/1.1 中可使用的方法。

GET：獲取資源

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

POST：傳輸實體主體

POST 方法用來傳輸實體的主體。

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

PUT：傳輸文件。

PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然后保存到請求 URI 指定的位置。

但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人都可以上傳文件 , 存在安全性問題，因此一般的 Web 網站不使用該方法。若配合 Web 應用程序的驗證機制，或架構設計采用REST（REpresentational State Transfer，表征狀態轉移）標準的同類Web 網站，就可能會開放使用 PUT 方法。

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，傳輸層安全）協議把通信內容加 密后經網絡隧道傳輸。

總結（HTTP方法）：

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

4、管線化（支持并發發送請求）

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

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

5、使用Cookie的狀態管理

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

假設要求登錄認證的Web頁面本身無法進行狀態的管理（不記錄已登錄的狀態），那么每次跳轉新頁面不是要再次登錄，就是要在每次請求報文中附加參數來管理登錄狀態。

無狀態協議由于不必保存狀態，自然可減少服務器的CPU及內存資源的消耗。

保留無狀態協議這個特征的同事又要解決類似的矛盾問題，于是引入了Cookie技術。Cookie技術通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。

Cookie會根據從服務器端發送的響應報文內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值后發送出去。

服務器端發現客戶端發送過來的Cookie后，會去檢查究竟是從哪一個客戶端發送來的連接請求，然后對比服務器上的記錄，最后得到之前的狀態信息。

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

• 1.請求報文（沒有Cookie信息的狀態）
• 2.響應報文（服務器端生成Cookie信息）
• 3.請求報文（自動發送保存著的Cookie信息）

關注頭條號“編程家園”，后續陸續會有更多技術領域（包括并不限于Android進階、JAVA進階、Kotlin、網絡、Flutter、Python等），以及架構、職業規劃、職業思考等方面資料的免費分享，期待您的關注！