一、HTTP協議

Hypertext Transfer Protocol，超文本傳輸協議，HTTP 是一個在計算機世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規范。

HTTP 優點

靈活可擴展。一個是語法上只規定了基本格式，空格分隔單詞，換行分隔字段等。另外一個就是傳輸形式上不僅可以傳輸文本，還可以傳輸圖片，視頻等任意數據。

請求-應答模式，通常而言，就是一方發送消息，另外一方要接受消息，或者是做出相應等。

可靠傳輸，HTTP是基于TCP/IP，因此把這一特性繼承了下來。

無狀態。

HTTP 缺點

無狀態，有時候，需要保存信息，比如像購物系統，需要保留下顧客信息等等，另外一方面，有時候，無狀態也會減少網絡開銷，比如類似直播行業這樣子等，這個還是分場景來說。

明文傳輸，即協議里的報文(主要指的是頭部)不使用二進制數據，而是文本形式。這讓HTTP的報文信息暴露給了外界，給攻擊者帶來了便利。

隊頭阻塞，當http開啟長連接時，共用一個TCP連接，當某個請求時間過長時，其他的請求只能處于阻塞狀態，這就是隊頭阻塞問題。

HTTP/1.0 HTTP1.1 HTTP2.0版本之間的差異

• HTTP 0.9

1991年,原型版本，功能簡陋，只有一個命令GET,只支持純文本內容，該版本已過時。

• HTTP 1.0

任何格式的內容都可以發送，這使得互聯網不僅可以傳輸文字，還能傳輸圖像、視頻、二進制等文件。除了GET命令，還引入了POST命令和HEAD命令。http請求和回應的格式改變，除了數據部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數據。只使用 header 中的 If-Modified-Since 和 Expires 作為緩存失效的標準。不支持斷點續傳，也就是說，每次都會傳送全部的頁面和數據。通常每臺計算機只能綁定一個 IP，所以請求消息中的 URL 并沒有傳遞主機名（hostname）

• HTTP 1.1

http1.1是目前最為主流的http協議版本，從1999年發布至今，仍是主流的http協議版本。引入了持久連接（ persistent connection），即TCP連接默認不關閉，可以被多個請求復用，不用聲明Connection: keep-alive。長連接的連接時長可以通過請求頭中的 keep-alive 來設置引入了管道機制（ pipelining），即在同一個TCP連接里，客戶端可以同時發送多個請求，進一步改進了HTTP協議的效率。HTTP 1.1 中新增加了 E-tag，If-Unmodified-Since, If-Match, If-None-Match 等緩存控制標頭來控制緩存失效。支持斷點續傳，通過使用請求頭中的 Range 來實現。使用了虛擬網絡，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址。新增方法：PUT、 PATCH、 OPTIONS、 DELETE。

• http1.x版本問題

在傳輸數據過程中，所有內容都是明文，客戶端和服務器端都無法驗證對方的身份，無法保證數據的安全性。HTTP/1.1 版本默認允許復用TCP連接，但是在同一個TCP連接里，所有數據通信是按次序進行的，服務器通常在處理完一個回應后，才會繼續去處理下一個，這樣子就會造成隊頭阻塞。http/1.x 版本支持Keep-alive，用此方案來彌補創建多次連接產生的延遲，但是同樣會給服務器帶來壓力，并且的話，對于單文件被不斷請求的服務，Keep-alive會極大影響性能，因為它在文件被請求之后還保持了不必要的連接很長時間。

• HTTP 2.0

二進制分幀 這是一次徹底的二進制協議，頭信息和數據體都是二進制，并且統稱為"幀"：頭信息幀和數據幀。頭部壓縮 HTTP 1.1版本會出現 「User-Agent、Cookie、Accept、Server、Range」 等字段可能會占用幾百甚至幾千字節，而 Body 卻經常只有幾十字節，所以導致頭部偏重。HTTP 2.0 使用 HPACK 算法進行壓縮。多路復用 復用TCP連接，在一個連接里，客戶端和瀏覽器都可以同時發送多個請求或回應，且不用按順序一一對應，這樣子解決了隊頭阻塞的問題。服務器推送 允許服務器未經請求，主動向客戶端發送資源，即服務器推送。請求優先級 可以設置數據幀的優先級，讓服務端先處理重要資源，優化用戶體驗。

HTTP 常見狀態碼

