HTTP協議圖--HTTP 響應狀態代碼（重點分析）

標籤：作用   sam   enc   轉寄   重新導向   轉換   strip   auto   檔案   

1. 狀態代碼概述

• HTTP 狀態代碼負責表示用戶端 HTTP 要求的返回結果、標記伺服器端的處理是否正常、通知出現的錯誤等工作。
• HTTP 狀態代碼如 200 OK ，以 3 位元字和原因短語組成。數字中的第一位指定了響應類別，後兩位無分類。
• 不少返回的響應狀態代碼都是錯誤的，但是使用者可能察覺不到這點。比如 Web 應用程式內部發生錯誤，狀態代碼依然返回 200 OK。

2. 狀態代碼類別

	類別	原因短語
1xx	Informational(資訊性狀態代碼)	接收的請求正在處理
2xx	Success(成功狀態代碼)	請求正常處理完畢
3xx	Redirection(重新導向狀態代碼)	需要進行附加操作以完成請求
4xx	Client Error(用戶端錯誤狀態代碼)	伺服器無法處理請求
5xx	Server Error(伺服器錯誤狀態代碼)	伺服器處理請求出錯

我們可以自行改變 RFC2616 中定義的狀態代碼或者伺服器端自行建立狀態代碼，只要遵守狀態代碼的類別定義就可以了。

3. 常用狀態代碼解析

HTTP 狀態代碼種類繁多，數量達幾十種。其中最常用的有以下 14 種，一起來看看。

3.1 200 OK

表示從用戶端發來的請求在伺服器端被正常處理了。

3.2 204 No Content

• 代表格服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。另外，也不允許返回任何實體的主體。
• 一般在只需要從用戶端向伺服器端發送訊息，而伺服器端不需要向用戶端發送新訊息內容的情況下使用。

3.3 206 Partial Content

表示用戶端進行了範圍請求，而伺服器成功執行了這部分的 GET 請求。響應報文中包含由 Content-Range 首部欄位指定範圍的實體內容。

3.4 301 Moved Permanently

永久性重新導向。表示請求的資源已被分配了新的 URI。以後應使用資源現在所指的 URI。也就是說，如果已經把資源對應的 URI 儲存為書籤了，這時應該按 Location 首部欄位提示的 URI 重新儲存。

3.5 302 Found

• 臨時性重新導向。表示請求的資源已被分配了新的 URI，希望使用者（本次）能使用新的 URI 訪問。
• 和 301 Moved Permanently 狀態代碼相似，但 302 Found 狀態代碼代表資源不是被永久移動，只是臨時性質的。換句話說，已移動的資源對應的 URI 將來還有可能發生改變。

3.6 303 See Other

• 表示由於請求的資源存在著另一個 URI，應使用 GET 方法定向擷取請求的資源。
• 303 See Other 和 302 Found 狀態代碼有著相同的功能，但 303 See Other 狀態代碼明確表示用戶端應採用 GET 方法擷取資源，這點與 302 Found 狀態代碼有區別。

3.7 304 Not Modified

• 表示用戶端發送附帶條件的請求時，伺服器端允許請求訪問的資源，但未滿足條件的情況。
• 304 Not Modified 狀態代碼返回時，不包含任何響應的主體部分。
• 304 Not Modified 雖然被劃分到 3xx 類別中，但和重新導向沒有關係。

3.8 307 Temporary Redirect

臨時重新導向。該狀態代碼與 302 Found 有著相同的含義。

3.9 400 Bad Request

• 表示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。
• 另外，瀏覽器會像 200 OK 一樣對待該狀態代碼。

3.10 401 Unauthorized

• 表示發送的請求需要有通過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證資訊。
• 另外，若之前已進行過 1 次請求，則表示使用者認證失敗。
• 返回含有 401 Unauthorized 的響應必須包含一個適用於被請求資源的 WWW-Authenticate 首部用以質詢（challenge）使用者資訊。

3.11 403 Forbidden

