JavaSE6的特性

Java 語言從誕生的那天起，就非常注重網路程式設計方面的應用。隨著網際網路應用的飛速發展，Java 的基礎類庫也不斷地對網路相關的 API 進行加強和擴充套件。在 Java SE 6 當中，圍繞著 HTTP 協議出現了很多實用的新特性：NTLM 認證提供了一種 Window 平臺下較為安全的認證機制;JDK 當中提供了一個輕量級的 HTTP 伺服器;提供了較為完善的 HTTP Cookie 管理功能;更為實用的 NetworkInterface;DNS 域名的國際化支援等等。NTLM 認證不可避免，網路中有很多資源是被安全域保護起來的。訪問這些資源需要對使用者的身份進行認證。下面是一個簡單的例子：import .*;import .*;public class Test { public static void main(String[] args) throws Exception { URL url = new URL(""); URLConnection connection = Connection(); InputStream in = nputStream(); byte[] data = new byte[1024]; while((data)>0) { //do something for data } e(); }}

當 Java 程式試圖從一個要求認證的網站讀取資訊的時候，也就是說，從聯絡於 這個 URLConnection 的 InputStream 中 read 資料時，會引發 FileNotFoundException.儘管認為，這個 Exception 的型別與實際錯誤發生的原因實在是相去甚遠;但這個錯誤確實是由網路認證失敗所導致的。要解決這個問題，有兩種方法：其一，是給 URLConnection 設定一個“Authentication”屬性：String credit = USERNAME + "：" + PASSWORD;String encoding = new 64Encoder()。encode (ytes());equestProperty ("Authorization"， "Basic " + encoding);

這裡假設 使用了基本(Basic)認證型別。從上面的例子，我們可以看出，設定 Authentication 屬性還是比較複雜的：使用者必須瞭解認證方式的細節，才能將使用者名稱/密碼以一定的規範給出，然後用特定的編碼方式加以編碼。Java 類庫有沒有提供一個封裝了認證細節，只需要給出使用者名稱/密碼的工具呢?這就是我們要介紹的另一種方法，使用 entication 類。每當遇到網站需要認證的時候，HttpURLConnection 都會向 Authentication 類詢問使用者名稱和密碼。Authentication 類不會知道究竟使用者應該使用哪個 username/password 那麼使用者如何向 Authentication 類提供自己的使用者名稱和密碼呢?提供一個繼承於 Authentication 的類，實現 getPasswordAuthentication 方法，在 PasswordAuthentication 中給出使用者名稱和密碼：class DefaultAuthenticator extends Authenticator { public PasswordAuthentication getPasswordAuthentication () { return new PasswordAuthentication ("USER"， "PASSWORD"arArray()); }}

然後，將它設為預設的(全域性)Authentication：efault (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這裡我們著重介紹 是 NT LAN Manager 的縮寫。早期的 SMB 協議在網路上明文傳輸口令，這是很不安全的。微軟隨後提出了 WindowsNT 挑戰/響應驗證機制，即 協議是這樣的：客戶端首先將使用者的密碼加密成為密碼雜湊;客戶端向伺服器傳送自己的使用者名稱，這個使用者名稱是用明文直接傳輸的;伺服器產生一個 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， arArray())); }}

這裡，根據 Windows 域賬戶的命名規範，賬戶名為域名+“/”+域使用者名稱。如果不想每生成 PasswordAuthentication 時，每次新增域名，可以設定一個系統變數名“in”。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 = ider(); InetSocketAddress addr = new InetSocketAddress(7778); HttpServer httpServer = teHttpServer(addr， 1); teContext("/myapp/"， new MyHttpHandler()); xecutor(null); t(); tln("started");}static class MyHttpHandler implements HttpHandler{ public void handle(HttpExchange httpExchange) throws IOException { String response = "Hello world!"; ResponseHeaders(200， th()); OutputStream out = esponseBody(); e(ytes()); e(); } }

首先，HttpServer 是從 HttpProvider 處得到的，這裡我們使用了 JDK 6 提供的實現。使用者也可以自行實現一個 HttpProvider 和相應的 HttpServer 實現。其次，HttpServer 是有上下文(context)的概念的。比如，http://localhost：7778/myapp/ 中“/myapp/”就是相對於 HttpServer Root 的上下文。對於每個上下文，都有一個 HttpHandler 來接收 http 請求並給出回答。最後，在 HttpHandler 給出具體回答之前，一般先要返回一個 Http head.這裡使用 ResponseHeaders(int code， int length)。其中 code 是 Http 響應的返回值，比如那個著名的. th 指的是 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 有著很不錯的支援。 裡面也有相關的類來支援開發者對 Cookie 的管理。不過，在 Java SE 6 之前， Java一直都沒有提供 Cookie 管理的功能。在 Java SE 5 裡面， 包裡面有一個 CookieHandler 抽象類，不過並沒有提供其他具體的實現。到了Java SE 6，Cookie 相關的管理類在 Java 類庫裡面才得到了實現。有了這些 Cookie 相關支援的類，Java 開發者可以在伺服器端程式設計中很好的操作 Cookie，更好的支援 HTTP 相關應用，建立有狀態的 HTTP 會話。用 HttpCookie 代表 Cookie 類是 Java SE 6 新增的一個表示 HTTP Cookie 的新類，其物件可以表示 Cookie 的內容， 可以支援所有三種 Cookie 規範：Netscape 草案RFC 2109 - 2965 - 這個類儲存了Cookie 的名稱，路徑，值，協議版本號，是否過期，網路域，最大生命期等等資訊。用CookiePolicy 規定 Cookie 接受策略iePolicy 介面可以規定Cookie 的接受策略。其中唯一的方法用來判斷某一特定的 Cookie 是否能被某一特定的地址所接受。 這個類內建了 3 個實現的子類。一個類接受所有的 Cookie，另一個則拒絕所有，還有一個類則接受所有來自原地址的 Cookie.用CookieStore 儲存ieStore 介面負責儲存和取出Cookie. 當有 HTTP 請求的時候，它便儲存那些被接受的 Cookie; 當有HTTP 迴應的時候，它便取出相應的 Cookie. 另外，當一個Cookie 過期的時候，它還負責自動刪去這個Cookie.用 CookieManger/CookieHandler 管理ieManager 是整個 Cookie 管理機制的核心，它是 CookieHandler 的預設實現子類。