RFC 規定 HTTP 的狀態碼為「三位數」，第一個數字定義了響應的類別，被分為五類:

• 1xx: 代表請求已被接受，需要繼續處理。
• 2xx: 表示成功狀態。
• 3xx: 重定向狀態。
• 4xx: 客戶端錯誤。
• 5xx: 服務器端錯誤。

200 OK：請求正常處理完畢
204 No Content：請求成功處理，沒有實體的主體返回
206 Partial Content：GET范圍請求已成功處理
301 Moved Permanently：永久重定向，資源已永久分配新URI
302 Found：臨時重定向，資源已臨時分配新URI
303 See Other：臨時重定向，期望使用GET定向獲取
304 Not Modified：用于瀏覽器緩存的狀態代碼。 如果響應尚未修改，則客戶端/用戶可以繼續使用相同的響應/緩存版本。 例如，如果資源已自特定時間以來被修改，瀏覽器可以請求。 如果沒有，則發送狀態代碼 304。 如果已修改，則發送狀態代碼 200 以及資源。
307 Temporary Redirect：臨時重定向，POST不會變成GET
400 Bad Request：請求報文語法錯誤或參數錯誤
401 Unauthorized：需要通過HTTP認證，或認證失敗
403 Forbidden：請求資源被拒絕
404 Not Found：無法找到請求資源（服務器無理由拒絕）
500 Internal Server Error;服務器故障或Web應用故障
503 Service Unavailable；服務器超負載或停機維護

更詳細的狀態碼解釋

HTTP 請求方法

二、HTTP請求行、請求頭、請求體

HTTP請求報文解剖 ：HTTP請求報文由3部分組成（ 請求行+請求頭+請求體 ）

請求行屬性

• ①是請求方法，GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當前的大多數瀏覽器只支持GET和POST，Spring 3.0提供了一個HiddenHttpMethodFilter，允許你通過“_method”的表單參數指定這些特殊的HTTP方法（實際上還是通過POST提交表單）。服務端配置了HiddenHttpMethodFilter后，Spring會根據_method參數指定的值模擬出相應的HTTP方法，這樣，就可以使用這些HTTP方法對處理方法進行映射了。
• ②為請求對應的URL地址，它和報文頭的Host屬性組成完整的請求URL
• ③是協議名稱及版本號。

HTTP請求報文頭屬性

• ④是HTTP的報文頭，報文頭包含若干個屬性，格式為“屬性名:屬性值”，服務端據此獲取客戶端的信息。

報文頭屬性是什么東西呢？我們不妨以一個小故事來說明吧。

• 快到中午了，張三豐不想去食堂吃飯，于是打電話叫外賣：老板，我要一份[魚香肉絲]，要12：30之前給我送過來哦，我在江湖湖公司研發部，叫張三豐。
• 這里，你要[魚香肉絲]相當于HTTP報文體，而“12：30之前送過來”，你叫“張三豐”等信息就相當于HTTP的報文頭。它們是一些附屬信息，幫忙你和飯店老板順利完成這次交易。

• 常見的HTTP請求報文頭屬性

Accept ：請求報文可通過一個“Accept”報文頭屬性告訴服務端：客戶端接受什么類型的響應。 Accept屬性的值可以為一個或多個MIME類型的值。

更多關于MIME類型，大家請參考：http://en.wikipedia.org/wiki/MIME_type

Cookie ：客戶端的Cookie就是通過這個報文頭屬性傳給服務端的哦！

Referer ：表示這個請求是從哪個URL過來的，假如你通過google搜索出一個商家的廣告頁面，你對這個廣告頁面感興趣，鼠標一點發送一個請求報文到商家的網站，這個請求報文的Referer報文頭屬性值就是http://www.google.com。

Cache-Control ：對緩存進行控制，如一個請求希望響應返回的內容在客戶端要被緩存一年，或不希望被緩存就可以通過這個報文頭達到目的。

Accept-Charset：告訴服務器能夠發送哪些字符集

Accept-Encoding：告訴服務器能夠發送哪些編碼方式

Accept-Language：告訴服務器能夠發送哪些語言

Host：指定要請求的資源所在的主機和端口

User-Agent 作用：告訴服務器，客戶端使用的操作系統、瀏覽器版本和名稱

Client-IP：提供了運行客戶端的機器的IP地址

From：提供了客戶端用戶的E-mail地址

