這是關於網路系列的第六篇文章,接下來會有更多精彩內容.敬請期待! 讓我們一起乘風破浪!
前言
HTTP報文是客戶端和伺服器交流使用的“對話方式”，彼此說對方都能理解的話，才能相互溝通。就像TCP使用TCP報文交流一樣.那麼HTTP報文的格式到底怎樣，讓我們一探究竟！在本篇中，你將瞭解到一下內容：
- 報文的流動方式
- 報文的組成部分
- 請求報文和響應報文的區別
- 請求報文的各種功能
- 狀態碼的含義
- HTTP首部是用來做什麼的
瞭解報文流的概念
HTTP報文在客戶端、伺服器、和代理之間的傳遞可以形象的稱為流動。術語“流入”、“流出”、“上游”、“下游”是在流的基礎上定義的，用來描述報文方向。
- “流入”意為報文從客戶端到達伺服器；“流出”，則和流入相反。可以看出，這兩個術語是針對伺服器而言。
- “上游”和“下游”，不管是請求報文還是響應報文，所有報文都會向“下游”流動。所有報文的傳送者都在接收者的“上游”。
報文的格式
開篇的圖片很好的說明了HTTP報文的基本格式。
/// 請求報文格式
<method>空格<request-url>空格<version>
<headers>
空行
<entity-body>
/// 響應報文格式
<version>空格<status>空格<reason-phrase>
<headers>
空行
<entity-body>
複製程式碼各部分的作用如下:
- 起始行和首部是由行分割的ASCII文字，每行由一個回車符(\n)和一個換行符(\r)組成的序列結束。這個序列可以寫作
CRLF。 method，客戶端希望伺服器執行的動作。request-url，請求的資源路徑。version，HTTP的版本，如HTTP/1.0。不同版本有不同的特性。status，3位數，描述了請求過程中的情況。具體介紹在後面。reason-phrase，和status對應，是其描述。headers，可以沒有或多個。具體介紹在後面。entity-body，資料塊，主體是可選的，可以為二進位制或文字。
下面我們再瞭解下方法、狀態碼和首部的內容。
方法
HTTP方法列表：
| HTTP方法 | 描述 |
|---|---|
| GET | 告知伺服器，需要從伺服器向客戶端傳送命名資源 |
| HEAD | 僅傳送命名資源響應中的HTTP首部 |
| PUT | 將客戶端的資料儲存的命名的伺服器資源中 |
| POST | 將客戶端資料傳送到一個伺服器應用程式 |
| TRACE | 追溯一個請求 |
| OPTIONS | 檢視伺服器對資源支援的操作 |
| DELETE | 從伺服器刪除資源 |
雖然HTTP規定了這些方法，具體伺服器是否支援，由伺服器確定。
GET，從伺服器獲取資源，HTTP/1.1要求實現的方法。HEAD，和GET方法類似，但是響應報文中不會包含主體部分。使用該特性，可以在不真正獲取資源的情況下完成：- 判斷資源型別
- 檢視對應資源是否存在
- 檢視資源是否被修改
HTTP/1.1規範中要求實現該方法，並且對於同一資源，該方法響應首部應該和
GET方法返回的相同。
PUT，和GET相反，請求伺服器在指定位置建立檔案，內容為請求主體的內容。若對應資源存在，則替換。POST，客戶端向伺服器傳送資料。常用來提交表單。TRACE，客戶端發出請求後，可能經過中間的閘道器、代理等，原始請求可能被修改，使用TRACE可以檢視最終到達伺服器的請求具體是什麼樣子（伺服器在響應報文的主體中包含其收到的請求報文）。下面是一個示例：TRACE通常用於診斷一個請求是否能到達伺服器，不能帶有主體部分。OPTIONS，用於檢視伺服器對特定資源所支援的方法。在請求報文中若使用*代替URL，則意為檢視伺服器對所有資源的通用方法。DELETE，請求伺服器刪除指定資源。當然，具體是否刪除，由伺服器決定。
HTTP擴充套件方法
HTTP擴充套件方法指的是沒有在HTTP規範中定義的方法。例如，下面是在WebDAV HTTP擴充套件中的方法：
| 擴充套件方法名 | 描述 |
|---|---|
| LOCK | 告知伺服器，對指定資源鎖定，防止其他人對其更改 |
| MKCOL | 允許使用者建立資源 |
| COPY | 允許使用者 複製資源 |
| MOVE | 移動伺服器資源 |
狀態碼
100~199資訊性狀態碼
這些狀態碼較新，在HTTP/1.1引入。下面是已定義的狀態碼:
| Code | 原因短語 | 描述 |
|---|---|---|
| 100 | Continue | 伺服器收到請求的初始部分，請客戶端繼續。 |
| 101 | Switching Protocols | 伺服器正在根據客戶端的指定，將協議更換成Update首部所列協議。 |
對於狀態碼100，起初的設計是為了：客戶端想傳送一個實體到伺服器，但在傳送之前想檢視伺服器是否願意接受。需要知道的是：
- 對於客戶端，若客戶端希望傳送一個實體，並且願意等待伺服器狀態碼為100的響應，那麼客戶端的請求報文中應包含值為
100 Continue的Expect首部。客戶端在傳送請求後，不要一直等待，可以在超出一定時間後直接傳送實體。 - 對於伺服器，若伺服器收到包含值為
100 Continue的首部，應該以100 Continue或其他對應錯誤狀態碼響應。伺服器不應該向沒有包含100 Continue首部的請求響應100 Continue狀態碼。若伺服器在響應100 Continue狀態之前已經收到客戶端傳送的實體部分，可以跳過響應100 Continue，但要響應最終的狀態。 - 對於代理，若代理接受到客戶端包含
100 Continue的請求，在代理知道請求的下一跳只支援HTTP/1.0（或更早），它應該響應417 Expectation Failed；在代理知道下一跳支援HTTP/1.1或沒有清楚的狀態，則應轉發這一請求。若代理將上游伺服器響應轉發給客戶端時，知道客戶端不支援HTTP/1.1，則不應響應100 Continue。
200~299成功狀態碼
在請求成功時，伺服器會返回代表成功的狀態碼；對於不同的請求方法，狀態碼有可能會有區別。已知的成功狀態碼如下：
| Code | 原因短語 | 描述 |
|---|---|---|
| 200 | OK | 最常見。請求成功，響應主體包含了具體的資料。 |
| 201 | Created | 響應在伺服器 建立資源的請求，如PUT。伺服器應確保資源被建立，並在響應報文中包含資源URL。 |
| 202 | Accepted | 伺服器以接收到請求，但還未執行任何操作。 |
| 203 | Non-Authoritative Information | 實體首部（也可以稱為元資訊）包含的資訊不是來自於伺服器，而是資源的一個副本。若中間節點上有一份資源副本，但無法或沒有對它發出的與資源有關的元資訊進行驗證，就會出現這種情況。當然，這種狀態並不是非用不可，若實體首部來自伺服器，返回200完全可以。 |
| 204 | No Content | 響應報文中無主體部分。主要用於在瀏覽器不轉為顯示新文件情況下，對其更新。 |
| 205 | Reset Content | 負責告知瀏覽器清除當前頁面中所有HTML元素。 |
| 206 | Partial Content | 成功執行一個部分或Range請求。客戶端可以在首部中指定請求某個範圍內的檔案。該狀態響應頭部必須包含Content-Range、Date、以及ETag或Content-Location。 |
300~399重定向狀態碼
已知狀態碼列表：
| Code | 原因短語 | 描述 |
|---|---|---|
| 300 | Multiple Choices | 客戶端請求實際指向多個資源的URL。客戶端可以在響應中找到資源列表。 |
| 301 | Moved Permanently | 請求的URL已被移除。響應的Location首部包含現在所處的位置。 |
| 302 | Found | 與301類似，客戶端本次應使用響應中的臨時URL，將來的請求任使用以前的URL。 |
| 303 | See Other | 告知客戶端使用另一個URL來獲取資源。其主要目的是，允許POST請求的響應將客戶端定向的某一個資源上去。 |
| 304 | Not Modified | 若客戶端發起一個有條件的GET請求，而資源未被修改，可以使用該狀態碼說明資源未被修改。 |
| 305 | Use Proxy | 必須通過代理來訪問這一資源，代理有Location首部給出。需要知道的是，客戶端接收到這一狀態時，不應該假定所有請求都經過代理。 |
| 306 | 未使用 | 暫未使用。 |
| 307 | Temporary Redirect | 和302相同。 |
對於302、303、307狀態碼的說明：從上面表格上看，這3個狀態碼出現交叉的情況；在HTTP/1.0，只有302，伺服器希望對POST請求響應302後，客戶端向從定向的URL傳送GET請求。303、307是在HTTP/1.1加入，303時，瀏覽器依然執行HTTP/1.0 302的動作；307，只是不會將原始的POST轉為GET，而是詢問使用者。這些都是規範說辭，但實際運用中不是這麼回事，你有看到大量的307？
400~499客戶端錯誤狀態碼
有時客戶端傳送伺服器無法處理的東西，會導致錯誤。 已知狀態碼列表：
| Code | 原因短語 | 描述 |
|---|---|---|
| 400 | Bad Request | 告知客戶端它傳送了一個錯誤的請求。 |
| 401 | Unauthorized | 與適當首部一同返回，告知客戶端在請求之前先進行認證。 |
| 402 | Payment Required | 保留未使用。 |
| 403 | Forbidden | 請求被拒絕。 |
| 404 | Not Found | 伺服器無法找到請求的URL。 |
| 405 | Method Not Allowed | 客戶端使用不支援的方法請求URL。應該在首部使用Allow告知客戶端正確的方法。 |
| 406 | Not Acceptable | 客戶端在使用指定引數說明其願意接收什麼型別的實體，但伺服器沒有與之對應的資源。 |
| 407 | Proxy Authentication Required | 代理伺服器要求客戶端驗證。 |
| 408 | Request Timeout | 客戶端完成請求時間過長，伺服器可以關閉連結。 |
| 409 | Conflict | 伺服器認為該請求可能引起衝突。響應主體中應包含衝突的主體的描述。 |
| 410 | Gone | 與404類似，只是伺服器曾經擁有此資源，後來被移除。 |
| 411 | Length Required | 伺服器要求請求報文中包含Content-Length首部。 |
| 412 | Precondition Failed | 客戶端發起條件請求，其中有條件失敗。 |
| 413 | Request Entity Too Large | 客戶端傳送的主體部分比伺服器能夠活希望處理的要大。 |
| 414 | Request URI Too Long | URL過長。 |
| 415 | Unsupported Media Type | 伺服器無法理解或無法支援客戶端傳送的內容型別。 |
| 416 | Requested Range Not Satisfiable | 請求範圍無效或無法滿足。 |
| 417 | Expectation Failed | 請求首部包含Expect期望，但伺服器無法滿足。 |
500~599伺服器錯誤狀態碼
客戶端傳送的是有效請求，伺服器自身出錯。下面是已知狀態碼列表：
| Code | 原因短語 | 描述 |
|---|---|---|
| 500 | Internal Server Error | 伺服器遇到一個妨礙它提供服務的錯誤。 |
| 501 | Not Implemented | 客戶端發起的請求超出伺服器能力範圍，如使用了不支援的方法。 |
| 502 | Bad Gateway | 無效閘道器。通常不是這上游伺服器關閉，而是使用了上游伺服器不同意協議交換資料。 |
| 503 | Service Unavailable | 伺服器暫時無法提供服務。若伺服器知道服務什麼時間可以使用，可以在響應頭中加入Retry-After首部說明。 |
| 504 | Gateway Timeout | 於408類似，只是這裡的響應來自一個閘道器或代理，它們在等待另一個伺服器響應對其請求響應時超時。 |
| 505 | HTTP Version Not Support | 伺服器收到的請求使用了它無法支援的協議版本。 |
首部
首部和方法的配合，共同決定了客戶端和伺服器能夠做什麼樣的事情。 首部的型別分為：
-
通用首部，請求報文和響應報文都可以使用。包括但不僅限於：
首部 描述 Connection 客戶端和伺服器指定連結有關選項 Date 日期時間標誌，說明報文是什麼時間建立的 MIME-Version 傳送端使用的MIME版本 Trailer 若報文采取分塊傳輸編碼方式，可以使用該首部列出位於報文拖掛部分的首部集合。 Transfer-Encoding 告知接收方為了保證報文的可靠傳輸，對報文采用了什麼編碼方式。 Update 傳送端可能想要升級使用的新版本或協議 Via 報文經過的中間節點 Cache-Control 快取指示 -
請求首部，只在請求報文中有意義，說明了客戶端的情況。包括但不僅限於：
首部 描述 Client-IP 客戶端IP地址 From 客戶端使用者E-mail地址 Host 接收請求的伺服器主機名和埠號 Referer 包含當前請求URI的文件的URL。就是說當前請求URL所在的那個頁面對應的URL。 User-Agent 發起請求的應用程式資訊 UA-Color、UA-CPU、UA-Disp、UA-OS、UA-Pixels 分別代表客戶端顯示器顏色資訊、CPU資訊、顯示器資訊、作業系統資訊、顯示器畫素資訊 Accept、Accept-Charset、Accept-Encoding、Accept-Language、TE 分別表示客戶端可接受的媒體型別、字符集、編碼方式、語言以及擴充套件編碼 Expect 允許客戶端列出要求伺服器的行為 If-Match 若實體標記與文件當前實體標記 匹配，就獲取這份文件If-None-Match 若實體標記與文件當前實體標記 不匹配，就獲取這份文件If-Modified-Since 除非在指定日期之後資源 被修改過，否則就限制這個請求If-Unmodified-Since 除非在指定日期之後資源 沒有被修改過，否則就限制這個請求If-Range 對文件某範圍進行條件請求 Range 請求指定範圍內的資源 Authorization 客戶端提供給伺服器以便進行認證的資料 Cookie 客戶端向伺服器傳送的令牌 Cookie2 說明客戶端支援的cookie版本 Max-Forward 和TRACE方法一同使用，控制請求轉發的最大次數 Proxy-Authorization 和代理進行認證是使用 Proxy-Connect 和代理建立連結時控制連結 -
響應首部 響應首部為客戶端提供了額外資訊，使得客戶端可以做出更好的響應。包括但不僅限於：
首部 描述 Age 從最初建立開始，響應持續時間 Public 伺服器為其資源支援的請求方法列表 Retry-After 若資源不可用，在此日期之後重試 Server 伺服器應用軟體資訊 Title HTML文件的標題 Warning 比原因短語更詳細的警告報文 Accept-Ranges 伺服器可以接收的範圍型別 Vary 快取資訊 Proxy-Authenticate 代理對客戶端的質詢列表 Set-Cookie 伺服器在客戶端設定的令牌 WWW-Authenticate 伺服器對客戶端的質詢列表 -
實體首部，描述實體相關資訊。包括但不僅限於：
首部 描述 Allow 對此實體支援的請求方法 Location 告知客戶端資源的實際位置 Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type 分別表示主體的基礎URL、編碼方式、使用語言、長度或尺寸、實際位置、MD5校驗和、在整個範圍中該實體的位元組範圍、物件型別 BTag 實體標記 Expires 實體不再有效 Last-Modified 最後一次被修改的日期
結語
該篇主要是擴大眼界，不必死記硬背。我們下篇見.祝大家有個開心的週末!
注
- 部分圖片來源於網路，如有侵權，請告知。
- 如有錯誤，還請指出。共勉！
- 您的喜歡是最大的讚賞。