Java SE 6 新特性: HTTP 增強

來源:互聯網
上載者:User

  2006 年底,Sun 公司發布了 Java Standard Edition 6(Java SE 6)的最終正式版,代號 Mustang(野馬)。跟 Tiger(Java SE 5)相比,Mustang 在效能方面有了不錯的提升。與 Tiger 在 API 庫方面的大幅度加強相比,雖然 Mustang 在 API 庫方面的新特性顯得不太多,但是也提供了許多實用和方便的功能:在指令碼,WebService,XML,編譯器 API,資料庫,JMX,網路和 Instrumentation 方面都有不錯的新特性和功能加強。 本系列文章主要介紹 Java SE 6 在 API 庫方面的部分新特性,通過一些例子和講解,協助開發人員在編程實踐當中更好的運用 Java SE 6,提高開發效率。

  本文是系列文章的第二篇,介紹了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 authentication
  • HTTP Digest authentication
  • NTLM
  • Http SPNEGO Negotiate
    • Kerberos
    • NTLM

  這裡我們著重介紹 NTLM。

  NTLM 是 NT LAN Manager 的縮寫。早期的 SMB 協議在網路上明文傳輸口令,這是很不安全的。微軟隨後提出了 WindowsNT 挑戰/響應驗證機制,即 NTLM。

  NTLM 協議是這樣的:

  1.用戶端首先將使用者的密碼加密成為密碼散列;

  2.用戶端向伺服器發送自己的使用者名稱,這個使用者名稱是用明文直接傳輸的;

  3.伺服器產生一個 16 位的隨機數字發送給用戶端,作為一個 challenge(挑戰) ;

  4.用戶端用步驟1得到的密碼散列來加密這個 challenge ,然後把這個返回給伺服器;

  5.伺服器把使用者名稱、給用戶端的 challenge 、用戶端返回的 response 這三個東西,發送網域控制站 ;

  6.網域控制站用這個使用者名稱在 SAM 密碼管理庫中找到這個使用者的密碼散列,然後使用這個密碼散列來加密 challenge;

  7.網域控制站比較兩次加密的 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 代表 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 管理類的關係

  一個 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 協議的網際網路編程,有了更加強大的支援。



    相關文章

    Beyond APAC's No.1 Cloud

    19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

    Learn more >

    Apsara Conference 2019

    The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

    Learn more >

    Alibaba Cloud Free Trial

    Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

    Learn more >

    聯繫我們

    該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

    如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。