Java 語言從誕生的那天起，就非常注重網絡編程方面的應用。隨着互聯網應用的飛速發展，Java 的基礎類庫也不斷地對網絡相關的 API 進行加強和擴展。在 Java SE 6 當中，圍繞着 HTTP 協議出現了很多實用的新特性：NTLM 認證提供了一種 Window 平臺下較爲安全的認證機制；JDK 當中提供了一個輕量級的 HTTP 服務器；提供了較爲完善的 HTTP Cookie 管理功能；更爲實用的 NetworkInterface；DNS 域名的國際化支持等等。
不可避免，網絡中有很多資源是被安全域保護起來的。訪問這些資源需要對用戶的身份進行認證。下面是一個簡單的例子：
import java.net.*;
import java.io.*;
public class Test {
public static void main(String[] args) throws Exception {
URL url = new URL("http://PROTECTED.com");
URLConnection connection = url.openConnection();
InputStream in = connection.getInputStream();
byte[] data = new byte[1024];
while(in.read(data)>0)
{
//do something for data
}
in.close();
}
}
|
當 Java 程序試圖從一個要求認證的網站讀取信息的時候，也就是說，從聯繫於 http://Protected.com 這個 URLConnection 的 InputStream 中 read 數據時，會引發 FileNotFoundException。儘管筆者認爲，這個 Exception 的類型與實際錯誤發生的原因實在是相去甚遠；但這個錯誤確實是由網絡認證失敗所導致的。
要解決這個問題，有兩種方法：
其一，是給 URLConnection 設定一個“Authentication”屬性：
String credit = USERNAME + ":" + PASSWORD;
String encoding = new sun.misc.BASE64Encoder().encode (credit.getBytes());
connection.setRequestProperty ("Authorization", "Basic " + encoding);
|
這裏假設 http://PROTECTED.COM 使用了基本（Basic）認證類型。
從上面的例子，我們可以看出，設定 Authentication 屬性還是比較複雜的：用戶必須瞭解認證方式的細節，才能將用戶名/密碼以一定的規範給出，然後用特定的編碼方式加以編碼。Java 類庫有沒有提供一個封裝了認證細節，只需要給出用戶名/密碼的工具呢？
這就是我們要介紹的另一種方法，使用 java.net.Authentication 類。
每當遇到網站需要認證的時候，HttpURLConnection 都會向 Authentication 類詢問用戶名和密碼。
Authentication 類不會知道究竟用戶應該使用哪個 username/password 那麼用戶如何向 Authentication 類提供自己的用戶名和密碼呢?
提供一個繼承於 Authentication 的類，實現 getPasswordAuthentication 方法，在 PasswordAuthentication 中給出用戶名和密碼：
class DefaultAuthenticator extends Authenticator {
public PasswordAuthentication getPasswordAuthentication () {
return new PasswordAuthentication ("USER", "PASSWORD".toCharArray());
}
}
|
然後，將它設爲默認的（全局）Authentication:
Authenticator.setDefault (new DefaultAuthenticator()); |
那麼，不同的網站需要不同的用戶名/密碼又怎麼辦呢?
Authentication 提供了關於認證發起者的足夠多的信息，讓繼承類根據這些信息進行判斷，在 getPasswordAuthentication 方法中給出了不同的認證信息：
- getRequestingHost()
- getRequestingPort()
- getRequestingPrompt()
- getRequestingProtocol()
- getRequestingScheme()
- getRequestingURL()
- getRequestingSite()
- getRequestorType()
另一件關於 Authentication 的重要問題是認證類型。不同的認證類型需要 Authentication 執行不同的協議。至 Java SE 6.0 爲止，Authentication 支持的認證方式有：
- HTTP Basic authentication
- HTTP Digest authentication
- NTLM
- Http SPNEGO Negotiate
- Kerberos
- NTLM
這裏我們着重介紹 NTLM。
NTLM 是 NT LAN Manager 的縮寫。早期的 SMB 協議在網絡上明文傳輸口令，這是很不安全的。微軟隨後提出了 WindowsNT 挑戰/響應驗證機制，即 NTLM。
NTLM 協議是這樣的：
- 客戶端首先將用戶的密碼加密成爲密碼散列；
- 客戶端向服務器發送自己的用戶名，這個用戶名是用明文直接傳輸的；
- 服務器產生一個 16 位的隨機數字發送給客戶端，作爲一個 challenge（挑戰） ；
- 客戶端用步驟1得到的密碼散列來加密這個 challenge ，然後把這個返回給服務器；
- 服務器把用戶名、給客戶端的 challenge 、客戶端返回的 response 這三個東西，發送域控制器 ；
- 域控制器用這個用戶名在 SAM 密碼管理庫中找到這個用戶的密碼散列，然後使用這個密碼散列來加密 challenge；
- 域控制器比較兩次加密的 challenge ，如果一樣，那麼認證成功；
Java 6 以前的版本，是不支持 NTLM 認證的。用戶若想使用 HttpConnection 連接到一個使用有 Windows 域保護的網站時，是無法通過 NTLM 認證的。另一種方法，是用戶自己用 Socket 這樣的底層單元實現整個協議過程，這無疑是十分複雜的。
終於，Java 6 的 Authentication 類提供了對 NTLM 的支持。使用十分方便，就像其他的認證協議一樣：
class DefaultAuthenticator extends Authenticator {
private static String username = "username ";
private static String domain = "domain ";
private static String password = "password ";
public PasswordAuthentication getPasswordAuthentication() {
String usernamewithdomain = domain + "/ "+username;
return (new PasswordAuthentication(usernamewithdomain, password.toCharArray()));
}
}
|
這裏，根據 Windows 域賬戶的命名規範，賬戶名爲域名+”/”+域用戶名。如果不想每生成 PasswordAuthentication 時，每次添加域名，可以設定一個系統變量名“http.auth.ntlm.domain“。
Java 6 中 Authentication 的另一個特性是認證協商。目前的服務器一般同時提供幾種認證協議，根據客戶端的不同能力，協商出一種認證方式。比如，IIS 服務器會同時提供 NTLM with kerberos 和 NTLM 兩種認證方式，當客戶端不支持 NTLM with kerberos 時，執行 NTLM 認證。
目前，Authentication 的默認協商次序是：
GSS/SPNEGO -> Digest -> NTLM -> Basic |
那麼 kerberos 的位置究竟在哪裏呢?
事實上，GSS/SPNEGO 以 JAAS 爲基石，而後者實際上就是使用 kerberos 的。
Java 6 還提供了一個輕量級的純 Java Http 服務器的實現。下面是一個簡單的例子：
public static void main(String[] args) throws Exception{
HttpServerProvider httpServerProvider = HttpServerProvider.provider();
InetSocketAddress addr = new InetSocketAddress(7778);
HttpServer httpServer = httpServerProvider.createHttpServer(addr, 1);
httpServer.createContext("/myapp/", new MyHttpHandler());
httpServer.setExecutor(null);
httpServer.start();
System.out.println("started");
}
static class MyHttpHandler implements HttpHandler{
public void handle(HttpExchange httpExchange) throws IOException {
String response = "Hello world!";
httpExchange.sendResponseHeaders(200, response.length());
OutputStream out = httpExchange.getResponseBody();
out.write(response.getBytes());
out.close();
}
}
|
然後，在瀏覽器中訪問 http://localhost:7778/myapp/，我們得到：
圖一 瀏覽器顯示
首先，HttpServer 是從 HttpProvider 處得到的，這裏我們使用了 JDK 6 提供的實現。用戶也可以自行實現一個 HttpProvider 和相應的 HttpServer 實現。
其次，HttpServer 是有上下文（context）的概念的。比如，http://localhost:7778/myapp/ 中“/myapp/”就是相對於 HttpServer Root 的上下文。對於每個上下文，都有一個 HttpHandler 來接收 http 請求並給出回答。
最後，在 HttpHandler 給出具體回答之前，一般先要返回一個 Http head。這裏使用 HttpExchange.sendResponseHeaders(int code, int length)。其中 code 是 Http 響應的返回值，比如那個著名的 404。length 指的是 response 的長度，以字節爲單位。
Cookie 是 Web 應用當中非常常用的一種技術， 用於儲存某些特定的用戶信息。雖然，我們不能把一些特別敏感的信息存放在 Cookie 裏面，但是，Cookie 依然可以幫助我們儲存一些瑣碎的信息，幫助 Web 用戶在訪問網頁時獲得更好的體驗，例如個人的搜索參數，顏色偏好以及上次的訪問時間等等。網絡程序開發者可以利用 Cookie 來創建有狀態的網絡會話（Stateful Session）。 Cookie 的應用越來越普遍。在 Windows 裏面，我們可以在“Documents And Settings”文件夾裏面找到IE使用的 Cookie，假設用戶名爲 admin，那麼在 admin 文件夾的 Cookies 文件夾裏面，我們可以看到名爲“admin@(domain)”的一些文件，其中的 domain 就是表示創建這些 Cookie 文件的網絡域， 文件裏面就儲存着用戶的一些信息。
JavaScript 等腳本語言對 Cookie 有着很不錯的支持。 .NET 裏面也有相關的類來支持開發者對 Cookie 的管理。 不過，在 Java SE 6 之前， Java一直都沒有提供 Cookie 管理的功能。在 Java SE 5 裏面， java.net 包裏面有一個 CookieHandler 抽象類，不過並沒有提供其他具體的實現。到了 Java SE 6， Cookie 相關的管理類在 Java 類庫裏面纔得到了實現。有了這些 Cookie 相關支持的類，Java 開發者可以在服務器端編程中很好的操作 Cookie， 更好的支持 HTTP 相關應用，創建有狀態的 HTTP 會話。
- 用 HttpCookie 代表 Cookie
java.net.HttpCookie 類是 Java SE 6 新增的一個表示 HTTP Cookie 的新類， 其對象可以表示 Cookie 的內容， 可以支持所有三種 Cookie 規範：
- Netscape 草案
- RFC 2109 - http://www.ietf.org/rfc/rfc2109.txt
- RFC 2965 - http://www.ietf.org/rfc/rfc2965.txt
這個類儲存了 Cookie 的名稱，路徑，值，協議版本號，是否過期，網絡域，最大生命期等等信息。
- 用 CookiePolicy 規定 Cookie 接受策略
java.net.CookiePolicy 接口可以規定 Cookie 的接受策略。 其中唯一的方法用來判斷某一特定的 Cookie 是否能被某一特定的地址所接受。 這個類內置了 3 個實現的子類。一個類接受所有的 Cookie，另一個則拒絕所有，還有一個類則接受所有來自原地址的 Cookie。
- 用CookieStore 儲存 Cookie
java.net.CookieStore 接口負責儲存和取出 Cookie。 當有 HTTP 請求的時候，它便儲存那些被接受的 Cookie； 當有 HTTP 迴應的時候，它便取出相應的 Cookie。 另外，當一個 Cookie 過期的時候，它還負責自動刪去這個 Cookie。
- 用 CookieManger/CookieHandler 管理 Cookie
java.net.CookieManager 是整個 Cookie 管理機制的核心，它是 CookieHandler 的默認實現子類。下圖顯示了整個 HTTP Cookie 管理機制的結構：
圖 2. Cookie 管理類的關係![圖 2. Cookie 管理類的關係]()
一個 CookieManager 裏面有一個 CookieStore 和一個 CookiePolicy，分別負責儲存 Cookie 和規定策略。用戶可以指定兩者，也可以使用系統默認的 CookieManger。
- 例子
下面這個簡單的例子說明了 Cookie 相關的管理功能：
// 創建一個默認的 CookieManager CookieManager manager = new CookieManager(); // 將規則改掉，接受所有的 Cookie manager.setCookiePolicy(CookiePolicy.ACCEPT_ALL); // 保存這個定製的 CookieManager CookieHandler.setDefault(manager); // 接受 HTTP 請求的時候，得到和保存新的 Cookie HttpCookie cookie = new HttpCookie("...(name)...","...(value)..."); manager.getCookieStore().add(uri, cookie); // 使用 Cookie 的時候： // 取出 CookieStore CookieStore store = manager.getCookieStore(); // 得到所有的 URI List<URI> uris = store.getURIs(); for (URI uri : uris) { // 篩選需要的 URI // 得到屬於這個 URI 的所有 Cookie List<HttpCookie> cookies = store.get(uri); for (HttpCookie cookie : cookies) { // 取出了 Cookie } } // 或者，取出這個 CookieStore 裏面的全部 Cookie // 過期的 Cookie 將會被自動刪除 List<HttpCookie> cookies = store.getCookies(); for (HttpCookie cookie : cookies) { // 取出了 Cookie }
從 Java SE 1.4 開始，JDK 當中出現了一個網絡工具類 java.net.NetworkInterface，提供了一些網絡的實用功能。 在 Java SE 6 當中，這個工具類得到了很大的加強，新增了很多實用的方法。例如：
public boolean isUp()用來判斷網絡接口是否啓動並運行
public boolean isLoopback()用來判斷網絡接口是否是環回接口（loopback）
public boolean isPointToPoint()用來判斷網絡接口是否是點對點（P2P）網絡
public boolean supportsMulticast()用來判斷網絡接口是否支持多播
public byte[] getHardwareAddress()用來得到硬件地址（MAC）
public int getMTU()用來得到最大傳輸單位（MTU，Maximum Transmission Unit）
public boolean isVirtual()用來判斷網絡接口是否是虛擬接口
在最近的一些 RFC 文檔當中，規定 DNS 服務器可以解析除開 ASCII 以外的編碼字符。有一個算法可以在這種情況下做 Unicode 與 ASCII 碼之間的轉換，實現域名的國際化。java.net.IDN 就是實現這個國際化域名轉換的新類，IDN 是“國際化域名”的縮寫（internationalized domain names）。這個類很簡單，主要包括 4 個靜態函數，做字符的轉換。
Java SE 6 有着很多 HTTP 相關的新特性，使得 Java SE 平臺本身對網絡編程，尤其是基於 HTTP 協議的因特網編程，有了更加強大的支持。