發現一篇介紹http認證的好文章，就嘗試翻譯了一下，記錄在下面。（翻譯的很挫，哈哈哈）
原文：
http協議(rfc 2616)定義了一種簡單的訪問認證模式。 假設有某一組網頁，它們通常作為乙個被保護的領域被引用，或者僅僅對能夠對伺服器驗證提供憑證的使用者開放訪問。
如果乙個http客戶端（例如乙個web瀏覽器），請求乙個屬於乙個被保護領域的頁面，伺服器會響應401，並在響應中包含乙個 www-authenticate 頭資訊。 這個頭資訊必須包含至少乙個適用於被請求頁面的 認證質詢（authentication challenge）。
下一步，客戶端傳送另乙個請求，這次請求會含有乙個認證頭屬性（authentication header field ），它包含客戶端對伺服器認證質詢（authentication challenge）的憑證（credentials ）。
如果伺服器接受到這個憑證，它響應被請求的頁面。 另一方面，它返回另乙個401響應來表明客戶端的憑證是無效的。
真正的www-authenticate和認證頭屬性的內容依賴於使用的認證模式。寫作這篇文章時，有兩種認證模式被廣泛使用。
basic authentication 模式假設你（瀏覽器）的認證包含乙個使用者名稱（username）和乙個密碼（password），密碼只對你和伺服器可知。
伺服器的401響應包含乙個由」basic」字元和乙個可以指定被保護領域名稱的名值對構成。
例如：www-authenticate: basic realm="control panel"
當接受到伺服器的401響應後，你的瀏覽器提示你輸入關聯到這個領域的使用者名稱和密碼。如下圖：
你接下來傳送的請求的認證頭資訊包括字元」basic」和乙個base64編碼的乙個字串（它是由 使用者名稱，冒號(:)和密碼組成），例如
authorization: basic qwrtaw46zm9vymfy
qwrtaw46zm9vymfy 編碼之前應該類似於 zhangsan:123456
伺服器以base64解碼客戶端發來的憑證並與資料庫比對，如果正確，那麼你就登入進來了。
basic authentication 模式最大的缺點在於對於竊聽者來說很容易竊取到你的密碼，因為它是通過明文傳輸的。
cryptography to the rescue!（使用密碼學來解決）
另外一種可用的認證模式叫做 摘要認證（digest authentication ）， 它通過使用加密來彌補明文傳輸的缺點，通常是使用md5報文摘要演算法（frc 1321）。
md5可以將任意長度的字串計算為128位的數字， 因為md5是單向的，本質上來說是不可能通過密文得到最初的結果的（不可逆）。
現在，如果你像basic認證中那樣將使用者名稱和密碼使用md5加密後傳送給伺服器，那麼很顯然乙個竊聽者可以記錄你加密後的使用者名稱和密碼。當這個竊聽者向伺服器請求認證時，它可以簡單地把這個加密後的使用者名稱和密碼傳送給伺服器，並最終登入成功。 這叫做 重放攻擊（replay attack）。
為了安全的阻止重放攻擊（replay attack）， 很明顯我們需要乙個更加複雜的認證過程： 摘要認證模式。
首先，伺服器最初的401響應中的www-authenticate頭資訊中包含著除了認證範圍（realm）字串之外的更多的一些名值對，包括乙個叫做nonce（number used once 非重複隨機數）的值。伺服器必須確保每乙個401響應中包含乙個唯一的，之前未使用的nonce值。
現在你的瀏覽器在接下來的請求中包含這樣的認證頭資訊，它包含你的明文的使用者名稱，你剛剛在401響應中接受到的nonce值和所謂的摘要請求，摘要請求可能按照下面的方式計算得到（hashmd5為md5加密）：
a1 = string.hashmd5 (username + ":" + realm + ":" + password)
a2 = string.hashmd5 (paramtable.method + ":" + paramtable.uri)
requestdigest = string.hashmd5 (a1 + ":" + nonce + ":" + a2) （requestdigest 就是計算得到的請求摘要）
在這個計算過程中，所有的計算值要麼是伺服器已知的要麼是請求頭資訊的一部分，所以伺服器可以進行同樣的計算，如果它的計算得到（yield）同樣的請求摘要（就是上面計算最終得到的requestdigest）， 那麼就可以確定你擁有正確的密碼。
更進一步， 因為md5演算法是不可逆的，竊聽者不能夠從請求摘要中獲得你的密碼。同樣，伺服器能夠相當有效的阻止重放攻擊（replay attack），因為它不會在超過一次的認證請求中接受同乙個nonce值。對於每次新的請求，伺服器都要給出乙個不同的nonce值，所以客戶端每次也必須產生乙個新的請求摘要。
事實上，以上所描述的是摘要認證的乙個輕量級實現版本。 rfc 2617 描述了增強的功能，包括乙個用來阻止第三方操作在傳輸中的報文體的方法。
你應該時刻記住即便是摘要認證，除了密碼外的所有資料都是明文傳輸的，對於竊聽者都是可竊聽的。
沒有一種方法可以使客戶端去確認它正在訪問的伺服器就是它真實希望訪問的那台。 沒有一種適當的機制允許伺服器來向客戶端認證自己。
對於摘要認證安全細節的詳細介紹可以參考 rfc 2617的第4部分。
不幸的是，一些瀏覽器目前缺乏對摘要認證的支援。
***********************************=翻譯結束***********************************====
basic authentication 實驗截圖（通過wireshark）：
HTTP認證機制
http請求報頭 authorization http響應報頭 www authenticate http認證 基於 質詢 回應 challenge response 的認證模式。基本認證 basic authentication http1.0提出的認證方法 客戶端對於每乙個realm，通過提供使...
HTTP認證機制
http請求報頭 authorization http響應報頭 www authenticate http認證 基於 質詢 回應 challenge response 的認證模式。基本認證 basic authentication http1.0提出的認證方法 客戶端對於每乙個realm，通過提供使...
PHP的HTTP認證機制
php的http認證機制因此該功能不適用於 cgi 版本。在 apache 模組的 php 指令碼中，可以用 header 函式來向客戶端瀏覽器傳送authentication required資訊，使其彈出乙個使用者名稱 密碼輸入視窗。當使用者輸入使用者名稱和密碼後，包含有 url 的 php 指...