HTTP原理及狀態碼彙總

HTTP協議的主要特點

　　1.支持客戶/服務器模式。
　　2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
　　3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
　　4.無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
　　5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

技術架構：

　　HTTP是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。通過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認端口爲80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（user agent）。應答的服務器上存儲着（一些）資源，比如HTML文件和圖像。（我們稱）這個應答服務器爲源服務器（origin server）。在用戶代理和源服務器中間可能存在多箇中間層，比如代理，網關，或者隧道（tunnels）。儘管TCP/IP協議是互聯網上最流行的應用，HTTP協議並沒有規定必須使用它和（基於）它支持的層。 事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。
　　通常，由HTTP客戶端發起一個請求，建立一個到服務器指定端口（默認是80端口）的TCP連接。HTTP服務器則在那個端口監聽客戶端發送過來的請求。一旦收到請求，服務器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（響應的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。HTTP使用TCP而不是UDP的原因在於（打開）一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。
　　通過HTTP或者HTTPS協議請求的資源由統一資源標示符（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。

工作流程：

　　既然HTTP是基於傳輸層的TCP協議，而TCP協議是面向連接的端到端的協議。因此，使用HTTP協議傳輸前，首先建立TCP連接，就是因此在談的TCP鏈接過程的“三次握手”。如圖

　　在Web上，HTTP協議使用TCP協議而不是UDP協議的原因在於一個網頁必須傳送很多數據，而且保證其完整性。TCP協議提供傳輸控制，按順序組織數據和錯誤糾正的一系列功能。

　　一次HTTP操作稱爲一個事務，其工作過程可分爲四步：

　　　   1、客戶端與服務器需要建立連接。（比如某個超級鏈接，HTTP就開始了。）
　　　　2、建立連接後，發送請求。
　　　　3、服務器接到請求後，響應其響應信息。
　　　　4、客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然後客戶機與服務器斷開連接。

 

　　建立連接，其實建立在TCP連接基礎之上。圖解核心工作過程（即省去連接過程）如下：

關於HTTP協議

　　HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URL、協議版本、以及包含請求修飾符、客戶信息和內容的類似於MIME的消息結構。服務器以一個狀態行作爲響應，響應的內容包括消息協議的版本，成功或者錯誤編碼加上包含服務器信息、實體元信息以及可能的實體內容。

　　通常HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。這兩種類型的消息由一個起始行，一個或者多個頭域，一個指示頭域結束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展爲多行，在每行開始處，使用至少一個空格或製表符。

通用頭域：

　　通用頭域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴展，如果存在不支持的通用頭域，一般將會作爲實體頭域處理。下面簡單介紹幾個在UPnP消息中使用的通用頭域：

1.Cache-Control頭域
　　Cache-Control指定請求和響應遵循的緩存機制。

2.Date頭域
　　Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。

3.Pragma頭域
　　Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。

請求消息

　　請求消息的第一行爲下面的格式：
　　MethodSPRequest-URISPHTTP-VersionCRLFMethod表示對於Request-URI完成的方法，這個字段是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。

1.Host頭域
　　Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。

2.Referer頭域
　　Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務器生成回退鏈表，可用來登陸、優化cache等。

3.Range頭域
　　Range頭域可以請求實體的一個或者多個子範圍。

4.User-Agent頭域
　　User-Agent頭域的內容包含發出請求的用戶信息。

響應消息

　　響應消息的第一行爲下面的格式：
　　HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
　　HTTP-Version表示支持的HTTP版本，例如爲HTTP/1.1。Status-Code是一個三個數字的結果代碼。Reason-Phrase給Status-Code提供一個簡單的文本描述。
　　Status-Code的第一個數字定義響應的類別，後兩個數字沒有分類的作用。第一個數字可能取5個不同的值：

　　　　1xx:信息響應類，表示接收到請求並且繼續處理
　　　　2xx:處理成功響應類，表示動作被成功接收、理解和接受
　　　　3xx:重定向響應類，爲了完成指定的動作，必須接受進一步處理
　　　　4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行
　　　　5xx:服務端錯誤，服務器不能正確執行一個正確的請求

