本文轉(zhuǎn)自 ：flyhero 碼上實戰(zhàn)《一個HTTP打趴80%面試者》

HTTP協(xié)議簡介

HTTP（超文本傳輸協(xié)議）是應(yīng)用層上的一種客戶端/服務(wù)端模型的通信協(xié)議,它由請求和響應(yīng)構(gòu)成，且是無狀態(tài)的。（暫不介紹HTTP2）

• 協(xié)議：協(xié)議規(guī)定了通信雙方必須遵循的數(shù)據(jù)傳輸格式，這樣通信雙方按照約定的格式才能準確的通信。
• 無狀態(tài)：無狀態(tài)是指兩次連接通信之間是沒有任何關(guān)系的，每次都是一個新的連接，服務(wù)端不會記錄前后的請求信息。
• 客戶端/服務(wù)端模型

五層網(wǎng)絡(luò)模型

URL構(gòu)成

協(xié)議內(nèi)容

請求（Request）

客戶端發(fā)送一個HTTP請求到服務(wù)端的格式：

• 請求行
• 請求頭
• 請求體

響應(yīng)（Response）

服務(wù)器響應(yīng)客戶端格式：

• 狀態(tài)行
• 響應(yīng)頭
• 響應(yīng)體

狀態(tài)碼

HTTP狀態(tài)碼由三個十進制數(shù)字組成，第一個十進制數(shù)字定義了狀態(tài)碼的類型，后兩個數(shù)字沒有分類的作用。HTTP狀態(tài)碼共分為5種類型：

分類分類描述

1**	信息，服務(wù)器收到請求，需要請求者繼續(xù)執(zhí)行操作
2**	成功，操作被成功接收并處理
3**	重定向，需要進一步的操作以完成請求
4**	客戶端錯誤，請求包含語法錯誤或無法完成請求
5**	服務(wù)器錯誤，服務(wù)器在處理請求的過程中發(fā)生了錯誤

更詳細的狀態(tài)碼可查看?HTTP狀態(tài)碼

但一般我們只需要知道幾個常見的就行，比如 200，400，401，403，404，500，502

請求方法

截止到HTTP1.1共有下面幾種方法：

方法描述

GET	GET請求會顯示請求指定的資源。一般來說GET方法應(yīng)該只用于數(shù)據(jù)的讀取，而不應(yīng)當用于會產(chǎn)生副作用的非冪等的操作中。它期望的應(yīng)該是而且應(yīng)該是安全的和冪等的。這里的安全指的是，請求不會影響到資源的狀態(tài)。
POST	向指定資源提交數(shù)據(jù)進行處理請求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請求體中。POST請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改。
PUT	PUT請求會身向指定資源位置上傳其最新內(nèi)容，PUT方法是冪等的方法。通過該方法客戶端可以將指定資源的最新數(shù)據(jù)傳送給服務(wù)器取代指定的資源的內(nèi)容。
PATCH	PATCH方法出現(xiàn)的較晚，它在2010年的RFC 5789標準中被定義。PATCH請求與PUT請求類似，同樣用于資源的更新。二者有以下兩點不同：1.PATCH一般用于資源的部分更新，而PUT一般用于資源的整體更新。2.當資源不存在時，PATCH會創(chuàng)建一個新的資源，而PUT只會對已在資源進行更新。
DELETE	DELETE請求用于請求服務(wù)器刪除所請求URI（統(tǒng)一資源標識符，Uniform Resource Identifier）所標識的資源。DELETE請求后指定資源會被刪除，DELETE方法也是冪等的。
OPTIONS	允許客戶端查看服務(wù)器的性能。
CONNECT	HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
HEAD	類似于get請求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報頭。
TRACE	回顯服務(wù)器收到的請求，主要用于測試或診斷。

請求和響應(yīng)常見通用頭

名稱作用

Content-Type	請求體/響應(yīng)體的類型，如：text/plain、application/json
Accept	說明接收的類型，可以多個值，用,(半角逗號)分開
Content-Length	請求體/響應(yīng)體的長度，單位字節(jié)
Content-Encoding	請求體/響應(yīng)體的編碼格式，如gzip,deflate
Accept-Encoding	告知對方我方接受的Content-Encoding
ETag	給當前資源的標識，和Last-Modified、If-None-Match、If-Modified-Since配合，用于緩存控制
Cache-Control	取值為一般為?no-cache或max-age=XX，XX為個整數(shù)，表示該資源緩存有效期(秒)

注意：

Content-Type，內(nèi)容類型，一般是指網(wǎng)頁中存在的Content-Type，用于定義網(wǎng)絡(luò)文件的類型和網(wǎng)頁的編碼，決定瀏覽器將以什么形式、什么編碼讀取這個文件。

常見的媒體格式類型如下：

Content-Type(Mime-Type)描述

text/html	HTML格式
text/plain	純文本格式
text/xml	XML格式
image/gif	gif圖片格式
image/jpeg	jpg圖片格式
image/png	png圖片格式

以application開頭的媒體格式類型：

Content-Type(Mime-Type)描述

application/xml	XML數(shù)據(jù)格式
application/json	JSON數(shù)據(jù)格式
application/pdf	pdf格式
application/msword	Word文檔格式
application/octet-stream	二進制流數(shù)據(jù)（如常見的文件下載）
application/x-www-form-urlencoded	form表單數(shù)據(jù)被編碼為key/value格式發(fā)送到服務(wù)器（表單默認的提交數(shù)據(jù)的格式）
multipart/form-data	需要在表單中進行文件上傳時，就需要使用該格式

常見請求頭

名稱作用

Authorization	用于設(shè)置身份認證信息
User-Agent	用戶標識，如：OS和瀏覽器的類型和版本
If-Modified-Since	值為上一次服務(wù)器返回的?Last-Modified?值，用于確認某個資源是否被更改過，沒有更改過(304)就從緩存中讀取
If-None-Match	值為上一次服務(wù)器返回的 ETag 值，一般會和If-Modified-Since一起出現(xiàn)
Cookie	已有的Cookie
Referer	表示請求引用自哪個地址，比如你從頁面A跳轉(zhuǎn)到頁面B時，值為頁面A的地址
Host	請求的主機和端口號

常見響應(yīng)頭

名稱作用

Date	服務(wù)器的日期
Last-Modified	該資源最后被修改時間
Transfer-Encoding	取值為一般為chunked，出現(xiàn)在Content-Length不能確定的情況下，表示服務(wù)器不知道響應(yīng)版體的數(shù)據(jù)大小，一般同時還會出現(xiàn)Content-Encoding響應(yīng)頭
Set-Cookie	設(shè)置Cookie
Location	重定向到另一個URL，如輸入瀏覽器就輸入baidu.com回車，會自動跳到?https://www.baidu.com?，就是通過這個響應(yīng)頭控制的
Server	后臺服務(wù)器

?

?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的一篇搞懂HTTP协议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。