表明對請求資源的訪問被伺服器拒絕了。伺服器端沒有必要給出詳細的拒絕理由，當然也可以在響應報文的實體主體部分對原因進行描述。

3.12 404 Not Found

表明伺服器上無法找到請求的資源。除此之外，也可以在伺服器端拒絕請求且不想說明理由的時候使用。

3.13 500 Internal Server Error

表明伺服器端在執行請求時發生了錯誤。也可能是 Web 應用程式存在的 bug 或某些臨時的故障。

3.14 503 Service Unavailable

表明伺服器暫時處於超負載或進行中停機維護，現在無法處理請求。如果事先得知解除以上狀況需要的時間，最好寫入 Retry-After 首部欄位再返回給用戶端。

八、HTTP 報文實體1. HTTP 報文實體概述 HTTP 報文結構

大家請仔細看看上面樣本中，各個組成部分對應的內容。
接著，我們來看看報文和實體的概念。如果把 HTTP 報文想象成網際網路貨運系統中的箱子，那麼 HTTP 實體就是報文中實際的貨物。

• 報文：是網路中交換和傳輸的資料單元，即網站一次性要發送的資料區塊。報文包含了將要發送的完整的資料資訊，其長短很不一致，長度不限且可變。
• 實體：作為請求或響應的有效載荷資料（補充項）被傳輸，其內容由實體首部和實體主體組成。（實體首部相關內容在上面第六點中已有闡述。）

我們可以看到，上面樣本右圖中深紅色框的內容就是報文的實體部分，而藍色框的兩部分內容分別就是實體首部和實體主體。而左圖中粉紅框內容就是報文主體。
通常，報文主體等於實體主體。只有當傳輸中進行編碼操作時，實體主體的內容發生變化，才導致它和報文主體產生差異。

2. 內容編碼

• HTTP 應用程式有時在發送之前需要對內容進行編碼。例如，在把很大的 HTML 文檔發送給通過慢速連線上來的用戶端之前，伺服器可能會對其進行壓縮，這樣有助於減少傳輸實體的時間。伺服器還可以把內容攪亂或加密，以此來防止未授權的第三方看到文檔的內容。
• 這種類型的編碼是在發送方應用到內容之上的。當內容經過內容編碼後，編好碼的資料就放在實體主體中，像往常一樣發送給接收方。

內容編碼類別型：

編碼方式	描述
gzip	表明實體採用 GNU zip 編碼
compress	表明實體採用 Unix 的檔案壓縮程式
deflate	表明實體採用 zlib 的格式壓縮的
identity	表明沒有對實體進行編碼，當沒有 Content-Encoding 首部欄位時，預設採用此編碼方式

3. 傳輸編碼

內容編碼是對報文的主體進行的可逆變換，是和內容的具體格式細節緊密相關的。
傳輸編碼也是作用在實體主體上的可逆變換，但使用它們是由於架構方面的原因，同內容的格式無關。使用傳輸編碼是為了改變報文中的資料在網路上傳輸的方式。

 

 內容編碼和傳輸編碼的對比4. 分塊編碼

分塊編碼把報文分割成若干已知大小的塊。塊之間是緊挨著發送的，這樣就不需要在發送之前知道整個報文的大小了。分塊編碼是一種傳輸編碼，是報文的屬性。

分塊編碼與持久串連
若用戶端與伺服器端之間不是持久串連，用戶端就不需要知道它在讀取的主體的長度，而只需要讀取到伺服器關閉主體串連為止。
當使用持久串連時，在伺服器寫主體之前，必須知道它的大小並在 Content-Length 首部中發送。如果伺服器動態建立內容，就可能在發送之前無法知道主體的長度。
分塊編碼為這種困難提供瞭解決方案，只要允許伺服器把主體分塊發送，說明每塊的大小就可以了。因為主體是動態建立的，伺服器可以緩衝它的一部分，發送其大小和相應的塊，然後在主體發送完之前重複這個過程。伺服器可以用大小為 0 的塊作為主體結束的訊號，這樣就可以繼續保持串連，為下一個響應做準備。
來看看一個分塊編碼的報文樣本：

 分塊編碼的報文

 