TE：告訴服務器可以使用那些擴展傳輸編碼

Expect：允許客戶端列出某請求所要求的服務器行為

Range：如果服務器支持范圍請求，就請求資源的指定范圍

更詳細的請求頭解釋

請求體

• ⑤是報文體，它將一個頁面表單中的組件值通過param1=value1&param2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數的數據。不但報文體可以傳遞請求參數，請求URL也可以通過類似于“/chapter15/user.htmlparam1=value1&param2=value2”的方式傳遞請求參數。

• 請求體的多種格式

multipart/form-data

application/x-www-from-urlencoded

raw

binary

• multipart/form-data

以表單形式提交，主要是上傳文件用它，在http中格式為

• application/x-www-from-urlencoded以鍵值對的數據格式提交

• raw

• 選擇text，則請求頭是： text/plain
• 選擇javascript，則請求頭是： application/javascript
• 選擇json，則請求頭是： application/json (如果想以json格式傳參，就用raw+json就行了)
• 選擇html，則請求頭是： text/html 選擇application/xml，則請求頭是： application/xml

• binary

相當于Content-Type:application/octet-stream,從字面意思得知，只可以上傳二進制數據，通常用來上傳文件，由于沒有鍵值，所以，一次只能上傳一個文件。(一般用的不多)

• postman中 Params和Body的區別

Params 它會將參數放入url的?后面提交到后臺（帶到請求的接口鏈接里）

Body是放在請求體里面

三、HTTP響應行、響應頭、響應體

響應行：

• ①報文協議及版本；
• ②狀態碼及狀態描述；

響應頭

Cache-Control（對應請求中的Cache-Control）Cache-Control:private 默認為private 響應只能夠作為私有的緩存，不能再用戶間共享

Content-Type：text/html;charset=UTF-8 告訴客戶端，資源文件的類型，還有字符編碼，客戶端通過utf-8對資源進行解碼，然后對資源進行html解析。

Content-Encoding:gzip 告訴客戶端，服務端發送的資源是采用gzip編碼的，客戶端看到這個信息后，應該采用gzip對資源進行解碼。

Date: Tue, 03 Apr 2018 03:52:28 GMT 這個是服務端發送資源時的服務器時間，GMT是格林尼治所在地的標準時間。http協議中發送的時間都是GMT的，這主要是解決在互聯網上，不同時區在相互請求資源的時候，時間混亂問題。

Server Server：Tengine/1.4.6 這個是服務器和相對應的版本，只是告訴客戶端服務器信息。

Transfer-Encoding：chunked 這個響應頭告訴客戶端，服務器發送的資源的方式是分塊發送的。

Expires:Sun, 1 Jan 2000 01:00:00 GMT 這個響應頭也是跟緩存有關的，告訴客戶端在這個時間前，可以直接訪問緩存副本。

Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT 所請求的對象的最后修改日期(按照 RFC 7231 中定義的“超文本傳輸協議日期”格式來表示)

Connection：keep-alive 這個字段作為回應客戶端的Connection：keep-alive，告訴客戶端服務器的tcp連接也是一個長連接，客戶端可以繼續使用這個tcp連接發送http請求。

ETag: “737060cd8c284d8af7ad3082f209582d” 就是一個對象（比如URL）的標志值，就一個對象而言，比如一個html文件，如果被修改了，其Etag也會別修改。

Refresh: 5; url=http://baidu.com 用于重定向，或者當一個新的資源被創建時。默認會在5秒后刷新重定向。

Access-Control-Allow-Origin: * *號代表所有網站可以跨域資源共享，如果當前字段為*那么Access-Control-Allow-Credentials就不能為true
Access-Control-Allow-Origin: www.baidu.com 指定哪些網站可以跨域資源共享

Access-Control-Allow-MethodsAccess-Control-Allow-Methods：GET,POST,PUT,DELETE 允許哪些方法來訪問

Access-Control-Allow-CredentialsAccess-Control-Allow-Credentials: true 是否允許發送cookie。默認情況下，Cookie不包括在CORS請求之中。

更詳細的響應頭解釋

響應體

由Content-Type決定，一般有以下類型：

• application/javascript
• application/html
• application/json

最后推薦直接看官方文檔

參考文章

總結

以上是生活随笔為你收集整理的HTTP，request，response的全部內容，希望文章能夠幫你解決所遇到的問題。

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