第一篇：HTTP協議學習心得體會
HTTP協議學習心得體會
HTTP(HyperText Transfer Protocol)
====================================
是TCP/IP協議集中的一個應用層協議，用于定義瀏覽器和Web服務器之間交換數據的過程以及數據本身的格式。現在被廣泛使用的是HTTP1.1，相對于1.0，1.1的最大特點是支持持續連接。
基于HTTP1.0協議的客戶機與服務器的信息交換過程包括四個步驟：建立連接；發送請求信息；回送響應信息；關閉連接。
通信過程總是通過瀏覽器發送請求來啟動的，Web服務器則是被動地對這些請求作出響應。HTTP協議是無狀態的。
HTTP1.1與HTTP1.0的比較
------
HTTP1.0規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理后立即斷開TCP連接。服務器不跟蹤每個客戶機，也不記錄過去的請求。為了克服HTTP1.0的這個缺陷，HTTP1.1支持持久連接，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。HTTP1.1還允許客戶端不用等待上一次請求結果返回，就可以發送下一次請求，但服務器端必須按照接受到客戶端請求的先后順序依次回送響應結果，以保證客戶端能夠區分出每次請求的響應內容。
HTTP1.1還增加了host請求頭字段，用于明確表示訪問服務器上的哪個web站點，可以在一個IP地址和端口號上使用不同的主機名來創建多個虛擬web站點。HTTP1.1還有keep-alive請求頭來支持持續連接。
HTTP消息的格式
-----------------------
一個完整的請求消息包括：一個請求行，若干消息頭，以及實體內容，其中消息頭和實體內容都是可選的。消息頭和實體內容之間要用空行隔開。瀏覽器使用GET方式的請求消息可以放松不含實體內容的請求消息。只有使用POST, PUT, DELETE方式的請求消息中才可以包含實體內容。
Hypertext Transfer Protocol
GET / HTTP/1.1rn
Request Method: GET
Request URI: /
Request Version: HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap,application/x-shockwave-flash, application/vnd.ms-excel, application/vn
Accept-Language: zh-cnrn
UA-CPU: x86rn
Accept-Encoding: gzip, deflatern
User-Agent: Mozilla/4.0(compatible;MSIE 7.0;Windows NT 6.0;SLCC1;.NET CLR
2.0.50727;.NET CLR 3.0.04506)rn
Connection: Keep-Alivern
rn
一個完整的響應消息包括：一個狀態行，若干消息頭，以及實體內容。同樣，消息頭和實體內容都是可選的。消息頭和實體內容之間要用空行隔開。消息響應的實體內容就是網頁文檔的內容。
Hypertext Transfer Protocol
HTTP/1.1 200 OKrn
Request Version: HTTP/1.1
Response Code: 200
Cache-Control: privatern
Content-Type: text/html;charset=UTF-8rn
Set-Cookie:
PREF=ID=7f53f6f0b1511417:NW=1:TM=1205568884:LM=1205568884:S=zHreYqNC-Z3rmOc6;expires=Mon, 15-Mar-2010 08:14:44 GMT;path=/;domain=.google.cnrn
Content-Encoding: gziprn
Server: gwsrn
Transfer-Encoding: chunkedrn
Date: Sat, 15 Mar 2008 08:14:44 GMTrn
rn
HTTP chunked response
Data chunk(1025 octets)
Chunk size: 1025 octets
Data(1025 bytes)
HTTP消息頭
----------------
HTTP請求和響應都使用消息頭來描述HTTP消息本身的信息，可以實現HTTP客戶機與服務器之間的條件請求和應答。
消息頭可以分為：通用消息頭，請求頭，響應頭，實體頭四類。
請求行與狀態行
-----------------------
請求消息的請求行包括三個部分：請求方式，資源路徑，以及使用的HTTP版本。如：GET /
HTTP/1.1rn。
響應消息的狀態行包括三個部分：HTTP協議的版本號，一個表示成功或者失敗的整數代碼（狀態碼）和對狀態碼進行描述的文本信息。如：HTTP/1.1 200 OKrn。
使用GET和POST方式傳遞參數
-------------
在URL地址后面可以附加一些參數，每個參數由參數名和參數值組成，例如：當使用GET方式提交表單內容時，瀏覽器將各個表單字段元素及其數據按照URL參數的格式附加在請求行中的資源路徑后面。使用GET方式傳送的數據量有限制，一般在1KB以下。
當使用POST方式提交表單內容時，瀏覽器將個表單字段元素及其數據作為HTTP消息的實體內容發送給服務器。因此數據量可以比GET方式大的多。使用POST方式時，還必須將Content-Type消息頭設置為“application/x-www-form-urlencoded”，將Content-length消息頭設置為實體內容的長度。
響應狀態碼
---------------
1.100~199: 成功接受請求，要求客戶端繼續提交下一次請求才能完成整個處理過程。
2.200~299: 成功接受請求并已完成整個處理過程。
3.300~399: 為完成請求，客戶端需要進一步細化請求。
4.400~499: 客戶端的請求有錯誤。
5.500~599: 服務器段出現錯誤。
通用信息頭
==============
即能用于請求消息，也能用于響應消息，包括一些與被傳輸的實體內容沒有關系的常用消息頭字段。
1.Cache-Control
2.Connection
3.Date
4.Pragma
5.Trailer
6.Transfer-Encoding
7.Upgrade
8.Via
9.Warning
Cache-Control
--------------------
如果位于請求消息頭，用于通知位于客戶機和服務之間的代理服務器如何使用已緩存的頁面，可以取值為：no-cache, no-store, max-age, max-stale, min-fresh, no-transform, only-if-cached等。
如果位于響應消息頭，用于通知客戶機和代理服務器如何緩存該頁面，可以取值為：public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, s-maxage等。
Connection
---------------
用于指定處理完本次請求/響應后，客戶端與服務器是否還要繼續保持連接。如果為Keep-Alive，則保持連接，如果為close，則關閉。HTTP1.1默認采用持久連接。
Date
---------
表示HTTP消息產生的當前時間。服務器回送的正常響應消息中，應該總是設置Date頭字段。如果客戶機發送的請求消息中包含有實體內容，也要設置Date。
Pragma
------------
只能固定為no-cache.Trailer
-----------
一些頭字段可以放置在整個HTTP消息的尾部。
Transfer-Encoding
---------------------
指定傳輸編碼方式，目前標準的設置值只有chunked，用于把整個消息分成一連串的分段后進行傳輸。
Upgrade
------------
允許客戶機指定它所支持并希望將當前協議切換到的通信協議。
Via
-----
用于指定HTTP消息所途徑的中介代理服務器名稱和所使用的協議。
請求頭
=========
客戶端可以接受的數據類型，壓縮方法，語言，以及發出請求的超鏈接所屬頁面的URL地址等信息。Accept：指出客戶端程序能夠處理的MIME類型。
Accept-Charset：用于指出客戶端程序可以使用的字符集。
Accept-Encoding：客戶機能夠進行解碼的數據編碼方式。
Accept-Language：指定客戶機期望服務器返回哪個國家語言的文檔。
Authorization：兩種認證方式BASIC，和DIGEST.Except:
From:
Host: 指定資源所在的主機號和端口號。HTTP1.1中每個請求消息中都必須包含Host請求字段。If-Match:
If-Modified-Since:
If-None-Match:
If-Range
If-Unmodified-Since
Max-Forwards:
Proxy-Authorization:
Range:
Referer: 當單擊另一個網頁上的超鏈接時發出的請求在Referer字段中指定URL。
TE：
User-Agent:
響應頭
==========
Accept-Range, Age, Etag,Location: 用于通知客戶機應當到哪個新的地址去獲取文檔。狀態碼為300~399的響應消息都應該使用Location字段將新的文檔地址告訴客戶機，以便客戶機自動重新連接到新地址并檢索新文檔。使用Location頭的HTTP消息不應該有實體內容。所以，HTTP消息頭中不能同時出現Location和Content-Type這兩個頭字段。
Proxy-Authenticate，Retry-After, Server, Vary, WWW-Authenticate。
實體頭
========
是實體內容的元信息，描述了實體內容的屬性，包括實體信息類型、長度、壓縮方法、最后一次修改時間、數據有效期等。
Allow: 指定客戶端請求的資源所支持的請求方法（如GET，POST等）。
Content-Encoding: 指定實體內容的壓縮編碼方式。
Content-Language:
Content-Length: 用于表示實體內容的長度（字節數），瀏覽器與Web服務器之間使用持久連接時，這個字段在非Chunked傳輸編碼的響應消息中是必不可少的。
Content-Location: 指定響應消息中所封裝的實體內容的實際位置路徑。
Content-MD5, Content-Range, Content-Type
Expires: 指定當前文檔應該在什么時候被認為過期，瀏覽器到哪個時候以后不能再繼續使用本地緩存，而是在有需要時應該像服務器發出新的請求訪問。
Last-Modified：文檔的最后更改時間。
擴展頭
========
現在流行的瀏覽器實際上都支持Cookie，Set-Cookie，Refresh和Content-Disposition等幾個常用的擴展頭字段。
Refresh: 告訴瀏覽器多少秒后自動刷新頁面。
第二篇：http協議介紹（模版）
（二）召開會議
民主生活會上，班子成員要緊緊圍繞主題和征求到的意見建議，認真開展黨性分析，深入查找問題，實事求是開展批評與自我批評。順序為先班子、后個人，先主要負責人、后其他班子成員。黨組織書記要對班子成員的發言逐個進行評議，班子成員之間也要互相進行評議，幫助查找存在的問題，提出改進的意見建議。
（三）會后工作。
領導班子要針對群眾普遍關心、反映強烈和民主生活會上查找出來的問題，提出切實有效的整改措施，明確具體責任人和整改時限。班子成員也要制定和落實個人整改措施。本次民主生活會形成的整改措施和干部群眾對上次民主生活會形成的整改落實情況的滿意度，會后要在一定范圍向干部群眾通報，確保整改措施落到實處。會后6天內上報民主生活會情況報告，報告要附有會前征求到的干部群眾意見材料、會后制定的整改措施。
六、會議要求
（一）召開民主生活會，提前10天向街道黨工委報告，主動接受指導和監督。
（二）制定落實整改措施。民主生活會后，辦公室、黨員領導領導干部要根據民主生活會情況，進一步查找問題，逐項研究，深入分析，制定出切實可行的整改措施和方案。同時要把學習貫徹黨的十七大精神同同履行崗位職責結合起來，切實轉變作風，做好本職工作，提高工作效率和和工作水平，發揮好黨員領導干部表率帶動作用。
（三）上報民主生活會情況。召開民主生活會的情況、原始記錄、會前征求意見、整改措施和方案及上次民主生活會整改措施落實情況，要及時上報街道黨工委備案。
第三篇：常用的HTTP協議狀態碼
常用的HTTP協議狀態碼
200Standard response for successful HTTP requests.301This and all future requests should be directed to the given.403forbidden request(matches a deny filter)=> HTTP 403
Not Found,服務器找不到請求的頁面。
Internal Server Error（內部服務器錯誤）
A generic error message, given when no more specific message is suitable.502the server returned an invalid or incomplete response => HTTP 502
Service Unavailable（服務當前不可用）,可能因為超載或停機維護。
The server is currently unavailable(because it is overloaded or down for maintenance).504the server failed to reply in time => HTTP 504
-The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.更多：
一些常見HTTP狀態碼為： 200 – 服務器成功返回網頁 404 – 請求的網頁不存在 503 – 服務不可用 常見HTTP狀態碼大全
1xx（臨時響應）
表示臨時響應并需要請求者繼續執行操作的狀態代碼。
代碼 說明
http狀態碼 100（繼續）請求者應當繼續提出請求。服務器返回此代碼表示已收到請求的第一部分，正在等待其余部分。
http狀態碼 101（切換協議）請求者已要求服務器切換協議，服務器已確認并準備切換。
2xx（成功）
表示成功處理了請求的狀態代碼。代碼 說明
http狀態碼 200（成功）服務器已成功處理了請求。通常，這表示服務器提供了請求的網頁。
http狀態碼 201（已創建）請求成功并且服務器創建了新的資源。http狀態碼 202（已接受）服務器已接受請求，但尚未處理。
http狀態碼 203（非授權信息）服務器已成功處理了請求，但返回的信息可能來自另一來源。
http狀態碼 204（無內容）服務器成功處理了請求，但沒有返回任何內容。http狀態碼 205（重置內容）服務器成功處理了請求，但沒有返回任何內容。http狀態碼 206（部分內容）服務器成功處理了部分 GET 請求。3xx（重定向）
表示要完成請求，需要進一步操作。通常，這些狀態代碼用來重定向。代碼 說明
http狀態碼 300（多種選擇）針對請求，服務器可執行多種操作。服務器可根據請求者(user agent)選擇一項操作，或提供操作列表供請求者選擇。http狀態碼 301（永久移動）請求的網頁已永久移動到新位置。服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。http狀態碼 302（臨時移動）服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。
http狀態碼 303（查看其他位置）請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。
http狀態碼 304（未修改）自從上次請求后，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。http狀態碼 305（使用代理）請求者只能使用代理訪問請求的網頁。如果服務器返回此響應，還表示請求者應使用代理。
http狀態碼 307（臨時重定向）服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。4xx（請求錯誤）
這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。
代碼 說明
http狀態碼 400（錯誤請求）服務器不理解請求的語法。
http狀態碼 401（未授權）請求要求身份驗證。對于需要登錄的網頁，服務器可能返回此響應。
http狀態碼 403（禁止）服務器拒絕請求。
http狀態碼 404（未找到）服務器找不到請求的網頁。http狀態碼 405（方法禁用）禁用請求中指定的方法。
http狀態碼 406（不接受）無法使用請求的內容特性響應請求的網頁。http狀態碼 407（需要代理授權）此狀態代碼與 401（未授權）類似，但指定請求者應當授權使用代理。
http狀態碼 408（請求超時）服務器等候請求時發生超時。
http狀態碼 409（沖突）服務器在完成請求時發生沖突。服務器必須在響應中包含有關沖突的信息。
http狀態碼 410（已刪除）如果請求的資源已永久刪除，服務器就會返回此響應。
http狀態碼 411（需要有效長度）服務器不接受不含有效內容長度標頭字段的請求。
http狀態碼 412（未滿足前提條件）服務器未滿足請求者在請求中設置的其中一個前提條件。
http狀態碼 413（請求實體過大）服務器無法處理請求，因為請求實體過大，超出服務器的處理能力。
http狀態碼 414（請求的 URI 過長）請求的 URI（通常為網址）過長，服務器無法處理。
http狀態碼 415（不支持的媒體類型）請求的格式不受請求頁面的支持。http狀態碼 416（請求范圍不符合要求）如果頁面無法提供請求的范圍，則服務器會返回此狀態代碼。
http狀態碼 417（未滿足期望值）服務器未滿足”期望”請求標頭字段的要求。
5xx（服務器錯誤）
這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。這些錯誤可能是服務器本身的錯誤，而不是請求出錯。
代碼 說明
http狀態碼 500（服務器內部錯誤）服務器遇到錯誤，無法完成請求。http狀態碼 501（尚未實施）服務器不具備完成請求的功能。例如，服務器無法識別請求方法時可能會返回此代碼。http狀態碼 502（錯誤網關）服務器作為網關或代理，從上游服務器收到無效響應。
http狀態碼 503（服務不可用）服務器目前無法使用（由于超載或停機維護）。通常，這只是暫時狀態。
http狀態碼 504（網關超時）服務器作為網關或代理，但是沒有及時從上游服務器收到請求。
http狀態碼 505（HTTP 版本不受支持）服務器不支持請求中所用的 HTTP 協議版本
第四篇：HTTP協議以及Python開發技巧
TTPYTHONhttp協議的相關知識應該都很清楚，這里簡單回顧下其流程。首先HTTP底層是利用TCP進行通訊的；其次，HTTP本身協議是面向無連接的：限制每次連接只處理一個請求，服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
Python采用httplib庫進行HTTP通訊，用法很簡單：
import httplib #導入httplib庫
conn = httplib.HTTPConnection(“10.197.32.136”,8080)#建立http鏈接，只需要IP地址和端口
conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str,{})#發送url請求
response = conn.getresponse()#獲取返回信息
conn.close()#關閉鏈接
request函數是非阻塞函數，也就是說，它向服務器發送了url請求之后，可以正常運行之后的任務。
getresponse函數是阻塞函數，如果沒有收到服務器的返回信息，程序將無法繼續。
close函數在任何地方都可以調用，因此，如果無需服務器返回信息，則可以在發送請求之后就關閉鏈接。
Httplib無法連續發送兩個request，例如：
conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str1,{})conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str2,{})
程序將會拋異常，并且關閉。因為http協議本身一次鏈接只支持一個request，在收到response或者關閉才能開啟下一次鏈接。所以，正常的程序應該是：
conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str1,{})
conn.close()
或者：
conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str1,{})
response = conn.getresponse()
conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str2,{})conn.request(“POST”,“/RealTimeServer/WebSocketDemo”,str2,{})
第五篇：http頭文件分析心得體會
http頭文件分析心得體會
一、http簡介
HTTP即超文本傳輸協議(Hypertext transfer protocol)。是一種詳細規定了瀏覽器和萬維網(“，結果稱為 HA2。
3、對HA1、服務器密碼隨機數(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。
語法：
challenge
= ”Digest“ digest-challenge
digest-challenge = 1#(realm | [ domain ] | nonce |
[ opaque ] |[ stale ] | [ algorithm ] |
[ qop-options ] | [auth-param])
domain
= ”domain“ ”=“ <”> URI(1*SP URI)<“>
URI
= absoluteURI | abs_path
nonce
= ”nonce“ ”=“ nonce-value
nonce-value
= quoted-string
opaque
= ”opaque“ ”=“ quoted-string
stale
= ”stale“ ”=“(”true“ | ”false“)
algorithm
= ”algorithm“ ”=“(”MD5“ | ”MD5-sess“ |
token)
qop-options
= ”qop“ ”=“ <”> 1#qop-value <“>
qop-value
= ”auth“ | ”auth-int“ | token
realm：讓客戶知道使用哪個用戶名和密碼的字符串。不同的領域可能密碼不一樣。至少告訴用戶是什么主機做認證，他可能會提示用哪個用戶名登錄，類似一個Email。
domain：一個URI列表，指示要保護的域。可能是一個列表。提示用戶這些URI采用一樣的認證。如果為空或忽略則為整個服務器。nonce：隨機字符串，每次401都不一樣。跟算法有關。算法類似Base64加密：time-stamp H(time-stamp ”:“ ETag ”:“ private-key)。time-stamp為服務器時鐘，ETag為請求的Etag頭。private-key為服務器知道的一個值。
opaque：服務器產生的由客戶下去請求時原樣返回。最好是Base64串或十六進制字符串。
auth-param：為擴展用的，現階段忽略。
其他域請參考RFC2617。
授權頭語法：
credentials
= ”Digest“ digest-response
digest-response = 1#(username | realm | nonce | digest-uri
| response | [ algorithm ] | [cnonce] |
[opaque] | [message-qop] |
[nonce-count] | [auth-param])
username
= ”username“ ”=“ username-value
username-value = quoted-string
digest-uri
= ”uri“ ”=“ digest-uri-value
digest-uri-value = request-uri;As specified by HTTP/1.1
message-qop
= ”qop“ ”=“ qop-value
cnonce
= ”cnonce“ ”=“ cnonce-value
cnonce-value
= nonce-value
nonce-count
= ”nc“ ”=“ nc-value
nc-value
= 8LHEX
response
= ”response“ ”=“ request-digest
request-digest = <”> 32LHEX <“>
LHEX
= ”0“ | ”1“ | ”2“ | ”3“ |
”4“ | ”5“ | ”6“ | ”7“ |
”8“ | ”9“ | ”a“ | ”b“ |
”c“ | ”d“ | ”e“ | ”f“
response：加密后的密碼
digest-uri：拷貝Request-Line，用于Proxy cnonce：如果qop設置，才設置，用于雙向認證，防止攻擊。
nonce-count:如果服務器看到同樣的計數，就是一次重放。
示例：
401響應：
HTTP/1.1 401 Unauthorized
www.tmdps.cnonce=”0a4f113b“，response=”6629fae49393a05397450978507c4ef1“，opaque=”5ccc069c403ebaf9f0171e9517f40e41"
一，用摘要保護密碼
摘要認證的一個改進之處是用摘要代替密碼的傳輸，遵循的基本原則是“絕對不通過網絡發送明文密碼”，而是發送一個密碼的摘要信息，并且這摘要信息是不可逆 的，即無法通
過摘要信息反推出密碼信息。而服務器本身是存儲這個密碼的（實際上，服務器只需知道密碼的摘要即可），而客戶端和服務器本身都知道這個密碼。這樣的話，服 務器可以讀取客戶端的摘要和本身知道的密碼進行同樣計算得出的摘要進行比較，若匹配，則驗證通過。
摘要是對信息主體的濃縮，摘要是一種單向函數，主要用于將無限的輸入值轉為有限的濃縮輸出值，如MD5，則是將任意長度的字節系列轉換為一個128位的摘要。MD5輸出的128位的摘要通常會寫出32個十六進制的字符，每個字符表示4個bit。
二，用隨機數防止重放攻擊
使用單向摘要就無需以明文形式發送密碼了，可以只發送密碼的摘要，并且可以確信，沒有哪個惡意用戶能輕易的從摘要中解碼出原始密碼。
但是，摘要被截獲也可能跟密碼一起好用，為了防止重放攻擊的發送，服務器可以向客戶端發送一個稱為隨機數nonce的特殊令牌，這個數會經常發生變化(可 能是每毫秒，或者每次認證都發生變化，具體由服務器控制)，客戶端在計算摘要之前要先將這個隨機數附加到密碼上去。這樣，在密碼中加入隨機數就會使得摘要 隨著隨機數的每次變化而變化，記錄下的密碼摘要只對特定的隨機數有效，而沒有密碼的話，攻擊者就無法計算出正確的摘要，這樣就可以防止重放攻擊的發生。
摘要認證要求使用隨機數，隨機數是在www.tmdps.cnonce。如下例子：
GET/cgi-bin/checkout?a=b HTTP/1.1 Authorization: Digest username=”tenfyguo”
realm=”test realm”
nonce=” 66C4EF58DA7CB956BD04233FBB64E0A4” //服務器端的隨機數一起帶回
uri=”/cgi-bin/checkout?a=b” //必須跟請求行一致
qop=”auth” //保護質量參數
nc=0000001
cnonce=”xxxxx234132543strwerr65sgdrftdfytryts” //客戶端隨機數，用于對稱校驗
response=” ABC4EF58DA7CB956BD04345FBB64E0A4”//最終摘要
3，服務接受摘要，選擇算法以及掌握的數據，重新計算新的摘要跟客戶端傳輸的摘要進行比較，驗證是否匹配，若客戶端反過來用客戶端隨機數對服務器進行質詢，就 會創建客戶端摘要，服務可以預先將下一個隨機數計算出來，提前傳遞給客戶端，通過Authentication-Info發送下一個隨機數。如下例子：
HTTP/1.1 200 OK Authorization-Info:nextnonce=” 88C4EF58DA7CB956BD04233FBB64E0A4”
qop=”auth”
rspauth=”23543534DfasetwerwgDTerGDTERERRE”
cnonce=” xxxxx234132543strwerr65sgdrftdfytryts”
四，摘要的計算
在說明如何計算摘要之前，先說明參加摘要計算的信息塊。信息塊主要有兩種：
1，表示與安全相關的數據的A1。
A1中的數據時密碼和受保護信息的產物，它包括用戶名，密碼，保護域和隨機數等內容，A1只涉及安全信息，與底層報文自身無關。
若算法是：MD5 則A1= 若算法是：MD5-sess 則A1=MD5( ): 2，表示與報文相關的數據的A2.A2表示是與報文自身相關的信息，比如URL，請求反復和報文實體的主體部分，A2加入摘要計算主要目的是有助于防止反復，資源或者報文被篡改。 若qop未定義或者auth： A2= 下面定義摘要的計算規則： 若qop沒有定義： 摘要response=MD5(MD5(A1): 若qop為auth: 摘要response=MD5(MD5(A1): 若qop為auth-int: 摘要response= MD5(MD5(A1): 五，隨機數的生成 RFC2617建議采用這個假想的隨機數公式： nonce = BASE64(time-stamp MD5(time-stamp “:” ETag “:” private-key))其中: time-stamp是服務器產生的時間戳或者其他不會重復的序列號，ETag是與所請求實體有關的HTTP ETag首部的值，priviate-key是只有服務器知道的數據。 這樣，服務器就可以收到客戶端的認證首部之后重新計算散列部分，如果結果與那個首部的隨機數不符，或者是時間戳的值不夠新，就可以拒絕請求，服務器可以通過這種方式來限制隨機數的有效持續時間。 包括了ETag可以防止對已經更新資源版本的重放請求。注意：在隨機數中包含客戶端IP，服務器好像就可以限制原來獲取此隨機數的客戶端重用這個隨 機數了，但這會破壞代理集群的工作，使用代理集群時候，來自單個用戶的多條請求通常會經過不同的代理進行傳輸，而且IP地址欺騙實現起來也不復雜。
點擊咨詢 