2.1 HTTP協議用于客戶端和服務端直接的通信
在一條通信線路上必定一端是客戶端，另一端則是服務端。

2.2 通過請求和響應的交換達成通信。
HTTP協議規定，==請求從客戶端發出，最后服務器響應該請求并返回==。

請求報文的構成和解讀。

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

響應報文的構成和解讀

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

2.3 HTTP是不保存狀態的協議
協議對于發送過的請求或響應都不做持久化處理。目的是==在于更快地處理大量事務，確保協議的可伸縮性，而特意把HTTP協議設計地如此簡單==。

新情況下遭遇到的問題：比如購物網站的業務，用戶登錄到一家購物網站，即使他跳轉到該站的其他頁面后，也需要能繼續保持登錄狀態。所以網站為了能夠掌握是誰發送的請求，需要保存用戶的狀態。

針對上面問題的解決方案：HTTP是無狀態協議，但為了實現期望的保持狀態功能，于是引入了cookie技術。

2.4 HTTP協議使用URI定位互聯網上的資源。
指定請求URI的方式

URI為完整的請求URI

在首部字段Host中寫明網絡域名或IP地址

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

方法名作用說明

GET	獲取資源	側重獲取
POST	傳輸實體主體	側重發送
PUT	傳輸文件	一般不使用，存在安全性問題
HEAD	獲取響應報文首部	用于確認URI的有效性及資源更新的日期等
DELETE	刪除文件	一般不使用
OPTIONS	詢問支持的方法	返回例如GET、POST、HEAD等
TRACE	追蹤路徑	一般不使用，且易引發XST（跨站追蹤）攻擊
CONNECT	要求用隧道協議連接代理	主要使用SSL和TLS協議把通信內容加密后經網絡隧道傳輸。

2.6 使用方法下達命令

2.7 持久連接節省通信量

HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。而使用瀏覽器瀏覽一個包含多張圖片的HTML頁面時，在發送請求訪問HTML頁面時也會請求該HTML頁面里包含的其他資源。因此每次的請求都會造成無謂的TCP連接建立和斷開，增加通信量的開銷。

2.7.1 持久連接
HTTP/1.1中，所有的連接默認都是持久連接（除非哪一方提出斷開連接否則不會斷開TCP連接），但在HTTP/1.0內未標準化。

2.7.2 管線化
不用等待響應可直接發送下一個請求。比持久連接更快。

2.8 使用Cookie的狀態管理

轉載于:https://www.cnblogs.com/foxNike/p/6337282.html

總結

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

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