Java SE 6 新特性深度解析：HTTP 增強與輕量級服務器實戰

概覽：Mustang 版本的網絡能力躍升

Java SE 6 (代號 Mustang) 在網絡棧引入四大實用增強：NTLM 認證支持、內置輕量級 HTTP 服務器、完善的 Cookie 管理 API、國際化域名 (IDN) 支持。本文結合源碼級示例，演示如何在企業集成、測試桩、微服務網關等場景落地這些能力。

NTLM 認證：Windows 域環境集成的關鍵

背景：Basic/Digest 的不足

Basic 認證 Base64 編碼明文傳輸憑證，Digest 雖用 MD5 挑戰響應但仍易受中間人攻擊。企業內網普遍部署 **Windows 域控制器 + NTLM/Kerberos**，Java 6 前無法原生支持，只能手工構建 Socket 協議極其痛苦。

NTLM 協議流程（簡化）

1. 客戶端發送用戶名（明文）
2. 服務端返回 16 字節隨機 Challenge
3. 客戶端用 NTLM Hash（密碼 MD4）加密 Challenge 返回 Response
4. 服務端轉發給域控驗證，域控比對 SAM 數據庫中用戶 Hash 加密的 Challenge
5. 一致則認證通過

Java 6 一行代碼啟用 NTLM

Authenticator.setDefault(new Authenticator() {
    @Override
    protected PasswordAuthentication getPasswordAuthentication() {
        String user = "DOMAIN\\username"; // 或 "username@domain"
        return new PasswordAuthentication(user, "password".toCharArray());
    }
});

// 可選：系統屬性避免重複拼接域名
// System.setProperty("http.auth.ntlm.domain", "DOMAIN");

HttpURLConnection 遇到 401 + WWW-Authenticate: NTLM 時，自動觸發上述回調完成握手，**業務代碼零感知**。

認證協商順序

JDK 6 默認順序：GSS/SPNEGO (Kerberos) → Digest → NTLM → Basic。
Kerberos 通過 JAAS + GSS-API 實現，SPNEGO 協商機制自動選擇雙方均支持的最高強度協議。

輕量級 HTTP 服務器：`com.sun.net.httpserver.HttpServer`

核心 API 與最小化示例

HttpServer server = HttpServer.create(new InetSocketAddress(7778), 1); // backlog=1
server.createContext("/myapp/", exchange -> {
    String response = "Hello, Java 6 HttpServer!";
    exchange.sendResponseHeaders(200, response.getBytes().length);
    try (OutputStream os = exchange.getResponseBody()) {
        os.write(response.getBytes());
    }
});
server.setExecutor(null); // 默認執行器
server.start();
System.out.println("Server started on port 7778");

瀏覽器訪問 https://localhost:7778/myapp/ 即見響應。

架構要點

• HttpServerProvider SPI：允許替換底層實現（如 Jetty、Undertow 適配器）。
• Context 路由：createContext(path, handler) 支持前綴匹配，HttpExchange 封裝請求/響應、頭、體、Principal。
• Filter 鏈：server.createContext("/", new FilterChain(...)) 實現認證、日志、限流等橫切邏輯。
• 異步非阻塞：JDK 6 為同步阻塞模型，高併發建議升級 JDK 11+ HttpClient 或引入 Netty/Vert.x。

實戰場景

• 測試桩/契約測試：單元測試中啟動內嵌服務器模擬下游 API，驗證請求/響應契約。
• 微服務網關原型：動態路由、負載均衡、熔斷邏輯快速驗證。
• Webhook 接收端：GitHub/GitLab CI 回調、支付寶/微信支付異步通知接收。
• 內部管理端點：健康檢查、指標暴露、配置熱刷新。

Cookie 管理：`java.net.CookieManager` 體系

類結構與職責

CookieHandler (抽象)
  └─ CookieManager (默認實現)
        ├─ CookieStore 存儲/檢索/過期清理
        └─ CookiePolicy 接受/拒絕策略
              ├─ ACCEPT_ALL
              ├─ ACCEPT_NONE
              └─ ACCEPT_ORIGINAL_SERVER (默認，同源策略)
HttpCookie: 不可變數據載體，支持 Netscape/RFC2109/RFC2965 三規範

完整使用示例

// 1. 全局啟用，接受所有 Cookie（爬蟲/測試場景）
CookieManager manager = new CookieManager();
manager.setCookiePolicy(CookiePolicy.ACCEPT_ALL);
CookieHandler.setDefault(manager);

// 2. 手動添加 Cookie（模擬登錄態）
HttpCookie sessionCookie = new HttpCookie("JSESSIONID", "abc123");
sessionCookie.setDomain("example.com");
sessionCookie.setPath("/");
sessionCookie.setSecure(true);
sessionCookie.setHttpOnly(true);
manager.getCookieStore().add(new URI("https://example.com/"), sessionCookie);

// 3. 發送請求時自動攜帶匹配 Cookie
URL url = new URL("https://example.com/api/user");
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
// conn 自動從 CookieManager 獲取並設置 Cookie 頭

// 4. 讀取響應中 Set-Cookie 並自動存儲
// 由 HttpURLConnection 內部完成，無需手動干預

// 5. 遍歷/清理 Cookie
List<HttpCookie> all = manager.getCookieStore().getCookies();
for (HttpCookie c : all) {
    if (c.hasExpired()) manager.getCookieStore().remove(uri, c);
}

生產級注意事項

• 持久化：默認 InMemoryCookieStore 進程重啟丟失。實現 CookieStore 接口對接 Redis/DB。
• 同源策略繞過：跨域場景需自定義 CookiePolicy，謹慎評估安全風險（CSRF）。
• HttpOnly/Secure/SameSite：HttpCookie 支持屬性設置，確保合規。

國際化域名 (IDN) 支持

java.net.IDN 提供 toASCII()/toUnicode() 實現 Punycode 編解碼：

String unicode = "https://例子.测试";
String ascii = IDN.toASCII(unicode); // "https://xn--fsq.xn--0zwm56d"
URI uri = new URI(ascii); // 後續網絡調用使用 ASCII 形式

解決中文/阿拉伯文等非 ASCII 域名在 DNS、HTTP、證書中的互操作問題。

總結與遷移建議

Java SE 6 的網絡增強雖屬「小步快跑」，卻精準解決了企業集成中的**認證、測試、會話管理**三大痛點。理解其設計哲學（SPI 可插拔、標準 API、安全默認），有助於在現代技術棧中做出正確選型。