Java後臺開發(1)——HTTP協議

時間 2019-11-07

標籤 java 後臺開發 http 協議欄目 Java 简体版

原文原文鏈接

轉自：http://www.cnblogs.com/EricaMIN1987_IT/p/3837436.htmlhtml

參考連接：程序員

HTTP協議詳解(Cnblog)：http://www.cnblogs.com/EricaMIN1987_IT/p/3837436.html
HTTP協議詳解(CSDN)：http://blog.csdn.net/gueter/article/details/1524447
HTTP請求返回狀態碼詳解：http://blog.csdn.net/wangsen2235068/article/details/8081274
HTTP請求返回狀態碼CheetSheet：http://tool.oschina.net/commons?type=5
HTTP請求流程：http://www.cnblogs.com/stg609/archive/2008/07/06/1236966.html
HTTP請求頭Content-Encoding字段：http://guojuanjun.blog.51cto.com/277646/667067/
解析HTTP Transfer-Encoding: chunked：http://blog.csdn.net/zhangboyj/article/details/6236780

1、概念web

協議是指計算機通訊網絡中兩臺計算機之間進行通訊所必須共同遵照的規定或規則，超文本傳輸協議(HTTP)是一種通訊協議，它容許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。算法

HTTP協議，即超文本傳輸協議(Hypertext transfer protocol)。是一種詳細規定了瀏覽器和萬維網(WWW = World Wide Web)服務器之間互相通訊的規則，經過因特網傳送萬維網文檔的數據傳送協議。跨域

HTTP協議是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它能夠使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。瀏覽器

HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。緩存

在Internet中全部的傳輸都是經過TCP/IP進行的。HTTP協議做爲TCP/IP模型中應用層的協議也不例外。HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS。以下圖所示：安全

HTTP默認的端口號爲80，HTTPS的端口號爲443。服務器

瀏覽網頁是HTTP的主要應用，可是這並不表明HTTP就只能應用於網頁的瀏覽。HTTP是一種協議，只要通訊的雙方都遵照這個協議，HTTP就能有用武之地。好比我們經常使用的QQ，迅雷這些軟件，都會使用HTTP協議(還包括其餘的協議)。cookie

2、簡史

它的發展是萬維網協會（World Wide Web Consortium）和Internet工做小組IETF（Internet Engineering Task Force）合做的結果，（他們）最終發佈了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天廣泛使用的一個版本——HTTP 1.1。

3、特色

HTTP協議永遠都是客戶端發起請求，服務器回送響應。這樣就限制了使用HTTP協議，沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端。

HTTP協議的主要特色可歸納以下：
一、支持客戶/服務器模式。支持基本認證和安全認證。
二、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
三、靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
四、HTTP 0.9和1.0使用非持續鏈接：限制每次鏈接只處理一個請求，服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。HTTP 1.1使用持續鏈接：沒必要爲每一個web對象建立一個新的鏈接，一個鏈接能夠傳送多個對象。
五、無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。

無狀態協議：
協議的狀態是指下一次傳輸能夠「記住」此次傳輸信息的能力。
http是不會爲了下一次鏈接而維護此次鏈接所傳輸的信息,爲了保證服務器內存。
好比客戶得到一張網頁以後關閉瀏覽器，而後再一次啓動瀏覽器，再登錄該網站，可是服務器並不知道客戶關閉了一次瀏覽器。
由於Web服務器要面對不少瀏覽器的併發訪問，爲了提升Web服務器對併發訪問的處理能力，在設計HTTP協議時規定Web服務器發送HTTP應答報文和文檔時，不保存發出請求的Web瀏覽器進程的任何狀態信息。這有可能出現一個瀏覽器在短短几秒以內兩次訪問同一對象時，服務器進程不會由於已經給它發過應答報文而不接受第二期服務請求。因爲Web服務器不保存發送請求的Web瀏覽器進程的任何信息，所以HTTP協議屬於無狀態協議（Stateless Protocol）。

HTTP協議是無狀態的和Connection: keep-alive的區別：
無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。從另外一方面講，打開一個服務器上的網頁和你以前打開這個服務器上的網頁之間沒有任何聯繫。
HTTP是一個無狀態的面向鏈接的協議，無狀態不表明HTTP不能保持TCP鏈接，更不能表明HTTP使用的是UDP協議（無鏈接）。
從HTTP/1.1起，默認都開啓了Keep-Alive，保持鏈接特性，簡單地說，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接。
Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。

4、工做流程

一次HTTP操做稱爲一個事務，其工做過程可分爲四步：
1）首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始。
2）創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
3）服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。
4）客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。
若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了。

HTTP是基於傳輸層的TCP協議，而TCP是一個端到端的面向鏈接的協議。所謂的端到端能夠理解爲進程到進程之間的通訊。因此HTTP在開始傳輸以前，首先須要創建TCP鏈接，而TCP鏈接的過程須要所謂的「三次握手」。下圖所示TCP鏈接的三次握手。
在TCP三次握手以後，創建了TCP鏈接，此時HTTP就能夠進行傳輸了。一個重要的概念是面向鏈接，既HTTP在傳輸完成之間並不斷開TCP鏈接。在HTTP1.1中(經過Connection頭設置)這是默認行爲。

5、使用Wireshark抓TCP、http包

打開Wireshark，選擇工具欄上的"Capture"->"Options"

點擊"Capture Filter"，此處選擇的是"HTTP TCP port（80）"，選擇後點擊上圖的"Start"開始抓包。
而後在瀏覽器中打開http://image.baidu.com/，抓包結果以下圖所示：

