BurpSuite工具-HTTP協定詳解部分(不懂就查系列)

目錄

一、概念

二、簡史

三、特點

四、工作流程

​五、使用Wireshark抓TCP、http包

六、頭域

6.1、請求資訊：

6.2、請求方法

6.3、響應消息

 6.4、響應頭域

6.5、HTTP常見的請求頭（在HTTP/1.1 協定中，所有的請求頭，除Host外，都是可選的）

6.6、HTTP常見的響應頭

七、解決HTTP無狀态的問題

7.1、通過Cookies儲存狀态資訊

7.2、通過Session儲存狀态資訊

7.3、通過表單變量保持狀态

7.4、通過QueryString保持狀态

八、使用telnet進行http測試

九、URL詳解

十、緩存的實作原理

10.1、緩存的優點

10.2、用戶端緩存生效的常見流程

10.3、Web緩存機制

十一、HTTP應用

11.1、斷點續傳的實作原理

11.2、多線程下載下傳的原理

11.3、http代理

11.4、虛拟主機

十二、HTTP認證方式

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

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

十三、HTTPS傳輸協定原理

13.1、兩種基本的加解密算法類型

13.2、HTTPS通信過程

13.3、HTTPS通信的優點

十四、http的狀态響應碼

一、概念

協定是指計算機通信網絡中兩台計算機之間進行通信所必須共同遵守的規定或規則，超文本傳輸協定(HTTP)是一種通信協定，它允許将超文本标記語言(HTML)文檔從Web伺服器傳送到用戶端的浏覽器。

HTTP協定，即超文本傳輸協定(Hypertext transfer protocol)。是一種詳細規定了浏覽器和網際網路(W W W = World Wide Web)伺服器之間互相通信的規則，通過網際網路傳送網際網路文檔的資料傳送協定。

HTTP協定是用于從W W W伺服器傳輸超文本到本地浏覽器的傳送協定。它可以使浏覽器更加高效，使網絡傳輸減少。它 不僅保證計算機正确快速地傳輸超文本文檔，還确定傳輸文檔中的哪一部分，以及哪部分内容首先顯示(如文本先于圖 形)等。

HTTP是一個應用層協定，由請求和響應構成，是一個标準的用戶端伺服器模型。HTTP是一個無狀态的協定。 在Internet中所有的傳輸都是通過TCP/IP進行的。HTTP協定作為TCP/IP模型中應用層的協定也不例外。HTTP協定通 常承載于TCP協定之上，有時也承載于TLS或SSL協定層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：

HTTP預設的端口号為80，HTTPS的端口号為443。

浏覽網頁是HTTP的主要應用，但是這并不代表HTTP就隻能應用于網頁的浏覽。HTTP是一種協定，隻要通信的雙方都 遵守這個協定，HTTP就能有用武之地。比如咱們常用的QQ，迅雷這些軟體，都會使用HTTP協定(還包括其他的協定)。

二、簡史

它的發展是網際網路協會（W orld W ide W eb Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終釋出了一系列的RFC，RFC1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。

三、特點

HTTP協定永遠都是用戶端發起請求，伺服器回送響應。這樣就限制了使用HTTP協定，無法實作在用戶端沒有發起請求 的時候，伺服器将消息推送給用戶端。

HTTP協定的主要特點可概括如下：

1、支援客戶/伺服器模式。支援基本認證和安全認證。

2、簡單快速：客戶向伺服器請求服務時，隻需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方 法規定了客戶與伺服器聯系的類型不同。由于HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通信速度很快。

3、靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type加以标記。

4、HTTP 0.9和1.0使用非持續連接配接：限制每次連接配接隻處理一個請求，伺服器處理完客戶的請求，并收到客戶的應答 後，即斷開連接配接。HTTP 1.1使用持續連接配接：不必為每個web對象建立一個新的連接配接，一個連接配接可以傳送多個對象，采用 這種方式可以節省傳輸時間。

5、無狀态：HTTP協定是無狀态協定。無狀态是指協定對于事務處理沒有記憶能力。缺少狀态意味着如果後續處理需要 前面的資訊，則它必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。

無狀态協定:

協定的狀态是指下一次傳輸可以“記住”這次傳輸資訊的能力。

http是不會為了下一次連接配接而維護這次連接配接所傳輸的資訊,為了保證伺服器記憶體。 比如客戶獲得一張網頁之後關閉浏覽器，然後再一次啟動浏覽器，再登陸該網站,但是伺服器并不知道客戶關閉了一次浏覽器。