1.Location響應頭
　　Location響應頭用於重定向接收者到一個新URI地址。

2.Server響應頭
　　Server響應頭包含處理請求的原始服務器的軟件信息。

實體信息

　　請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關於實體的原信息，實體頭包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允許客戶端定義新的實體頭，但是這些域可能無法被接受方識別。

1.Content-Type實體頭
　　Content-Type實體頭用於向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型

2.Content-Range實體頭

　　Content-Range實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。

3.Last-modified實體頭
　　Last-modified實體頭指定服務器上保存內容的最後修訂時間。

報文格式：

　　HTTP報文由從客戶機到服務器的請求和從服務器到客戶機的響應構成。請求報文格式如下：
　　　　請求行 － 通用信息頭 － 請求頭 － 實體頭 － 報文主體

　　請求行以方法字段開始，後面分別是 URL 字段和 HTTP 協議版本字段，並以 CRLF 結尾。SP 是分隔符。除了在最後的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關通用信息頭，請求頭和實體頭方面的具體內容可以參照相關文件。

　　如下：

　　

　　對於其中請求報文詳解:
　　　　1、請求行
　　　　方法字段 + URL + Http協議版本
　　　　2、通用信息頭
　　　　Cache-Control頭域：指定請求和響應遵循的緩存機制。
　　　　keep-alive 是其連接持續有效
　　　　3、請求頭
　　　　Host頭域
　　　　Referer頭域：允許客戶端指定請求URL的資源地址。
　　　　User-Agent頭域：請求用戶信息。【可以看出一些客戶端瀏覽器的內核信息】
　　　　4、報文主體

　　應答報文格式如下：
　　　　狀態行 － 通用信息頭 － 響應頭 － 實體頭 － 報文主體

　　狀態碼元由3位數字組成，表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述，狀態碼用來支持自動操作，而原因分析用來供用戶使用。客戶機無需用來檢查或顯示語法。有關通用信息頭，響應頭和實體頭方面的具體內容可以參照相關文件。

　　

請求報文相關：

請求行-請求方法

　　GET 請求獲取Request-URI所標識的資源
　　POST 在Request-URI所標識的資源後附加新的數據
　　HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭
　　PUT 請求服務器存儲一個資源，並用Request-URI作爲其標識
　　DELETE 請求服務器刪除Request-URI所標識的資源
　　TRACE 請求服務器回送收到的請求信息，主要用於測試或診斷
　　CONNECT 保留將來使用
　　OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求

響應報文相關：

響應行-狀態碼

HTTP狀態碼的作用是：web服務器用來告訴客戶端，發生了什麼事。

狀態碼位於HTTP Response 的第一行中，會返回一個”三位數字的狀態碼“和一個“狀態消息”。 ”三位數字的狀態碼“便於程序進行處理， “狀態消息”更便於人理解。

      HTTP狀態碼被分成了五類:
      100-199 用於指定客戶端應相應的某些動作。
      200-299 用於表示請求成功。
      300-399 用於已經移動的文件並且常被包含在定位頭信息中指定新的地址信息。
      400-499 用於指出客戶端的錯誤。
      500-599 用於支持服務器錯誤。

下面提供 HTTP 狀態碼的完整列表。

一、臨時響應

100-199(臨時響應)

表示臨時響應並需要請求者繼續執行操作的狀態碼。

狀態碼	原因短語	含義
100	繼續	說明收到了請求的初始部分，請客戶端繼續發送
101	切換協議

二、成功

200-299 (成功)

表示成功處理了請求的狀態碼。

狀態碼	原因短語	含義
200	成功	請求成功
201	已創建	用於創建服務器對象的請求（比如put）響應的實體主體部分中應該包含了各種引用了已創建的資源的URL。服務器必須在發送這個狀態碼之前創建好對象
202	已接受)	請求已被接收，但服務器還未對其執行任何動作。最終該請求可能會也可能不會被執行。在異步操作的場合下，沒有比發送這個狀態碼更方便的做法了。 返回202狀態碼的響應的目的是允許服務器接受其他過程的請求（例如某個每天只執行一次的基於批處理的操作），而不必讓客戶端一直保持與服務器的連接 直到批處理操作全部完成。
203	非授權信息	實體首部包含的信息不是來自於源端服務器，而是來自資源的一份副本。
204	無內容	響應報文中包含若干首部和一個狀態行，但沒有實體的主體部分
205	重置內容	負責告知瀏覽器清除當前頁面中所有的HTML表單元素
206	部分內容	服務器成功處理了部分 GET 請求。

