深入理解HTTP协议、HTTP协议原理分析
技術架構
HTTP是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。通過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認端口為80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（user agent）。應答的服務器上存儲著（一些）資源，比如HTML文件和圖像。（我們稱）這個應答服務器為源服務器（origin server）。在用戶代理和源服務器中間可能存在 http和其他幾種網絡協議 多個中間層，比如代理，網關，或者隧道（tunnels）。盡管TCP/IP協議是互聯網上最流行的應用，HTTP協議并沒有規定必須使用它和（基于）它支持的層。 事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。 通常，由HTTP客戶端發起一個請求，建立一個到服務器指定端口（默認是80端口）的TCP連接。HTTP服務器則在那個端口監聽客戶端發送過來的請求。一旦收到請求，服務器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（響應的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。 HTTP協議的網頁 HTTP使用TCP而不是UDP的原因在于（打開）一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。 通過HTTP或者HTTPS協議請求的資源由統一資源標示符（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。協議功能
HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先于圖形)等。 HTTP是客戶端瀏覽器或其他程序與Web服務器之間的應用層通信協議。在Internet上的Web服務器上存放的都是超文本信息，客戶機需要通過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不僅可用于Web訪問，也可以用于其他因特網/內聯網應用系統之間的通信，從而實現各類應用資源超媒體訪問的集成。 我們在瀏覽器的地址欄里輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位符)。就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在 http功用 瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，并翻譯成漂亮的網頁。協議基礎
HTTP（HyperText Transport Protocol）是超文本傳輸協議的縮寫，它用于傳送WWW方式的數據，關于HTTP協議的詳細內容請參考RFC2616。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URL、協議版本、以及包含請求修飾符、客戶信息和內容的類似于MIME的消息結構。服務器以一個狀態行作為響應，響應的內容包括消息協議的版本，成功或者錯誤編碼加上包含服務器信息、實體元信息以及可能的實體內容。 通常HTTP消息包括客戶機向服務器的請求消息和服務器向客戶機的響應消息。這兩種類型的消息由一個起始行，一個或者多個頭域，一個指示頭域結束的空行和可選的消息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或制表符。通用頭域
通用頭域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴展，如果存在不支持的通用頭域，一般將會作為實體頭域處理。下面簡單介紹幾個在UPnP消息中使用的通用頭域： 1.Cache-Control頭域 Cache-Control指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置Cache-Control并不會修改另一個消息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各個消息中的指令含義如下： Public指示響應可被任何緩存區緩存。 Private指示對于單個用戶的整個或部分響應消息，不能被共享緩存處理。這允許服務器僅僅描述當用戶 http結構 的部分響應消息，此響應消息對于其他用戶的請求無效。 no-cache指示請求或響應消息不能緩存 no-store用于防止重要的信息被無意的發布。在請求消息中發送將使得請求和響應消息都不使用緩存。 max-age指示客戶機可以接收生存期不大于指定時間（以秒為單位）的響應。 min-fresh指示客戶機可以接收響應時間小于當前時間加上指定時間的響應。 max-stale指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那么客戶機可以接收超出超時期指定值之內的響應消息。 HTTP Keep-Alive Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上的大部分Web服務器，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。對于提供靜態內容的網站來說，這個功能通常很有用。但是，對于負擔較重的網站來說，這里存在另外一個問題：雖然為客戶保留打開的連接有一定的好處，但它同樣影響了性能，因為在處理暫停期間，本來可以釋放的資源仍舊被占用。當Web服務器和應用服務器在同一臺機器上運行時，Keep- Alive功能對資源利用的影響尤其突出。 KeepAliveTime 值控制 TCP/IP 嘗試驗證空閑連接是否完好的頻率。如果這段時間內沒有活動，則會發送保持活動信號。如果網絡工作正常，而且接收方是活動的，它就會響應。如果需要對丟失接收方敏感，換句話說，需要更快地發現丟失了接收方，請考慮減小這個值。如果長期不活動的空閑連接出現次數較多，而丟失接收方的情況出現較少，您可能會要提高該值以減少開銷。缺省情況下，如果空閑連接 7200000 毫秒（2 小時）內沒有活動，Windows 就發送保持活動的消息。通常，1800000 毫秒是首選值，從而一半的已關閉連接會在 30 分鐘內被檢測到。 KeepAliveInterval 值定義了如果未從接收方收到保持活動消息的響應，TCP/IP 重復發送保持活動信號的頻率。當連續發送保持活動信號、但未收到響應的次數超出 TcpMaxDataRetransmissions 的值時，會放棄該連接。如果期望較長的響應時間，您可能需要提高該值以減少開銷。如果需要減少花在驗證接收方是否已丟失上的時間，請考慮減小該值或 TcpMaxDataRetransmissions 值。缺省情況下，在未收到響應而重新發送保持活動的消息之前，Windows 會等待 1000 毫秒（1 秒）。 KeepAliveTime 根據你的需要設置就行，比如10分鐘，注意要轉換成MS。 XXX代表這個間隔值得大小。 2.Date頭域 Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區。 3.Pragma頭域 Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache-Control:no-cache相同。請求消息
請求消息的第一行為下面的格式： MethodSPRequest-URISPHTTP-VersionCRLFMethod表示對于Request-URI完成的方法，這個字段是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD應該被所有的通用WEB服務器支持，其他所有方法的實現是可選的。GET方法取回由Request-URI標識的信息。HEAD方法也是取回由Request-URI標識的信息，只是可以在響應時，不返回消息體。POST方法可以請求服務器接收包含在請求中的實體信息，可以用于提交表單，向新聞組、BBS、郵件群組和數據庫發送消息。 SP表示空格。Request-URI遵循URI格式，在此字段為星號（*）時，說明請求并不用于某個特定的資源地址，而是用于服務器本身。HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。CRLF表示換行回車符。請求頭域允許客戶端向服務器傳遞關于請求或者關于客戶機的附加信 http架構 息。請求頭域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴展要求通訊雙方都支持，如果存在不支持的請求頭域，一般將會作為實體頭域處理。 典型的請求消息： Host: download.*******.de Accept: */* Pragma: no-cache Cache-Control: no-cache User-Agent: Mozilla/4.04[en](Win95;I;Nav) Range: bytes=554554- 上例第一行表示HTTP客戶端（可能是瀏覽器、下載程序）通過GET方法獲得指定URL下的文件。棕色的部分表示請求頭域的信息，綠色的部分表示通用頭部分。 1.Host頭域 Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。 2.Referer頭域 Referer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務器生成回退鏈表，可用來登陸、優化cache等。他也允許廢除的或錯誤的連接由于維護的目的被追蹤。如果請求的uri沒有自己的uri地址，Referer不能被發送。如果指定的是部分uri地址，則此地址應該是一個相對地址。 3.Range頭域 Range頭域可以請求實體的一個或者多個子范圍。例如， 表示頭500個字節：bytes=0-499 表示第二個500字節：bytes=500-999 表示最后500個字節：bytes=-500 表示500字節以后的范圍：bytes=500- 第一個和最后一個字節：bytes=0-0,-1 同時指定幾個范圍：bytes=500-600,601-999 但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206（PartialContent）返回而不是以200（OK）。 4.User-Agent頭域 User-Agent頭域的內容包含發出請求的用戶信息。響應消息
響應消息的第一行為下面的格式： HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF HTTP-Version表示支持的HTTP版本，例如為HTTP/1.1。Status-Code是一個三個數字的結果代碼。Reason-Phrase給Status-Code提供一個簡單的文本描述。Status-Code主要用于機器自動識別，Reason-Phrase主要用于幫助用戶理解。Status-Code的第一個數字定義響應的類別，后兩個數字沒有分類的作用。第一個數字可能取5個不同的值： 1xx:信息響應類，表示接收到請求并且繼續處理 2xx:處理成功響應類，表示動作被成功接收、理解和接受 3xx:重定向響應類，為了完成指定的動作，必須接受進一步處理 4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行 5xx:服務端錯誤，服務器不能正確執行一個正確的請求 響應頭域允許服務器傳遞不能放在狀態行的附加信息，這些域主要描述服務器的信息和Request-URI進一步的信息。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通訊雙方都支持，如果存在不支持的響應頭域，一般將會作為實體頭域處理。 典型的響應消息： HTTP/1.0200OK Date:Mon,31Dec200104:25:57GMT Server:Apache/1.3.14(Unix) Content-type:text/html Last-modified:Tue,17Apr200106:46:28GMT Etag:"a030f020ac7c01:1e9f" Content-length:39725426 Content-range:bytes55******/40279980 上例第一行表示HTTP服務端響應一個GET方法。棕色的部分表示響應頭域的信息，綠色的部分表示通用頭部分，紅色的部分表示實體頭域的信息。 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允許客戶端定義新的實體頭，但是這些域可能無法被接受方識別。實體可以是一個經過編碼的字節流，它的編碼方式由Content-Encoding或Content-Type定義，它的長度由Content-Length或Content-Range定義。 1.Content-Type實體頭 Content-Type實體頭用于向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型 2.Content-Range實體頭 Content-Range實體頭用于指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的范圍和整個實體長度。一般格式： Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth 例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對范圍請求的響應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍，Content-Length表示實際傳送的字節數。 3.Last-modified實體頭 Last-modified實體頭指定服務器上保存內容的最后修訂時間。 例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234如果一個http消息包含此節（例如，對范圍請求的響應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍，Content-Length表示實際傳送的字節數。運作方式
在WWW中，“客戶”與“服務器”是一個相對的概念，只存在于一個特定的連接期間，即在某個連接中的客戶在另一個連接中可能作為服務器。基于HTTP協議的客戶/服務器模式的信息交換過程，它分四個過程：建立連接、發送請求信息、發送響應信息、關閉連接。 HTTP協議是基于請求/響應范式的。一個客戶機與服務器建立連接后，發送一個請求給服務器，請求方式的格式為，統一資源標識符、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。服務器接到請求后，給予相應的響應信息，其格式為一個狀態行包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。 http運作方式的一種 其實簡單說就是任何服務器除了包括HTML文件以外，還有一個HTTP駐留程序，用于響應用戶請求。你的瀏覽器是HTTP客戶，向服務器發送請求，當瀏覽器中輸入了一個開始文件或點擊了一個超級鏈接時，瀏覽器就向服務器發送了HTTP請求，此請求被送往由IP地址指定的URL。駐留程序接收到請求，在進行必要的操作后回送所要求的文件。在這一過程中，在網絡上發送和接收的數據已經被分成一個或多個數據包（packet），每個數據包包括：要傳送的數據；控制信息，即告訴網絡怎樣處理數據包。TCP/IP決定了每個數據包的格式。如果事先不告訴你，你可能不會知道信息被分成用于傳輸和再重新組合起來的許多小塊。 許多HTTP通訊是由一個用戶代理初始化的并且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理(UA)和源服務器(O)之間通過一個單獨的連接來完成。 當一個或多個中介出現在請求/響應鏈中時，情況就變得復雜一些。中介有三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)。一個代理根據URI的絕對格式來接受請求，重寫全部或部分消息，通過URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，作為一些其它服務器的上層，并且如果必須的話，可以把請求翻譯給下層的服務器協議。一個通道作為不改變消息的兩個連接之間的中繼點。當通訊需要通過一個中介(例如：防火墻等)或者是中介不能識別消息的內容時，通道經常被使用。報文格式
HTTP報文由從客戶機到服務器的請求和從服務器到客戶機的響應構成。請求報文格式如下： 請求行 － 通用信息頭 － 請求頭 － 實體頭 － 報文主體 請求行以方法字段開始，后面分別是 URL 字段和 HTTP 協議版本字段，并以 CRLF 結尾。SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有關通用信息頭，請求頭和實體頭方面的具體內容可以參照相關文件。 應答報文格式如下： 狀態行 － 通用信息頭 － 響應頭 － 實體頭 － 報文主體 狀態碼元由3位數字組成，表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述，狀態碼用來支持自動操作，而原因分析用來供用戶使用。客戶機無需用來檢查或顯示語法。有關通用信息頭，響應頭和實體頭方面的具體內容可以參照相關文件。工作原理
一次HTTP操作稱為一個事務，其工作過程可分為四步： 首先客戶機與服務器需要建立連接。只要單擊某個超級鏈接，HTTP的工作就開始了。 建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。 服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。 客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上，然后客 http工作流程圖 戶機與服務器斷開連接。 如果在以上過程中的某一步出現錯誤，那么產生錯誤的信息將返回到客戶端，由顯示屏輸出。對于用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。 許多HTTP通訊是由一個用戶代理初始化的并且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理和服務器之間通過一個單獨的連接來完成。在Internet上，HTTP通訊通常發生在TCP/IP連接之上。缺省端口是TCP 80，但其它的端口也是可用的。但這并不預示著HTTP協議在Internet或其它網絡的其它協議之上才能完成。HTTP只預示著一個可靠的傳輸。 這個過程就好像我們打電話訂貨一樣，我們可以打電話給商家，告訴他我們需要什么規格的商品，然后商家再告訴我們什么商品有貨，什么商品缺貨。這些，我們是通過電話線用電話聯系（HTTP是通過TCP/IP），當然我們也可以通過傳真，只要商家那邊也有傳真。狀態消息
| 100 Continue | 服務器僅接收到部分請求，但是一旦服務器并沒有拒絕該請求，客戶端應該繼續發送其余的請求。 |
| 101 Switching Protocols | 服務器轉換協議：服務器將遵從客戶的請求轉換到另外一種協議。 |
| 200 OK | 請求成功（其后是對GET和POST請求的應答文檔。） |
| 201 Created | 請求被創建完成，同時新的資源被創建。 |
| 202 Accepted | 供處理的請求已被接受，但是處理未完成。 |
| 203 Non-authoritative Information | 文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝。 |
| 204 No Content | 沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。 |
| 205 Reset Content | 沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。 |
| 206 Partial Content | 客戶發送了一個帶有Range頭的GET請求，服務器完成了它。 |
| 300 Multiple Choices | 多重選擇。鏈接列表。用戶可以選擇某鏈接到達目的地。最多允許五個地址。 |
| 301 Moved Permanently | 所請求的頁面已經轉移至新的url。 |
| 302 Found | 所請求的頁面已經臨時轉移至新的url。 |
| 303 See Other | 所請求的頁面可在別的url下被找到。 |
| 304 Not Modified | 未按預期修改文檔。客戶端有緩沖的文檔并發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩沖的文檔還可以繼續使用。 |
| 305 Use Proxy | 客戶請求的文檔應該通過Location頭所指明的代理服務器提取。 |
| 306?Unused | 此代碼被用于前一版本。目前已不再使用，但是代碼依然被保留。 |
| 307 Temporary Redirect | 被請求的頁面已經臨時移至新的url。 |
| 400 Bad Request | 服務器未能理解請求。 |
| 401 Unauthorized | 被請求的頁面需要用戶名和密碼。 |
| 401.1 | 登錄失敗。 |
| 401.2 | 服務器配置導致登錄失敗。 |
| 401.3 | 由于 ACL 對資源的限制而未獲得授權。 |
| 401.4 | 篩選器授權失敗。 |
| 401.5 | ISAPI/CGI 應用程序授權失敗。 |
| 401.7 | 訪問被 Web 服務器上的 URL 授權策略拒絕。這個錯誤代碼為 IIS 6.0 所專用。 |
| 402 Payment Required | 此代碼尚無法使用。 |
| 403 Forbidden | 對被請求頁面的訪問被禁止。 |
| 403.1 | 執行訪問被禁止。 |
| 403.2 | 讀訪問被禁止。 |
| 403.3 | 寫訪問被禁止。 |
| 403.4 | 要求 SSL。 |
| 403.5 | 要求 SSL 128。 |
| 403.6 | IP 地址被拒絕。 |
| 403.7 | 要求客戶端證書。 |
| 403.8 | 站點訪問被拒絕。 |
| 403.9 | 用戶數過多。 |
| 403.10 | 配置無效。 |
| 403.11 | 密碼更改。 |
| 403.12 | 拒絕訪問映射表。 |
| 403.13 | 客戶端證書被吊銷。 |
| 403.14 | 拒絕目錄列表。 |
| 403.15 | 超出客戶端訪問許可。 |
| 403.16 | 客戶端證書不受信任或無效。 |
| 403.17 | 客戶端證書已過期或尚未生效。 |
| 403.18 | 在當前的應用程序池中不能執行所請求的 URL。這個錯誤代碼為 IIS 6.0 所專用。 |
| 403.19 | 不能為這個應用程序池中的客戶端執行 CGI。這個錯誤代碼為 IIS 6.0 所專用。 |
| 403.20 | Passport 登錄失敗。這個錯誤代碼為 IIS 6.0 所專用。 |
| 404 Not Found | 服務器無法找到被請求的頁面。 |
| 404.0 | （無）–沒有找到文件或目錄。 |
| 404.1 | 無法在所請求的端口上訪問 Web 站點。 |
| 404.2 | Web 服務擴展鎖定策略阻止本請求。 |
| 404.3 | MIME 映射策略阻止本請求。 |
| 405 Method Not Allowed | 請求中指定的方法不被允許。 |
| 406 Not Acceptable | 服務器生成的響應無法被客戶端所接受。 |
| 407 Proxy Authentication Required | 用戶必須首先使用代理服務器進行驗證，這樣請求才會被處理。 |
| 408 Request Timeout | 請求超出了服務器的等待時間。 |
| 409 Conflict | 由于沖突，請求無法被完成。 |
| 410 Gone | 被請求的頁面不可用。 |
| 411 Length Required | "Content-Length" 未被定義。如果無此內容，服務器不會接受請求。 |
| 412 Precondition Failed | 請求中的前提條件被服務器評估為失敗。 |
| 413 Request Entity Too Large | 由于所請求的實體的太大，服務器不會接受請求。 |
| 414 Request-url Too Long | 由于url太長，服務器不會接受請求。當post請求被轉換為帶有很長的查詢信息的get請求時，就會發生這種情況。 |
| 415 Unsupported Media Type | 由于媒介類型不被支持，服務器不會接受請求。 |
| 416 Requested Range Not Satisfiable | 服務器不能滿足客戶在請求中指定的Range頭。 |
| 417 Expectation Failed | 執行失敗。 |
| 423 | 鎖定的錯誤。 |
| 500 Internal Server Error | 請求未完成。服務器遇到不可預知的情況。 |
| 500.12 | 應用程序正忙于在 Web 服務器上重新啟動。 |
| 500.13 | Web 服務器太忙。 |
| 500.15 | 不允許直接請求 Global.asa。 |
| 500.16 | UNC 授權憑據不正確。這個錯誤代碼為 IIS 6.0 所專用。 |
| 500.18 | URL 授權存儲不能打開。這個錯誤代碼為 IIS 6.0 所專用。 |
| 500.100 | 內部 ASP 錯誤。 |
| 501 Not Implemented | 請求未完成。服務器不支持所請求的功能。 |
| 502 Bad Gateway | 請求未完成。服務器從上游服務器收到一個無效的響應。 |
| 502.1 | CGI 應用程序超時。 · |
| 502.2 | CGI 應用程序出錯。 |
| 503 Service Unavailable | 請求未完成。服務器臨時過載或當機。 |
| 504 Gateway Timeout | 網關超時。 |
| 505 HTTP Version Not Supported | 服務器不支持請求中指明的HTTP協議版本。 |
版本歷史
超文本傳輸協議已經演化出了很多版本，它們中的大部分都是向下兼容的。在RFC 2145中描述了HTTP 配置http通行證 版本號的用法。客戶端在請求的開始告訴服務器它采用的協議版本號，而后者則在響應中采用相同或者更早的協議版本。 0.9 已過時。只接受 GET 一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由于該版本不支持 POST 方法，所以客戶端無法向服務器傳遞太多信息。 HTTP/1.0 這是第一個在通訊中指定版本號的HTTP 協議版本，至今仍被廣泛采用，特別是在代理服務器中。 HTTP/1.1 當前版本。持久連接被默認采用，并能很好地配合代理服務器工作。還支持以管道方式同時發送多個請求，以便降低線路負載，提高傳輸速度。 HTTP/1.1相較于 HTTP/1.0 協議的區別主要體現在： 1 緩存處理 2 帶寬優化及網絡連接的使用 3 錯誤通知的管理 4 消息在網絡中的發送 5 互聯網地址的維護 6 安全性及完整性2.6?請求頭
HTTP最常見的請求頭如下：
l?????????Accept：瀏覽器可接受的MIME類型；
l?????????Accept-Charset：瀏覽器可接受的字符集；
l?????????Accept-Encoding：瀏覽器能夠進行解碼的數據編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間；
l?????????Accept-Language：瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時要用到；
l?????????Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中；
l?????????Connection：表示是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然后在正式寫出內容之前計算它的大小；
l?????????Content-Length：表示請求消息正文的長度；
l?????????Cookie：這是最重要的請求頭信息之一；
l?????????From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它；
l?????????Host：初始URL中的主機和端口；
l?????????If-Modified-Since：只有當所請求的內容在指定的日期之后又經過修改才返回它，否則返回304“Not Modified”應答；
l?????????Pragma：指定“no-cache”值表示服務器必須返回一個刷新后的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝；
l?????????Referer：包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。
l?????????User-Agent：瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用；
l?????????UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。
2.7?響應頭
HTTP最常見的響應頭如下所示：
l?????????Allow：服務器支持哪些請求方法（如GET、POST等）；
l?????????Content-Encoding：文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面；
l?????????Content-Length：表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發送內容；
l?????????Content-Type：?表示后面的文檔屬于什么MIME類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由于經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。?可在web.xml文件中配置擴展名和MIME類型的對應關系；
l?????????Date：當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩；
l?????????Expires：指明應該在什么時候認為文檔已經過期，從而不再緩存它。
l?????????Last-Modified：文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置；
l?????????Location：表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302；
l?????????Refresh：表示瀏覽器應該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設置HTML頁面HEAD區的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">實現，這是因為，自動刷新或重定向對于那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設置Refresh頭更加方便。注意Refresh的意義是“N秒之后刷新本頁面或訪問指定頁面”，而不是“每隔N秒刷新本頁面或訪問指定頁面”。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷新，不管是使用Refresh頭還是<META HTTP-EQUIV="Refresh" ...>。注意Refresh頭不屬于HTTP 1.1正式規范的一部分，而是一個擴展，但Netscape和IE都支持它。
2.8實體頭
實體頭用坐實體內容的元信息，描述了實體內容的屬性，包括實體信息類型，長度，壓縮方法，最后一次修改時間，數據有效性等。
l?????????Allow：GET,POST
l?????????Content-Encoding：文檔的編碼（Encode）方法，例如：gzip，見“2.5?響應頭”；
l?????????Content-Language：內容的語言類型，例如：zh-cn；
l?????????Content-Length：表示內容長度，eg：80，可參考“2.5響應頭”；
l?????????Content-Location：表示客戶應當到哪里去提取文檔，例如：http://www.dfdf.org/dfdf.html，可參考“2.5響應頭”；
l?????????Content-MD5：MD5?實體的一種MD5摘要，用作校驗和。發送方和接受方都計算MD5摘要，接受方將其計算的值與此頭標中傳遞的值進行比較。Eg1：Content-MD5: <base64 of 128 MD5 digest>。Eg2：dfdfdfdfdfdfdff==；
l?????????Content-Range：隨部分實體一同發送；標明被插入字節的低位與高位字節偏移，也標明此實體的總長度。Eg1：Content-Range: 1001-2000/5000，eg2：bytes 2543-4532/7898
l?????????Content-Type：標明發送或者接收的實體的MIME類型。Eg：text/html; charset=GB2312???????主類型/子類型；
l?????????Expires：為0證明不緩存；
l?????????Last-Modified：WEB?服務器認為對象的最后修改時間，比如文件的最后修改時間，動態頁面的最后產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT.
2.8擴展頭
在HTTP消息中，也可以使用一些再HTTP1.1正式規范里沒有定義的頭字段，這些頭字段統稱為自定義的HTTP頭或者擴展頭，他們通常被當作是一種實體頭處理。
現在流行的瀏覽器實際上都支持Cookie,Set-Cookie,Refresh和Content-Disposition等幾個常用的擴展頭字段。
l?????????Refresh：1;url=http://www.dfdf.org? //過1秒跳轉到指定位置；
l?????????Content-Disposition：頭字段,可參考“2.5響應頭”；
l?????????Content-Type：WEB?服務器告訴瀏覽器自己響應的對象的類型。
eg1：Content-Type：application/xml?；
eg2：applicaiton/octet-stream；
Cookie和Session
Cookie和Session都為了用來保存狀態信息，都是保存客戶端狀態的機制，它們都是為了解決HTTP無狀態的問題而所做的努力。
Session可以用Cookie來實現，也可以用URL回寫的機制來實現。用Cookie來實現的Session可以認為是對Cookie更高級的應用。
3.1.1兩者比較
Cookie和Session有以下明顯的不同點：
1）Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；
2）Cookies是服務器在本地機器上存儲的小段文本并隨每一個請求發送至同一個服務器。Cookie最早在RFC2109中實現，后續RFC2965做了增強。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies并將它們保存為一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies。Session并沒有在HTTP的協議中定義；
3）Session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置為由get來返回給服務器；
4）就安全性來說：當你訪問一個使用session?的站點，同時在自己機子上建立一個cookie，建議在服務器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的信息。
3.1.2?Session機制
Session機制是一種服務器端的機制，服務器使用一種類似于散列表的結構（也可能就是使用散列表）來保存信息。
當程序需要為某個客戶端的請求創建一個session的時候，服務器首先檢查這個客戶端的請求里是否已包含了一個session標識?-?稱為?session?id，如果已包含一個session?id則說明以前已經為此客戶端創建過session，服務器就按照session?id把這個?session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session?id，則為此客戶端創建一個session并且生成一個與此session相關聯的session?id，session?id的值應該是一個既不會重復，又不容易被找到規律以仿造的字符串，這個?session?id將被在本次響應中返回給客戶端保存。
3.1.6?Session的實現方式
3.1.6.1 ?使用Cookie來實現
服務器給每個Session分配一個唯一的JSESSIONID，并通過Cookie發送給客戶端。
當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器能夠找到這個客戶端對應的Session。
流程如下圖所示：
????
3.1.6.2 ?使用URL回顯來實現
URL回寫是指服務器在發送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務器。
如果直接在瀏覽器輸入服務端資源的url來請求該資源，那么Session是匹配不到的。
Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，如果發現客戶端支持Cookie，就繼續使用Cookie，停止使用URL回寫。如果發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的鏈接記得使用response.encodeURL()?。
3.1.3在J2EE項目中Session失效的幾種情況
1）Session超時：Session在指定時間內失效，例如30分鐘，若在30分鐘內沒有操作，則Session會失效，例如在web.xml中進行了如下設置：
<session-config>?
? ?? ???<session-timeout>30</session-timeout> //單位：分鐘
? ? </session-config>
2）使用session.invalidate()明確的去掉Session。
3.1.4與Cookie相關的HTTP擴展頭
1）Cookie：客戶端將服務器設置的Cookie返回到服務器；
2）Set-Cookie：服務器向客戶端設置Cookie；
3）Cookie2?(RFC2965)）：客戶端指示服務器支持Cookie的版本；
4）Set-Cookie2?(RFC2965)：服務器向客戶端設置Cookie。
Cookie的流程
服務器在響應消息中用Set-Cookie頭將Cookie的內容回送給客戶端，客戶端在新的請求中將相同的內容攜帶在Cookie頭中發送給服務器。從而實現會話的保持。
???????
GET和POST
???????常用的請求方式是GET和POST.
l?????????GET方式：是以實體的方式得到由請求URI所指定資源的信息，如果請求URI只是一個數據產生過程，那么最終要在響應實體中返回的是處理過程的結果所指向的資源，而不是處理過程的描述。
l?????????POST方式：用來向目的服務器發出請求，要求它接受被附在請求后的實體，并把它當作請求隊列中請求URI所指定資源的附加新子項，Post被設計成用統一的方法實現下列功能：
1：對現有資源的解釋；
2：向電子公告欄、新聞組、郵件列表或類似討論組發信息；
3：提交數據塊；
4：通過附加操作來擴展數據庫?。
從上面描述可以看出，Get是向服務器發索取數據的一種請求；而Post是向服務器提交數據的一種請求，要提交的數據位于信息頭后面的實體中。
GET與POST方法有以下區別：
（1）???在客戶端，Get方式在通過URL提交數據，數據在URL中可以看到,請求的數據會附在URL之后(就是把數據放置在HTTP協議頭中)，以?分割URL和傳輸數據，多個參數用&連接。如果數據是英文字母/數字，原樣發送，如果是空格，轉換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：?%E4%BD%A0%E5%A5%BD，其中%XX中的XX為該符號以16進制表示的ASCII。；POST方式，數據放置在HTML HEADER內提交。
（2）?? GET方式提交的數據最多只能有1024字節，而POST則沒有此限制。
而在實際開發中存在的限制主要有：
GET:特定瀏覽器和服務器對URL長度有限制，例如IE對URL長度的限制是2083字節(2K+35)。對于其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決于操作系統的支持。
因此對于GET提交時，傳輸數據就會受到URL長度的限制。
POST:由于不是通過URL傳值，理論上數據不受限。但實際各個WEB服務器會規定對post提交數據大小進行限制，Apache、IIS6都有各自的配置。
（3）???安全性問題。正如在（1）中提到，使用?Get?的時候，參數會顯示在地址欄上，而?Post?不會。所以，如果這些數據是中文數據而且是非敏感數據，那么使用?get；如果用戶輸入的數據不是中文字符而且包含敏感數據，那么還是使用?post為好。
（4）???安全的和冪等的。所謂安全的意味著該操作用于獲取信息而非修改信息。冪等的意味著對同一?URL?的多個請求應該返回同樣的結果。完整的定義并不像看起來那樣嚴格。換句話說，GET?請求一般不應產生副作用。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。反之亦然。POST?請求就不那么輕松了。POST?表示可能改變服務器上的資源的請求。仍然以新聞站點為例，讀者對文章的注解應該通過?POST?請求實現，因為在注解提交之后站點已經不同了。
HTTP 定義了與服務器交互的不同方法，最常用的有4種，Put(增),Delete(刪)，Post(改),Get(查)，即增刪改查：
1)Get，?它用于獲取信息，注意，他只是獲取、查詢數據，也就是說它不會修改服務器上的數據，從這點來講，它是數據安全的，而稍后會提到的Post它是可以修改數據的，所以這也是兩者差別之一了。
2)?Post，它是可以向服務器發送修改請求，從而修改服務器的，比方說，我們要在論壇上回貼、在博客上評論，這就要用到Post了，當然它也是可以僅僅獲取數據的。
3)Delete 刪除數據。可以通過Get/Post來實現。
4)Put，增加、放置數據，可以通過Get/Post來實現。
根據HTTP規范，GET用于信息獲取，而且應該是安全的和冪等的 。
1.所謂安全的意味著該操作用于獲取信息而非修改信息。換句話說，GET請求一般不應產生副作用。就是說，僅僅是獲取資源信息，就像數據庫查詢一樣，不會修改，增加數據，不會影響資源的狀態。(注意：這里安全的含義僅僅是指是非修改信息。)
根據HTTP規范，POST表示可能修改變服務器上的資源的請求?。繼續引用上面的例子：還是新聞以網站為例，讀者對新聞發表自己的評論應該通過POST實現，因為在評論提交后站點的資源已經不同了，或者說資源被修改了。
?表現形式區別：
HTTP請求：在HTTP請求中，第一行必須是一個請求行(request?line)，用來說明請求類型、要訪問的資源以及使用的HTTP版本。緊接著是一個首部(header)小節，用來說明服務器要使用的附加信息。在首部之后是一個空行，再此之后可以添加任意的其他數據[稱之為主體(body)]。
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀
總結
以上是生活随笔為你收集整理的深入理解HTTP协议、HTTP协议原理分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 平时优化SQL的集合
- 下一篇： 哪个保险公司是属于国家的