《圖解HTTP》——簡單的HTTP協議

本章是針對HTTP的結構進行講解

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

請求訪問文本或圖像等資源的一端爲客戶端，而提供資源相應的一端成爲服務器端。
HTTP協議可以明確區分哪端是客戶端，哪端是服務器端。

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

HTTP協議規定，請求從客戶端發出，最後服務器響應應該請求並返回。（先從客戶端開始創建通訊， 服務器端在沒有接收到請求以前不會發送響應）
具體實例：

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

接收到請求的服務器，會將請求內容的處理結果以響應的形式返回。

響應報文基本上由 協議版本、狀態碼、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。

2.3 HTTP是不保存狀態的協議

HTTP是一種不保存狀態，即無狀態協議。HTTP協議自身不對請求和響應之間的通訊狀態進行保存。

使用HTTP協議，每當有新的請求發送時，就會有對應的新響應產生。協議自己並不保存以前一切的請求和響應報文的信息。這是 爲了更快地處理大量的事務，確保協議的可伸縮性，特地把HTTP協議設計成如此簡單的。
隨着Web的不斷髮展，無狀態而致使業務處理變得棘手的狀況增多了。好比登陸狀態的保存。
爲了實現 保持狀態功能，引入了 Cookie技術，可對狀態進行管理。

2.4 請求URI定位資源

由於URI的特定的功能，在互聯網上任意位置的資源都能訪問到。

當客戶端請求訪問資源而發送請求時，URI須要將做爲請求報文中的請求URI包含在內。指定請求URI的方法有不少。

若是不是訪問特定資源而是對 服務器自己發起請求，能夠用一個 * 來代替請求URI。 給個栗子：

上圖用以查詢HTTP服務器端支持的HTTP方法種類.

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

• GET：獲取資源
  

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

給個栗子：

• POST：傳輸實體主體
  

POST方法用來傳輸實體的主體。雖然用GET方法也能夠傳輸實體的主體，但通常不用GET，而用POST。POST功能與GET很類似，但其主要目的並非獲取響應的主體內容。

給個栗子：

• PUT：傳輸文件
  

POST方法用來傳輸文件。就像FTP協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求URI指定的位置。HTTP/1.1的PUT方法自身不帶驗證機制，任何人均可以上傳文件，存在安全性問題，通常的Web網站不使用該方法不使用，除非配合Web應用程序的驗證機制，或架構設計採用REST標準的同類Web網站。

給個栗子：

• HEAD：獲取報文首部
  

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

給個栗子：

• DELETE：刪除文件
  

DELETE方法用來刪除文件，是與PUT相反的方法。此方法按請求URI刪除指定的資源。和PUT同樣自己不帶驗證機制，通常Web網站不使用。

給個栗子：

• OPTIONS：詢問支持的方法
  

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

給個栗子：

• TRACE：追蹤路徑
  

TRACE方法是讓Web服務器端將以前的請求通訊環回給客戶端的方法。
發送請求時，在Max-Forwards首部字段中填入數值，每通過一個服務器端數字減一，當減到0時，中止傳輸。最後服務器端返回200。客戶端經過TRACE方法能夠查詢發送出去的請求時怎樣被加工修改的。請求想要鏈接到源目標服務器可能經過代理中轉，此方法用來確認鏈接過程發生的一系列操做。
TRACE方法不經常使用，並且容易引起XST（跨站追蹤）攻擊。

給個栗子：

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

CONNECT方法要求在代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。主要使用SSL（安全套接層）和TLS（傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。

給個栗子：

2.6 使用方法下達命令

向請求URI指定的資源發送請求報文時，採用稱爲方法的命令。
方法的做用：能夠指定請求的資源定期望產生某種行爲。方法名區分大小寫，要用大寫字母！

2.7 持久鏈接節省通訊量

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

2.7.1 持久鏈接

持久鏈接特色：只要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態。

持久鏈接好處在於 減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。減小開銷的那部分時間，使HTTP請求和相應更早結束，Web頁面顯示速度相應提升。

2.7.2 管線化

持久鏈接使得多數請求以管線化方式發送成爲可能。管線化技術不用等待響應就可直接發送下一個請求。這樣可以作到同時並行發送多個請求，不須要一個接一個等待相應。

2.8 使用Cookie的狀態管理(※)

HTTP沒法根據以前的狀態進行本次的請求處理。最多見的是沒法進行登錄狀態的保存。
無狀態協議也有優勢——因爲沒必要保存狀態，可減小服務器的CUP及內存資源的消耗。

Cookie技術經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
Cookie根據從服務器發送的相應報文內的 Set-Cookie的首部字段信息，通知客戶端 保存Cookie。下次客戶端再往服務器發送請求時，客戶端會自動 在請求報文中加入Cookie後發送出去。
服務器端發現客戶端傳來的Cookie後，會 檢查到底是從哪個客戶端發送來的鏈接請求，對比服務器上的記錄，獲得以前的狀態信息。

！improtant

• 服務器端在沒有接收到請求以前不會發送響應。
• 請求報文是由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。
• 響應報文基本上由協議版本、狀態碼、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。
• HTTP是一種不保存狀態，即無狀態協議，這是爲了更快地處理大量的事務，確保協議的可伸縮性。
• HTTP方法
  • GET：獲取資源
  • POST：傳輸實體主體
  • PUT：傳輸文件
  • HEAD：得到報文首部
  • DELETE：刪除文件
  • OPTIONS：詢問支持的方法
  • TRACE：追蹤路徑
  • CONNECT：要求用隧道協議鏈接代理
• 持久鏈接減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。
• 管線化技術不用等待響應就可直接發送下一個請求。
• Cookie技術經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。