前面一篇部落格介紹了在 Java 中使用 HttpURLConnection 和 HttpClient 通過代理訪問 HTTP 站點的方法，但是可以看到程式碼中使用的代理都是免費公開的代理，不需要使用者名稱密碼就能直接訪問。由於網際網路上公開的代理安全性不能保證，這種代理隨便用用即可，如果要慎重起見，我推薦大家還是自己搭建代理伺服器。但是有一點要特別注意，如果自己搭建代理伺服器的話，一定不要公開，要設定使用者名稱密碼，一般情況下，我們使用簡單的基本身份認證就可以了。如果你不設定密碼的話，沒過幾天你就會發現你的伺服器會卡到爆，登上去使用 netstat 一看，幾百上千個連線，伺服器頻寬全佔滿了。這是因為網際網路上有著大量的代理掃描程式在沒日沒夜的掃描，你搭建的代理伺服器沒設密碼，或者弱密碼，都會被掃出來，而掃出來的後果就是，你的代理伺服器被公開到各大免費代理站點，然後所有人都來連你的代理伺服器，直到把你的頻寬流量耗盡。

一、關於 HTTP 的身份認證

我們這裡給代理伺服器設定了使用者名稱和密碼之後，無論在程式中，還是在瀏覽器裡使用該代理時，都需要進行身份認證了。HTTP 協議最常見的認證方式有兩種：基本認證（Basic authentication）和摘要認證（Digest authentication）。HTTP 的認證模型非常簡單，就是所謂的質詢/響應（challenge/response）框架：當用戶向伺服器傳送一條 HTTP 請求報文時，伺服器首先回復一個“認證質詢”響應，要求使用者提供身份資訊，然後使用者再一次傳送 HTTP 請求報文，這次的請求頭中附帶上身份資訊（使用者名稱密碼），如果身份匹配，伺服器則正常響應，否則伺服器會繼續對使用者進行質詢或者直接拒絕請求。

摘要認證的實現比基本認證要複雜一點，在平時的使用中也並不多見，這裡忽略，如果想詳細瞭解它，可以檢視維基百科上關於 HTTP 摘要認證 的解釋。這裡重點介紹下 HTTP 基本認證，因為無論是代理伺服器對使用者進行認證，還是 Web 伺服器對使用者進行認證，最常用的手段都是 HTTP 基本認證，它實現簡單，容易理解，幾乎所有的伺服器都能支援它。

一個典型的 HTTP 基本認證，如下圖所示，圖片摘自《HTTP 權威指南》：

使用者第一次向伺服器發起請求時，伺服器會返回一條 401 Unauthorized 響應，如果使用者是使用瀏覽器訪問的話，瀏覽器會彈出一個密碼提示框，提醒使用者輸入使用者名稱和密碼，於是使用者重新發起請求，在第二次請求中將在 Authorization 頭部新增上身份資訊，這個身份資訊其實只是簡單的對使用者輸入的使用者名稱密碼做了 

二、使用基本認證

2.1 區分 Proxy 認證 和 WWW 認證

這篇部落格本來是介紹代理認證的，但是代理認證其實只是 HTTP 身份認證中的一種而已，所以上面大部分內容對於代理認證來說是一樣的，包括質詢/響應框架以及身份認證的基本流程。不過要在程式碼裡實現這兩種認證，細節方面會有所不同，下面是兩種認證的一個對比。

• 根本區別
  • WWW 認證：指的是 Web 伺服器對客戶端發起的認證
  • Proxy 認證：指的是代理伺服器對客戶端發起的認證
• 響應的狀態碼不同
  • WWW 認證：第一次訪問時響應 401 Unauthorized
  • Proxy 認證：第一次訪問時響應 407 Unauthorized
• 認證頭部不同
  • WWW 認證：WWW-Authenticate, Authorization, Authentication-Info
  • Proxy 認證：Proxy-Authenticate, Proxy-Authorization, Proxy-Authentication-Info

2.2 手工設定認證頭部

通過上面的介紹我們瞭解到，要實現 HTTP 身份認證，無論是 WWW 認證也好，Proxy 認證也罷，其實只需要在 HTTP 的請求頭部新增一個認證的頭部（Authorization 或者 Proxy-Authorization）。認證頭部的資訊就是使用者名稱和密碼，將使用者名稱和密碼使用冒號分割，然後再對其進行 Base64 編碼即可，我們使用 HttpURLConnection 來模擬這個過程，如下：

