什么是HTTP：
HTTP(HyperText Transfer Protocol超文本傳輸協議)是互聯網上應用最為廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標准,為了提供一種發布和接收HTML頁面的方法。HTTP定義了信息如何被格式化、如何被傳輸，以及在各種命令下服務器和瀏覽器所采取的響應。
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操作稱為一個事務，其工作過程可分為四步：
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 的第一行中，會返回一個”三位數字的狀態碼“和一個“狀態消息”。 ”三位數字的狀態碼“便於程序進行處理， “狀態消息”更便於人理解。
1xx：指示信息–表示請求已接收，繼續處理
2xx：成功–表示請求已被成功接收、理解、接受
3xx：重定向–要完成請求必須進行更進一步的操作
4xx：客戶端錯誤–請求有語法錯誤或請求無法實現
5xx：服務器端錯誤–服務器未能實現合法的請求
下面提供 HTTP 狀態碼的完整列表。
一、臨時響應
1xx(臨時響應)
表示臨時響應並需要請求者繼續執行操作的狀態碼。
100(繼續)請求者應當繼續提出請求。服務器返回此代碼表示已收到請求的第一部分，正在等待其余部分。
101(切換協議)請求者已要求服務器切換協議，服務器已確認並准備切換。只有在切換新的協議更有好處的時候才應該采取類似措施。
102 Processing由WebDAV（RFC 2518）擴展的狀態碼，代表處理將被繼續執行。
二、成功
2xx (成功)
表示成功處理了請求的狀態碼。
200(成功)服務器已成功處理了請求。通常，這表示服務器提供了請求的網頁。如果是對您的 robots.txt 文件顯示此狀態碼，則表示 Googlebot 已成功檢索到該文件。
201(已創建)請求成功並且服務器創建了新的資源。
202(已接受)服務器已接受請求，但尚未處理。
203(非授權信息)服務器已成功處理了請求，但返回的信息可能來自另一來源。
204(無內容)服務器成功處理了請求，但沒有返回任何內容。
205(重置內容)服務器成功處理了請求，但沒有返回任何內容。與 204 響應不同，此響應要求請求者重置文檔視圖(例如，清除表單內容以輸入新內容)。
206(部分內容)服務器成功處理了部分 GET 請求。
三、重定向
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 會繼續抓取原有位置並編制索引。
四、請求錯誤
4xx(請求錯誤)
這些狀態碼表示請求可能出錯，妨礙了服務器的處理。
400(錯誤請求)服務器不理解請求的語法。
401(未授權)請求要求身份驗證。對於登錄后請求的網頁，服務器可能返回此響應。
403(禁止)服務器拒絕請求。如果您在 Googlebot 嘗試抓取您網站上的有效網頁時看到此狀態碼(您可以在 Google 網站管理員工具診斷下的網絡抓取頁面上看到此信息)，可能是您的服務器或主機拒絕了 Googlebot 訪問。
404(未找到)服務器找不到請求的網頁。例如，對於服務器上不存在的網頁經常會返回此代碼。
如果您的網站上沒有 robots.txt 文件，而您在 Google 網站管理員工具"診斷"標簽的 robots.txt 頁上看到此狀態碼，則這是正確的狀態碼。但是，如果您有 robots.txt 文件而又看到此狀態碼，則說明您的 robots.txt 文件可能命名錯誤或位於錯誤的位置(該文件應當位於頂級域，名為 robots.txt)。
如果對於 Googlebot 抓取的網址看到此狀態碼(在"診斷"標簽的 HTTP 錯誤頁面上)，則表示 Googlebot 跟隨的可能是另一個頁面的無效鏈接(是舊鏈接或輸入有誤的鏈接)。
405(方法禁用)禁用請求中指定的方法。
406(不接受)無法使用請求的內容特性響應請求的網頁。
407(需要代理授權)此狀態碼與 401(未授權)類似，但指定請求者應當授權使用代理。如果服務器返回此響應，還表示請求者應當使用代理。
408(請求超時)服務器等候請求時發生超時。
409(沖突)服務器在完成請求時發生沖突。服務器必須在響應中包含有關沖突的信息。服務器在響應與前一個請求相沖突的 PUT 請求時可能會返回此代碼，以及兩個請求的差異列表。
410(已刪除)如果請求的資源已永久刪除，服務器就會返回此響應。該代碼與 404(未找到)代碼類似，但在資源以前存在而現在不存在的情況下，有時會用來替代404代碼。如果資源已永久移動，您應使用 301 指定資源的新位置。
411(需要有效長度)服務器不接受不含有效內容長度標頭字段的請求。
412(未滿足前提條件)服務器未滿足請求者在請求中設置的其中一個前提條件。
413(請求實體過大)服務器無法處理請求，因為請求實體過大，超出服務器的處理能力。
414(請求的 URI 過長)請求的 URI(通常為網址)過長，服務器無法處理。
415(不支持的媒體類型)請求的格式不受請求頁面的支持。
416(請求范圍不符合要求)如果頁面無法提供請求的范圍，則服務器會返回此狀態碼。
417(未滿足期望值)服務器未滿足"期望"請求標頭字段的要求。
五、服務器錯誤
5xx(服務器錯誤)
這些狀態碼表示服務器在處理請求時發生內部錯誤。這些錯誤可能是服務器本身的錯誤，而不是請求出錯。
500(服務器內部錯誤)服務器遇到錯誤，無法完成請求。
501(尚未實施)服務器不具備完成請求的功能。例如，服務器無法識別請求方法時可能會返回此代碼。
502(錯誤網關)服務器作為網關或代理，從上游服務器收到無效響應。
503(服務不可用)服務器目前無法使用(由於超載或停機維護)。通常，這只是暫時狀態。
504(網關超時)服務器作為網關或代理，但是沒有及時從上游服務器收到請求。
505(HTTP 版本不受支持)服務器不支持請求中所用的 HTTP 協議版本。
參考：