摘要
Java SE 有著很多 HTTP 相關的新特性使得 Java SE 平台本身對網絡編程尤其是基於 HTTP 協議的因特網編程有了更加強大的支持
概述
Java 語言從誕生的那天起就非常注重網絡編程方面的應用隨著互聯網應用的飛速發展Java 的基礎類庫也不斷地對網絡相關的 API 進行加強和擴展在 Java SE 當中圍繞著 HTTP 協議出現了很多實用的新特性NTLM 認證提供了一種 Window 平台下較為安全的認證機制JDK 當中提供了一個輕量級的 HTTP 服務器提供了較為完善的 HTTP Cookie 管理功能更為實用的 NetworkInterfaceDNS 域名的國際化支持等等
NTLM 認證
不可避免網絡中有很多資源是被安全域保護起來的訪問這些資源需要對用戶的身份進行認證下面是一個簡單的例子
import *;
import javaio*;
public class Test {
public static void main(String[] args) throws Exception {
URL url = new URL();
URLConnection connection = urlopenConnection();
InputStream in = connectiongetInputStream();
byte[] data = new byte[];
while(inread(data)>)
{
//do something for data
}
inclose();
}
}
當 Java 程序試圖從一個要求認證的網站讀取信息的時候也就是說從聯系於 這個 URLConnection 的 InputStream 中 read 數據時會引發 FileNotFoundException盡管筆者認為這個 Exception 的類型與實際錯誤發生的原因實在是相去甚遠但這個錯誤確實是由網絡認證失敗所導致的
要解決這個問題有兩種方法
其一是給 URLConnection 設定一個Authentication屬性
String credit = USERNAME + : + PASSWORD;
String encoding = new sunmiscBASEEncoder()encode (creditgetBytes());
connectionsetRequestProperty (Authorization Basic + encoding);
這裡假設 使用了基本（Basic）認證類型
從上面的例子我們可以看出設定 Authentication 屬性還是比較復雜的用戶必須了解認證方式的細節才能將用戶名/密碼以一定的規范給出然後用特定的編碼方式加以編碼Java 類庫有沒有提供一個封裝了認證細節只需要給出用戶名/密碼的工具呢？
這就是我們要介紹的另一種方法使用 Authentication 類
每當遇到網站需要認證的時候HttpURLConnection 都會向 Authentication 類詢問用戶名和密碼
Authentication 類不會知道究竟用戶應該使用哪個 username/password 那麼用戶如何向 Authentication 類提供自己的用戶名和密碼呢？
提供一個繼承於 Authentication 的類實現 getPasswordAuthentication 方法在 PasswordAuthentication 中給出用戶名和密碼
class DefaultAuthenticator extends Authenticator {
public PasswordAuthentication getPasswordAuthentication () {
return new PasswordAuthentication (USER PASSWORDtoCharArray());
}
}
然後將它設為默認的（全局）Authentication
AuthenticatorsetDefault (new DefaultAuthenticator());
那麼不同的網站需要不同的用戶名/密碼又怎麼辦呢？
[NextPage]
Authentication 提供了關於認證發起者的足夠多的信息讓繼承類根據這些信息進行判斷在 getPasswordAuthentication 方法中給出了不同的認證信息
getRequestingHost()
getRequestingPort()
getRequestingPrompt()
getRequestingProtocol()
getRequestingScheme()
getRequestingURL()
getRequestingSite()
getRequestorType()
另一件關於 Authentication 的重要問題是認證類型不同的認證類型需要 Authentication 執行不同的協議至 Java SE 為止Authentication 支持的認證方式有
HTTP Basic authentication
HTTP Digest authentication
NTLM
Http SPNEGO Negotiate
Kerberos
NTLM
這裡我們著重介紹 NTLM
NTLM 是 NT LAN Manager 的縮寫早期的 SMB 協議在網絡上明文傳輸口令這是很不安全的微軟隨後提出了 WindowsNT 挑戰/響應驗證機制即 NTLM
NTLM 協議是這樣的
·客戶端首先將用戶的密碼加密成為密碼散列
·客戶端向服務器發送自己的用戶名這個用戶名是用明文直接傳輸的
·服務器產生一個 位的隨機數字發送給客戶端作為一個 challenge（挑戰）
·客戶端用步驟得到的密碼散列來加密這個 challenge 然後把這個返回給服務器
·服務器把用戶名給客戶端的 challenge 客戶端返回的 response 這三個東西發送域控制器
·域控制器用這個用戶名在 SAM 密碼管理庫中找到這個用戶的密碼散列然後使用這個密碼散列來加密 challenge
·域控制器比較兩次加密的 challenge 如果一樣那麼認證成功
Java 以前的版本是不支持 NTLM 認證的用戶若想使用 HttpConnection 連接到一個使用有 Windows 域保護的網站時是無法通過 NTLM 認證的另一種方法是用戶自己用 Socket 這樣的底層單元實現整個協議過程這無疑是十分復雜的
終於Java 的 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 時每次添加域名可以設定一個系統變量名
Java 中 Authentication 的另一個特性是認證協商目前的服務器一般同時提供幾種認證協議根據客戶端的不同能力協商出一種認證方式比如IIS 服務器會同時提供 NTLM with kerberos 和 NTLM 兩種認證方式當客戶端不支持 NTLM with kerberos 時執行 NTLM 認證
目前Authentication 的默認協商次序是
GSS/SPNEGO > Digest > NTLM > Basic
那麼 kerberos 的位置究竟在哪裡呢？
事實上GSS/SPNEGO 以 JAAS 為基石而後者實際上就是使用 kerberos 的
輕量級 HTTP 服務器
Java 還提供了一個輕量級的純 Java Http 服務器的實現下面是一個簡單的例子
public static void main(String[] args) throws Exception{
HttpServerProvider ();
InetSocketAddress addr = new InetSocketAddress();
HttpServer httpServer = (addr );
(/myapp/ new MyHttpHandler());
(null);
();
Systemoutprintln(started);
}
static class MyHttpHandler implements HttpHandler{
public void handle(HttpExchange httpExchange) throws IOException {
String response = Hello world!;
( responselength());
OutputStream out = ();
outwrite(responsegetBytes());
outclose();
}
}
[NextPage]
然後在浏覽器中訪問//localhost/myapp/我們得到
圖一 浏覽器顯示
首先HttpServer 是從 HttpProvider 處得到的這裡我們使用了 JDK 提供的實現用戶也可以自行實現一個 HttpProvider 和相應的 HttpServer 實現
其次HttpServer 是有上下文（context）的概念的比如//localhost/myapp/ 中/myapp/就是相對於 HttpServer Root 的上下文對於每個上下文都有一個 HttpHandler 來接收 http 請求並給出回答
最後在 HttpHandler 給出具體回答之前一般先要返回一個 Http head這裡使用 HttpExchangesendResponseHeaders（int code int length）其中 code 是 Http 響應的返回值比如那個著名的 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 之前 Java一直都沒有提供 Cookie 管理的功能在 Java SE 裡面 包裡面有一個 CookieHandler 抽象類不過並沒有提供其他具體的實現到了 Java SE Cookie 相關的管理類在 Java 類庫裡面才得到了實現有了這些 Cookie 相關支持的類Java 開發者可以在服務器端編程中很好的操作 Cookie 更好的支持 HTTP 相關應用創建有狀態的 HTTP 會話
·用 HttpCookie 代表 Cookie
HttpCookie 類是 Java SE 新增的一個表示 HTTP Cookie 的新類 其對象可以表示 Cookie 的內容 可以支持所有三種 Cookie 規范
Netscape 草案
RFC
RFC
這個類儲存了 Cookie 的名稱路徑值協議版本號是否過期網絡域最大生命期等等信息
·用 CookiePolicy 規定 Cookie 接受策略
CookiePolicy 接口可以規定 Cookie 的接受策略 其中唯一的方法用來判斷某一特定的 Cookie 是否能被某一特定的地址所接受 這個類內置了 個實現的子類一個類接受所有的 Cookie另一個則拒絕所有還有一個類則接受所有來自原地址的 Cookie
·用CookieStore 儲存 Cookie
CookieStore 接口負責儲存和取出 Cookie 當有 HTTP 請求的時候它便儲存那些被接受的 Cookie 當有 HTTP 回應的時候它便取出相應的 Cookie 另外當一個 Cookie 過期的時候它還負責自動刪去這個 Cookie
·用 CookieManger/CookieHandler 管理 Cookie
CookieManager 是整個 Cookie 管理機制的核心它是 CookieHandler 的默認實現子類下圖顯示了整個 HTTP Cookie 管理機制的結構
圖 Cookie 管理類的關系
一個 CookieManager 裡面有一個 CookieStore 和一個 CookiePolicy分別負責儲存 Cookie 和規定策略用戶可以指定兩者也可以使用系統默認的 CookieManger
[NextPage]
例子
下面這個簡單的例子說明了 Cookie 相關的管理功能
// 創建一個默認的 CookieManager
CookieManager manager = new CookieManager();
// 將規則改掉接受所有的 Cookie
managersetCookiePolicy(CookiePolicyACCEPT_ALL);
// 保存這個定制的 CookieManager
CookieHandlersetDefault(manager);
// 接受 HTTP 請求的時候得到和保存新的 Cookie
HttpCookie cookie = new HttpCookie((name)(value));
managergetCookieStore()add(uri cookie);
// 使用 Cookie 的時候
// 取出 CookieStore
CookieStore store = managergetCookieStore();
// 得到所有的 URI
List uris = storegetURIs();
for (URI uri : uris) {
// 篩選需要的 URI
// 得到屬於這個 URI 的所有 Cookie
List cookies = storeget(uri);
for (HttpCookie cookie : cookies) {
// 取出了 Cookie
}
}
// 或者取出這個 CookieStore 裡面的全部 Cookie
// 過期的 Cookie 將會被自動刪除
List cookies = storegetCookies();
for (HttpCookie cookie : cookies) {
// 取出了 Cookie
}
其他新特性
·NetworkInterface 的增強
從 Java SE 開始JDK 當中出現了一個網絡工具類 NetworkInterface提供了一些網絡的實用功能 在 Java SE 當中這個工具類得到了很大的加強新增了很多實用的方法例如
public boolean isUp（）
用來判斷網絡接口是否啟動並運行
public boolean isLoopback（）
用來判斷網絡接口是否是環回接口（loopback）
public boolean isPointToPoint（）
用來判斷網絡接口是否是點對點（PP）網絡
public boolean supportsMulticast（）
用來判斷網絡接口是否支持多播
public byte[] getHardwareAddress（）
用來得到硬件地址（MAC）
public int getMTU（）
用來得到最大傳輸單位（MTUMaximum Transmission Unit）
public boolean isVirtual（）
用來判斷網絡接口是否是虛饨湧？
關於此工具類的具體信息請參考 Java SE 相應文檔（見 參考資源）
·域名的國際化
在最近的一些 RFC 文檔當中規定 DNS 服務器可以解析除開 ASCII 以外的編碼字符有一個算法可以在這種情況下做 Unicode 與 ASCII 碼之間的轉換實現域名的國際化IDN 就是實現這個國際化域名轉換的新類IDN 是國際化域名的縮寫（internationalized domain names）這個類很簡單主要包括 個靜態函數做字符的轉換
結束語
Java SE 有著很多 HTTP 相關的新特性使得 Java SE 平台本身對網絡編程尤其是基於 HTTP 協議的因特網編程有了更加強大的支持
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26598.html