5.多部分媒體類型

MIME 中的 multipart（多部分）電子郵件報文中包含多個報文，它們合在一起作為單一的複雜報文發送。每一部分都是獨立的，有各自的描述其內容的集，不同部分之間用分界字串串連在一起。
相應得，HTTP 協議中也採納了多部分對象集合，發送的一份報文主體內可包含多種類型實體。
多部分對象集合包含的對象如下：

• multipart/form-data：在 Web 表單檔案上傳時使用。
• multipart/byteranges：狀態代碼 206 Partial Content 響應報文包含了多個範圍的內容時使用。

6. 範圍請求

假設你正在下載一個很大的檔案，已經下了四分之三，忽然網路中斷了，那下載就必須重頭再來一遍。為瞭解決這個問題，需要一種可恢複的機制，即能從之前下載中斷處恢複下載。要實現該功能，這就要用到範圍請求。
有了範圍請求， HTTP 用戶端可以通過請求曾擷取失敗的實體的一個範圍（或者說一部分），來恢複下載該實體。當然這有一個前提，那就是從用戶端上一次請求該實體到這一次發出範圍請求的時間段內，該對象沒有改變過。例如：

GET  /bigfile.html  HTTP/1.1Host: www.sample.comRange: bytes=20224-···

 實體範圍請求樣本

上面樣本中，用戶端請求的是文檔開頭20224位元組之後的部分。

九、與 HTTP 協作的 Web 服務器

HTTP 通訊時，除用戶端和伺服器外，還有一些用於協助通訊的應用程式。如下列出比較重要的幾個：代理、緩衝、網關、隧道、Agent 代理。

1.代理 代理

 

HTTP Proxy 伺服器是 Web 安全、應用整合以及效能最佳化的重要組成模組。代理位於用戶端和伺服器端之間，接收用戶端所有的 HTTP 要求，並將這些請求轉寄給伺服器（可能會對請求進行修改之後再進行轉寄）。對使用者來說，這些應用程式就是一個代理，代表使用者訪問伺服器。
出於安全考慮，通常會將代理作為轉寄所有 Web 流量的可信任中間節點使用。代理還可以對請求和響應進行過濾，安全上網或綠色上網。

2. 緩衝

瀏覽器第一次請求：

 瀏覽器第一次請求

 

瀏覽器再次請求：

 瀏覽器再次請求

 

Web 緩衝或代理緩衝是一種特殊的 HTTP Proxy 伺服器，可以將經過代理傳輸的常用文檔複製儲存起來。下一個請求同一文檔的用戶端就可以享受緩衝的私人副本所提供的服務了。用戶端從附近的緩衝下載文檔會比從遠程 Web 服務器下載快得多。

3. 網關 HTTP / FTP 網關

 

網關是一種特殊的伺服器，作為其他伺服器的中間實體使用。通常用於將 HTTP 流量轉換成其他的協議。網關接收請求時就好像自己是資源的原始伺服器一樣。用戶端可能並不知道自己正在跟一個網關進行通訊。

4. 隧道 HTTP/SSL 隧道

 

隧道是會在建立起來之後，就會在兩條串連之間對未經處理資料進行盲轉寄的 HTTP 應用程式。HTTP 隧道通常用來在一條或多條 HTTP 串連上轉寄非 HTTP 資料，轉寄時不會窺探資料。
HTTP 隧道的一種常見用途就是通過 HTTP 串連承載加密的安全通訊端層（SSL）流量，這樣 SSL 流量就可以穿過只允許 Web 流量通過的防火牆了。

5. Agent 代理 自動搜尋引擎“網路蜘蛛”

 

Agent 代理是代表使用者發起 HTTP 要求的用戶端應用程式。所有發布 Web 請求的應用程式都是 HTTP Agent 代理。

 

 

 

HTTP協議圖--HTTP 響應狀態代碼（重點分析）