由于Web伺服器要面對很多浏覽器的并發通路,為了提高W eb伺服器對并發通路的處理能力，在設計HTTP協定時規定 W eb伺服器發送HTTP應答封包和文檔時,不儲存送出請求的W eb浏覽器程序的任何狀态資訊。這有可能出現一個浏覽器在短短幾秒之内兩次通路同一對象時，伺服器程序不會因為已經給它發過應答封包而不接受第二期服務請求。由于 Web伺服器不儲存發送請求的W eb浏覽器程序的任何資訊，是以HTTP協定屬于無狀态協定（Stateless Protocol）。

HTTP協定是無狀态的和Connection: keep-alive的差別：

無狀态是指協定對于事務處理沒有記憶能力，伺服器不知道用戶端是什麼狀态。從另一方面講，打開一個伺服器上的網 頁和你之前打開這個伺服器上的網頁之間沒有任何聯系。

HTTP是一個無狀态的面向連接配接的協定，無狀态不代表HTTP不能保持TCP連接配接，更不能代表HTTP使用的是UDP協定 （無連接配接）。

從HTTP/1.1起，預設都開啟了Keep-Alive，保持連接配接特性，簡單地說，當一個網頁打開完成後，用戶端和伺服器之間 用于傳輸HTTP資料的TCP連接配接不會關閉，如果用戶端再次通路這個伺服器上的網頁，會繼續使用這一條已經建立的連接配接。

Keep-Alive不會永久保持連接配接，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。

四、工作流程

一次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頭設定)這是預設行為。

五、使用Wireshark抓TCP、http包

打開W ireshark，選擇工具欄上的"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）确認； 

7）No8：用戶端浏覽器（192.168.1.6）确認；

8）No81：用戶端（192.168.1.6）發出一個圖檔HTTP請求；

9）No202：伺服器（115.239.210.36）發送狀态響應碼200 OK。 

六、頭域

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

6.1、請求資訊：

發出的請求資訊格式如下：

●請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請求logo.gif這個檔案。

●（請求）頭，例如Accept-Language: en

●空行

●可選的消息體 請求行和标題必須以作為結尾（也就是，回車然後換行）。空行内必須隻有 而無其他空格。在HTTP/1.1協定中，所有的請求頭，除post外，都是可選的。

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

6.2、請求方法

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的差別：

1、GET送出的資料會放在URL之後，以?分割URL和傳輸資料，參數之間以&相連，如EditPosts.aspx? name=test1&id=123456. POST方法是把送出的資料放在HTTP包的Body中。

2、GET送出的資料大小有限制，最多隻能有1024位元組（因為浏覽器對URL的長度有限制），而POST方法送出的資料沒 有限制。

3、GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來擷取變量的值。

4、GET方式送出資料，會帶來安全問題，比如一個登入頁面，通過GET方式送出資料時，使用者名和密碼将出現在URL 上，如果頁面可以被緩存或者其他人可以通路這台機器，就可以從曆史記錄獲得該使用者的賬号和密碼。

6.3、響應消息

用戶端向伺服器發送一個請求，伺服器以一個狀态行作為響應，響應的内容包括：消息協定的版本、成功或者錯誤編 碼、伺服器資訊、實體元資訊以及必要的實體内容。根據響應類别的類别，伺服器響應裡可以含實體内容，但不是所有 的響應都有實體内容。

響應頭第一行也稱為狀态行，格式如下（下圖中紅線标出的那行）：

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.4、響應頭域

伺服器需要傳遞許多附加資訊，這些資訊不能全放在狀态行裡。是以，需要另行定義響應頭域，用來描述這些附加信 息。響應頭域主要描述伺服器的資訊和Request-URI的資訊。

6.5、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; W indows 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：授權資訊，通常出現在對伺服器發送的W W W -Authenticate頭的應答中。主要用于證明用戶端有權檢視某個資源。當浏覽器通路一個頁面時，如果收到伺服器的響應代碼為401（未授權），可以發送一個包含 Authorization請求報頭域的請求，要求伺服器對其進行驗證。

UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE浏覽器所發送的非标準的請求頭，表示螢幕大小、顔色深 度、作業系統和CPU類型。

