篇3介紹了HTTP的請求報文和響應(yīng)報文，重點是請求方法和狀態(tài)碼（我在面試阿里和騰訊分別被問到過），這其實就是HTTP協(xié)議的核心了！
用于HTTP協(xié)議交互的信息被稱為HTTP報文。請求端的HTTP報文叫做請求報文，響應(yīng)端的叫做響應(yīng)報文。HTTP報文大致可分為報文首部和報文主體兩塊，如圖1所示。
請求報文和響應(yīng)報文主要不同在于報文首部分別是請求行和狀態(tài)行，其含義如下：
- 請求行：包含用于請求的方法，請求URI和HTTP版本
- 狀態(tài)行：包含表明響應(yīng)結(jié)果的狀態(tài)碼，原因短語和HTTP版本
- 首部字段：包含表示請求和響應(yīng)的各種條件和屬性的各類首部
下面以請求簡書博客地址為例，解釋請求報文和響應(yīng)報文
1 - 請求報文
請求報文是由請求方法、請求URI、協(xié)議版本、可選的請求首部字段和內(nèi)容實體組成的。
// 請求報文
GET http://www.itdecent.cn/u/d97a1dec9e2d HTTP/1.1
// 請求首部字段
Host: www.itdecent.cn
Proxy-Connection: keep-alive
Accept: application/json
Chrome/57.0.2979.2 Safari/537.36
Referer: http://www.itdecent.cn/u/d97a1dec9e2d
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
// 內(nèi)容實體
Cookie: ...
name=binjiang&age=100
- “GET”：請求方法
- “www.itdecent.cn/u/d97a1dec9e2d”：請求URI
- “HTTP/1.1”：協(xié)議版本
1.1 - HTTP請求方法
(1). GET：獲取資源
GET方法用來請求訪問已被URI識別的資源，指定的資源經(jīng)服務(wù)端解析后返回響應(yīng)內(nèi)容。如果資源是文本、圖片，就直接返回；如果是接口程序，就返回執(zhí)行的結(jié)果。
(2). POST：傳輸實體主體
POST方法用來傳輸實體的主體，盡管GET方法也可以傳輸實體的主體，但一般不用GET方法進行傳輸，而是POST方法。
這是因為GET提交，請求的數(shù)據(jù)會附在URI之后，而POST提交會把請求的數(shù)據(jù)放置在內(nèi)容實體中。因此，GET提交的數(shù)據(jù)會在地址欄中顯示出來，而POST提交，地址欄不會改變。
同時，GET方法在特定瀏覽器和服務(wù)器對URL長度有限制，這也會導(dǎo)致POST可以傳輸?shù)膬?nèi)容更多一些。并且POST的安全性要比GET的安全性高。
(3). PUT：傳輸文件
PUT方法用來傳輸文件。但是鑒于HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件，存在安全性，因此一般的web網(wǎng)站不使用該方法。除非配合web應(yīng)用程序的驗證機制或是采用REST標準的網(wǎng)站架構(gòu)設(shè)計。
(4). HEAD：獲得報文首部
HEAD方法和GET方法一樣，只是不返回報文主體部分。用于確認URI的有效性及資源更新的日期時間等。
(5). DELETE：刪除文件
DELETE方法用來刪除文件，是與PUT相反的方法。同樣HTTP/1.1的DELETE方法自身不帶驗證機制，因此一般的web網(wǎng)站不使用該方法。
(6). OPTIONS：詢問支持的方法
OPTIONS方法用來查詢針對URI指定的資源支持的方法。
(7). TRACE：追蹤路徑
TRACE方法是讓web服務(wù)器端將之前的請求通信環(huán)回給客戶端的方法?？蛻舳送ㄟ^TRACE方法可以查詢發(fā)送出去的請求是怎樣被加工修改/篡改的。這是因為，請求在連接到目標服務(wù)器的中途可能會經(jīng)過代理中轉(zhuǎn)，TRACE方法就是用來確認連接過程中發(fā)生的一系列操作。
(8). CONNECT：要求用隧道協(xié)議連接代理
CONNECT方法要求在與代理服務(wù)器通信時建立隧道，實現(xiàn)用隧道協(xié)議進行TCP通信。主要使用SSL（Secure Sockets Layer，安全套接層）和TSL（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸
2 - 響應(yīng)報文
響應(yīng)報文是由協(xié)議版本、狀態(tài)碼、說明、可選響應(yīng)首部字段以及實體主體構(gòu)成。
HTTP/1.1 200 OK
// 響應(yīng)首部字段
Date: Mon, 13 Mar 2017 04:36:45 GMT
Content-Length: 362
Content-Type: text/html
// 主體
<html>
...
2.1 - HTTP狀態(tài)碼
狀態(tài)碼的作用是當客戶端向服務(wù)端發(fā)送請求后，服務(wù)端返回處理結(jié)果的狀態(tài)。因為客戶端需要知道服務(wù)端返回的是有效的還是錯誤的數(shù)據(jù)，如果是錯誤的數(shù)據(jù)，是客戶端的問題，還是服務(wù)端的問題。
| 類別 | 原因短語 | |
|---|---|---|
| 1XX | Informational（信息性狀態(tài)碼） | 請求正在處理中 |
| 2XX | Success | 正常處理完畢 |
| 3XX | Redirection | 需要進行附加操作才算完成請求 |
| 4XX | Client Error | 客戶端發(fā)送的請求數(shù)據(jù)問題 |
| 5XX | Server Error | 服務(wù)端處理請求時出錯 |
這里面最需要關(guān)注的是4XX和5XX。因為在Web開發(fā)和調(diào)試過程中，不可避免會出現(xiàn)Bug，返回碼可以幫助快速定位到出錯點。例如經(jīng)常會出現(xiàn)的“404 Not Found”錯誤，表明了服務(wù)器上無法找到請求的資源，而服務(wù)器本身是正常工作的?！?01 Internal Server Error”表明服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤，此時服務(wù)器并沒有正常工作。
3 - 首部字段含義
- 通用首部字段（General Header Fields）: 請求報文和響應(yīng)報文兩方都會使用的首部；
- 請求首部字段（Request Header Fields）: 從客戶端向服務(wù)器發(fā)送請求報文時使用的首部。補充了請求的附加內(nèi)容，客戶端的信息，響應(yīng)內(nèi)容相關(guān)的優(yōu)先級等信息。
- 響應(yīng)首部字段（Response Header Fields）: 從服務(wù)器向客戶端返回響應(yīng)報文時使用的首部。補充了響應(yīng)的附加內(nèi)容，也會要求客戶端附加額外的內(nèi)容信息。
- 實體首部字段（Entity Header Fields）: 針對請求報文和響應(yīng)報文的實體部分使用的首部。補充了資源內(nèi)容更新時間等與實體有關(guān)的信息。
3.1 - 通用首部字段
| 首部字段名 | 說明 |
|---|---|
| Cache-Control | 控制緩存的行為 |
| Connection | 逐跳首部，連接的管理 |
| Date | 創(chuàng)建報文的日期時間 |
| Pragna | 報文指令 |
| Trailer | 報文末端的首部一覽 |
| Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
| Upgrade | 升級為其他協(xié)議 |
| Via | 代理服務(wù)器的相關(guān)信息 |
| Warning | 錯誤通知 |
3.2 - 請求首部字段
| 首部字段名 | 說明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型 |
| Accept—Charset | 優(yōu)先的字符集 |
| Accept-Encoding | 優(yōu)先的內(nèi)容編碼 |
| Accept-Language | 優(yōu)先的語言（自然語言） |
| Authorization | Web認證信息 |
| Expect | 期待服務(wù)器的指定行為 |
| From | 用戶的電子郵箱地址 |
| Host | 請求資源所在服務(wù)器 |
| if-Match | 比較實體標記（ETag） |
| if-Modified-Since | 比較資源的更新時間 |
| if-None-Match | 比較實體標記（與if-Match相反） |
| if-Range | 資源為更新時發(fā)送實體Byte的范圍請求 |
| if-Unmodified-Since | 比較資源的更新時間（與if-Modified-Since相反） |
| Max-Forwards | 最大傳輸逐跳數(shù) |
| Proxy-Authorization | 代理服務(wù)器要求客戶端的認證信息 |
| Range | 實體字節(jié)范圍請求 |
| Referer | 對請求中的URL的原始獲取方法 |
| TE | 傳輸編碼的優(yōu)先級 |
| User-Agent | HTTP客戶端程序的信息 |
3.3 - 響應(yīng)首部字段
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節(jié)范圍請求 |
| Age | 推算資源創(chuàng)建經(jīng)過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定的URL |
| Proxy-Authenticate | 代理服務(wù)器對客戶端的認證信息 |
| Rety-After | 對再次發(fā)起請求的時機要求 |
| Server | HTTP服務(wù)器的安裝信息 |
| Vary | 代理服務(wù)器緩存的管理信息 |
| WWW-Authenticate | 服務(wù)器對客戶端的認證信息 |
3.4 - 實體首部字段
| 首部字段名 | 說明 |
|---|---|
| Allow | 資源科支持的HTTP方法 |
| Content-Encoding | 實體主體適用的編碼方式 |
| Content-Language | 實體主體的自然語言 |
| Content-Length | 實體主體的大?。▎挝唬鹤止?jié)） |
| Content-Location | 替代對資源的URL |
| Content-MD5 | 實體主體的報文摘要 |
| Content-Range | 實體主體的位置范圍 |
| Content-Type | 實體主體的媒體類型 |
| Expires | 實體主體過期的日期時間 |
| Last-Modified | 資源的最后修改日期時間 |
4 - Cookie服務(wù)的首部字段
| 首部字段名 | 說明 | 首部類型 |
|---|---|---|
| Set-Cookie | 開始狀態(tài)管理所有的Cookie信息 | 響應(yīng)首部字段 |
| Cookie | 服務(wù)器接收到的Cookie信息 | 請求首部字段 |
4.1 - Set-Cookie字段的屬性
| 屬性 | 說明 |
|---|---|
| NAME=VALUE | 賦予Cookie的名稱和其值 |
| expires=DATE | Cookie的有效期（若不mingque指定則默認為瀏覽器關(guān)閉前為止） |
| path=PATH | 將服務(wù)器上的文件目錄作為Cookie的適用對象（若不指定則默認為文檔所在的目錄） |
| domain=域名 | 作為Cookie適用對象的域名（若不指定則默認為創(chuàng)建Cookie的服務(wù)器的域名） |
| Scure | 僅在HTTPS安全通信時才會發(fā)送Cookie |
| HttpOnly | 加以限制，使Cookie不能被JavaScript腳本訪問 |
大家好，我是彬彬醬，目前在騰訊從事Web后端開發(fā)。
菜鳥必知的 http 知識專題整理了關(guān)于網(wǎng)絡(luò)的基礎(chǔ)知識，適合大家進行入門級學(xué)習(xí)，這個專題現(xiàn)包含下列文章：
菜鳥必知的 http 知識（一）—— TCP 握手協(xié)議
菜鳥必知的 http 知識（二）—— HTTP 協(xié)議特點
菜鳥必知的 http 知識（三）—— 請求和響應(yīng)報文
菜鳥必知的 http 知識（四）—— HTTP 和 HTTPS
菜鳥必知的 http 知識（五）—— 新技術(shù)的出現(xiàn)
菜鳥必知的 http 知識（六）—— web的結(jié)構(gòu)組件