三、重定向

300-399 (重定向)

要完成請求，需要進一步操作。通常，這些狀態碼用來重定向。Google 建議您在每次請求中使用重定向不要超過 5 次。您可以使用網站管理員工具查看一下 Googlebot 在抓取重定向網頁時是否遇到問題。診斷下的網絡抓取頁列出了由於重定向錯誤導致 Googlebot 無法抓取的網址。

狀態碼	原因短語	含義
300	多種選擇	客戶端請求一個實際指向多個資源的URL時會返回這個狀態碼，比如服務器上有某個HTML文檔的英語和法語版本。返回這個代碼時會帶有一個選項列表， 這樣用戶就可以選擇他希望使用的那一項。
301	永久移動	被請求的資源已永久移動到新位置，在請求的URL已被移除時使用。響應的location首部中應該包含資源現在所處的URL
302	臨時移動	請求的資源現在臨時從不同的 URI 響應請求。
303	查看其他位置	告知客戶端應該用另一個URL來獲取資源。新的URL位於響應報文的location首部。其主要目的是允許post請求的響應將客戶端定向到某個資源上去
304	未修改	如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則服務器應當返回這個狀態碼。
305	使用代理	用來說明必須使用一個代理來訪問資源，代理的位置由location首部給出。
307	臨時重定向	請求的資源現在臨時從不同的URI 響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以後的請求。 只有在Cache-Control或Expires中進行了指定的情況下，這個響應纔是可緩存的。

 

四、請求錯誤

400-499 (請求錯誤)

這些狀態碼錶示請求可能出錯，妨礙了服務器的處理。

狀態碼	原因短語	含義
400	錯誤請求	用於告知客戶端它發送了一個錯誤的請求
401	未授權	當前請求需要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端可以重複提交一個包含恰當的Authorization 頭信息的請求。如果當前請求已經包含了 Authorization 證書，那麼401響應代表着服務器驗證已經拒絕了那些證書。
403	禁止	服務器已經理解請求，但是拒絕執行它。如果服務器想說明拒絕原因，可以在包含實體的主體部分來對原因進行描述。但這個狀態碼通常在服務器不想說明拒絕原因時 使用
404	未找到	無法找到指定位置的資源。
405	方法禁用	請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用。
406	不接受	表示請求資源的MIME類型與客戶端中Accept頭信息中指定的類型不一致。
407	需要代理授權	此狀態碼與 401(未授權)類似，但指定請求者應當授權使用代理。如果服務器返回此響應，還表示請求者應當使用代理。
408	請求超時	請求超時

五、服務器錯誤

500-599(服務器錯誤)

這些狀態碼錶示服務器在處理請求時發生內部錯誤。這些錯誤可能是服務器本身的錯誤，而不是請求出錯。

狀態碼	原因短語	含義
500	服務器內部錯誤	服務器遇到一個妨礙它爲請求提供服務的錯誤時，使用此狀態碼。該狀態經常由CGI程序引起也可能（但願不會如此！）由無法正常運行的或返回頭信息格式 不正確的servlet引起。
501	尚未實施	客戶端使用了服務器未實現的請求方法
502	錯誤網關	服務器作爲網關或者代理時，爲了完成請求訪問下一個服務器，但該服務器返回了非法的應答。
503	服務不可用	用於說明服務器現在無法爲請求提供服務。但將來可以，服務器可提供一個Retry-After頭信息告訴客戶端什麼時候資源可用。
504	網關超時	該狀態也用於充當代理或網關的服務器；它指出接收服務器沒有從遠端服務器得到及時的響應。
505	HTTP 版本不受支持	服務器不支持在請求中所標明 HTTP 版本。

參考：

圖解 HTTP 協議

HTTP協議詳解

HTTP狀態碼作用