HTTP請求：Hyper Text Transfer Protocol的縮寫，即超文本傳輸協議。
一、HTTP協議的結構
HTTP報文由客戶機到服務器的請求和從服務器到客戶機的相應構成。
1、請求報文的組成：
| 請求行 | 信息頭 | 請求頭 | 實體頭 | 報文主體 |
請求行的格式如下：
Method [分隔符] Request - URL [分隔符] HTTP-Version CRLF
解釋說明：
（1）Method 表示完成Request - URL的方法，該字段是大小寫敏感的，據RFC2616標准（現行的HTTP/1.1）得知，通常有以下8種方法：
| OPTIONS | 請求獲得由Request-URI標識的資源在請求/響應的通信過程中可以使用的功能選項 |
| HEAD | HEAD方法跟GET方法相同，只不過服務器響應時不會返回消息體 |
| PUT | 把消息本體中的消息發送到一個URL,跟POST類似 |
| TRACE | 是用來調用一個遠程的請求信息應用程序層的循環后退 |
| CONNECT | HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。 |
| DELETE | 請求服務器刪除Request-URI所標識的資源 |
| GET | 由客戶端請求服務端獲取Request-URI所標識的資源的方法 |
| POST | 由客戶端向服務端提交Request-URI所標識的資源后附加新的數據 |
（2）[分隔符]為空格
（3）Request - URL： 遵循URL格式，此字段為星號（*）時，說明請求並不用於某個特定的資源地址，而是用於服務本身。
（4）HTTP-Version：表示支持的HTTP版本，如HTTP/1.1
（5）CRLF：表示換行回車符
HTTP的頭包括通用的信息頭、請求頭、響應頭、實體頭4部分，每個頭域由一個域名、冒號和值域3部分組成。域名是大小寫無關的；域值前可以添加任何數量的空格，每個HTTP請求可以包含多個HTTP頭域。
HTTP報文主體則包含了HTTP請求的內容，對於get方法，報文主體為空，對於post方法，報文主體則包含需要發送給服務器的數據。
2、響應報文的組成：
| 狀態行 | 信息頭 | 響應頭 | 實體頭 | 報文主體 |
解釋說明：
（1）狀態行由狀態碼和原因分析兩部分組成，其中，狀態碼由3位數字組成，表示請求是否被理解或被滿足，用來支持自動操作；原因分析是對原文的狀態碼作簡單的描述，用於供用戶使用。
3、無論是請求報文還是響應報文，雖然分別由以上五個部分組成，但是在一定情況下有些並不是必須要的，但是對於：General-header(通用頭部)、請求頭（客戶端->服務器[Request Header])、響應頭(服務端->客戶端[Response Header]) 這三部分是必須要有的。於是我那一個實例來對這三部分的內容進行說明記錄：
（1）General-header(通用頭部)
1 Request URL: http://115.148.141.110:8980/v1/purchase/list # 請求的URL地址（包含請求類型、請求域名、請求端口、請求地址）
2 Request Method: POST # 請求方式
3 Status Code: 200 OK # 響應的狀態碼、結果
4 Remote Address: 127.0.0.1:8899 # 請求的遠程地址
5 Referrer Policy: no-referrer-when-downgrade # referrer策略（五種方法）
（2）請求頭（客戶端->服務器[Request Header]) --以下數據是通過fidder抓取所得（關於Fidder基本說明的去這里：https://www.cnblogs.com/Zhan-W/p/9813218.html）。
1 POST /v1/purchase/list HTTP/1.1 # 請求方式、請求地址、請求所使用的協議和版本 2 Host: 115.157.151.673:8180 # 目標主機地址和端口號 3 Connection: keep-alive # 維護客戶端和服務端的連接關系 4 Content-Length: 68 # 描述HTTP消息實體的傳輸長度 5 Accept: application/json, text/javascript, */*; q=0.01 #發送端（客戶端）希望接受的數據類型、q 是權重系數，范圍 0 =< q <= 1，q 值越大，請求越傾向於獲得其“;”之前的類型表示的內容 6 Origin: http://apptest.zhidianlife.com:8007 # 瀏覽器在referrer字段中只顯示源網站的源地址（即協議、域名、端口），而不包括完整的路徑 7 Authorization: c81e7286507f4aa4b6179f4c381b4c64 # 請求所需的認證信息 8 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36 # 客戶端版本號的名字 9 Content-Type: application/json # 請求實體，文檔類型 10 Referer: http://apptest.zhidianlife.com:8007/procurement/order?_t=756512&_winid=w9290 # 從來於哪里 11 Accept-Encoding: gzip, deflate # 客戶端接收編碼類型，一些網絡壓縮格式： gzip, deflate 12 Accept-Language: zh-CN,zh;q=0.9 # 客戶端接收的語言類型 、中文
（3）響應頭(服務端->客戶端[Response Header])
1 HTTP/1.1 200 OK # 請求協議以及本版、請求狀態碼
2 Date: Tue, 02 Jul 2019 14:07:31 GMT # 服務端響應客戶端的內容過期時間
3 Content-Type: application/json; charset=utf-8 # 服務端發送的類型及采用的編碼方式
4 Server: Kestrel # WEB 服務器 服務端的Web服務端名
5 Vary: Origin # WEB服務器用該頭部的內容告訴 Cache 服務器，在什么條件下才能用本響應所返回的對象響應后續的請求
6 Access-Control-Allow-Credentials: true # 允許運行客戶端攜帶證書式訪問
7 Access-Control-Allow-Origin: http://apptest.zhidianlife.com:8007
8 Content-Length: 33310 # 允許指定的域名、地址訪問
其中涉及到前端頁面性能問題的字段主要有以下：Accept-Encoding、Connection、Date
3、GET與POST請求過程
POST請求的過程：
- 瀏覽器請求tcp連接（第一次握手）
- 服務器答應進行tcp連接（第二次握手）
- 瀏覽器確認，並發送post請求頭（第三次握手，這個報文比較小，所以http會在此時進行第一次數據發送）
- 服務器返回100 Continue響應
- 瀏覽器發送數據
- 服務器返回200 OK響應
GET請求的過程：
- 瀏覽器請求tcp連接（第一次握手）
- 服務器答應進行tcp連接（第二次握手）
- 瀏覽器確認，並發送get請求頭和數據（第三次握手，這個報文比較小，所以http會在此時進行第一次數據發送）
- 服務器返回200OK響應
4、HTTP狀態碼的分類
| 分類 | 分類描述 |
| 1** | 信息，服務器收到請求，需要請求者繼續執行操作 |
| 2** | 成功，操作被成功接收並處理 |
| 3** | 重定向，需要進一步的操作以完成請求 |
| 4** | 客戶端錯誤，請求包含語法錯誤或無法完成請求 |
| 5** | 服務器錯誤，服務器在處理請求的過程中發生了錯誤 |
-----時間不夠了，明天還要上班，還在公司加班，寫的粗糙，有什么不對的以及可以完善的希望各位大神留言---