如果是代理認證的話，設定頭部的程式碼改成下面這樣：

這種方式最為原始，也最為簡單直白，幾乎沒什麼好解釋的。

但是在我使用這種方式來訪問 HTTPS 站點的時候卻遇到了問題：第一種情況是訪問需要進行基本身份認證的 HTTPS 站點，測試通過；第二種情況是訪問 HTTPS 站點，通過一個代理，代理需要進行基本身份認證，測試失敗，返回下面的錯誤：

java.io.IOException: Unable to tunnel through proxy. Proxy returns "HTTP/1.0 407 Proxy Authentication Required"
at sun.net.www.protocol.http.HttpURLConnection.doTunneling(HttpURLConnection.java:2085)
at sun.net...https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:183)

我的第一直覺是通過代理訪問 HTTPS 站點時，代理的認證資訊應該沒有發出去，果不其然，使用 Wireshark 截獲了兩次請求的資料包，第二次請求裡沒有我們加的 Proxy-Authorization 頭部。
在 Google 上搜索這個問題，發現早在 2000 年（那可是 16 年前，當時 Java 的版本還是 1.0 呢）就有人在 JDK 的 bug database 裡提交了這個問題（JDK-4323990），看這個問題的更新狀態應該是在 JDK 1.4 版本里已經修復了，但是為啥我這裡還是測試不通過呢！

下面是測試的完整程式碼，始終不理解為什麼通不過，還需要繼續研究下 HttpURLConnection 中的實現細節，如果有高人知道，還請多多指教。

2.3 實現 Authenticator

自己手工設定認證頭部雖然簡單，而且在某些情況下可以達到意想不到的效果。但是使用這種方法可能會出現問題（像上面提到的訪問 HTTPS 站點時遇到的問題），而且 Proxy 認證和 WWW 認證這兩種情形還需要分別處理，不是很方便。除了可以自己手工拼 HTTP 請求頭部之外，其實還有另一種更簡單的方法，那就是 java.net 提供的 Authenticator 類。Authenticator 類是一個抽象類，必須先定義一個類來繼承它，然後重寫它的 getPasswordAuthentication() 這個方法，定義新類比較繁瑣，我們可以直接使用匿名類，如下：

請求部分程式碼還是一樣，如果使用代理，openConnection() 方法就加個代理引數。這種方式不區分是 Proxy 認證還是 WWW 認證，如果是 Proxy 認證，userName 和 password 就設定成代理的使用者名稱密碼，如果是 WWW 認證，則設定成 Web 伺服器認證的使用者名稱密碼。

要特別注意的一點是，通過這種方式設定認證方式是 JVM 全域性的，同一個 JVM 下的所有應用程式都會受影響。

然後抱著實驗精神，和 2.2 節一樣，我也做了幾個測試，看看 Authenticator 類對 HTTPS 的支援情況，發現無論是帶認證的 HTTPS 站點，還是通過帶認證的代理去訪問 HTTPS 站點，都沒問題。不過在測試的過程中還是發現了一些有趣的現象，在使用正確的使用者名稱和密碼時都可以成功認證，但是在使用錯誤的使用者名稱和密碼時，不同情況下的錯誤情形略有不同。有些情況可能報 407 錯誤，有些情況可能報 401 錯誤，有些情況還可能報 “java.net.ProtocolException: Server redirected too many times (20)”。雖然這可能並沒有什麼卵用，我還是在這裡記錄一下吧，算是做個總結。

注：上圖是使用 Lucidchart 線上畫的，強大的線上版 Visio ，推薦！

2.4 使用 HttpClient 的 CredentialsProvider

和 Authenticator 類似，HttpClient 也提供了一個類 CredentialsProvider 來實現 HTTP 的身份認證，它的子類BasicCredentialsProvider 用於基本身份認證。和 Authenticator 不一樣的是，這種方法不再是全域性的，而是針對指定的 HttpClient 例項有效，可以根據需要來設定。這裡不再多述，示例程式碼如下：