跟 Tiger（Java SE 5）相比,Mustang 在性能方面有了不錯的提升.與 Tiger 在 API 庫方面的大幅度加強相比,雖然 Mustang 在 API 庫方面的新特性顯得不太多,但是也提供了許多實用和方便的功能：在腳本,WebService,XML,編譯器 API,資料庫,JMX,網路和 Instrumentation 方面都有不錯的新特性和功能加強. 本系列 文章主要介紹 Java SE 6 在 API 庫方面的部分新特性 ,介紹了Java SE 6 在 HTTP 方面的新特性.
概述
Java 語言從誕生的那天起,就非常注重網路編程方面的應用.隨著互聯網應用的飛速發展,Java 的基礎類庫也不斷地對網路相關的 API 進行加強和擴展.在 Java SE 6 當中,圍繞著 HTTP 協議出現了很多實用的新特性：NTLM 認證提供了一種 Window 平台下較為安全的認證機制；JDK 當中提供了一個輕量級的 HTTP 伺服器；提供了較為完善的 HTTP Cookie 管理功能；更為實用的 NetworkInterface；DNS 域名的國際化支持等等.NTLM 認證不可避免,網路中有很多資源是被安全域保護起來的.訪問這些資源需要對用戶的身份進行認證.下面是一個簡單的例子：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 authenticationHTTP Digest authenticationNTLMHttp SPNEGO NegotiateKerberosNTLM這裡我們著重介紹 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 的.輕量級 HTTP 伺服器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 管理特性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 代表 Cookiejava.net.HttpCookie 類是 Java SE 6 新增的一個表示 HTTP Cookie 的新類, 其對象可以表示 Cookie 的內容, 可以支持所有三種 Cookie 規範：Netscape 草案RFC 2109 - http://www.ietf.org/rfc/rfc2109.txtRFC 2965 - http://www.ietf.org/rfc/rfc2965.txt這個類儲存了 Cookie 的名稱,路徑,值,協議版本號,是否過期,網路域,最大生命期等等信息.用 CookiePolicy 規定 Cookie 接受策略java.net.CookiePolicy 介面可以規定 Cookie 的接受策略.其中唯一的方法用來判斷某一特定的 Cookie 是否能被某一特定的地址所接受. 這個類內置了 3 個實現的子類.一個類接受所有的 Cookie,另一個則拒絕所有,還有一個類則接受所有來自原地址的 Cookie.用CookieStore 儲存Cookiejava.net.CookieStore 介面負責儲存和取出 Cookie. 當有 HTTP 請求的時候,它便儲存那些被接受的 Cookie； 當有 HTTP 回應的時候,它便取出相應的 Cookie. 另外,當一個 Cookie 過期的時候,它還負責自動刪去這個 Cookie.用 CookieManger/CookieHandler 管理 Cookiejava.net.CookieManager 是整個 Cookie 管理機制的核心,它是 CookieHandler 的默認實現子類.下圖顯示了整個 HTTP Cookie 管理機制的結構：
圖 2. Cookie 管理類的關係
一個 CookieManager 裡面有一個 CookieStore 和一個 CookiePolicy,分別負責儲存 Cookie 和規定策略.用戶可以指定兩者,也可以使用系統默認的 CookieManger.例子下面這個簡單的例子說明了 Cookie 相關的管理功能：// 創建一個默認的 CookieManagerCookieManager manager = new CookieManager();// 將規則改掉,接受所有的 Cookiemanager.setCookiePolicy(CookiePolicy.ACCEPT_ALL);// 保存這個定製的 CookieManagerCookieHandler.setDefault(manager); // 接受 HTTP 請求的時候,得到和保存新的 CookieHttpCookie 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}
其他新特性NetworkInterface 的增強從 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()用來判斷網路介面是否是虛擬介面關於此工具類的具體信息,請參考 Java SE 6 相應文檔（見 參考資源）.域名的國際化在最近的一些 RFC 文檔當中,規定 DNS 伺服器可以解析除開 ASCII 以外的編碼字元.有一個演算法可以在這種情況下做 Unicode 與 ASCII 碼之間的轉換,實現域名的國際化.java.net.IDN 就是實現這個國際化域名轉換的新類,IDN 是「國際化域名」的縮寫（internationalized domain names）.這個類很簡單,主要包括 4 個靜態函數,做字元的轉換.結語
Java SE 6 有著很多 HTTP 相關的新特性,是的 Java SE 平台本身對網路編程,尤其是基於 HTTP 協議的網際網路編程,有了更加強大的支持.
