HTTP及狀態碼彙總

時間 2019-11-12

標籤 http 狀態彙總欄目 HTTP/TCP 简体版

原文原文鏈接

什麼是HTTP：html

　　HTTP(HyperText Transfer Protocol超文本傳輸協議)是互聯網上應用最爲普遍的一種網絡協議。全部的WWW文件都必須遵照這個標準,爲了提供一種發佈和接收HTML頁面的方法。HTTP定義了信息如何被格式化、如何被傳輸，以及在各類命令下服務器和瀏覽器所採起的響應。web

　　HTTP是客戶端瀏覽器或其餘程序與Web服務器之間的應用層通訊協議。在Internet上的Web服務器上存放的都是超文本信息，客戶機須要經過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不只可用於Web訪問，也能夠用於其餘因特網/內聯網應用系統之間的通訊，從而實現各種應用資源超媒體訪問的集成。瀏覽器

　　關於HTTP協議的詳細內容請參考RFC2616。緩存

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操做稱爲一個事務，其工做過程可分爲四步：

　　　一、客戶端與服務器須要創建鏈接。（好比某個超級連接，HTTP就開始了。）
　　　　二、創建鏈接後，發送請求。
　　　　三、服務器接到請求後，響應其響應信息。
　　　　四、客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。

　　創建鏈接，其實創建在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-MD五、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 是必需的以外，其餘均可以不要。有關通用信息頭，請求頭和實體頭方面的具體內容能夠參照相關文件。

　　以下：

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

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

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

請求報文相關：

請求行-請求方法

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

響應報文相關：

響應行-狀態碼

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

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

1xx：指示信息–表示請求已接收，繼續處理
　　2xx：成功–表示請求已被成功接收、理解、接受
　　3xx：重定向–要完成請求必須進行更進一步的操做
　　4xx：客戶端錯誤–請求有語法錯誤或請求沒法實現
　　5xx：服務器端錯誤–服務器未能實現合法的請求

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

1、臨時響應

1xx(臨時響應)

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

　　100(繼續)請求者應當繼續提出請求。服務器返回此代碼表示已收到請求的第一部分，正在等待其他部分。

　　101(切換協議)請求者已要求服務器切換協議，服務器已確認並準備切換。只有在切換新的協議更有好處的時候才應該採起相似措施。

　　102 Processing由WebDAV（RFC 2518）擴展的狀態碼，表明處理將被繼續執行。

2、成功

2xx (成功)

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

　　200(成功)服務器已成功處理了請求。一般，這表示服務器提供了請求的網頁。若是是對您的 robots.txt 文件顯示此狀態碼，則表示 Googlebot 已成功檢索到該文件。

　　201(已建立)請求成功而且服務器建立了新的資源。

　　202(已接受)服務器已接受請求，但還沒有處理。

　　203(非受權信息)服務器已成功處理了請求，但返回的信息可能來自另外一來源。

　　204(無內容)服務器成功處理了請求，但沒有返回任何內容。

　　205(重置內容)服務器成功處理了請求，但沒有返回任何內容。與 204 響應不一樣，此響應要求請求者重置文檔視圖(例如，清除表單內容以輸入新內容)。

　　206(部份內容)服務器成功處理了部分 GET 請求。

3、重定向

3xx (重定向)

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

　　300(多種選擇)針對請求，服務器可執行多種操做。服務器可根據請求者 (user agent) 選擇一項操做，或提供操做列表供請求者選擇。

　　301(永久移動)請求的網頁已永久移動到新位置。服務器返回此響應(對 GET 或 HEAD 請求的響應)時，會自動將請求者轉到新位置。您應使用此代碼告訴某個網頁或網站已永久移動到新位置。

　　302(臨時移動)服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來響應之後的請求。此代碼與響應 GET 和 HEAD 請求的 301 代碼相似，會自動將請求者轉到不一樣的位置，但您不該使用此代碼來告訴某個網頁或網站已經移動，由於 Googlebot 會繼續抓取原有位置並編制索引。

　　303(查看其餘位置)請求者應當對不一樣的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。對於除 HEAD 以外的全部請求，服務器會自動轉到其餘位置。

　　304(未修改)自從上次請求後，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。

若是網頁自請求者上次請求後再也沒有更改過，您應將服務器配置爲返回此響應(稱爲 If-Modified-Since HTTP 標頭)。服務器能夠告訴 Googlebot 自從上次抓取後網頁沒有變動，進而節省帶寬和開銷。

　　305(使用代理)請求者只能使用代理訪問請求的網頁。若是服務器返回此響應，還表示請求者應使用代理。

　　307(臨時重定向)服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來響應之後的請求。此代碼與響應 GET 和 HEAD 請求的 301 代碼相似，會自動將請求者轉到不一樣的位置，但您不該使用此代碼來告訴 Googlebot 某個頁面或網站已經移動，由於 Googlebot 會繼續抓取原有位置並編制索引。

4、請求錯誤

4xx(請求錯誤)

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

　　400(錯誤請求)服務器不理解請求的語法。

　　401(未受權)請求要求身份驗證。對於登陸後請求的網頁，服務器可能返回此響應。

　　403(禁止)服務器拒絕請求。若是您在 Googlebot 嘗試抓取您網站上的有效網頁時看到此狀態碼(您能夠在 Google 網站管理員工具診斷下的網絡抓取頁面上看到此信息)，多是您的服務器或主機拒絕了 Googlebot 訪問。

　　404(未找到)服務器找不到請求的網頁。例如，對於服務器上不存在的網頁常常會返回此代碼。

若是您的網站上沒有 robots.txt 文件，而您在 Google 網站管理員工具"診斷"標籤的 robots.txt 頁上看到此狀態碼，則這是正確的狀態碼。可是，若是您有 robots.txt 文件而又看到此狀態碼，則說明您的 robots.txt 文件可能命名錯誤或位於錯誤的位置(該文件應當位於頂級域，名爲 robots.txt)。