在上圖中，可清晰的看到客戶端瀏覽器（ip爲192.168.1.6）與服務器（115.239.210.36）的交互過程：
1）No1：瀏覽器（192.168.1.6）向服務器（115.239.210.36）發出鏈接請求。此爲TCP三次握手第一步，此時從圖中能夠看出，爲SYN，seq:X （x=0）；
2）No2：服務器（115.239.210.36）迴應了瀏覽器（192.168.1.6）的請求，並要求確認，此時爲：SYN，ACK，此時seq：y（y爲0），ACK：x+1（爲1）。此爲三次握手的第二步；
3）No3：瀏覽器（192.168.1.6）迴應了服務器（115.239.210.36）的確認，鏈接成功。爲：ACK，此時seq：x+1（爲1），ACK：y+1（爲1）。此爲三次握手的第三步；
4）No4：瀏覽器（192.168.1.6）發出一個頁面HTTP請求；
5）No5：服務器（115.239.210.36）確認；
6）No6：服務器（115.239.210.36）發送數據；
7）No8：客戶端瀏覽器（192.168.1.6）確認；

8）No81：客戶端（192.168.1.6）發出一個圖片HTTP請求；
9）No202：服務器（115.239.210.36）發送狀態響應碼200 OK。

6、頭域

每一個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前能夠添加任何數量的空格符，頭域能夠被擴展爲多行，在每行開始處，使用至少一個空格或製表符。

6.一、請求信息：
發出的請求信息格式以下：
●請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請求logo.gif這個文件。
●（請求）頭，例如Accept-Language: en
●空行
●可選的消息體　請求行和標題必須以<CR><LF>做爲結尾（也就是，回車而後換行）。空行內必須只有<CR><LF>而無其餘空格。在HTTP/1.1協議中，全部的請求頭，除post外，都是可選的。

三個部分分別是：請求行、消息報頭、請求正文。

6.二、請求方法
HTTP/1.1協議中共定義了八種方法（有時也叫「動做」）來代表Request-URI指定的資源的不一樣操做方式：
OPTIONS - 返回服務器針對特定資源所支持的HTTP請求方法。也能夠利用向Web服務器發送'*'的請求來測試服務器的功能性。
HEAD- 向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法能夠在沒必要傳輸整個響應內容的狀況下，就能夠獲取包含在響應消息頭中的元信息。該方法經常使用於測試超連接的有效性，是否能夠訪問，以及最近是否更新。
GET - 向特定的資源發出請求。注意：GET方法不該當被用於產生「反作用」的操做中，例如在web app.中。其中一個緣由是GET可能會被網絡蜘蛛等隨意訪問。
POST - 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。
PUT - 向指定資源位置上傳其最新內容。
DELETE - 請求服務器刪除Request-URI所標識的資源。
TRACE- 回顯服務器收到的請求，主要用於測試或診斷。
CONNECT - HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
PATCH - 用來將局部修改應用於某一資源，添加於規範RFC5789。
方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（Method Not Allowed）；當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。
HTTP服務器至少應該實現GET和HEAD方法，其餘方法都是可選的。此外，除了上述方法，特定的HTTP服務器還可以擴展自定義的方法。

GET和POST的區別：
一、GET提交的數據會放在URL以後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中。
二、GET提交的數據大小有限制，最多隻能有1024字節（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制。
三、GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值。
四、GET方式提交數據，會帶來安全問題，好比一個登陸頁面，經過GET方式提交數據時，用戶名和密碼將出如今URL上，若是頁面能夠被緩存或者其餘人能夠訪問這臺機器，就能夠從歷史記錄得到該用戶的帳號和密碼。

6.三、響應消息
客戶端向服務器發送一個請求，服務器以一個狀態行做爲響應，響應的內容包括：消息協議的版本、成功或者錯誤編碼、服務器信息、實體元信息以及必要的實體內容。根據響應類別的類別，服務器響應裏能夠含實體內容，但不是全部的響應都有實體內容。
響應頭第一行也稱爲狀態行，格式以下（下圖中紅線標出的那行）：
HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF
HTTP- Version表示HTTP版本，例如爲HTTP/1.1。Status- Code是結果代碼，用三個數字表示。Reason-Phrase是個簡單的文本描述，解釋Status-Code的具體緣由。Status-Code用於機器自動識別，Reason-Phrase用於人工理解。Status-Code的第一個數字表明響應類別，可能取5個不一樣的值。後兩個數字沒有分類做用。Status-Code的第一個數字表明響應的類別，後續兩位描述在該類響應下發生的具體情況，具體請參見：HTTP狀態碼。

響應消息的結構：

三個部分分別是：狀態行、消息報頭、響應正文。

無論你什麼時候瀏覽一個網頁，你的電腦都會經過一個使用HTTP協議的服務器來獲取所請求的數據。在你請求的網頁顯示在瀏覽器以前，支配網頁的網站服務器會返回一個包含有狀態碼的HTTP頭文件。這個狀態碼提供了有關所請求網頁的相關條件信息。若是一切正常，一個標準網頁會收到一條諸如200的狀態碼。固然咱們的目的不是去研究200響應碼，而是去探討那些表明出現錯誤信息的服務器頭文件響應碼，例如表示「未找到指定網頁」的404碼。

6.四、響應頭域
服務器須要傳遞許多附加信息，這些信息不能全放在狀態行裏。所以，須要另行定義響應頭域，用來描述這些附加信息。響應頭域主要描述服務器的信息和Request-URI的信息。

6.五、HTTP常見的請求頭（在HTTP/1.1 協議中，全部的請求頭，除Host外，都是可選的）

If-Modified-Since：把瀏覽器端緩存頁面的最後修改時間發送到服務器去，服務器會把這個時間與服務器上實際文件的最後修改時間進行對比。若是時間一致，那麼返回304，客戶端就直接使用本地緩存文件。若是時間不一致，就會返回200和新的文件內容。客戶端接到以後，會丟棄舊文件，把新文件緩存起來，並顯示在瀏覽器中。
例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT

