前言：

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

1. HTTP協(xié)議概念

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

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

4. HTTP通過持久連接來節(jié)省通信量

5. HTTP管線化（支持并發(fā)發(fā)送請求）

1、HTTP協(xié)議概念

HTTP協(xié)議：

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

客戶端&服務器端：

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

圖示如下：

HTTP 是不保存狀態(tài)的協(xié)議：

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

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

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

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

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

GET：獲取資源

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

POST：傳輸實體主體

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

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

PUT：傳輸文件。

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

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

HEAD：獲得報文首部

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

DELETE：刪除文件

DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。

但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機制，所以一般的 Web 網(wǎng)站也不使用 DELETE 方法。當配合 Web 應用程序的驗證機制，或遵守 REST 標準時還是有可能會開放使用的。

OPTIONS：詢問支持的方法

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

TRACE：追蹤路徑

TRACE 方法是讓 Web 服務器端將之前的請求通信環(huán)回給客戶端的方法。

發(fā)送請求時，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個服務器端就將該數(shù)字減 1，當數(shù)值剛好減到 0 時，就停止繼續(xù)傳輸，最后接收到請求的服務器端則返回狀態(tài)碼 200 OK 的響應。

客戶端通過 TRACE 方法可以查詢發(fā)送出去的請求是怎樣被加工修改/ 篡改的。這是因為，請求想要連接到源目標服務器可能會通過代理中轉(zhuǎn)，TRACE 方法就是用來確認連接過程中發(fā)生的一系列操作。

但是，TRACE 方法本來就不怎么常用，再加上它容易引發(fā)XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會用到了。

CONNECT：要求用隧道協(xié)議連接代理

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

總結(jié)（HTTP方法）：

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

4、管線化（支持并發(fā)發(fā)送請求）

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

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

5、使用Cookie的狀態(tài)管理

HTTP是無狀態(tài)協(xié)議，它不對之前發(fā)生過的請求和響應的狀態(tài)進行管理。也就是說，無法根據(jù)之前的狀態(tài)進行本次的請求處理。

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

無狀態(tài)協(xié)議由于不必保存狀態(tài)，自然可減少服務器的CPU及內(nèi)存資源的消耗。

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

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

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

上圖展示了發(fā)送Cookie交互的情景，HTTP請求報文和響應報文的內(nèi)容如下。

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

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