寫在前面：本文僅供個人學習使用，如有侵權，請聯系刪除。文章中所用圖片絕大多數來源于《圖解HTTP》，請讀者支持原版。

文章目錄

• 第 2章 簡單的HTTP協議
• • 2.1 HTTP協議用于客戶端和服務器端之間的通信
  • 2.2 通過請求和響應的交換達成通信
  • 2.3 HTTP是不保存狀態的協議
  • 2.4 請求URI定位資源
  • 2.5 告知服務器意圖的HTTP方法
  • 2.6 使用方法下達命令
  • 2.7 持久連接節省通信量
  • • 2.7.1 持久連接
    • 2.7.2 管線化
  • 2.8 使用Cookie的狀態管理

本章將針對HTTP協議結構進行講解，主要使用HTTP/1.1版本。學完這章，想必大家就能理解HTTP協議的基礎了。

第 2章 簡單的HTTP協議

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

HTTP協議和TCP/IP協議族內的其他眾多協議相同，用于客戶端和服務器之間的通信。
請求訪問文本或圖像等資源的一端稱為客戶端，而提供資源響應的一端稱為服務器端。

在兩臺計算機之間使用HTTP協議通信時，在一條通信線路上必定有一端是客戶端，另一端則是服務器端。

有時候，按實際情況，兩臺計算機作為客戶端和服務器端的角色有可能會互換。但就僅從一條通信路線來說，服務器端和客戶端的角色是確定的，而用HTTP協議能夠明確區分哪端是客戶端，哪端是服務器端。

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

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

下面，我們來看一個具體的例子。

下面則是從客戶端發送給某個HTTP服務器端的請求報文中的內容。

GET /index.htm HTTP/1.1 Host:hachr.jp

起始行開頭的GET表示請求訪問服務器的類型，稱為方法(method)。隨后的字符串index.htm指明了請求訪問的資源對象，也叫做請求URI(request-URI)。最后的HTTP/1.1，即HTTP的版本號，用來提示客戶端使用的HTTP協議功能。

綜合來看，這段請求內容的意思是：請求訪問某臺HTTP服務器上的/index.htm頁面資源。

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

請求首部字段及內容實體稍后會作詳細說明。接下來，我們繼續講解。接收到請求的服務器，會將請求內容的處理結果以響應的形式返回。

在起始行開頭的HTTP/1.1 表示服務器對應的HTTP版本。

緊挨著的200 OK 表示請求的處理結果的狀態碼(status code) 和原因短語(reason-phrase) 。下一行顯示了創建響應的日期時間，是首部字段(header field) 內的一個屬性。

接著以一空行分隔，之后的內容稱為資源實體的主體(entity body).

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

2.3 HTTP是不保存狀態的協議

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

使用HTTP協議，每當有新的請求發送時，就會有對應的新響應產生。協議本身并不保留之前一切的請求或響應報文的信息。這是為了更快地處理大量事物，確保協議的可伸縮性，而特意把HTTP協議設計成如此簡單的。

可是，隨著Web的不斷發展，因無狀態而導致業務處理變得棘手的情況增多了。比如，用戶登錄一家購物網站，即使他跳轉到該站的其他頁面后，也需要繼續保持登陸狀態。針對這個實例，網站為了能夠掌握是誰發送的請求，需要保存用戶的狀態。

HTTP/1.1雖然是無狀態協議，但為了實現期望的保持狀態功能，于是引入了Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。有關Cookie的詳細內容稍后講解。

2.4 請求URI定位資源

HTTP協議使用URI定位互聯網上的資源。正是因為URI的特定功能，在互聯網上任意位置的資源都能訪問到。

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

• URI為完整的請求URI，比如GET http://hackr.jp/index.htm HTTP/1.1
• 在首部字段Host中寫明網絡域名或IP地址。比如GET/index.htm HTTP/1.1 Host:hackr.jp

除此之外，如果不是訪問特定資源而是對服務器本身發起請求，可以用一個*來代替請求URI。下面這個例子是查詢HTTP服務器端支持的HTTP方法種類。

OPTIONS * HTTP/1.1

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

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

GET：獲取資源

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

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

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

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

PUT：傳輸文件

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

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

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

這里的響應是指：請求執行成功了，但是無數據返回。

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

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

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

OPTIONS：詢問支持的方法

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

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

TRACE：追蹤路徑

TRACE方法是讓Web服務器端將之前的請求通信返回給客戶端的方法。

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

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

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

使用TRACE請求·響應的例子

CONNECT：要求用隧道協議連接代理

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

CONNECT方法的格式如下所示

CONNECT 代理服務器名:端口號 HTTP版本

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

2.6 使用方法下達命令

向請求URI指定的資源發送請求報文時，采用稱為方法的命令。

方法的作用在于，可以指定請求的資源按期望產生某種行為。方法中有GET、POST和HEAD等

上面我們給出了方法名和用法。方法名區分大小寫，注意要用大寫字母。

2.7 持久連接節省通信量

HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。

以當年的通信情況來看，因為都是些容量很小的文本傳輸，所以即使這樣也沒有多大問題?？呻S著HTTP的普及，文檔中包含大量圖片的情況多了起來。

比如，使用瀏覽器瀏覽一個包含多張圖片的HTML頁面時，在發送請求訪問HTML頁面資源的同時，也會請求該HTML頁面包含的其他資源。因此，每次的請求都會造成無謂的TCP連接建立和斷開，增加通信量的開銷。

2.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內并未標準化。雖然有一部分服務器通過非標準的手段實現了持久連接，但服務器端不一定能夠支持持久連接。毫無疑問，除了服務器端，客戶端也需要支持持久連接。

2.7.2 管線化

持久連接使得多數請求以管線化(pipelining)方式發送成為可能。從前發送請求后需要等待并收到響應，才能發送下一個請求。管線化技術出現后，不用等待響應也可以直接發送下一個請求。

這樣就能夠做到同時并行發送多個請求，而不需要一個接一個地等待響應了。

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

2.8 使用Cookie的狀態管理

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

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

不可否認，無狀態協議當然也有它的優點。由于不必保存狀態，自然可減少服務器的CPU及內存資源的消耗。從另一側面來說，也正是因為HTTP協議本身是非常簡單的，所以才會被應用在各種場景里。

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

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

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

下圖展示了發生Cookie交互的情景。

HTTP請求報文和響應報文的內容如下

總結

以上是生活随笔為你收集整理的《图解HTTP》读书笔记--第2章简单的HTTP协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。