If-None-Match：If- None-Match和ETag一塊兒工做，工做原理是在HTTP Response中添加ETag信息。當用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match信息(ETag的值)。若是服務器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用本地緩存文件。不然將返回200狀態和新的資源和Etag. 使用這樣的機制將提升網站的性能。例如: If-None-Match: "03f2b33c0bfcc1:0"。

Pragma：指定「no-cache」值表示服務器必須返回一個刷新後的文檔，即便它是代理服務器並且已經有了頁面的本地拷貝；在HTTP/1.1版本中，它和 Cache-Control:no-cache做用如出一轍。Pargma只有一個用法，例如： Pragma: no-cache
注意: 在HTTP/1.0版本中，只實現了Pragema:no-cache, 沒有實現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、s-maxage。

Cache-Control:Public 能夠被任何緩存所緩存
Cache-Control:Private 內容只緩存到私有緩存中
Cache-Control:no-cache 全部內容都不會被緩存
Cache-Control:no-store 用於防止重要的信息被無心的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存。
Cache-Control:max-age 指示客戶機能夠接收生存期不大於指定時間（以秒爲單位）的響應。
Cache-Control:min-fresh 指示客戶機能夠接收響應時間小於當前時間加上指定時間的響應。
Cache-Control:max-stale 指示客戶機能夠接收超出超時期間的響應消息。若是指定max-stale消息的值，那麼客戶機能夠接收超出超時期指定值以內的響應消息。