From：請求發送者的email位址，由一些特殊的W eb客戶程式使用，浏覽器不會用到它。

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.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：指明實體正文的長度，以位元組方式存儲的十進制數字來表示。在資料下行的過程中，ContentLength的方式要預先在伺服器中緩存所有資料，然後所有資料再一股腦兒地發給用戶端。隻有當浏覽器使用持久HTTP 連接配接時才需要這個資料。如果你想要利用持久連接配接的優勢，可以把輸出文檔寫入ByteArrayOutputStram，完成後檢視其大小，然後把該值放入Content-Length頭，最後通過 byteArrayStream.writeTo(response.getOutputStream()發送内容。

例如: Content-Length: 19847

Content-Encoding：W EB伺服器表明自己使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。隻有在解碼之 後才可以得到Content-Type頭指定的内容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載下傳時間。Java的 GZIPOutputStream可以很友善地進行gzip壓縮，但隻有Unix上的Netscape和W indows上的IE 4、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.5、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區的實作，這是因 為，自動重新整理或重定向對于那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設定 Refresh頭更加友善。注意Refresh的意義是“N秒之後重新整理本頁面或通路指定頁面”，而不是“每隔N秒重新整理本頁面或通路 指定頁面”。是以，連續重新整理要求每次都發送一個Refresh頭，而發送204狀态代碼則可以阻止浏覽器繼續重新整理，不管是 使用Refresh頭還是。注意Refresh頭不屬于HTTP 1.1正式規範的一部分，而 是一個擴充，但Netscape和IE都支援它。

WWW -Authenticate：該響應報頭域必須被包含在401（未授權的）響應消息中，用戶端收到401響應消息時候，并發送Authorization報頭域請求伺服器對其進行驗證時，服務端響應報頭就包含該報頭域。

eg：WWW -Authenticate:Basic realm="Basic Auth Test!" //可以看出伺服器對請求資源采用的是基本驗證機制。

七、解決HTTP無狀态的問題

7.1、通過Cookies儲存狀态資訊

通過Cookies，伺服器就可以清楚的知道請求2和請求1來自同一個用戶端。

7.2、通過Session儲存狀态資訊

Session機制是一種伺服器端的機制，伺服器使用一種類似于散清單的結構（也可能就是使用散清單）來儲存資訊。 當程式需要為某個用戶端的請求建立一個session的時候，伺服器首先檢查這個用戶端的請求裡是否已包含了一個 session辨別 - 稱為 session id，如果已包含一個session id則說明以前已經為此用戶端建立過session，伺服器就按 照session id把這個 session檢索出來使用（如果檢索不到，可能會建立一個），如果用戶端請求不包含session id， 則為此用戶端建立一個session并且生成一個與此session相關聯的session id，session id的值應該是一個既不會重 複，又不容易被找到規律以仿造的字元串，這個session id将被在本次響應中傳回給用戶端儲存。

Session的實作方式：

1、使用Cookie來實作

伺服器給每個Session配置設定一個唯一的JSESSIONID，并通過Cookie發送給用戶端。 當用戶端發起新的請求的時候，将在Cookie頭中攜帶這個JSESSIONID。這樣伺服器能夠找到這個用戶端對應的 Session。

2、使用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.3、通過表單變量保持狀态

除了Cookies之外，還可以使用表單變量來保持狀态，比如Asp.net就通過一個叫ViewState的Input=“hidden”的框 來保持狀态,比如:

這個原理和Cookies大同小異，隻是每次請求和響應所附帶的資訊變成了表單變量。

7.4、通過QueryString保持狀态

QueryString通過将資訊儲存在所請求位址的末尾來向伺服器傳送資訊，通常和表單結合使用，一個典型的QueryString比如:www.xxx.com/xxx.aspx?var1=value&var2=value2

八、使用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

九、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 

十、緩存的實作原理

WEB緩存(cache)位于W eb伺服器和用戶端之間。

緩存會根據請求儲存輸出内容的副本，例如html頁面，圖檔，檔案，當下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應通路請求，而不是向源伺服器再次發送請求。

HTTP協定定義了相關的消息頭來使WEB緩存盡可能好的工作。

10.1、緩存的優點

減少相應延遲：因為請求從緩存伺服器（離用戶端更近）而不是源伺服器被相應，這個過程耗時更少，讓web伺服器看上去相應更快。

減少網絡帶寬消耗：當副本被重用時會減低用戶端的帶寬消耗；客戶可以節省帶寬費用，控制帶寬的需求的增長并更易于管理。

10.2、用戶端緩存生效的常見流程

伺服器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭，用戶端将該資源儲存在cache中，并記錄這 兩個屬性。當用戶端需要發送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的 值分别是響應中Last-Modified和ETag頭的值。伺服器通過這兩個頭判斷本地資源未發生變化，用戶端不需要重新下 載，傳回304響應。

10.3、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的請求的話，緩存就會過期。

十一、HTTP應用

11.1、斷點續傳的實作原理

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.2、多線程下載下傳的原理

下載下傳工具開啟多個發出HTTP請求的線程；

每個http請求隻請求資源檔案的一部分：Content-Range: bytes 20000-40000/47000；

合并每個線程下載下傳的檔案。

11.3、http代理

http代理伺服器

代理伺服器英文全稱是Proxy Server，其功能就是代理網絡使用者去取得網絡資訊。形象的說：它是網絡資訊的中轉站。 代理伺服器是介于浏覽器和W eb伺服器之間的一台伺服器，有了它之後，浏覽器不是直接到W eb伺服器去取回網頁而是 向代理伺服器送出請求，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.4、虛拟主機

虛拟主機：是在網絡伺服器上劃分出一定的磁盤空間供使用者放置站點、應用元件等，提供必要的站點功能與資料存放、 傳輸功能。

所謂虛拟主機，也叫“網站空間”就是把一台運作在網際網路上的伺服器劃分成多個“虛拟”的伺服器，每一個虛拟主機都具有 獨立的域名和完整的Internet伺服器（支援W W W、FTP、E-mail等）功能。一台伺服器上的不同虛拟主機是各自獨立 的，并由使用者自行管理。但一台伺服器主機隻能夠支援一定數量的虛拟主機，當超過這個數量時，使用者将會感到性能急劇下降。

虛拟主機的實作原理

虛拟主機是用同一個WEB伺服器，為不同域名網站提供服務的技術。Apache、Tomcat等均可通過配置實作這個功能。 相關的HTTP消息頭：Host。

例如：Host: www.baidu.com

用戶端發送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是用戶端輸入的域名。這樣伺服器可以根據Host頭确認客戶要通路的是哪一個域名。

十二、HTTP認證方式

HTTP請求報頭： Authorization

HTTP響應報頭： W W W -Authenticate

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

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

基本認證是一種用來允許Web浏覽器或其他用戶端程式在請求時提供使用者名和密碼形式的身份憑證的一種登入驗證方式。

把 "使用者名+冒号+密碼"用BASE64算法加密後的字元串放在http request 中的header Authorization中發送給服務端。

用戶端對于每一個realm，通過提供使用者名和密碼來進行認證的方式。

包含密碼的明文傳遞。

當浏覽器通路使用基本認證的網站的時候， 浏覽器會提示你輸入使用者名和密碼，如下圖：

假如使用者名密碼錯誤的話，伺服器會傳回401，如下圖：

基本認證步驟：

1、用戶端通路一個受http基本認證保護的資源。

2、伺服器傳回401狀态，要求用戶端提供使用者名和密碼進行認證。（驗證失敗的時候，響應頭會加上W W W - Authenticate: Basic realm="請求域"。） 401 Unauthorized W W W -Authenticate： Basic realm="W allyW orld"

3、用戶端将輸入的使用者名密碼用Base64進行編碼後，采用非加密的明文方式傳送給伺服器。 Authorization: Basic xxxxxxxxxx.

4、伺服器将Authorization頭中的使用者名密碼解碼并取出，進行驗證，如果認證成功，則傳回相應的資源。如果認證失敗，則仍傳回401狀态，要求重新進行認證。

特記事項：

1、Http是無狀态的，同一個用戶端對同一個realm内資源的每一個通路會被要求進行認證。

2、用戶端通常會緩存使用者名和密碼，并和authentication realm一起儲存，是以，一般不需要你重新輸入使用者名和密碼。

3、以非加密的明文方式傳輸，雖然轉換成了不易被人直接識别的字元串，但是無法防止使用者名密碼被惡意盜用。雖然用肉眼看不出來，但用程式很容易解密。

優點：

基本認證的一個優點是基本上所有流行的網頁浏覽器都支援基本認證。基本認證很少在可公開通路的網際網路網站上使用，有時候會在小的私有系統中使用（如路由器 網頁管理接口）。後來的機制HTTP摘要認證是為替代基本認證而開發的，允許密鑰以相對安全的方式在不安全的通道上傳輸。

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

缺點：雖然基本認證非常容易實作，但該方案建立在以下的假設的基礎上，即：用戶端和伺服器主機之間的連接配接是安全可信 的。特别是，如果沒有使用SSL/TLS這樣的傳輸 層安全的協定，那麼以明文傳輸的密鑰和密碼很容易被攔截。該方案也同樣沒有對伺服器傳回的資訊提供保護。

現存的浏覽器儲存認證資訊直到标簽頁或浏覽器被關閉，或者使用者清除曆史記錄。HTTP沒有為伺服器提供一種方法訓示 用戶端丢棄這些被緩存的密鑰。這意味着服務 器端在使用者不關閉浏覽器的情況下，并沒有一種有效的方法來讓使用者登出。

一個例子：這一個典型的HTTP用戶端和HTTP伺服器的對話，伺服器安裝在同一台計算機上（localhost），包含以下步驟：

用戶端請求一個需要身份認證的頁面，但是沒有提供使用者名和密碼。這通常是使用者在位址欄輸入一個URL，或是打開了一個指向該頁面的連結。服務端響應一個401應答碼，并提供一個認證域。

接到應答後，用戶端顯示該認證域（通常是所通路的計算機或系統的描述）給使用者并提示輸 入使用者名和密碼。此時使用者可以選擇确定或取消。使用者輸入了使用者名和密碼後，用戶端軟體會在原先的請求上增加認證消息頭（值是                         base64encode(username+":"+password)），然後重新發送再次嘗試。

在本例中，伺服器接受了該認證螢幕并傳回了頁面。如果使用者憑據非法或無效，伺服器可能再次傳回401應答碼，用戶端可以再次提示使用者輸入密碼。

注意:用戶端有可能不需要使用者互動，在第一次請求中就發送認證消息頭。

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

這個認證可以看做是基本認證的增強版本，不包含密碼的明文傳遞。

引入了一系列安全增強的選項；“保護品質”(qop)、随機數計數器由用戶端增加、以及客戶生成的随機數。

 在HTTP摘要認證中使用 MD5 加密是為了達成"不可逆的"，也就是說，當輸出已知的時候，确定原始的輸入應該是相當 困難的。

如果密碼本身太過簡單，也許可以 通過嘗試所有可能的輸入來找到對應的輸出（窮舉攻擊），甚至可以通過字典或者适當的查找表加快查找速度。

示例及說明

下面的例子僅僅涵蓋了“auth”保護品質的代碼，因為在撰寫期間，所知道的隻有Opera和Konqueror網頁浏覽器支 持“auth-int”（帶完整性保護的認證）。

典型的認證過程包括如下步驟：

用戶端請求一個需要認證的頁面，但是不提供使用者名和密碼。通常這是由于使用者簡單的輸入了一個位址或者在頁面中點選了某個超連結。

伺服器傳回401 "Unauthorized" 響應代碼，并提供認證域(realm)，以及一個随機生成的、隻使用一次的數值，稱為 密碼随機數 nonce。

此時，浏覽器會向使用者提示認證域(realm)（通常是所通路的計算機或系統的描述），并且提示使用者名和密碼。使用者此時可以選擇取消。

一旦提供了使用者名和密碼，用戶端會重新發送同樣的請求，但是添加了一個認證頭包括了響應代碼。 注意：用戶端可能已經擁有了使用者名和密碼，是以不需要提示使用者，比如以前存儲在浏覽器裡的。

response 值由三步計算而成。當多個數值合并的時候，使用冒号作為分割符：

1、對使用者名、認證域(realm)以及密碼的合并值計算 MD5 哈希值，結果稱為 HA1。

2、對HTTP方法以及URI的摘要的合并值計算 MD5 哈希值，例如，"GET" 和 "/dir/index.html"，結果稱為 HA2。

3、對HA1、伺服器密碼随機數(nonce)、請求計數(nc)、用戶端密碼随機數(cnonce)、保護品質(qop)以及 HA2 的合 并值計算 MD5 哈希值。結果即為用戶端提供的 response 值。 

 因為伺服器擁有與用戶端同樣的資訊，是以伺服器可以進行同樣的計算，以驗證用戶端送出的 response 值的正确性。 在上面給出的例子中，結果是如下計算的。

（MD5()表示用于計算MD5哈希值的函數；“\”表示接下一行；引号并不參與計算）

HA1 = MD5( "Mufasa:[email protected]: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：以上隻介紹了兩種比較基礎的，還有其他的一些認證方式就不在這裡一一說明了。

十三、HTTPS傳輸協定原理

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

 13.1、兩種基本的加解密算法類型

對稱加密：密鑰隻有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等。 非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加 密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

13.2、HTTPS通信過程

 13.3、HTTPS通信的優點

用戶端産生的密鑰隻有用戶端和伺服器端能得到；

加密的資料隻有用戶端和伺服器端才能得到明文；

用戶端到服務端的通信是安全的。

十四、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報頭域一起使用

HTTP401.1 - 未授權：登入失敗 

HTTP401.2 - 未授權：伺服器配置問題導緻登入失敗 

HTTP401.3 - ACL 禁止通路資源 

HTTP401.4 - 未授權：授權被篩選器拒絕 

HTTP401.5 - 未授權：ISAPI 或 CGI 授權失敗

402——保留有效ChargeTo頭響應

403——禁止通路，伺服器收到請求，但是拒絕提供服務

HTTP403.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：由于超載或停機維護，伺服器目前無法使用，一段時間後可能恢複正常。