Accept：瀏覽器端能夠接受的MIME類型。例如：Accept: text/html 表明瀏覽器能夠接受服務器回發的類型爲 text/html 也就是咱們常說的html文檔，若是服務器沒法返回text/html類型的數據，服務器應該返回一個406錯誤(non acceptable)。通配符 * 表明任意類型，例如 Accept: */* 表明瀏覽器能夠處理全部類型，(通常瀏覽器發給服務器都是發這個)。

Accept-Encoding：瀏覽器申明本身可接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate）;Servlet可以向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這能夠減小5到10倍的下載時間。例如： Accept-Encoding: gzip, deflate。若是請求消息中沒有設置這個域，服務器假定客戶端對各類內容編碼均可以接受。

Accept-Language：瀏覽器申明本身接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，好比big5，gb2312，gbk等等；例如：Accept-Language: en-us。若是請求消息中沒有設置這個報頭域，服務器假定客戶端對各類語言均可以接受。

Accept-Charset：瀏覽器可接受的字符集。若是在請求消息中沒有設置這個域，缺省表示任何字符集均可以接受。

User-Agent：告訴HTTP服務器，客戶端使用的操做系統和瀏覽器的名稱和版本。
例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)。

Content-Type：例如：Content-Type: application/x-www-form-urlencoded。

Referer：包含一個URL，用戶從該URL表明的頁面出發訪問當前請求的頁面。提供了Request的上下文信息的服務器，告訴服務器我是從哪一個連接過來的，好比從我主頁上連接到一個朋友那裏，他的服務器就可以從HTTP Referer中統計出天天有多少用戶點擊我主頁上的連接訪問他的網站。
例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Connection：
例如：Connection: keep-alive 當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接。HTTP 1.1默認進行持久鏈接。利用持久鏈接的優勢，當頁面包含多個元素時（例如Applet，圖片），顯著地減小下載所須要的時間。要實現這一點，Servlet須要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入 ByteArrayOutputStream，而後在正式寫出內容以前計算它的大小。
Connection: close 表明一個Request完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接會關閉，當客戶端再次發送Request，須要從新創建TCP鏈接。

Host：（發送請求時，該頭域是必需的）主要用於指定被請求資源的Internet主機和端口號，它一般從HTTP URL中提取出來的。HTTP/1.1請求必須包含主機頭域，不然系統會以400狀態碼返回。
例如: 咱們在瀏覽器中輸入：http://www.guet.edu.cn/index.html，瀏覽器發送的請求消息中，就會包含Host請求頭域：Host：http://www.guet.edu.cn，此處使用缺省端口號80，若指定了端口號，則變成：Host：指定端口號。

Cookie：最重要的請求頭之一, 將cookie的值發送給HTTP服務器。

Content-Length：表示請求消息正文的長度。例如：Content-Length: 38。

Authorization：受權信息，一般出如今對服務器發送的WWW-Authenticate頭的應答中。主要用於證實客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，若是收到服務器的響應代碼爲401（未受權），能夠發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。

UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操做系統和CPU類型。

From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它。

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）。

6.六、HTTP常見的響應頭

Allow：服務器支持哪些請求方法（如GET、POST等）。

Date：表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，須要知道用戶所在的時區。你能夠用setDateHeader來設置這個頭以免轉換時間格式的麻煩

Expires：指明應該在何時認爲文檔已通過期，從而再也不緩存它，從新從服務器獲取，會更新緩存。過時以前使用本地緩存。HTTP1.1的客戶端和緩存會將非法的日期格式（包括0）看做已通過期。eg：爲了讓瀏覽器不要緩存頁面，咱們也能夠將Expires實體報頭域，設置爲0。
例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

P3P：用於跨域設置Cookie, 這樣能夠解決iframe跨域訪問cookie的問題
例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR

Set-Cookie：很是重要的header, 用於把cookie發送到客戶端瀏覽器，每個寫入cookie都會生成一個Set-Cookie。
例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

ETag：和If-None-Match 配合使用。

Last-Modified：用於指示資源的最後修改日期和時間。Last-Modified也可用setDateHeader方法來設置。

Content-Type：WEB 服務器告訴瀏覽器本身響應的對象的類型和字符集。Servlet默認爲text/plain，但一般須要顯式地指定爲text/html。因爲常常要設置 Content-Type，所以HttpServletResponse提供了一個專用的方法setContentType。可在web.xml文件中配置擴展名和MIME類型的對應關係。
例如:Content-Type: text/html;charset=utf-8
　　 Content-Type:text/html;charset=GB2312
　　 Content-Type: image/jpeg

媒體類型的格式爲：大類/小類，好比text/html。
IANA(The Internet Assigned Numbers Authority，互聯網數字分配機構)定義了8個大類的媒體類型，分別是:
application— (好比: application/vnd.ms-excel.)
audio (好比: audio/mpeg.)
image (好比: image/png.)
message (好比,:message/http.)
model(好比:model/vrml.)
multipart (好比:multipart/form-data.)
text(好比:text/html.)
video(好比:video/quicktime.)

Content-Range：用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。通常格式：Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-length。
例如，傳送頭500個字節次字段的形式：Content-Range:bytes0-499/1234若是一個http消息包含此節（例如，對範圍請求的響應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍。

Content-Length：指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程當中，Content-Length的方式要預先在服務器中緩存全部數據，而後所有數據再一古腦兒地發給客戶端。只有當瀏覽器使用持久HTTP鏈接時才須要這個數據。若是你想要利用持久鏈接的優點，能夠把輸出文檔寫入 ByteArrayOutputStram，完成後查看其大小，而後把該值放入Content-Length頭，最後經過 byteArrayStream.writeTo(response.getOutputStream()發送內容。
例如: Content-Length: 19847

Content-Encoding：WEB 服務器代表本身使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。只有在解碼以後才能夠獲得Content-Type頭指定的內容類型。利用gzip壓縮文檔可以顯著地減小HTML文檔的下載時間。Java的GZIPOutputStream能夠很方便地進行gzip壓縮，但只有Unix 上的Netscape和Windows上的IE 四、IE 5才支持它。所以，Servlet應該經過查看Accept-Encoding頭（即request.getHeader("Accept- Encoding")）檢查瀏覽器是否支持gzip，爲支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，爲其餘瀏覽器返回普通頁面。
例如：Content-Encoding：gzip

Content-Language：WEB服務器告訴瀏覽器本身響應的對象所用的天然語言。例如： Content-Language:da。沒有設置該域則認爲實體內容將提供給全部的語言閱讀。

Server：指明HTTP服務器用來處理請求的軟件信息。例如：Server: Microsoft-IIS/7.五、Server：Apache-Coyote/1.1。此域能包含多個產品標識和註釋，產品標識通常按照重要性排序。

X-AspNet-Version：若是網站是用ASP.NET開發的，這個header用來表示ASP.NET的版本。
例如: X-AspNet-Version: 4.0.30319

X-Powered-By：表示網站是用什麼技術開發的。
例如： X-Powered-By: ASP.NET

Connection：
例如：Connection: keep-alive 當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接。
Connection: close 表明一個Request完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接會關閉，當客戶端再次發送Request，須要從新創建TCP鏈接。

Location：用於重定向一個新的位置，包含新的URL地址。表示客戶應當到哪裏去提取文檔。Location一般不是直接設置的，而是經過 HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼爲302。Location響應報頭域經常使用在更換域名的時候。

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都支持它。

WWW-Authenticate：該響應報頭域必須被包含在401（未受權的）響應消息中，客戶端收到401響應消息時候，併發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。
eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //能夠看出服務器對請求資源採用的是基本驗證機制。

7、解決HTTP無狀態的問題

7.一、經過Cookies保存狀態信息
經過Cookies，服務器就能夠清楚的知道請求2和請求1來自同一個客戶端。

7.二、經過Session保存狀態信息

Session機制是一種服務器端的機制，服務器使用一種相似於散列表的結構（也可能就是使用散列表）來保存信息。
當程序須要爲某個客戶端的請求建立一個session的時候，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 - 稱爲 session id，若是已包含一個session id則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個 session檢索出來使用（若是檢索不到，可能會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。

Session的實現方式：

一、使用Cookie來實現
服務器給每一個Session分配一個惟一的JSESSIONID，並經過Cookie發送給客戶端。
當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器可以找到這個客戶端對應的Session。

二、使用URL回寫來實現
URL回寫是指服務器在發送給瀏覽器頁面的全部連接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個連接都會把JSESSIONID帶會服務器。若是直接在瀏覽器輸入服務端資源的url來請求該資源，那麼Session是匹配不到的。
Tomcat 對Session的實現，是一開始同時使用Cookie和URL回寫機制，若是發現客戶端支持Cookie，就繼續使用Cookie，中止使用URL回寫。若是發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的連接記得使用 response.encodeURL() 。

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機制更安全些。由於它不會任意讀取客戶存儲的信息。

7.三、經過表單變量保持狀態
除了Cookies以外，還能夠使用表單變量來保持狀態，好比Asp.net就經過一個叫ViewState的Input=「hidden」的框來保持狀態,好比:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMjA0OTM4MTAwNGRkXUfhlDv1Cs7/qhBlyZROCzlvf5U=" />
這個原理和Cookies大同小異，只是每次請求和響應所附帶的信息變成了表單變量。

7.四、經過QueryString保持狀態
QueryString經過將信息保存在所請求地址的末尾來向服務器傳送信息，一般和表單結合使用，一個典型的QueryString好比:www.xxx.com/xxx.aspx?var1=value&var2=value2

8、使用telnet進行http測試

在Windows下，可以使用命令窗口進行http簡單測試。輸入cmd進入命令窗口，在命令行鍵入以下命令後按回車：
telnet www.baidu.com 80
然後在窗口中按下"Ctrl+]"後按回車可以讓返回結果回顯。
接着開始發請求消息，例如發送以下請求消息請求baidu的首頁消息，使用的HTTP協議爲HTTP/1.1：
GET /index.html HTTP/1.1
注意：copy如上的消息到命令窗口後須要按兩個回車換行才能獲得響應的消息，第一個回車換行是在命令後鍵入回車換行，是HTTP協議要求的。第二個是確認輸入，發送請求。

可看到，當採用HTTP/1.1時，鏈接不是在請求結束後就斷開的。若採用HTTP1.0，在命令窗口鍵入：
GET /index.html HTTP/1.0
此時能夠看到請求結束以後立刻斷開。
讀者還能夠嘗試在使用GET或POST等時，帶上頭域信息，例如鍵入以下信息：
GET /index.html HTTP/1.1
connection: close
Host: www.baidu.com

9、URL詳解

URL(Uniform Resource Locator) 地址用於描述一個網絡上的資源，基本格式以下
schema://host[:port#]/path/.../[;url-params][?query-string][#anchor]
　　scheme 指定低層使用的協議(例如：http, https, ftp)
　　host HTTP服務器的IP地址或者域名
　　port# HTTP服務器的默認端口是80，這種狀況下端口號能夠省略。若是使用了別的端口，必須指明，例如 http://www.cnblogs.com:8080/
　　path 訪問資源的路徑
　　url-params
　　query-string 發送給http服務器的數據
　　anchor- 錨

URL 的一個例子：
http://www.mywebsite.com/sj/test;id=8079?name=sviergn&x=true#stuff
Schema: http
host: www.mywebsite.com
path: /sj/test
URL params: id=8079
Query String: name=sviergn&x=true
Anchor: stuff

10、緩存的實現原理

WEB緩存(cache)位於Web服務器和客戶端之間。
緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：若是是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。
HTTP協議定義了相關的消息頭來使WEB緩存儘量好的工做。

10.一、緩存的優勢
減小相應延遲：由於請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。
減小網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶能夠節省帶寬費用，控制帶寬的需求的增加並更易於管理。

10.二、客戶端緩存生效的常見流程

服務器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭，客戶端將該資源保存在cache中，並記錄這兩個屬性。當客戶端須要發送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應中Last- Modified和ETag頭的值。服務器經過這兩個頭判斷本地資源未發生變化，客戶端不須要從新下載，返回304響應。

10.三、Web緩存機制

HTTP/1.1 中緩存的目的是爲了在不少狀況下減小發送請求，同時在許多狀況下能夠不須要發送完整響應。前者減小了網絡迴路的數量；HTTP利用一個「過時（expiration）」機制來爲此目的。後者減小了網絡應用的帶寬；HTTP用「驗證（validation）」機制來爲此目的。
HTTP定義了3種緩存機制：
1）Freshness：容許一個迴應消息能夠在源服務器不被從新檢查，而且能夠由服務器和客戶端來控制。例如，Expires迴應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明瞭緩存的最長時間；
2）Validation：用來檢查以一個緩存的迴應是否仍然可用。例如，若是一個迴應有一個Last-Modified迴應頭，緩存可以使用If-Modified-Since來判斷是否已改變，以便判斷根據狀況發送請求；
3）Invalidation：在另外一個請求經過緩存的時候，經常有一個反作用。例如，若是一個URL關聯到一個緩存迴應，可是其後跟着POST、PUT和DELETE的請求的話，緩存就會過時。

11、HTTP應用

11.一、斷點續傳的實現原理

HTTP協議的GET方法，支持只請求某個資源的某一部分；
206 Partial Content 部份內容響應；
Range 請求的資源範圍；
Content-Range 響應的資源範圍；
在鏈接斷開重連時，客戶端只請求該資源未下載的部分，而不是從新請求整個資源，來實現斷點續傳。
分塊請求資源實例：
Eg1：Range: bytes=306302- ：請求這個資源從306302個字節到末尾的部分；
Eg2：Content-Range: bytes 306302-604047/604048：響應中指示攜帶的是該資源的第306302-604047的字節，該資源共604048個字節；
客戶端經過併發的請求相同資源的不一樣片斷，來實現對某個資源的併發分塊下載。從而達到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個原理。

11.二、多線程下載的原理
下載工具開啓多個發出HTTP請求的線程；
每一個http請求只請求資源文件的一部分：Content-Range: bytes 20000-40000/47000；
合併每一個線程下載的文件。

11.三、http代理
http代理服務器

代理服務器英文全稱是Proxy Server，其功能就是代理網絡用戶去取得網絡信息。形象的說：它是網絡信息的中轉站。
代理服務器是介於瀏覽器和Web服務器之間的一臺服務器，有了它以後，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，Request信號會先送到代理服務器，由代理服務器來取回瀏覽器所須要的信息並傳送給你的瀏覽器。
而且，大部分代理服務器都具備緩衝的功能，就好象一個大的Cache，它有很大的存儲空間，它不斷將新取得數據儲存到它本機的存儲器上，若是瀏覽器所請求的數據在它本機的存儲器上已經存在並且是最新的，那麼它就不從新從Web服務器取數據，而直接將存儲器上的數據傳送給用戶的瀏覽器，這樣就能顯著提升瀏覽速度和效率。更重要的是：Proxy Server(代理服務器)是Internet鏈路級網關所提供的一種重要的安全功能，它的工做主要在開放系統互聯(OSI)模型的對話層。

http代理服務器的主要功能：

1）突破自身IP訪問限制，訪問國外站點。如：教育網、169網等網絡用戶能夠經過代理訪問國外網站；
2）訪問一些單位或團體內部資源，如某大學FTP(前提是該代理地址在該資源的容許訪問範圍以內)，使用教育網內地址段免費代理服務器，就能夠用於對教育網開放的各種FTP下載上傳，以及各種資料查詢共享等服務；
3）突破中國電信的IP封鎖：中國電信用戶有不少網站是被限制訪問的，這種限制是人爲的，不一樣Serve對地址的封鎖是不一樣的。因此不能訪問時能夠換一個國外的代理服務器試試；
4）提升訪問速度：一般代理服務器都設置一個較大的硬盤緩衝區，當有外界的信息經過時，同時也將其保存到緩衝區中，當其餘用戶再訪問相同的信息時，則直接由緩衝區中取出信息，傳給用戶，以提升訪問速度；
5）隱藏真實IP：上網者也能夠經過這種方法隱藏本身的IP，免受攻擊。

對於客戶端瀏覽器而言，http代理服務器至關於服務器。
而對於Web服務器而言，http代理服務器又擔當了客戶端的角色。

11.四、虛擬主機

虛擬主機：是在網絡服務器上劃分出必定的磁盤空間供用戶放置站點、應用組件等，提供必要的站點功能與數據存放、傳輸功能。
所謂虛擬主機，也叫「網站空間」就是把一臺運行在互聯網上的服務器劃分紅多個「虛擬」的服務器，每個虛擬主機都具備獨立的域名和完整的Internet服務器（支持WWW、FTP、E-mail等）功能。一臺服務器上的不一樣虛擬主機是各自獨立的，並由用戶自行管理。但一臺服務器主機只可以支持必定數量的虛擬主機，當超過這個數量時，用戶將會感到性能急劇降低。

虛擬主機的實現原理

虛擬主機是用同一個WEB服務器，爲不一樣域名網站提供服務的技術。Apache、Tomcat等都可經過配置實現這個功能。
相關的HTTP消息頭：Host。
例如：Host: www.baidu.com
客戶端發送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是客戶端輸入的域名。這樣服務器能夠根據Host頭確認客戶要訪問的是哪個域名。

12、HTTP認證方式

HTTP請求報頭： Authorization
HTTP響應報頭： WWW-Authenticate

HTTP認證是基於質詢/迴應(challenge/response)的認證模式。

12.1 基本認證 basic authentication（HTTP1.0提出的認證方法）

基本認證是一種用來容許Web瀏覽器或其餘客戶端程序在請求時提供用戶名和口令形式的身份憑證的一種登陸驗證方式。

把 "用戶名+冒號+密碼"用BASE64算法加密後的字符串放在http request 中的header Authorization中發送給服務端。
客戶端對於每個realm，經過提供用戶名和密碼來進行認證的方式。
包含密碼的明文傳遞。

當瀏覽器訪問使用基本認證的網站的時候，瀏覽器會提示你輸入用戶名和密碼，以下圖：

假如用戶名密碼錯誤的話，服務器會返回401，以下圖：

基本認證步驟：
一、客戶端訪問一個受http基本認證保護的資源。
二、服務器返回401狀態，要求客戶端提供用戶名和密碼進行認證。（驗證失敗的時候，響應頭會加上WWW-Authenticate: Basic realm="請求域"。）
401 Unauthorized
WWW-Authenticate： Basic realm="WallyWorld"
三、客戶端將輸入的用戶名密碼用Base64進行編碼後，採用非加密的明文方式傳送給服務器。
Authorization: Basic xxxxxxxxxx.
四、服務器將Authorization頭中的用戶名密碼解碼並取出，進行驗證，若是認證成功，則返回相應的資源。若是認證失敗，則仍返回401狀態，要求從新進行認證。

特記事項：
一、Http是無狀態的，同一個客戶端對同一個realm內資源的每個訪問會被要求進行認證。
二、客戶端一般會緩存用戶名和密碼，並和authentication realm一塊兒保存，因此，通常不須要你從新輸入用戶名和密碼。
三、以非加密的明文方式傳輸，雖然轉換成了不易被人直接識別的字符串，可是沒法防止用戶名密碼被惡意盜用。雖然用肉眼看不出來，但用程序很容易解密。

優勢：
基本認證的一個優勢是基本上全部流行的網頁瀏覽器都支持基本認證。基本認證不多在可公開訪問的互聯網網站上使用，有時候會在小的私有系統中使用（如路由器
網頁管理接口）。後來的機制HTTP摘要認證是爲替代基本認證而開發的，容許密鑰以相對安全的方式在不安全的通道上傳輸。

程序員和系統管理員有時會在可信網絡環境中使用基本認證，使用Telnet或其餘明文網絡協議工具手動地測試Web服務器。這是一個麻煩的過程，可是網絡上傳輸的
內容是人可讀的，以便進行診斷。

缺點：
雖然基本認證很是容易實現，但該方案創建在如下的假設的基礎上，即：客戶端和服務器主機之間的鏈接是安全可信的。特別是，若是沒有使用SSL/TLS這樣的傳輸
層安全的協議，那麼以明文傳輸的密鑰和口令很容易被攔截。該方案也一樣沒有對服務器返回的信息提供保護。

現存的瀏覽器保存認證信息直到標籤頁或瀏覽器被關閉，或者用戶清除歷史記錄。HTTP沒有爲服務器提供一種方法指示客戶端丟棄這些被緩存的密鑰。這意味着服務
器端在用戶不關閉瀏覽器的狀況下，並無一種有效的方法來讓用戶登出。

一個例子：

這一個典型的HTTP客戶端和HTTP服務器的對話，服務器安裝在同一臺計算機上（localhost），包含如下步驟：

客戶端請求一個須要身份認證的頁面，可是沒有提供用戶名和口令。這一般是用戶在地址欄輸入一個URL，或是打開了一個指向該頁面的連接。服務端響應一個401應
答碼，並提供一個認證域。接到應答後，客戶端顯示該認證域（一般是所訪問的計算機或系統的描述）給用戶並提示輸入用戶名和口令。此時用戶能夠選擇肯定或取
消。用戶輸入了用戶名和口令後，客戶端軟件會在原先的請求上增長認證消息頭（值是base64encode(username+":"+password)），而後從新發送再次嘗試。
在本例中，服務器接受了該認證屏幕並返回了頁面。若是用戶憑據非法或無效，服務器可能再次返回401應答碼，客戶端能夠再次提示用戶輸入口令。
注意:客戶端有可能不須要用戶交互，在第一次請求中就發送認證消息頭。

客戶端請求（沒有認證信息）：
GET /private/index.html HTTP/1.0
Host: localhost
（跟隨一個換行，以回車（CR）加換行（LF）的形式）

服務端應答：
HTTP/1.0 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 311
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
  <HEAD>
    <TITLE>Error</TITLE>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
  </HEAD>
  <BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>

客戶端的請求（用戶名「"Aladdin」，口令, password 「open sesame」）：
GET /private/index.html HTTP/1.0
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
（跟隨一個空行，如上所述）

服務端的應答：
HTTP/1.0 200 OK
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:19:07 GMT
Content-Type: text/html
Content-Length: 10476
（跟隨一個空行，隨後是需憑據頁的HTML文本）。

HTTP OAuth認證
OAuth對於Http來講，就是放在Authorization header中的不是用戶名密碼，而是一個token。微軟的Skydrive就是使用這樣的方式。

12.二、摘要認證 digest authentication（HTTP1.1提出的基本認證的替代方法）

這個認證能夠看作是基本認證的加強版本，不包含密碼的明文傳遞。

引入了一系列安全加強的選項；「保護質量」(qop)、隨機數計數器由客戶端增長、以及客戶生成的隨機數。

在HTTP摘要認證中使用 MD5 加密是爲了達成"不可逆的"，也就是說，當輸出已知的時候，肯定原始的輸入應該是至關困難的。若是密碼自己太過簡單，也許能夠
經過嘗試全部可能的輸入來找到對應的輸出（窮舉攻擊），甚至能夠經過字典或者適當的查找表加快查找速度。

示例及說明
下面的例子僅僅涵蓋了「auth」保護質量的代碼，由於在撰寫期間，所知道的只有Opera和Konqueror網頁瀏覽器支持「auth-int」（帶完整性保護的認證）。

典型的認證過程包括以下步驟：
客戶端請求一個須要認證的頁面，可是不提供用戶名和密碼。一般這是因爲用戶簡單的輸入了一個地址或者在頁面中點擊了某個超連接。
服務器返回401 "Unauthorized" 響應代碼，並提供認證域(realm)，以及一個隨機生成的、只使用一次的數值，稱爲密碼隨機數 nonce。
此時，瀏覽器會向用戶提示認證域(realm)（一般是所訪問的計算機或系統的描述），而且提示用戶名和密碼。用戶此時能夠選擇取消。
一旦提供了用戶名和密碼，客戶端會從新發送一樣的請求，可是添加了一個認證頭包括了響應代碼。

注意：客戶端可能已經擁有了用戶名和密碼，所以不須要提示用戶，好比之前存儲在瀏覽器裏的。

客戶端請求 (無認證)：
GET /dir/index.html HTTP/1.0
Host: localhost
(跟隨一個新行，形式爲一個回車再跟一個換行）

服務器響應：
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",   //認證域
                        qop="auth,auth-int",   //保護質量
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",  //服務器密碼隨機數
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
  <HEAD>
    <TITLE>Error</TITLE>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
  </HEAD>
  <BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>

客戶端請求 (用戶名 "Mufasa", 密碼 "Circle Of Life")：
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,    //請求計數
                     cnonce="0a4f113b",   //客戶端密碼隨機數
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"
(跟隨一個新行，形式如前所述)。

服務器響應：
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984
(隨後是一個空行，而後是所請求受限制的HTML頁面)

response 值由三步計算而成。當多個數值合併的時候，使用冒號做爲分割符：

一、對用戶名、認證域(realm)以及密碼的合併值計算 MD5 哈希值，結果稱爲 HA1。
二、對HTTP方法以及URI的摘要的合併值計算 MD5 哈希值，例如，"GET" 和 "/dir/index.html"，結果稱爲 HA2。
三、對HA一、服務器密碼隨機數(nonce)、請求計數(nc)、客戶端密碼隨機數(cnonce)、保護質量(qop)以及 HA2 的合併值計算 MD5 哈希值。結果即爲客戶端提供的
response 值。
由於服務器擁有與客戶端一樣的信息，所以服務器能夠進行一樣的計算，以驗證客戶端提交的 response 值的正確性。在上面給出的例子中，結果是以下計算的。
（MD5()表示用於計算MD5哈希值的函數；「\」表示接下一行；引號並不參與計算）

HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
= 939e7578ed9e3c518a452acee763bce9

HA2 = MD5( "GET:/dir/index.html" )
= 39aff3a2bab6126f332b942af96d3366

Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:0a4f113b:auth:\
39aff3a2bab6126f332b942af96d3366" )
= 6629fae49393a05397450978507c4ef1

此時客戶端能夠提交一個新的請求，重複使用服務器密碼隨機數(nonce)（服務器僅在每次「401」響應後發行新的nonce），可是提供新的客戶端密碼隨機數(cnonce)。在後續的請求中，十六進制請求計數器(nc)必須比前一次使用的時候要大，不然攻擊者能夠簡單的使用一樣的認證信息重放老的請求。由服務器來確保在每一個發出的密碼隨機數nonce時，計數器是在增長的，並拒絕掉任何錯誤的請求。顯然，改變HTTP方法和/或計數器數值都會致使不同的 response值。

服務器應當記住最近所生成的服務器密碼隨機數nonce的值。也能夠在發行每個密碼隨機數nonce後，記住過一段時間讓它們過時。若是客戶端使用了一個過時的值，服務器應該響應「401」狀態號，而且在認證頭中添加stale=TRUE，代表客戶端應當使用新提供的服務器密碼隨機數nonce重發請求，而沒必要提示用戶其它用戶名和口令。

服務器不須要保存任何過時的密碼隨機數，它能夠簡單的認爲全部不認識的數值都是過時的。服務器也能夠只容許每個服務器密碼隨機數nonce使用一次，固然，這樣就會迫使客戶端在發送每一個請求的時候重複認證過程。須要注意的是，在生成後馬上過時服務器密碼隨機數nonce是不行的，由於客戶端將沒有任何機會來使用這個nonce。

PS：以上只介紹了兩種比較基礎的，還有其餘的一些認證方式就不在這裏一一說明了。

十3、HTTPS傳輸協議原理

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容請看SSL。

13.一、兩種基本的加解密算法類型
對稱加密：密鑰只有一個，加密解密爲同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等。
非對稱加密：密鑰成對出現（且根據公鑰沒法推知私鑰，根據私鑰也沒法推知公鑰），加密解密使用不一樣密鑰（公鑰加密須要私鑰解密，私鑰加密須要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

13.二、HTTPS通訊過程

13.三、HTTPS通訊的優勢
客戶端產生的密鑰只有客戶端和服務器端能獲得；
加密的數據只有客戶端和服務器端才能獲得明文；
客戶端到服務端的通訊是安全的。

十4、http的狀態響應碼

1**(信息類)：表示接收到請求而且繼續處理
100——客戶必須繼續發出請求
101——客戶要求服務器根據請求轉換HTTP協議版本

2**(響應成功)：表示動做被成功接收、理解和接受
200——代表該請求被成功地完成，所請求的資源發送回客戶端
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不肯定或不完整
204——請求收到，但返回信息爲空
205——服務器完成了請求，用戶代理必須復位當前已經瀏覽過的文件
206——服務器已經完成了部分用戶的GET請求

3**(重定向類)：爲了完成指定的動做，必須接受進一步處理
300——請求的資源可在多處獲得
301——本網頁被永久性轉移到另外一個URL
302——請求的網頁被轉移到一個新的地址，但客戶訪問仍繼續經過原始URL地址，重定向，新的URL會在response中的Location中返回，瀏覽器將會使用新的URL發出新的Request。
303——建議客戶訪問其餘URL或訪問方式
304——自從上次請求後，請求的網頁未修改過，服務器返回此響應時，不會返回網頁內容，表明上次的文檔已經被緩存了，還能夠繼續使用
305——請求的資源必須從服務器指定的地址獲得
306——前一版本HTTP中使用的代碼，現行版本中再也不使用
307——申明請求的資源臨時性刪除

4**(客戶端錯誤類)：請求包含錯誤語法或不能正確執行
400——客戶端請求有語法錯誤，不能被服務器所理解
401——請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用
HTTP 401.1 - 未受權：登陸失敗
　　HTTP 401.2 - 未受權：服務器配置問題致使登陸失敗
　　HTTP 401.3 - ACL 禁止訪問資源
　　HTTP 401.4 - 未受權：受權被篩選器拒絕
HTTP 401.5 - 未受權：ISAPI 或 CGI 受權失敗
402——保留有效ChargeTo頭響應
403——禁止訪問，服務器收到請求，可是拒絕提供服務
HTTP 403.1 禁止訪問：禁止可執行訪問
　　HTTP 403.2 - 禁止訪問：禁止讀訪問
　　HTTP 403.3 - 禁止訪問：禁止寫訪問
　　HTTP 403.4 - 禁止訪問：要求 SSL
　　HTTP 403.5 - 禁止訪問：要求 SSL 128
　　HTTP 403.6 - 禁止訪問：IP 地址被拒絕
　　HTTP 403.7 - 禁止訪問：要求客戶證書
　　HTTP 403.8 - 禁止訪問：禁止站點訪問
　　HTTP 403.9 - 禁止訪問：鏈接的用戶過多
　　HTTP 403.10 - 禁止訪問：配置無效
　　HTTP 403.11 - 禁止訪問：密碼更改
　　HTTP 403.12 - 禁止訪問：映射器拒絕訪問
　　HTTP 403.13 - 禁止訪問：客戶證書已被吊銷
　　HTTP 403.15 - 禁止訪問：客戶訪問許可過多
　　HTTP 403.16 - 禁止訪問：客戶證書不可信或者無效
HTTP 403.17 - 禁止訪問：客戶證書已經到期或者還沒有生效
404——一個404錯誤代表可鏈接服務器，但服務器沒法取得所請求的網頁，請求資源不存在。eg：輸入了錯誤的URL
405——用戶在Request-Line字段定義的方法不容許
406——根據用戶發送的Accept拖，請求資源不可訪問
407——相似401，用戶必須首先在代理服務器上獲得受權
408——客戶端沒有在用戶指定的餓時間內完成請求
409——對當前資源狀態，請求不能完成
410——服務器上再也不有此資源且無進一步的參考地址
411——服務器拒絕用戶定義的Content-Length屬性請求
412——一個或多個請求頭字段在當前請求中錯誤
413——請求的資源大於服務器容許的大小
414——請求的資源URL長於服務器容許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段，在當前請求資源範圍內沒有range指示值，請求也不包含If-Range請求頭字段
417——服務器不知足請求Expect頭字段指定的指望值，若是是代理服務器，多是下一級服務器不能知足請求長。

5**(服務端錯誤類)：服務器不能正確執行一個正確的請求
HTTP 500 - 服務器遇到錯誤，沒法完成請求
　　HTTP 500.100 - 內部服務器錯誤 - ASP 錯誤
　　HTTP 500-11 服務器關閉
　　HTTP 500-12 應用程序從新啓動
　　HTTP 500-13 - 服務器太忙
　　HTTP 500-14 - 應用程序無效
　　HTTP 500-15 - 不容許請求 global.asa
　　Error 501 - 未實現
HTTP 502 - 網關錯誤
HTTP 503：因爲超載或停機維護，服務器目前沒法使用，一段時間後可能恢復正常