HttpClient 4.3 中文用戶手冊

時間  2019-11-20
標籤 httpclient 4.3 中文 用戶 手冊 欄目 系統網絡 简体版
原文   原文鏈接

前言

Http協議應該是互聯網中最重要的協議。持續增加的web服務、可聯網的家用電器等都在繼承並拓展着Http協議，向着瀏覽器以外的方向發展。javascript

雖然jdk中的java.net包中提供了一些基本的方法，經過http協議來訪問網絡資源，可是大多數場景下，它都不夠靈活和強大。HttpClient致力於填補這個空白，它能夠提供有效的、最新的、功能豐富的包來實現http客戶端。html

爲了拓展，HttpClient即支持基本的http協議，還支持http-aware客戶端程序，如web瀏覽器，Webservice客戶端，以及利用or拓展http協議的分佈式系統。java

一、HttpClient的範圍/特性web

  • 是一個基於HttpCore的客戶端Http傳輸類庫
  • 基於傳統的（阻塞）IO
  • 內容無關

二、HttpClient不能作的事情算法

  • HttpClient不是瀏覽器，它是一個客戶端http協議傳輸類庫。HttpClient被用來發送和接受Http消息。HttpClient不會處理http消息的內容，不會進行javascript解析，不會關心content type，若是沒有明確設置，httpclient也不會對請求進行格式化、重定向url，或者其餘任何和http消息傳輸相關的功能。

 

第一章 基本概念

1.1. 請求執行

HttpClient最基本的功能就是執行Http方法。一個Http方法的執行涉及到一個或者多個Http請求/Http響應的交互，一般這個過程都會自動被HttpClient處理，對用戶透明。用戶只須要提供Http請求對象，HttpClient就會將http請求發送給目標服務器，而且接收服務器的響應，若是http請求執行不成功，httpclient就會拋出異樣。apache

下面是個很簡單的http請求執行的例子：json

 

  1. CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. HttpGet httpget = new HttpGet("http://localhost/");  
  3. CloseableHttpResponse response = httpclient.execute(httpget);  
  4. try {  
  5.     <...>  
  6. } finally {  
  7.     response.close();  
  8. }  

 

1.1.1. HTTP請求

全部的Http請求都有一個請求行(request line)，包括方法名、請求的URI和Http版本號。windows

HttpClient支持HTTP/1.1這個版本定義的全部Http方法：GET,HEAD,POST,PUT,DELETE,TRACE和OPTIONS。對於每一種http方法，HttpClient都定義了一個相應的類：HttpGet, HttpHead, HttpPost, HttpPut, HttpDelete, HttpTrace和HttpOpquertions。api

Request-URI即統一資源定位符，用來標明Http請求中的資源。Http request URIs包含協議名、主機名、主機端口（可選）、資源路徑、query（可選）和片斷信息（可選）。數組

 

  1. HttpGet httpget = new HttpGet(  
  2.      "http://www.google.com/search?hl=en&q=httpclient&btnG=Google+Search&aq=f&oq=");  

 

HttpClient提供URIBuilder工具類來簡化URIs的建立和修改過程。

 

  1. URI uri = new URIBuilder()  
  2.         .setScheme("http")  
  3.         .setHost("www.google.com")  
  4.         .setPath("/search")  
  5.         .setParameter("q", "httpclient")  
  6.         .setParameter("btnG", "Google Search")  
  7.         .setParameter("aq", "f")  
  8.         .setParameter("oq", "")  
  9.         .build();  
  10. HttpGet httpget = new HttpGet(uri);  
  11. System.out.println(httpget.getURI());  

 

上述代碼會在控制檯輸出：

 

  1. http://www.google.com/search?q=httpclient&btnG=Google+Search&aq=f&oq=  

 

1.1.2. HTTP響應

 

服務器收到客戶端的http請求後，就會對其進行解析，而後把響應發給客戶端，這個響應就是HTTP response.HTTP響應第一行是協議版本，以後是數字狀態碼和相關聯的文本段。

 

  1. HttpResponse response = new BasicHttpResponse(HttpVersion.HTTP_1_1,   
  2. HttpStatus.SC_OK, "OK");  
  3.   
  4. System.out.println(response.getProtocolVersion());  
  5. System.out.println(response.getStatusLine().getStatusCode());  
  6. System.out.println(response.getStatusLine().getReasonPhrase());  
  7. System.out.println(response.getStatusLine().toString());  


上述代碼會在控制檯輸出：

 

 

  1. HTTP/1.1  
  2. 200  
  3. OK  
  4. HTTP/1.1 200 OK  

 

1.1.3. 消息頭

一個Http消息能夠包含一系列的消息頭，用來對http消息進行描述，好比消息長度，消息類型等等。HttpClient提供了方法來獲取、添加、移除、枚舉消息頭。

 

  1. HttpResponse response = new BasicHttpResponse(HttpVersion.HTTP_1_1,   
  2.     HttpStatus.SC_OK, "OK");  
  3. response.addHeader("Set-Cookie",   
  4.     "c1=a; path=/; domain=localhost");  
  5. response.addHeader("Set-Cookie",   
  6.     "c2=b; path=\"/\", c3=c; domain=\"localhost\"");  
  7. Header h1 = response.getFirstHeader("Set-Cookie");  
  8. System.out.println(h1);  
  9. Header h2 = response.getLastHeader("Set-Cookie");  
  10. System.out.println(h2);  
  11. Header[] hs = response.getHeaders("Set-Cookie");  
  12. System.out.println(hs.length);  


上述代碼會在控制檯輸出：

 

 

  1. Set-Cookie: c1=a; path=/; domain=localhost  
  2. Set-Cookie: c2=b; path="/", c3=c; domain="localhost"  
  3. 2  

 

最有效的獲取指定類型的消息頭的方法仍是使用HeaderIterator接口。

 

  1. HttpResponse response = new BasicHttpResponse(HttpVersion.HTTP_1_1,   
  2.     HttpStatus.SC_OK, "OK");  
  3. response.addHeader("Set-Cookie",   
  4.     "c1=a; path=/; domain=localhost");  
  5. response.addHeader("Set-Cookie",   
  6.     "c2=b; path=\"/\", c3=c; domain=\"localhost\"");  
  7.   
  8. HeaderIterator it = response.headerIterator("Set-Cookie");  
  9.   
  10. while (it.hasNext()) {  
  11.     System.out.println(it.next());  
  12. }  

 

上述代碼會在控制檯輸出：

 

  1. Set-Cookie: c1=a; path=/; domain=localhost  
  2. Set-Cookie: c2=b; path="/", c3=c; domain="localhost"  

 

HeaderIterator也提供很是便捷的方式，將Http消息解析成單獨的消息頭元素。

 

  1. HttpResponse response = new BasicHttpResponse(HttpVersion.HTTP_1_1,   
  2.     HttpStatus.SC_OK, "OK");  
  3. response.addHeader("Set-Cookie",   
  4.     "c1=a; path=/; domain=localhost");  
  5. response.addHeader("Set-Cookie",   
  6.     "c2=b; path=\"/\", c3=c; domain=\"localhost\"");  
  7.   
  8. HeaderElementIterator it = new BasicHeaderElementIterator(  
  9.     response.headerIterator("Set-Cookie"));  
  10.   
  11. while (it.hasNext()) {  
  12.     HeaderElement elem = it.nextElement();   
  13.     System.out.println(elem.getName() + " = " + elem.getValue());  
  14.     NameValuePair[] params = elem.getParameters();  
  15.     for (int i = 0; i < params.length; i++) {  
  16.         System.out.println(" " + params[i]);  
  17.     }  
  18. }  

 

上述代碼會在控制檯輸出：

 

  1. c1 = a  
  2. path=/  
  3. domain=localhost  
  4. c2 = b  
  5. path=/  
  6. c3 = c  
  7. domain=localhost  

 

1.1.4. HTTP實體

Http消息能夠攜帶http實體，這個http實體既能夠是http請求，也能夠是http響應的。Http實體，能夠在某些http請求或者響應中發現，但不是必須的。Http規範中定義了兩種包含請求的方法：POST和PUT。HTTP響應通常會包含一個內容實體。固然這條規則也有異常狀況，如Head方法的響應，204沒有內容，304沒有修改或者205內容資源重置。

HttpClient根據來源的不一樣，劃分了三種不一樣的Http實體內容。

  • streamed流式: 內容是經過流來接受或者在運行中產生。特別是，streamed這一類包含從http響應中獲取的實體內容。通常說來，streamed實體是不可重複的。
  • self-contained自我包含式:內容在內存中或經過獨立的鏈接或其它實體中得到。self-contained類型的實體內容一般是可重複的。這種類型的實體一般用於關閉http請求。
  • wrapping包裝式: 這種類型的內容是從另外的http實體中獲取的。

當從Http響應中讀取內容時，上面的三種區分對於鏈接管理器來講是很是重要的。對於由應用程序建立並且只使用HttpClient發送的請求實體，streamed和self-contained兩種類型的不一樣就不那麼重要了。這種狀況下，建議考慮如streamed流式這種不能重複的實體，和能夠重複的self-contained自我包含式實體。

1.1.4.1. 可重複的實體

一個實體是可重複的，也就是說它的包含的內容能夠被屢次讀取。這種屢次讀取只有self contained（自包含）的實體能作到（好比ByteArrayEntity或者StringEntity)。

1.1.4.2. 使用Http實體

因爲一個Http實體既能夠表示二進制內容，又能夠表示文本內容，因此Http實體要支持字符編碼（爲了支持後者，即文本內容）。

當須要執行一個完整內容的Http請求或者Http請求已經成功，服務器要發送響應到客戶端時，Http實體就會被建立。

若是要從Http實體中讀取內容，咱們能夠利用HttpEntity類的getContent方法來獲取實體的輸入流（java.io.InputStream)，或者利用HttpEntity類的writeTo(OutputStream)方法來獲取輸出流，這個方法會把全部的內容寫入到給定的流中。
當實體類已經被接受後，咱們能夠利用HttpEntity類的getContentType()和getContentLength()方法來讀取Content-Type和Content-Length兩個頭消息（若是有的話）。因爲Content-Type包含mime-types的字符編碼，好比text/plain或者text/html,HttpEntity類的getContentEncoding()方法就是讀取這個編碼的。若是頭信息不存在，getContentLength（）會返回-1,getContentType()會返回NULL。若是Content-Type信息存在，就會返回一個Header類。

當爲發送消息建立Http實體時，須要同時附加meta信息。

 

  1. StringEntity myEntity = new StringEntity("important message",   
  2.    ContentType.create("text/plain", "UTF-8"));  
  3.   
  4. System.out.println(myEntity.getContentType());  
  5. System.out.println(myEntity.getContentLength());  
  6. System.out.println(EntityUtils.toString(myEntity));  
  7. System.out.println(EntityUtils.toByteArray(myEntity).length);  


上述代碼會在控制檯輸出：

 

 

  1. Content-Type: text/plain; charset=utf-8  
  2. 17  
  3. important message  
  4. 17  

 

1.1.5. 確保底層的資源鏈接被釋放

 

爲了確保系統資源被正確地釋放，咱們要麼管理Http實體的內容流、要麼關閉Http響應。

 

  1. CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. HttpGet httpget = new HttpGet("http://localhost/");  
  3. CloseableHttpResponse response = httpclient.execute(httpget);  
  4. try {  
  5.     HttpEntity entity = response.getEntity();  
  6.     if (entity != null) {  
  7.         InputStream instream = entity.getContent();  
  8.         try {  
  9.             // do something useful  
  10.         } finally {  
  11.             instream.close();  
  12.         }  
  13.     }  
  14. } finally {  
  15.     response.close();  
  16. }  


關閉Http實體內容流和關閉Http響應的區別在於，前者經過消耗掉Http實體內容來保持相關的http鏈接，而後後者會當即關閉、丟棄http鏈接。

 

請注意HttpEntity的writeTo(OutputStream)方法，當Http實體被寫入到OutputStream後，也要確保釋放系統資源。若是這個方法內調用了HttpEntity的getContent()方法，那麼它會有一個java.io.InpputStream的實例，咱們須要在finally中關閉這個流。

可是也有這樣的狀況，咱們只須要獲取Http響應內容的一小部分，而獲取整個內容並、實現鏈接的可重複性代價太大，這時咱們能夠經過關閉響應的方式來關閉內容輸入、輸出流。

 

  1. CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. HttpGet httpget = new HttpGet("http://localhost/");  
  3. CloseableHttpResponse response = httpclient.execute(httpget);  
  4. try {  
  5.     HttpEntity entity = response.getEntity();  
  6.     if (entity != null) {  
  7.         InputStream instream = entity.getContent();  
  8.         int byteOne = instream.read();  
  9.         int byteTwo = instream.read();  
  10.         // Do not need the rest  
  11.     }  
  12. } finally {  
  13.     response.close();  
  14. }  


上面的代碼執行後，鏈接變得不可用，全部的資源都將被釋放。

 

1.1.6. 消耗HTTP實體內容

HttpClient推薦使用HttpEntity的getConent()方法或者HttpEntity的writeTo(OutputStream)方法來消耗掉Http實體內容。HttpClient也提供了EntityUtils這個類，這個類提供一些靜態方法能夠更容易地讀取Http實體的內容和信息。和以java.io.InputStream流讀取內容的方式相比，EntityUtils提供的方法能夠以字符串或者字節數組的形式讀取Http實體。可是，強烈不推薦使用EntityUtils這個類，除非目標服務器發出的響應是可信任的，而且http響應實體的長度不會過大。

 

  1. CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. HttpGet httpget = new HttpGet("http://localhost/");  
  3. CloseableHttpResponse response = httpclient.execute(httpget);  
  4. try {  
  5.     HttpEntity entity = response.getEntity();  
  6.     if (entity != null) {  
  7.         long len = entity.getContentLength();  
  8.         if (len != -1 && len < 2048) {  
  9.             System.out.println(EntityUtils.toString(entity));  
  10.         } else {  
  11.             // Stream content out  
  12.         }  
  13.     }  
  14. } finally {  
  15.     response.close();  
  16. }  

 

有些狀況下，咱們但願能夠重複讀取Http實體的內容。這就須要把Http實體內容緩存在內存或者磁盤上。最簡單的方法就是把Http Entity轉化成BufferedHttpEntity，這樣就把原Http實體的內容緩衝到了內存中。後面咱們就能夠重複讀取BufferedHttpEntity中的內容。

 

  1. CloseableHttpResponse response = <...>  
  2. HttpEntity entity = response.getEntity();  
  3. if (entity != null) {  
  4.     entity = new BufferedHttpEntity(entity);  
  5. }  

 

1.1.7. 建立HTTP實體內容

 

HttpClient提供了一些類，這些類能夠經過http鏈接高效地輸出Http實體內容。HttpClient提供的這幾個類涵蓋的常見的數據類型，如String，byte數組，輸入流，和文件類型：StringEntity,ByteArrayEntity,InputStreamEntity,FileEntity。

 

  1. File file = new File("somefile.txt");  
  2. FileEntity entity = new FileEntity(file,   
  3.     ContentType.create("text/plain", "UTF-8"));          
  4.   
  5. HttpPost httppost = new HttpPost("http://localhost/action.do");  
  6. httppost.setEntity(entity);  

請注意因爲InputStreamEntity只能從下層的數據流中讀取一次，因此它是不能重複的。推薦，經過繼承HttpEntity這個自包含的類來自定義HttpEntity類，而不是直接使用InputStreamEntity這個類。FileEntity就是一個很好的起點（FileEntity就是繼承的HttpEntity）。

 

1.7.1.1. HTML表單

不少應用程序須要模擬提交Html表單的過程，舉個例子，登錄一個網站或者將輸入內容提交給服務器。HttpClient提供了UrlEncodedFormEntity這個類來幫助實現這一過程。

  1. List<NameValuePair> formparams = new ArrayList<NameValuePair>();  
  2. formparams.add(new BasicNameValuePair("param1", "value1"));  
  3. formparams.add(new BasicNameValuePair("param2", "value2"));  
  4. UrlEncodedFormEntity entity = new UrlEncodedFormEntity(formparams, Consts.UTF_8);  
  5. HttpPost httppost = new HttpPost("http://localhost/handler.do");  
  6. httppost.setEntity(entity);  

 

UrlEncodedFormEntity實例會使用所謂的Url編碼的方式對咱們的參數進行編碼，產生的結果以下：

  1. param1=value1&m2=value2  

 

1.1.7.2. 內容分塊

通常來講，推薦讓HttpClient本身根據Http消息傳遞的特徵來選擇最合適的傳輸編碼。固然，若是非要手動控制也是能夠的，能夠經過設置HttpEntity的setChunked()爲true。請注意：HttpClient僅會將這個參數當作是一個建議。若是Http的版本（如http 1.0)不支持內容分塊，那麼這個參數就會被忽略。

  1. StringEntity entity = new StringEntity("important message",  
  2.         ContentType.create("plain/text", Consts.UTF_8));  
  3. entity.setChunked(true);  
  4. HttpPost httppost = new HttpPost("http://localhost/acrtion.do");  
  5. httppost.setEntity(entity);  

 

1.1.8.RESPONSE HANDLERS

最簡單也是最方便的處理http響應的方法就是使用ResponseHandler接口，這個接口中有handleResponse(HttpResponse response)方法。使用這個方法，用戶徹底不用關心http鏈接管理器。當使用ResponseHandler時，HttpClient會自動地將Http鏈接釋放給Http管理器，即便http請求失敗了或者拋出了異常。

  1. CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. HttpGet httpget = new HttpGet("http://localhost/json");  
  3.   
  4. ResponseHandler<MyJsonObject> rh = new ResponseHandler<MyJsonObject>() {  
  5.   
  6.     @Override  
  7.     public JsonObject handleResponse(  
  8.             final HttpResponse response) throws IOException {  
  9.         StatusLine statusLine = response.getStatusLine();  
  10.         HttpEntity entity = response.getEntity();  
  11.         if (statusLine.getStatusCode() >= 300) {  
  12.             throw new HttpResponseException(  
  13.                     statusLine.getStatusCode(),  
  14.                     statusLine.getReasonPhrase());  
  15.         }  
  16.         if (entity == null) {  
  17.             throw new ClientProtocolException("Response contains no content");  
  18.         }  
  19.         Gson gson = new GsonBuilder().create();  
  20.         ContentType contentType = ContentType.getOrDefault(entity);  
  21.         Charset charset = contentType.getCharset();  
  22.         Reader reader = new InputStreamReader(entity.getContent(), charset);  
  23.         return gson.fromJson(reader, MyJsonObject.class);  
  24.     }  
  25. };  
  26. MyJsonObject myjson = client.execute(httpget, rh);  

 

1.2. HttpClient接口

對於Http請求執行過程來講，HttpClient的接口有着必不可少的做用。HttpClient接口沒有對Http請求的過程作特別的限制和詳細的規定，鏈接管理、狀態管理、受權信息和重定向處理這些功能都單獨實現。這樣用戶就能夠更簡單地拓展接口的功能（好比緩存響應內容）。

通常說來，HttpClient實際上就是一系列特殊的handler或者說策略接口的實現，這些handler（測試接口）負責着處理Http協議的某一方面，好比重定向、認證處理、有關鏈接持久性和keep alive持續時間的決策。這樣就容許用戶使用自定義的參數來代替默認配置，實現個性化的功能。

  1. ConnectionKeepAliveStrategy keepAliveStrat = new DefaultConnectionKeepAliveStrategy() {  
  2.   
  3.     @Override  
  4.     public long getKeepAliveDuration(  
  5.             HttpResponse response,  
  6.             HttpContext context) {  
  7.         long keepAlive = super.getKeepAliveDuration(response, context);  
  8.         if (keepAlive == -1) {  
  9.             // Keep connections alive 5 seconds if a keep-alive value  
  10.             // has not be explicitly set by the server  
  11.             keepAlive = 5000;  
  12.         }  
  13.         return keepAlive;  
  14.     }  
  15.   
  16. };  
  17. CloseableHttpClient httpclient = HttpClients.custom()  
  18.         .setKeepAliveStrategy(keepAliveStrat)  
  19.         .build();  

 

1.2.1.HTTPCLIENT的線程安全性

HttpClient已經實現了線程安全。因此但願用戶在實例化HttpClient時，也要支持爲多個請求使用。

1.2.2.HTTPCLIENT的內存分配

當一個CloseableHttpClient的實例再也不被使用，而且它的做用範圍即將失效，和它相關的鏈接必須被關閉，關閉方法能夠調用CloseableHttpClient的close()方法。

  1. CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. try {  
  3.     <...>  
  4. } finally {  
  5.     httpclient.close();  
  6. }  

 

1.3.Http執行上下文

最初，Http被設計成一種無狀態的、面向請求-響應的協議。然而，在實際使用中，咱們但願可以在一些邏輯相關的請求-響應中，保持狀態信息。爲了使應用程序能夠保持Http的持續狀態，HttpClient容許http鏈接在特定的Http上下文中執行。若是在持續的http請求中使用了一樣的上下文，那麼這些請求就能夠被分配到一個邏輯會話中。HTTP上下文就和一個java.util.Map<String, Object>功能相似。它實際上就是一個任意命名的值的集合。應用程序能夠在Http請求執行前填充上下文的值，也能夠在請求執行完畢後檢查上下文。

HttpContext能夠包含任意類型的對象，所以若是在多線程中共享上下文會不安全。推薦每一個線程都只包含本身的http上下文。

在Http請求執行的過程當中，HttpClient會自動添加下面的屬性到Http上下文中：

  • HttpConnection的實例，表示客戶端與服務器之間的鏈接
  • HttpHost的實例，表示要鏈接的目標服務器
  • HttpRoute的實例，表示所有的鏈接路由
  • HttpRequest的實例，表示Http請求。在執行上下文中，最終的HttpRequest對象會表明http消息的狀態。Http/1.0和Http/1.1都默認使用相對的uri。可是若是使用了非隧道模式的代理服務器，就會使用絕對路徑的uri。
  • HttpResponse的實例，表示Http響應
  • java.lang.Boolean對象，表示是否請求被成功的發送給目標服務器
  • RequestConfig對象，表示http request的配置信息
  • java.util.List<Uri>對象，表示Http響應中的全部重定向地址

咱們可使用HttpClientContext這個適配器來簡化和上下文交互的過程。

  1. HttpContext context = <...>  
  2. HttpClientContext clientContext = HttpClientContext.adapt(context);  
  3. HttpHost target = clientContext.getTargetHost();  
  4. HttpRequest request = clientContext.getRequest();  
  5. HttpResponse response = clientContext.getResponse();  
  6. RequestConfig config = clientContext.getRequestConfig();  

 

同一個邏輯會話中的多個Http請求，應該使用相同的Http上下文來執行，這樣就能夠自動地在http請求中傳遞會話上下文和狀態信息。
在下面的例子中，咱們在開頭設置的參數，會被保存在上下文中，而且會應用到後續的http請求中。

  1. CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. RequestConfig requestConfig = RequestConfig.custom()  
  3.         .setSocketTimeout(1000)  
  4.         .setConnectTimeout(1000)  
  5.         .build();  
  6.   
  7. HttpGet httpget1 = new HttpGet("http://localhost/1");  
  8. httpget1.setConfig(requestConfig);  
  9. CloseableHttpResponse response1 = httpclient.execute(httpget1, context);  
  10. try {  
  11.     HttpEntity entity1 = response1.getEntity();  
  12. } finally {  
  13.     response1.close();  
  14. }  
  15. HttpGet httpget2 = new HttpGet("http://localhost/2");  
  16. CloseableHttpResponse response2 = httpclient.execute(httpget2, context);  
  17. try {  
  18.     HttpEntity entity2 = response2.getEntity();  
  19. } finally {  
  20.     response2.close();  
  21. }  

 

1.4. 異常處理

HttpClient會被拋出兩種類型的異常，一種是java.io.IOException，當遇到I/O異常時拋出（socket超時，或者socket被重置）;另外一種是HttpException,表示Http失敗，如Http協議使用不正確。一般認爲，I/O錯誤時不致命、可修復的，而Http協議錯誤是致命了，不能自動修復的錯誤。

1.4.1.HTTP傳輸安全

Http協議不能知足全部類型的應用場景，咱們須要知道這點。Http是個簡單的面向協議的請求/響應的協議，當初它被設計用來支持靜態或者動態生成的內容檢索，以前歷來沒有人想過讓它支持事務性操做。例如，Http服務器成功接收、處理請求後，生成響應消息，而且把狀態碼發送給客戶端，這個過程是Http協議應該保證的。可是，若是客戶端因爲讀取超時、取消請求或者系統崩潰致使接收響應失敗，服務器不會回滾這一事務。若是客戶端從新發送這個請求，服務器就會重複的解析、執行這個事務。在一些狀況下，這會致使應用程序的數據損壞和應用程序的狀態不一致。

即便Http當初設計是不支持事務操做，可是它仍舊能夠做爲傳輸協議爲某些關鍵程序提供服務。爲了保證Http傳輸層的安全性，系統必須保證應用層上的http方法的冪等性。

1.4.2.方法的冪等性

HTTP/1.1規範中是這樣定義冪等方法的，Methods can also have the property of 「idempotence」 in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request。用其餘話來講，應用程序須要正確地處理同一方法屢次執行形成的影響。添加一個具備惟一性的id就能避免重複執行同一個邏輯請求，問題解決。

請知曉，這個問題不僅是HttpClient纔會有，基於瀏覽器的應用程序也會遇到Http方法不冪等的問題。

HttpClient默認把非實體方法get、head方法看作冪等方法，把實體方法post、put方法看作非冪等方法。

1.4.3.異常自動修復

默認狀況下，HttpClient會嘗試自動修復I/O異常。這種自動修復僅限於修復幾個公認安全的異常。

  • HttpClient不會嘗試修復任何邏輯或者http協議錯誤（即從HttpException衍生出來的異常）。
  • HttpClient會自動再次發送冪等的方法（若是首次執行失敗)。
  • HttpClient會自動再次發送遇到transport異常的方法，前提是Http請求仍舊保持着鏈接（例如http請求沒有所有發送給目標服務器，HttpClient會再次嘗試發送）。

1.4.4.請求重試HANDLER

若是要自定義異常處理機制，咱們須要實現HttpRequestRetryHandler接口。

  1. HttpRequestRetryHandler myRetryHandler = new HttpRequestRetryHandler() {  
  2.   
  3.     public boolean retryRequest(  
  4.             IOException exception,  
  5.             int executionCount,  
  6.             HttpContext context) {  
  7.         if (executionCount >= 5) {  
  8.             // Do not retry if over max retry count  
  9.             return false;  
  10.         }  
  11.         if (exception instanceof InterruptedIOException) {  
  12.             // Timeout  
  13.             return false;  
  14.         }  
  15.         if (exception instanceof UnknownHostException) {  
  16.             // Unknown host  
  17.             return false;  
  18.         }  
  19.         if (exception instanceof ConnectTimeoutException) {  
  20.             // Connection refused  
  21.             return false;  
  22.         }  
  23.         if (exception instanceof SSLException) {  
  24.             // SSL handshake exception  
  25.             return false;  
  26.         }  
  27.         HttpClientContext clientContext = HttpClientContext.adapt(context);  
  28.         HttpRequest request = clientContext.getRequest();  
  29.         boolean idempotent = !(request instanceof HttpEntityEnclosingRequest);  
  30.         if (idempotent) {  
  31.             // Retry if the request is considered idempotent  
  32.             return true;  
  33.         }  
  34.         return false;  
  35.     }  
  36. };  
  37. CloseableHttpClient httpclient = HttpClients.custom()  
  38.         .setRetryHandler(myRetryHandler)  
  39.         .build();  

 

1.5.終止請求

有時候因爲目標服務器負載太高或者客戶端目前有太多請求積壓，http請求不能在指定時間內執行完畢。這時候終止這個請求，釋放阻塞I/O的進程，就顯得很必要。經過HttpClient執行的Http請求，在任何狀態下都能經過調用HttpUriRequest的abort()方法來終止。這個方法是線程安全的，而且能在任何線程中調用。當Http請求被終止了，本線程（即便如今正在阻塞I/O）也會經過拋出一個InterruptedIOException異常，來釋放資源。

1.6. Http協議攔截器

HTTP協議攔截器是一種實現一個特定的方面的HTTP協議的代碼程序。一般狀況下，協議攔截器會將一個或多個頭消息加入到接受或者發送的消息中。協議攔截器也能夠操做消息的內容實體—消息內容的壓縮/解壓縮就是個很好的例子。一般，這是經過使用「裝飾」開發模式，一個包裝實體類用於裝飾原來的實體來實現。一個攔截器能夠合併，造成一個邏輯單元。

協議攔截器能夠經過共享信息協做——好比處理狀態——經過HTTP執行上下文。協議攔截器可使用Http上下文存儲一個或者多個連續請求的處理狀態。

一般，只要攔截器不依賴於一個特定狀態的http上下文，那麼攔截執行的順序就無所謂。若是協議攔截器有相互依賴關係，必須以特定的順序執行，那麼它們應該按照特定的順序加入到協議處理器中。

協議處理器必須是線程安全的。相似於servlets，協議攔截器不該該使用變量實體，除非訪問這些變量是同步的（線程安全的）。

下面是個例子，講述了本地的上下文時如何在連續請求中記錄處理狀態的：

  1. CloseableHttpClient httpclient = HttpClients.custom()  
  2.         .addInterceptorLast(new HttpRequestInterceptor() {  
  3.   
  4.             public void process(  
  5.                     final HttpRequest request,  
  6.                     final HttpContext context) throws HttpException, IOException {  
  7.                 AtomicInteger count = (AtomicInteger) context.getAttribute("count");  
  8.                 request.addHeader("Count", Integer.toString(count.getAndIncrement()));  
  9.             }  
  10.   
  11.         })  
  12.         .build();  
  13.   
  14. AtomicInteger count = new AtomicInteger(1);  
  15. HttpClientContext localContext = HttpClientContext.create();  
  16. localContext.setAttribute("count", count);  
  17.   
  18. HttpGet httpget = new HttpGet("http://localhost/");  
  19. for (int i = 0; i < 10; i++) {  
  20.     CloseableHttpResponse response = httpclient.execute(httpget, localContext);  
  21.     try {  
  22.         HttpEntity entity = response.getEntity();  
  23.     } finally {  
  24.         response.close();  
  25.     }  
  26. }  

 

上面代碼在發送http請求時，會自動添加Count這個header，可使用wireshark抓包查看。

1.7.1. 重定向處理

HttpClient會自動處理全部類型的重定向，除了那些Http規範明確禁止的重定向。See Other (status code 303) redirects on POST and PUT requests are converted to GET requests as required by the HTTP specification. 咱們可使用自定義的重定向策略來放鬆Http規範對Post方法重定向的限制。

  1. LaxRedirectStrategy redirectStrategy = new LaxRedirectStrategy();  
  2. CloseableHttpClient httpclient = HttpClients.custom()  
  3.         .setRedirectStrategy(redirectStrategy)  
  4.         .build();  

 

HttpClient在請求執行過程當中，常常須要重寫請求的消息。 HTTP/1.0和HTTP/1.1都默認使用相對的uri路徑。一樣，原始的請求可能會被一次或者屢次的重定向。最終結對路徑的解釋可使用最初的請求和上下文。URIUtils類的resolve方法能夠用於將攔截的絕對路徑構建成最終的請求。這個方法包含了最後一個分片標識符或者原始請求。

  1. CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. HttpClientContext context = HttpClientContext.create();  
  3. HttpGet httpget = new HttpGet("http://localhost:8080/");  
  4. CloseableHttpResponse response = httpclient.execute(httpget, context);  
  5. try {  
  6.     HttpHost target = context.getTargetHost();  
  7.     List<URI> redirectLocations = context.getRedirectLocations();  
  8.     URI location = URIUtils.resolve(httpget.getURI(), target, redirectLocations);  
  9.     System.out.println("Final HTTP location: " + location.toASCIIString());  
  10.     // Expected to be an absolute URI  
  11. } finally {  
  12.     response.close();  
  13. }  

 

第二章 鏈接管理

 

2.1.持久鏈接

兩個主機創建鏈接的過程是很複雜的一個過程，涉及到多個數據包的交換，而且也很耗時間。Http鏈接須要的三次握手開銷很大，這一開銷對於比較小的http消息來講更大。可是若是咱們直接使用已經創建好的http鏈接，這樣花費就比較小，吞吐率更大。

HTTP/1.1默認就支持Http鏈接複用。兼容HTTP/1.0的終端也能夠經過聲明來保持鏈接，實現鏈接複用。HTTP代理也能夠在必定時間內保持鏈接不釋放，方便後續向這個主機發送http請求。這種保持鏈接不釋放的狀況其實是創建的持久鏈接。HttpClient也支持持久鏈接。

2.2.HTTP鏈接路由

HttpClient既能夠直接、又能夠經過多箇中轉路由（hops）和目標服務器創建鏈接。HttpClient把路由分爲三種plain（明文 ），tunneled（隧道）和layered（分層）。隧道鏈接中使用的多箇中間代理被稱做代理鏈。

客戶端直接鏈接到目標主機或者只經過了一箇中間代理，這種就是Plain路由。客戶端經過第一個代理創建鏈接，經過代理鏈tunnelling，這種狀況就是Tunneled路由。不經過中間代理的路由不可能時tunneled路由。客戶端在一個已經存在的鏈接上進行協議分層，這樣創建起來的路由就是layered路由。協議只能在隧道—>目標主機，或者直接鏈接（沒有代理），這兩種鏈路上進行分層。

2.2.1.路由計算

RouteInfo接口包含了數據包發送到目標主機過程當中，通過的路由信息。HttpRoute類繼承了RouteInfo接口，是RouteInfo的具體實現，這個類是不容許修改的。HttpTracker類也實現了RouteInfo接口，它是可變的，HttpClient會在內部使用這個類來探測到目標主機的剩餘路由。HttpRouteDirector是個輔助類，能夠幫助計算數據包的下一步路由信息。這個類也是在HttpClient內部使用的。

HttpRoutePlanner接口能夠用來表示基於http上下文狀況下，客戶端到服務器的路由計算策略。HttpClient有兩個HttpRoutePlanner的實現類。SystemDefaultRoutePlanner這個類基於java.net.ProxySelector，它默認使用jvm的代理配置信息，這個配置信息通常來自系統配置或者瀏覽器配置。DefaultProxyRoutePlanner這個類既不使用java自己的配置，也不使用系統或者瀏覽器的配置。它一般經過默認代理來計算路由信息。

2.2.2. 安全的HTTP鏈接

爲了防止經過Http消息傳遞的信息不被未受權的第三方獲取、截獲，Http可使用SSL/TLS協議來保證http傳輸安全，這個協議是當前使用最廣的。固然也可使用其餘的加密技術。可是一般狀況下，Http信息會在加密的SSL/TLS鏈接上進行傳輸。

2.3. HTTP鏈接管理器

2.3.1. 管理鏈接和鏈接管理器

Http鏈接是複雜，有狀態的，線程不安全的對象，因此它必須被妥善管理。一個Http鏈接在同一時間只能被一個線程訪問。HttpClient使用一個叫作Http鏈接管理器的特殊實體類來管理Http鏈接，這個實體類要實現HttpClientConnectionManager接口。Http鏈接管理器在新建http鏈接時，做爲工廠類;管理持久http鏈接的生命週期;同步持久鏈接（確保線程安全，即一個http鏈接同一時間只能被一個線程訪問）。Http鏈接管理器和ManagedHttpClientConnection的實例類一塊兒發揮做用，ManagedHttpClientConnection實體類能夠看作http鏈接的一個代理服務器，管理着I/O操做。若是一個Http鏈接被釋放或者被它的消費者明確表示要關閉，那麼底層的鏈接就會和它的代理進行分離，而且該鏈接會被交還給鏈接管理器。這是，即便服務消費者仍然持有代理的引用，它也不能再執行I/O操做，或者更改Http鏈接的狀態。

下面的代碼展現瞭如何從鏈接管理器中取得一個http鏈接：

  1. HttpClientContext context = HttpClientContext.create();  
  2. HttpClientConnectionManager connMrg = new BasicHttpClientConnectionManager();  
  3. HttpRoute route = new HttpRoute(new HttpHost("localhost", 80));  
  4. // 獲取新的鏈接. 這裏可能耗費不少時間  
  5. ConnectionRequest connRequest = connMrg.requestConnection(route, null);  
  6. // 10秒超時  
  7. HttpClientConnection conn = connRequest.get(10, TimeUnit.SECONDS);  
  8. try {  
  9.     // 若是建立鏈接失敗  
  10.     if (!conn.isOpen()) {  
  11.         // establish connection based on its route info  
  12.         connMrg.connect(conn, route, 1000, context);  
  13.         // and mark it as route complete  
  14.         connMrg.routeComplete(conn, route, context);  
  15.     }  
  16.      // 進行本身的操做.  
  17. } finally {  
  18.     connMrg.releaseConnection(conn, null, 1, TimeUnit.MINUTES);  
  19. }  

 

若是要終止鏈接，能夠調用ConnectionRequest的cancel()方法。這個方法會解鎖被ConnectionRequest類get()方法阻塞的線程。

2.3.2.簡單鏈接管理器

BasicHttpClientConnectionManager是個簡單的鏈接管理器，它一次只能管理一個鏈接。儘管這個類是線程安全的，它在同一時間也只能被一個線程使用。BasicHttpClientConnectionManager會盡可能重用舊的鏈接來發送後續的請求，而且使用相同的路由。若是後續請求的路由和舊鏈接中的路由不匹配，BasicHttpClientConnectionManager就會關閉當前鏈接，使用請求中的路由從新創建鏈接。若是當前的鏈接正在被佔用，會拋出java.lang.IllegalStateException異常。

2.3.3.鏈接池管理器

相對BasicHttpClientConnectionManager來講，PoolingHttpClientConnectionManager是個更復雜的類，它管理着鏈接池，能夠同時爲不少線程提供http鏈接請求。Connections are pooled on a per route basis.當請求一個新的鏈接時，若是鏈接池有有可用的持久鏈接，鏈接管理器就會使用其中的一個，而不是再建立一個新的鏈接。

PoolingHttpClientConnectionManager維護的鏈接數在每一個路由基礎和總數上都有限制。默認，每一個路由基礎上的鏈接不超過2個，總鏈接數不能超過20。在實際應用中，這個限制可能會過小了，尤爲是當服務器也使用Http協議時。

下面的例子演示了若是調整鏈接池的參數：

  1. PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();  
  2. // Increase max total connection to 200  
  3. cm.setMaxTotal(200);  
  4. // Increase default max connection per route to 20  
  5. cm.setDefaultMaxPerRoute(20);  
  6. // Increase max connections for localhost:80 to 50  
  7. HttpHost localhost = new HttpHost("locahost", 80);  
  8. cm.setMaxPerRoute(new HttpRoute(localhost), 50);  
  9.   
  10. CloseableHttpClient httpClient = HttpClients.custom()  
  11.         .setConnectionManager(cm)  
  12.         .build();  

 

2.3.4.關閉鏈接管理器

當一個HttpClient的實例不在使用，或者已經脫離它的做用範圍，咱們須要關掉它的鏈接管理器，來關閉掉全部的鏈接，釋放掉這些鏈接佔用的系統資源。

  1. CloseableHttpClient httpClient = <...>  
  2. httpClient.close();  

 

2.4.多線程請求執行

當使用了請求鏈接池管理器（好比PoolingClientConnectionManager）後，HttpClient就能夠同時執行多個線程的請求了。

PoolingClientConnectionManager會根據它的配置來分配請求鏈接。若是鏈接池中的全部鏈接都被佔用了，那麼後續的請求就會被阻塞，直到有鏈接被釋放回鏈接池中。爲了防止永遠阻塞的狀況發生，咱們能夠把http.conn-manager.timeout的值設置成一個整數。若是在超時時間內，沒有可用鏈接，就會拋出ConnectionPoolTimeoutException異常。

  1. PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();  
  2. CloseableHttpClient httpClient = HttpClients.custom()  
  3.         .setConnectionManager(cm)  
  4.         .build();  
  5.   
  6. // URIs to perform GETs on  
  7. String[] urisToGet = {  
  8.     "http://www.domain1.com/",  
  9.     "http://www.domain2.com/",  
  10.     "http://www.domain3.com/",  
  11.     "http://www.domain4.com/"  
  12. };  
  13.   
  14. // create a thread for each URI  
  15. GetThread[] threads = new GetThread[urisToGet.length];  
  16. for (int i = 0; i < threads.length; i++) {  
  17.     HttpGet httpget = new HttpGet(urisToGet[i]);  
  18.     threads[i] = new GetThread(httpClient, httpget);  
  19. }  
  20.   
  21. // start the threads  
  22. for (int j = 0; j < threads.length; j++) {  
  23.     threads[j].start();  
  24. }  
  25.   
  26. // join the threads  
  27. for (int j = 0; j < threads.length; j++) {  
  28.     threads[j].join();  
  29. }  

 

即便HttpClient的實例是線程安全的，能夠被多個線程共享訪問，可是仍舊推薦每一個線程都要有本身專用實例的HttpContext。

下面是GetThread類的定義：

  1. static class GetThread extends Thread {  
  2.   
  3.     private final CloseableHttpClient httpClient;  
  4.     private final HttpContext context;  
  5.     private final HttpGet httpget;  
  6.   
  7.     public GetThread(CloseableHttpClient httpClient, HttpGet httpget) {  
  8.         this.httpClient = httpClient;  
  9.         this.context = HttpClientContext.create();  
  10.         this.httpget = httpget;  
  11.     }  
  12.   
  13.     @Override  
  14.     public void run() {  
  15.         try {  
  16.             CloseableHttpResponse response = httpClient.execute(  
  17.                     httpget, context);  
  18.             try {  
  19.                 HttpEntity entity = response.getEntity();  
  20.             } finally {  
  21.                 response.close();  
  22.             }  
  23.         } catch (ClientProtocolException ex) {  
  24.             // Handle protocol errors  
  25.         } catch (IOException ex) {  
  26.             // Handle I/O errors  
  27.         }  
  28.     }  
  29.   
  30. }  

 

2.5. 鏈接回收策略

經典阻塞I/O模型的一個主要缺點就是隻有當組側I/O時，socket才能對I/O事件作出反應。當鏈接被管理器收回後，這個鏈接仍然存活，可是卻沒法監控socket的狀態，也沒法對I/O事件作出反饋。若是鏈接被服務器端關閉了，客戶端監測不到鏈接的狀態變化（也就沒法根據鏈接狀態的變化，關閉本地的socket）。

HttpClient爲了緩解這一問題形成的影響，會在使用某個鏈接前，監測這個鏈接是否已通過時，若是服務器端關閉了鏈接，那麼鏈接就會失效。這種過期檢查並非100%有效，而且會給每一個請求增長10到30毫秒額外開銷。惟一一個可行的，且does not involve a one thread per socket model for idle connections的解決辦法，是創建一個監控線程，來專門回收因爲長時間不活動而被斷定爲失效的鏈接。這個監控線程能夠週期性的調用ClientConnectionManager類的closeExpiredConnections()方法來關閉過時的鏈接，回收鏈接池中被關閉的鏈接。它也能夠選擇性的調用ClientConnectionManager類的closeIdleConnections()方法來關閉一段時間內不活動的鏈接。

  1. public static class IdleConnectionMonitorThread extends Thread {  
  2.       
  3.     private final HttpClientConnectionManager connMgr;  
  4.     private volatile boolean shutdown;  
  5.       
  6.     public IdleConnectionMonitorThread(HttpClientConnectionManager connMgr) {  
  7.         super();  
  8.         this.connMgr = connMgr;  
  9.     }  
  10.   
  11.     @Override  
  12.     public void run() {  
  13.         try {  
  14.             while (!shutdown) {  
  15.                 synchronized (this) {  
  16.                     wait(5000);  
  17.                     // Close expired connections  
  18.                     connMgr.closeExpiredConnections();  
  19.                     // Optionally, close connections  
  20.                     // that have been idle longer than 30 sec  
  21.                     connMgr.closeIdleConnections(30, TimeUnit.SECONDS);  
  22.                 }  
  23.             }  
  24.         } catch (InterruptedException ex) {  
  25.             // terminate  
  26.         }  
  27.     }  
  28.       
  29.     public void shutdown() {  
  30.         shutdown = true;  
  31.         synchronized (this) {  
  32.             notifyAll();  
  33.         }  
  34.     }  
  35.       
  36. }  

 

2.6. 鏈接存活策略

Http規範沒有規定一個持久鏈接應該保持存活多久。有些Http服務器使用非標準的Keep-Alive頭消息和客戶端進行交互，服務器端會保持數秒時間內保持鏈接。HttpClient也會利用這個頭消息。若是服務器返回的響應中沒有包含Keep-Alive頭消息，HttpClient會認爲這個鏈接能夠永遠保持。然而，不少服務器都會在不通知客戶端的狀況下，關閉必定時間內不活動的鏈接，來節省服務器資源。在某些狀況下默認的策略顯得太樂觀，咱們可能須要自定義鏈接存活策略。

  1. ConnectionKeepAliveStrategy myStrategy = new ConnectionKeepAliveStrategy() {  
  2.   
  3.     public long getKeepAliveDuration(HttpResponse response, HttpContext context) {  
  4.         // Honor 'keep-alive' header  
  5.         HeaderElementIterator it = new BasicHeaderElementIterator(  
  6.                 response.headerIterator(HTTP.CONN_KEEP_ALIVE));  
  7.         while (it.hasNext()) {  
  8.             HeaderElement he = it.nextElement();  
  9.             String param = he.getName();  
  10.             String value = he.getValue();  
  11.             if (value != null && param.equalsIgnoreCase("timeout")) {  
  12.                 try {  
  13.                     return Long.parseLong(value) * 1000;  
  14.                 } catch(NumberFormatException ignore) {  
  15.                 }  
  16.             }  
  17.         }  
  18.         HttpHost target = (HttpHost) context.getAttribute(  
  19.                 HttpClientContext.HTTP_TARGET_HOST);  
  20.         if ("www.naughty-server.com".equalsIgnoreCase(target.getHostName())) {  
  21.             // Keep alive for 5 seconds only  
  22.             return 5 * 1000;  
  23.         } else {  
  24.             // otherwise keep alive for 30 seconds  
  25.             return 30 * 1000;  
  26.         }  
  27.     }  
  28.   
  29. };  
  30. CloseableHttpClient client = HttpClients.custom()  
  31.         .setKeepAliveStrategy(myStrategy)  
  32.         .build();  

 

2.7.socket鏈接工廠

Http鏈接使用java.net.Socket類來傳輸數據。這依賴於ConnectionSocketFactory接口來建立、初始化和鏈接socket。這樣也就容許HttpClient的用戶在代碼運行時，指定socket初始化的代碼。PlainConnectionSocketFactory是默認的建立、初始化明文socket（不加密）的工廠類。

建立socket和使用socket鏈接到目標主機這兩個過程是分離的，因此咱們能夠在鏈接發生阻塞時，關閉socket鏈接。

  1. HttpClientContext clientContext = HttpClientContext.create();  
  2. PlainConnectionSocketFactory sf = PlainConnectionSocketFactory.getSocketFactory();  
  3. Socket socket = sf.createSocket(clientContext);  
  4. int timeout = 1000; //ms  
  5. HttpHost target = new HttpHost("localhost");  
  6. InetSocketAddress remoteAddress = new InetSocketAddress(  
  7.         InetAddress.getByAddress(new byte[] {127,0,0,1}), 80);  
  8. sf.connectSocket(timeout, socket, target, remoteAddress, null, clientContext);  

 

2.7.1. 安全SOCKET分層

LayeredConnectionSocketFactory是ConnectionSocketFactory的拓展接口。分層socket工廠類能夠在明文socket的基礎上建立socket鏈接。分層socket主要用於在代理服務器之間建立安全socket。HttpClient使用SSLSocketFactory這個類實現安全socket，SSLSocketFactory實現了SSL/TLS分層。請知曉，HttpClient沒有自定義任何加密算法。它徹底依賴於Java加密標準（JCE）和安全套接字（JSEE）拓展。

2.7.2. 集成鏈接管理器

自定義的socket工廠類能夠和指定的協議（Http、Https）聯繫起來，用來建立自定義的鏈接管理器。

  1. ConnectionSocketFactory plainsf = <...>  
  2. LayeredConnectionSocketFactory sslsf = <...>  
  3. Registry<ConnectionSocketFactory> r = RegistryBuilder.<ConnectionSocketFactory>create()  
  4.         .register("http", plainsf)  
  5.         .register("https", sslsf)  
  6.         .build();  
  7.   
  8. HttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(r);  
  9. HttpClients.custom()  
  10.         .setConnectionManager(cm)  
  11.         .build();  

 

2.7.3. SSL/TLS定製

HttpClient使用SSLSocketFactory來建立ssl鏈接。SSLSocketFactory容許用戶高度定製。它能夠接受javax.net.ssl.SSLContext這個類的實例做爲參數，來建立自定義的ssl鏈接。

  1. HttpClientContext clientContext = HttpClientContext.create();  
  2. KeyStore myTrustStore = <...>  
  3. SSLContext sslContext = SSLContexts.custom()  
  4.         .useTLS()  
  5.         .loadTrustMaterial(myTrustStore)  
  6.         .build();  
  7. SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(sslContext);  

 

2.7.4. 域名驗證

除了信任驗證和在ssl/tls協議層上進行客戶端認證，HttpClient一旦創建起鏈接，就能夠選擇性驗證目標域名和存儲在X.509證書中的域名是否一致。這種驗證能夠爲服務器信任提供額外的保障。X509HostnameVerifier接口表明主機名驗證的策略。在HttpClient中，X509HostnameVerifier有三個實現類。重要提示：主機名有效性驗證不該該和ssl信任驗證混爲一談。

  • StrictHostnameVerifier: 嚴格的主機名驗證方法和java 1.4,1.5,1.6驗證方法相同。和IE6的方式也大體相同。這種驗證方式符合RFC 2818通配符。The hostname must match either the first CN, or any of the subject-alts. A wildcard can occur in the CN, and in any of the subject-alts.
  • BrowserCompatHostnameVerifier: 這種驗證主機名的方法，和Curl及firefox一致。The hostname must match either the first CN, or any of the subject-alts. A wildcard can occur in the CN, and in any of the subject-alts.StrictHostnameVerifier和BrowserCompatHostnameVerifier方式惟一不一樣的地方就是，帶有通配符的域名（好比*.yeetrack.com),BrowserCompatHostnameVerifier方式在匹配時會匹配全部的的子域名，包括 a.b.yeetrack.com .
  • AllowAllHostnameVerifier: 這種方式不對主機名進行驗證，驗證功能被關閉，是個空操做，因此它不會拋出javax.net.ssl.SSLException異常。HttpClient默認使用BrowserCompatHostnameVerifier的驗證方式。若是須要，咱們能夠手動執行驗證方式。
    1. SSLContext sslContext = SSLContexts.createSystemDefault();  
    2. SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(  
    3.         sslContext,  
    4.         SSLConnectionSocketFactory.STRICT_HOSTNAME_VERIFIER);  

2.8. HttpClient代理服務器配置

儘管，HttpClient支持複雜的路由方案和代理鏈，它一樣也支持直接鏈接或者只經過一跳的鏈接。

使用代理服務器最簡單的方式就是，指定一個默認的proxy參數。

  1. HttpHost proxy = new HttpHost("someproxy", 8080);  
  2. DefaultProxyRoutePlanner routePlanner = new DefaultProxyRoutePlanner(proxy);  
  3. CloseableHttpClient httpclient = HttpClients.custom()  
  4.         .setRoutePlanner(routePlanner)  
  5.         .build();  

 

咱們也可讓HttpClient去使用jre的代理服務器。

  1. SystemDefaultRoutePlanner routePlanner = new SystemDefaultRoutePlanner(  
  2.         ProxySelector.getDefault());  
  3. CloseableHttpClient httpclient = HttpClients.custom()  
  4.         .setRoutePlanner(routePlanner)  
  5.         .build();  

 

又或者，咱們也能夠手動配置RoutePlanner，這樣就能夠徹底控制Http路由的過程。

  1. HttpRoutePlanner routePlanner = new HttpRoutePlanner() {  
  2.   
  3.     public HttpRoute determineRoute(  
  4.             HttpHost target,  
  5.             HttpRequest request,  
  6.             HttpContext context) throws HttpException {  
  7.         return new HttpRoute(target, null,  new HttpHost("someproxy", 8080),  
  8.                 "https".equalsIgnoreCase(target.getSchemeName()));  
  9.     }  
  10.   
  11. };  
  12. CloseableHttpClient httpclient = HttpClients.custom()  
  13.         .setRoutePlanner(routePlanner)  
  14.         .build();  
  15.     }  
  16. }  

 

第三章 Http狀態管理

 

最初，Http被設計成一個無狀態的，面向請求/響應的協議，因此它不能在邏輯相關的http請求/響應中保持狀態會話。因爲愈來愈多的系統使用http協議，其中包括http歷來沒有想支持的系統，好比電子商務系統。所以，http支持狀態管理就很必要了。

當時的web客戶端和服務器軟件領先者，網景(netscape)公司，最早在他們的產品中支持http狀態管理，而且制定了一些專有規範。後來，網景經過發規範草案，規範了這一機制。這些努力促成 RFC standard track制定了標準的規範。可是，如今多數的應用的狀態管理機制都在使用網景公司的規範，而網景的規範和官方規定是不兼容的。所以全部的瀏覽器開發這都被迫兼容這兩種協議，從而致使協議的不統一。

3.1. Http cookies

所謂的Http cookie就是一個token或者很短的報文信息，http代理和服務器能夠經過cookie來維持會話狀態。網景的工程師把它們稱做「magic cookie」。

HttpClient使用Cookie接口來表明cookie。簡單說來，cookie就是一個鍵值對。通常，cookie也會包含版本號、域名、路徑和cookie有效期。

SetCookie接口能夠表明服務器發給http代理的一個set-cookie響應頭，在瀏覽器中，這個set-cookie響應頭能夠寫入cookie，以便保持會話狀態。SetCookie2接口對SetCookie接口進行了拓展，添加了Set-Cookie2方法。

ClientCookie接口繼承了Cookie接口，並進行了功能拓展，好比它能夠取出服務器發送過來的原始cookie的值。生成頭消息是很重要的，由於只有當cookie被指定爲Set-Cookie或者Set-Cookie2時，它才須要包括一些特定的屬性。

3.1.1 COOKIES版本

兼容網景的規範，可是不兼容官方規範的cookie，是版本0. 兼容官方規範的版本，將會是版本1。版本1中的Cookie可能和版本0工做機制有差別。

下面的代碼，建立了網景版本的Cookie：

  1. BasicClientCookie netscapeCookie = new BasicClientCookie("name", "value");  
  2. netscapeCookie.setVersion(0);  
  3. netscapeCookie.setDomain(".mycompany.com");  
  4. netscapeCookie.setPath("/");  

 

下面的代碼，建立標準版本的Cookie。注意，標準版本的Cookie必須保留服務器發送過來的Cookie全部屬性。

  1. BasicClientCookie stdCookie = new BasicClientCookie("name", "value");  
  2. stdCookie.setVersion(1);  
  3. stdCookie.setDomain(".mycompany.com");  
  4. stdCookie.setPath("/");  
  5. stdCookie.setSecure(true);  
  6. // Set attributes EXACTLY as sent by the server   
  7. stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");  
  8. stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");  

 

下面的代碼，建立了Set-Cookie2兼容cookie。

  1. BasicClientCookie2 stdCookie = new BasicClientCookie2("name", "value");  
  2. stdCookie.setVersion(1);  
  3. stdCookie.setDomain(".mycompany.com");  
  4. stdCookie.setPorts(new int[] {80,8080});  
  5. stdCookie.setPath("/");  
  6. stdCookie.setSecure(true);  
  7. // Set attributes EXACTLY as sent by the server   
  8. stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");  
  9. stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");  
  10. stdCookie.setAttribute(ClientCookie.PORT_ATTR, "80,8080");  

 

3.2. Cookie規範

CookieSpec接口表明了Cookie管理規範。Cookie管理規範規定了：

  • 解析Set-Cookie和Set-Cookie2(可選）頭消息的規則
  • 驗證Cookie的規則
  • 將指定的主機名、端口和路徑格式化成Cookie頭消息

HttpClient有下面幾種CookieSpec規範：

  • Netscape draft: 這種符合網景公司指定的規範。可是儘可能不要使用，除非必定要保證兼容很舊的代碼。
  • Standard: RFC 2965 HTTP狀態管理規範
  • Browser compatibility: 這種方式，儘可能模仿經常使用的瀏覽器，如IE和firefox
  • Best match: ‘Meta’ cookie specification that picks up a cookie policy based on the format of cookies sent with the HTTP response.它基本上將上面的幾種規範積聚到一個類中。
    ++ Ignore cookies: 忽略全部Cookie
    強烈推薦使用Best Match匹配規則，讓HttpClient根據運行時環境本身選擇合適的規範。

3.3. 選擇Cookie策略

咱們能夠在建立Http client的時候指定Cookie測試，若是須要，也能夠在執行http請求的時候，進行覆蓋指定。

  1. RequestConfig globalConfig = RequestConfig.custom()  
  2.         .setCookieSpec(CookieSpecs.BEST_MATCH)  
  3.         .build();  
  4. CloseableHttpClient httpclient = HttpClients.custom()  
  5.         .setDefaultRequestConfig(globalConfig)  
  6.         .build();  
  7. RequestConfig localConfig = RequestConfig.copy(globalConfig)  
  8.         .setCookieSpec(CookieSpecs.BROWSER_COMPATIBILITY)  
  9.         .build();  
  10. HttpGet httpGet = new HttpGet("/");  
  11. httpGet.setConfig(localConfig);  

 

3.4. 自定義Cookie策略

若是咱們要自定義Cookie測試，就要本身實現CookieSpec接口，而後建立一個CookieSpecProvider接口來新建、初始化自定義CookieSpec接口，最後把CookieSpecProvider註冊到HttpClient中。一旦咱們註冊了自定義策略，就能夠像其餘標準策略同樣使用了。

  1. CookieSpecProvider easySpecProvider = new CookieSpecProvider() {  
  2.   
  3.     public CookieSpec create(HttpContext context) {  
  4.   
  5.         return new BrowserCompatSpec() {  
  6.             @Override  
  7.             public void validate(Cookie cookie, CookieOrigin origin)  
  8.                     throws MalformedCookieException {  
  9.                 // Oh, I am easy  
  10.             }  
  11.         };  
  12.     }  
  13.   
  14. };  
  15. Registry<CookieSpecProvider> r = RegistryBuilder.<CookieSpecProvider>create()  
  16.         .register(CookieSpecs.BEST_MATCH,  
  17.             new BestMatchSpecFactory())  
  18.         .register(CookieSpecs.BROWSER_COMPATIBILITY,  
  19.             new BrowserCompatSpecFactory())  
  20.         .register("easy", easySpecProvider)  
  21.         .build();  
  22.   
  23. RequestConfig requestConfig = RequestConfig.custom()  
  24.         .setCookieSpec("easy")  
  25.         .build();  
  26.   
  27. CloseableHttpClient httpclient = HttpClients.custom()  
  28.         .setDefaultCookieSpecRegistry(r)  
  29.         .setDefaultRequestConfig(requestConfig)  
  30.         .build();  

 

3.5. Cookie持久化

HttpClient可使用任何存儲方式的cookie store，只要這個cookie store實現了CookieStore接口。默認的CookieStore經過java.util.ArrayList簡單實現了BasicCookieStore。存在在BasicCookieStore中的Cookie，當載體對象被當作垃圾回收掉後，就會丟失。若是必要，用戶能夠本身實現更爲複雜的方式。

  1. // Create a local instance of cookie store  
  2. CookieStore cookieStore = new BasicCookieStore();  
  3. // Populate cookies if needed  
  4. BasicClientCookie cookie = new BasicClientCookie("name", "value");  
  5. cookie.setVersion(0);  
  6. cookie.setDomain(".mycompany.com");  
  7. cookie.setPath("/");  
  8. cookieStore.addCookie(cookie);  
  9. // Set the store  
  10. CloseableHttpClient httpclient = HttpClients.custom()  
  11.         .setDefaultCookieStore(cookieStore)  
  12.         .build();  

 

3.6.HTTP狀態管理和執行上下文

在Http請求執行過程當中，HttpClient會自動向執行上下文中添加下面的狀態管理對象：

  • Lookup對象 表明實際的cookie規範registry。在當前上下文中的這個值優先於默認值。
  • CookieSpec對象 表明實際的Cookie規範。
  • CookieOrigin對象 表明實際的origin server的詳細信息。
  • CookieStore對象 表示Cookie store。這個屬性集中的值會取代默認值。

本地的HttpContext對象能夠用來在Http請求執行前，自定義Http狀態管理上下文;或者測試http請求執行完畢後上下文的狀態。咱們也能夠在不一樣的線程中使用不一樣的執行上下文。咱們在http請求層指定的cookie規範集和cookie store會覆蓋在http Client層級的默認值。

  1. CloseableHttpClient httpclient = <...>  
  2.   
  3. Lookup<CookieSpecProvider> cookieSpecReg = <...>  
  4. CookieStore cookieStore = <...>  
  5.   
  6. HttpClientContext context = HttpClientContext.create();  
  7. context.setCookieSpecRegistry(cookieSpecReg);  
  8. context.setCookieStore(cookieStore);  
  9. HttpGet httpget = new HttpGet("http://somehost/");  
  10. CloseableHttpResponse response1 = httpclient.execute(httpget, context);  
  11. <...>  
  12. // Cookie origin details  
  13. CookieOrigin cookieOrigin = context.getCookieOrigin();  
  14. // Cookie spec used  
  15. CookieSpec cookieSpec = context.getCookieSpec();  

 

第四章 HTTP認證

 

 

 

HttpClient既支持HTTP標準規範定義的認證模式，又支持一些普遍使用的非標準認證模式，好比NTLM和SPNEGO。

4.1.用戶憑證

任何用戶認證的過程，都須要一系列的憑證來肯定用戶的身份。最簡單的用戶憑證能夠是用戶名和密碼這種形式。UsernamePasswordCredentials這個類能夠用來表示這種狀況，這種憑據包含明文的用戶名和密碼。

這個類對於HTTP標準規範中定義的認證模式來講已經足夠了。

  1. UsernamePasswordCredentials creds = new UsernamePasswordCredentials("user", "pwd");  
  2. System.out.println(creds.getUserPrincipal().getName());  
  3. System.out.println(creds.getPassword());  

 

上述代碼會在控制檯輸出：

  1. user  
  2. pwd  

 

NTCredentials是微軟的windows系統使用的一種憑據，包含username、password，還包括一系列其餘的屬性，好比用戶所在的域名。在Microsoft Windows的網絡環境中，同一個用戶能夠屬於不一樣的域，因此他也就有不一樣的憑據。

  1. NTCredentials creds = new NTCredentials("user", "pwd", "workstation", "domain");  
  2. System.out.println(creds.getUserPrincipal().getName());  
  3. System.out.println(creds.getPassword());  

 

上述代碼輸出：

  1. DOMAIN/user  
  2. pwd  

 

4.2. 認證方案

AutoScheme接口表示一個抽象的面向挑戰/響應的認證方案。一個認證方案要支持下面的功能：

  • 客戶端請求服務器受保護的資源，服務器會發送過來一個chanllenge(挑戰），認證方案（Authentication scheme）須要解析、處理這個挑戰
  • 爲processed challenge提供一些屬性值：認證方案的類型，和此方案須要的一些參數，這種方案適用的範圍
  • 使用給定的受權信息生成受權字符串;生成http請求，用來響應服務器發送來過的受權challenge

請注意：一個認證方案多是有狀態的，由於它可能涉及到一系列的挑戰/響應。

HttpClient實現了下面幾種AutoScheme:

  • Basic: Basic認證方案是在RFC2617號文檔中定義的。這種受權方案用明文來傳輸憑證信息，因此它是不安全的。雖然Basic認證方案自己是不安全的，可是它一旦和TLS/SSL加密技術結合起來使用，就徹底足夠了。
  • Digest: Digest（摘要）認證方案是在RFC2617號文檔中定義的。Digest認證方案比Basic方案安全多了，對於那些受不了Basic+TLS/SSL傳輸開銷的系統，digest方案是個不錯的選擇。
  • NTLM: NTLM認證方案是個專有的認證方案，由微軟開發，而且針對windows平臺作了優化。NTLM被認爲比Digest更安全。
  • SPNEGO: SPNEGO(Simple and Protected GSSAPI Negotiation Mechanism)是GSSAPI的一個「僞機制」，它用來協商真正的認證機制。SPNEGO最明顯的用途是在微軟的HTTP協商認證機制拓展上。可協商的子機制包括NTLM、Kerberos。目前，HttpCLient只支持Kerberos機制。（原文：The negotiable sub-mechanisms include NTLM and Kerberos supported by Active Directory. At present HttpClient only supports the Kerberos sub-mechanism.）

4.3. 憑證 provider

憑證providers旨在維護一套用戶的憑證，當須要某種特定的憑證時，providers就應該能產生這種憑證。認證的具體內容包括主機名、端口號、realm name和認證方案名。當使用憑據provider的時候，咱們能夠很模糊的指定主機名、端口號、realm和認證方案，不用寫的很精確。由於，憑據provider會根據咱們指定的內容，篩選出一個最匹配的方案。

只要咱們自定義的憑據provider實現了CredentialsProvider這個接口，就能夠在HttpClient中使用。默認的憑據provider叫作BasicCredentialsProvider，它使用java.util.HashMap對CredentialsProvider進行了簡單的實現。

  1. CredentialsProvider credsProvider = new BasicCredentialsProvider();  
  2. credsProvider.setCredentials(  
  3.     new AuthScope("somehost", AuthScope.ANY_PORT),   
  4.     new UsernamePasswordCredentials("u1", "p1"));  
  5. credsProvider.setCredentials(  
  6.     new AuthScope("somehost", 8080),   
  7.     new UsernamePasswordCredentials("u2", "p2"));  
  8. credsProvider.setCredentials(  
  9.     new AuthScope("otherhost", 8080, AuthScope.ANY_REALM, "ntlm"),   
  10.     new UsernamePasswordCredentials("u3", "p3"));  
  11.   
  12. System.out.println(credsProvider.getCredentials(  
  13.     new AuthScope("somehost", 80, "realm", "basic")));  
  14. System.out.println(credsProvider.getCredentials(  
  15.     new AuthScope("somehost", 8080, "realm", "basic")));  
  16. System.out.println(credsProvider.getCredentials(  
  17.     new AuthScope("otherhost", 8080, "realm", "basic")));  
  18. System.out.println(credsProvider.getCredentials(  
  19.     new AuthScope("otherhost", 8080, null, "ntlm")));  

 

上面代碼輸出：

  1. [principal: u1]  
  2. [principal: u2]  
  3. null  
  4. [principal: u3]  

 

4.4.HTTP受權和執行上下文

HttpClient依賴AuthState類去跟蹤認證過程當中的狀態的詳細信息。在Http請求過程當中，HttpClient建立兩個AuthState實例：一個用於目標服務器認證，一個用於代理服務器認證。若是服務器或者代理服務器須要用戶的受權信息，AuthScope、AutoScheme和認證信息就會被填充到兩個AuthScope實例中。經過對AutoState的檢測，咱們能夠肯定請求的受權類型，肯定是否有匹配的AuthScheme，肯定憑據provider根據指定的受權類型是否成功生成了用戶的受權信息。

在Http請求執行過程當中，HttpClient會向執行上下文中添加下面的受權對象：

  • Lookup對象，表示使用的認證方案。這個對象的值能夠在本地上下文中進行設置，來覆蓋默認值。
  • CredentialsProvider對象，表示認證方案provider，這個對象的值能夠在本地上下文中進行設置，來覆蓋默認值。
  • AuthState對象，表示目標服務器的認證狀態，這個對象的值能夠在本地上下文中進行設置，來覆蓋默認值。
  • AuthState對象，表示代理服務器的認證狀態，這個對象的值能夠在本地上下文中進行設置，來覆蓋默認值。
  • AuthCache對象，表示認證數據的緩存，這個對象的值能夠在本地上下文中進行設置，來覆蓋默認值。

咱們能夠在請求執行前，自定義本地HttpContext對象來設置須要的http認證上下文;也能夠在請求執行後，再檢測HttpContext的狀態，來查看受權是否成功。

  1. CloseableHttpClient httpclient = <...>  
  2.   
  3. CredentialsProvider credsProvider = <...>  
  4. Lookup<AuthSchemeProvider> authRegistry = <...>  
  5. AuthCache authCache = <...>  
  6.   
  7. HttpClientContext context = HttpClientContext.create();  
  8. context.setCredentialsProvider(credsProvider);  
  9. context.setAuthSchemeRegistry(authRegistry);  
  10. context.setAuthCache(authCache);  
  11. HttpGet httpget = new HttpGet("http://somehost/");  
  12. CloseableHttpResponse response1 = httpclient.execute(httpget, context);  
  13. <...>  
  14.   
  15. AuthState proxyAuthState = context.getProxyAuthState();  
  16. System.out.println("Proxy auth state: " + proxyAuthState.getState());  
  17. System.out.println("Proxy auth scheme: " + proxyAuthState.getAuthScheme());  
  18. System.out.println("Proxy auth credentials: " + proxyAuthState.getCredentials());  
  19. AuthState targetAuthState = context.getTargetAuthState();  
  20. System.out.println("Target auth state: " + targetAuthState.getState());  
  21. System.out.println("Target auth scheme: " + targetAuthState.getAuthScheme());  
  22. System.out.println("Target auth credentials: " + targetAuthState.getCredentials());  

 

4.5. 緩存認證數據

從版本4.1開始，HttpClient就會自動緩存驗證經過的認證信息。可是爲了使用這個緩存的認證信息，咱們必須在同一個上下文中執行邏輯相關的請求。一旦超出該上下文的做用範圍，緩存的認證信息就會失效。

4.6. 搶先認證

HttpClient默認不支持搶先認證，由於一旦搶先認證被誤用或者錯用，會致使一系列的安全問題，好比會把用戶的認證信息以明文的方式發送給未受權的第三方服務器。所以，須要用戶本身根據本身應用的具體環境來評估搶先認證帶來的好處和帶來的風險。

即便如此，HttpClient仍是容許咱們經過配置來啓用搶先認證，方法是提早填充認證信息緩存到上下文中，這樣，以這個上下文執行的方法，就會使用搶先認證。

  1. CloseableHttpClient httpclient = <...>  
  2.   
  3. HttpHost targetHost = new HttpHost("localhost", 80, "http");  
  4. CredentialsProvider credsProvider = new BasicCredentialsProvider();  
  5. credsProvider.setCredentials(  
  6.         new AuthScope(targetHost.getHostName(), targetHost.getPort()),  
  7.         new UsernamePasswordCredentials("username", "password"));  
  8.   
  9. // Create AuthCache instance  
  10. AuthCache authCache = new BasicAuthCache();  
  11. // Generate BASIC scheme object and add it to the local auth cache  
  12. BasicScheme basicAuth = new BasicScheme();  
  13. authCache.put(targetHost, basicAuth);  
  14.   
  15. // Add AuthCache to the execution context  
  16. HttpClientContext context = HttpClientContext.create();  
  17. context.setCredentialsProvider(credsProvider);  
  18. context.setAuthCache(authCache);  
  19.   
  20. HttpGet httpget = new HttpGet("/");  
  21. for (int i = 0; i < 3; i++) {  
  22.     CloseableHttpResponse response = httpclient.execute(  
  23.             targetHost, httpget, context);  
  24.     try {  
  25.         HttpEntity entity = response.getEntity();  
  26.   
  27.     } finally {  
  28.         response.close();  
  29.     }  
  30. }  

 

4.7. NTLM認證

從版本4.1開始，HttpClient就全面支持NTLMv一、NTLMv2和NTLM2認證。當人咱們能夠仍舊使用外部的NTLM引擎（好比Samba開發的JCIFS庫）做爲與Windows互操做性程序的一部分。

4.7.1. NTLM鏈接持久性

相比Basic和Digest認證，NTLM認證要明顯須要更多的計算開銷，性能影響也比較大。這也多是微軟把NTLM協議設計成有狀態鏈接的主要緣由之一。也就是說，NTLM鏈接一旦創建，用戶的身份就會在其整個生命週期和它相關聯。NTLM鏈接的狀態性使得鏈接持久性更加複雜，The stateful nature of NTLM connections makes connection persistence more complex, as for the obvious reason persistent NTLM connections may not be re-used by users with a different user identity. HttpClient中標準的鏈接管理器就能夠管理有狀態的鏈接。可是，同一會話中邏輯相關的請求，必須使用相同的執行上下文，這樣才能使用用戶的身份信息。不然，HttpClient就會結束舊的鏈接，爲了獲取被NTLM協議保護的資源，而爲每一個HTTP請求，建立一個新的Http鏈接。更新關於Http狀態鏈接的信息，點擊此處。

因爲NTLM鏈接是有狀態的，通常推薦使用比較輕量級的方法來處罰NTLM認證（如GET、Head方法），而後使用這個已經創建的鏈接在執行相對重量級的方法，尤爲是須要附件請求實體的請求（如POST、PUT請求）。

  1. CloseableHttpClient httpclient = <...>  
  2.   
  3. CredentialsProvider credsProvider = new BasicCredentialsProvider();  
  4. credsProvider.setCredentials(AuthScope.ANY,  
  5.         new NTCredentials("user", "pwd", "myworkstation", "microsoft.com"));  
  6.   
  7. HttpHost target = new HttpHost("www.microsoft.com", 80, "http");  
  8.   
  9. // Make sure the same context is used to execute logically related requests  
  10. HttpClientContext context = HttpClientContext.create();  
  11. context.setCredentialsProvider(credsProvider);  
  12.   
  13. // Execute a cheap method first. This will trigger NTLM authentication  
  14. HttpGet httpget = new HttpGet("/ntlm-protected/info");  
  15. CloseableHttpResponse response1 = httpclient.execute(target, httpget, context);  
  16. try {  
  17.     HttpEntity entity1 = response1.getEntity();  
  18. } finally {  
  19.     response1.close();  
  20. }  
  21.   
  22. // Execute an expensive method next reusing the same context (and connection)  
  23. HttpPost httppost = new HttpPost("/ntlm-protected/form");  
  24. httppost.setEntity(new StringEntity("lots and lots of data"));  
  25. CloseableHttpResponse response2 = httpclient.execute(target, httppost, context);  
  26. try {  
  27.     HttpEntity entity2 = response2.getEntity();  
  28. } finally {  
  29.     response2.close();  
  30. }  

 

4.8. SPNEGO/Kerberos認證

SPNEGO(Simple and Protected GSSAPI Megotiation Mechanism），當雙方均不知道對方能使用/提供什麼協議的狀況下，可使用SP認證協議。這種協議在Kerberos認證方案中常用。It can wrap other mechanisms, however the current version in HttpClient is designed solely with Kerberos in mind.

4.8.1. 在HTTPCIENT中使用SPNEGO

SPNEGO認證方案兼容Sun java 1.5及以上版本。可是強烈推薦jdk1.6以上。Sun的JRE提供的類就已經幾乎徹底能夠處理Kerberos和SPNEGO token。這就意味着，須要設置不少的GSS類。SpnegoScheme是個很簡單的類，能夠用它來handle marshalling the tokens and 讀寫正確的頭消息。

最好的開始方法就是從示例程序中找到KerberosHttpClient.java這個文件，嘗試讓它運行起來。運行過程有可能會出現不少問題，可是若是人品比較高可能會順利一點。這個文件會提供一些輸出，來幫咱們調試。

在Windows系統中，應該默認使用用戶的登錄憑據;固然咱們也可使用kinit來覆蓋這個憑據，好比$JAVA_HOME\bin\kinit testuser@AD.EXAMPLE.NET，這在咱們測試和調試的時候就顯得頗有用了。若是想用回Windows默認的登錄憑據，刪除kinit建立的緩存文件便可。

確保在krb5.conf文件中列出domain_realms。這能解決不少沒必要要的問題。

4.8.2. 使用GSS/JAVA KERBEROS

下面的這份文檔是針對Windows系統的，可是不少信息一樣適合Unix。

org.ietf.jgss這個類有不少的配置參數，這些參數大部分都在krb5.conf/krb5.ini文件中配置。更多的信息，參考此處。

login.conf文件

下面是一個基本的login.conf文件，使用於Windows平臺的IIS和JBoss Negotiation模塊。

系統配置文件java.security.auth.login.config能夠指定login.conf文件的路徑。
login.conf的內容可能會是下面的樣子：

  1. com.sun.security.jgss.login {  
  2.   com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;  
  3. };  
  4.   
  5. com.sun.security.jgss.initiate {  
  6.   com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;  
  7. };  
  8.   
  9. com.sun.security.jgss.accept {  
  10.   com.sun.security.auth.module.Krb5LoginModule required client=TRUE useTicketCache=true;  
  11. };  

 

4.8.4. KRB5.CONF / KRB5.INI 文件

若是沒有手動指定，系統會使用默認配置。若是要手動指定，能夠在java.security.krb5.conf中設置系統變量，指定krb5.conf的路徑。krb5.conf的內容多是下面的樣子：

  1. [libdefaults]  
  2.     default_realm = AD.EXAMPLE.NET  
  3.     udp_preference_limit = 1  
  4. [realms]  
  5.     AD.EXAMPLE.NET = {  
  6.         kdc = KDC.AD.EXAMPLE.NET  
  7.     }  
  8. [domain_realms]  
  9. .ad.example.net=AD.EXAMPLE.NET  
  10. ad.example.net=AD.EXAMPLE.NET  

 

4.8.5. WINDOWS詳細的配置

爲了容許Windows使用當前用戶的tickets，javax.security.auth.useSubjectCredsOnly這個系統變量應該設置成false，而且須要在Windows註冊表中添加allowtgtsessionkey這個項，並且要allow session keys to be sent in the Kerberos Ticket-Granting Ticket.

Windows Server 2003和Windows 2000 SP4,配置以下：

  1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters  
  2. Value Name: allowtgtsessionkey  
  3. Value Type: REG_DWORD  
  4. Value: 0x01  

 

Windows XP SP2 配置以下：

  1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\  
  2. Value Name: allowtgtsessionkey  
  3. Value Type: REG_DWORD  
  4. Value: 0x01  

 

第五章 快速API

 

5.1. Easy to use facade API

HttpClient從4.2開始支持快速api。快速api僅僅實現了HttpClient的基本功能，它只要用於一些不須要靈活性的簡單場景。例如，快速api不須要用戶處理鏈接管理和資源釋放。

下面是幾個使用快速api的例子：

  1. // Execute a GET with timeout settings and return response content as String.  
  2. Request.Get("http://somehost/")  
  3.         .connectTimeout(1000)  
  4.         .socketTimeout(1000)  
  5.         .execute().returnContent().asString();  

 

 

  1. // Execute a POST with the 'expect-continue' handshake, using HTTP/1.1,  
  2. // containing a request body as String and return response content as byte array.  
  3. Request.Post("http://somehost/do-stuff")  
  4.         .useExpectContinue()  
  5.         .version(HttpVersion.HTTP_1_1)  
  6.         .bodyString("Important stuff", ContentType.DEFAULT_TEXT)  
  7.         .execute().returnContent().asBytes();  

 

  1. // Execute a POST with a custom header through the proxy containing a request body  
  2. // as an HTML form and save the result to the file  
  3. Request.Post("http://somehost/some-form")  
  4.         .addHeader("X-Custom-header", "stuff")  
  5.         .viaProxy(new HttpHost("myproxy", 8080))  
  6.         .bodyForm(Form.form().add("username", "vip").add("password", "secret").build())  
  7.         .execute().saveContent(new File("result.dump"));  


若是須要在指定的安全上下文中執行某些請求，咱們也能夠直接使用Exector，這時候用戶的認證信息就會被緩存起來，以便後續的請求使用。

  1. Executor executor = Executor.newInstance()  
  2.         .auth(new HttpHost("somehost"), "username", "password")  
  3.         .auth(new HttpHost("myproxy", 8080), "username", "password")  
  4.         .authPreemptive(new HttpHost("myproxy", 8080));  
  5.   
  6. executor.execute(Request.Get("http://somehost/"))  
  7.         .returnContent().asString();  
  8.   
  9. executor.execute(Request.Post("http://somehost/do-stuff")  
  10.         .useExpectContinue()  
  11.         .bodyString("Important stuff", ContentType.DEFAULT_TEXT))  
  12.         .returnContent().asString();  

 

5.1.1. 響應處理

 

通常狀況下，HttpClient的快速api不用用戶處理鏈接管理和資源釋放。可是，這樣的話，就必須在內存中緩存這些響應消息。爲了不這一狀況，建議使用使用ResponseHandler來處理Http響應。

  1. Document result = Request.Get("http://somehost/content")  
  2.         .execute().handleResponse(new ResponseHandler<Document>() {  
  3.   
  4.     public Document handleResponse(final HttpResponse response) throws IOException {  
  5.         StatusLine statusLine = response.getStatusLine();  
  6.         HttpEntity entity = response.getEntity();  
  7.         if (statusLine.getStatusCode() >= 300) {  
  8.             throw new HttpResponseException(  
  9.                     statusLine.getStatusCode(),  
  10.                     statusLine.getReasonPhrase());  
  11.         }  
  12.         if (entity == null) {  
  13.             throw new ClientProtocolException("Response contains no content");  
  14.         }  
  15.         DocumentBuilderFactory dbfac = DocumentBuilderFactory.newInstance();  
  16.         try {  
  17.             DocumentBuilder docBuilder = dbfac.newDocumentBuilder();  
  18.             ContentType contentType = ContentType.getOrDefault(entity);  
  19.             if (!contentType.equals(ContentType.APPLICATION_XML)) {  
  20.                 throw new ClientProtocolException("Unexpected content type:" +  
  21.                     contentType);  
  22.             }  
  23.             String charset = contentType.getCharset();  
  24.             if (charset == null) {  
  25.                 charset = HTTP.DEFAULT_CONTENT_CHARSET;  
  26.             }  
  27.             return docBuilder.parse(entity.getContent(), charset);  
  28.         } catch (ParserConfigurationException ex) {  
  29.             throw new IllegalStateException(ex);  
  30.         } catch (SAXException ex) {  
  31.             throw new ClientProtocolException("Malformed XML document", ex);  
  32.         }  
  33.     }  
  34.   
  35.     });  

 

第六章 HTTP緩存

6.1. 基本概念

HttpClient的緩存機制提供一個與HTTP/1.1標準兼容的緩存層 – 至關於Java的瀏覽器緩存。HttpClient緩存機制的實現遵循責任鏈（Chain of Responsibility）設計原則，默認的HttpClient是沒有緩存的，有緩存機制的HttpClient能夠用來臨時替代默認的HttpClient，若是開啓了緩存，咱們的請求結果就會從緩存中獲取，而不是從目標服務器中獲取。若是在Get請求頭中設置了If-Modified-Since或者If-None-Match參數，那麼HttpClient會自動向服務器校驗緩存是否過時。

HTTP/1.1版本的緩存是語義透明的，意思是不管怎樣，緩存都不該該修改客戶端與服務器之間傳輸的請求/響應數據包。所以，在existing compliant client-server relationship中使用帶有緩存的HttpClient也應該是安全的。雖然緩存是客戶端的一部分，可是從Http協議的角度來看，緩存機制是爲了兼容透明的緩存代理。

最後，HttpClient緩存也支持RFC 5861規定的Cache-Control拓展（stale-if-error'和stale-while-revalidate`)。

當開啓緩存的HttpClient執行一個Http請求時，會通過下面的步驟：

  • 檢查http請求是否符合HTTP 1.1的基本要求，若是不符合就嘗試修正錯誤。
  • 刷新該請求無效的緩存項。（Flush any cache entries which would be invalidated by this request.）
  • 檢測該請求是否能夠從緩存中獲取。若是不能，直接將請求發送給目標服務器，獲取響應並加入緩存。
  • 若是該請求能夠從緩存中獲取，HttpClient就嘗試讀取緩存中的數據。若是讀取失敗，就會發送請求到目標服務器，若是可能的話，就把響應緩存起來。
  • 若是HttpClient緩存的響應能夠直接返回給請求，HttpClient就會構建一個包含ByteArrayEntity的BasicHttpResponse對象，並將它返回給http請求。不然，HttpClient會向服務器從新校驗緩存。
  • 若是HttpClient緩存的響應，向服務器校驗失敗，就會向服務器從新請求數據，並將其緩存起來（若是合適的話）。
    當開啓緩存的HttpClient收到服務器的響應時，會通過下面的步驟：
  • 檢查收到的響應是否符合協議兼容性
  • 肯定收到的響應是否能夠緩存
  • 若是響應是能夠緩存的，HttpClient就會盡可能從響應消息中讀取數據（大小能夠在配置文件進行配置），而且緩存起來。
  • 若是響應數據太大，緩存或者重構消耗的響應空間不夠，就會直接返回響應，不進行緩存。
    須要注意的是，帶有緩存的HttpClient不是HttpClient的另外一種實現，而是經過向http請求執行管道中插入附加處理組件來實現的。

6.2. RFC-2616 Compliance

HttpClient的緩存機制和RFC-2626文檔規定是無條件兼容的。也就是說，只要指定了MUST，MUST NOT，SHOULD或者SHOULD NOT這些Http緩存規範，HttpClient的緩存層就會按照指定的方式進行緩存。即當咱們使用HttpClient的緩存機制時，HttpClient的緩存模塊不會產生異常動做。

6.3. 使用範例

下面的例子講述瞭如何建立一個基本的開啓緩存的HttpClient。而且配置了最大緩存1000個Object對象，每一個對象最大佔用8192字節數據。代碼中出現的數據，只是爲了作演示，而過不是推薦使用的配置。

  1. CacheConfig cacheConfig = CacheConfig.custom()  
  2.         .setMaxCacheEntries(1000)  
  3.         .setMaxObjectSize(8192)  
  4.         .build();  
  5. RequestConfig requestConfig = RequestConfig.custom()  
  6.         .setConnectTimeout(30000)  
  7.         .setSocketTimeout(30000)  
  8.         .build();  
  9. CloseableHttpClient cachingClient = CachingHttpClients.custom()  
  10.         .setCacheConfig(cacheConfig)  
  11.         .setDefaultRequestConfig(requestConfig)  
  12.         .build();  
  13.   
  14. HttpCacheContext context = HttpCacheContext.create();  
  15. HttpGet httpget = new HttpGet("http://www.mydomain.com/content/");  
  16. CloseableHttpResponse response = cachingClient.execute(httpget, context);  
  17. try {  
  18.     CacheResponseStatus responseStatus = context.getCacheResponseStatus();  
  19.     switch (responseStatus) {  
  20.         case CACHE_HIT:  
  21.             System.out.println("A response was generated from the cache with " +  
  22.                     "no requests sent upstream");  
  23.             break;  
  24.         case CACHE_MODULE_RESPONSE:  
  25.             System.out.println("The response was generated directly by the " +  
  26.                     "caching module");  
  27.             break;  
  28.         case CACHE_MISS:  
  29.             System.out.println("The response came from an upstream server");  
  30.             break;  
  31.         case VALIDATED:  
  32.             System.out.println("The response was generated from the cache " +  
  33.                     "after validating the entry with the origin server");  
  34.             break;  
  35.     }  
  36. } finally {  
  37.     response.close();  
  38. }  

 

6.4. 配置

有緩存的HttpClient繼承了非緩存HttpClient的全部配置項和參數（包括超時時間，鏈接池大小等配置項）。若是須要對緩存進行具體配置，能夠初始化一個CacheConfig對象來自定義下面的參數：

  • Cache size（緩存大小）. 若是後臺存儲支持，咱們能夠指定緩存的最大條數，和每一個緩存中存儲的response的最大size。
  • Public/private cacheing(公用/私有 緩存）. 默認狀況下，緩存模塊會把緩存當作公用的緩存，因此緩存機制不會緩存帶有受權頭消息或者指定Cache-Control:private的響應。可是若是緩存只會被一個邏輯上的用戶使用（和瀏覽器餓緩存相似），咱們可能但願關閉緩存共享機制。
  • Heuristic caching（啓發式緩存）。即便服務器沒有明確設置緩存控制headers信息，每一個RFC2616緩存也會存儲必定數目的緩存。這個特徵在HttpClient中默認是關閉的，若是服務器不設置控制緩存的header信息，可是咱們仍然但願對響應進行緩存，就須要在HttpClient中打開這個功能。激活啓發式緩存，而後使用默認的刷新時間或者自定義刷新時間。更多啓發式緩存的信息，能夠參考Http/1.1 RFC文檔的13.2.2小節，13.2.4小節。
  • Background validation(後臺校驗）。HttpClient的緩存機制支持RFC5861的stale-while-revalidate指令，它容許必定數目的緩存在後臺校驗是否過時。咱們可能須要調整能夠在後臺工做的最大和最小的線程數，以及設置線程在回收前最大的空閒時間。當沒有足夠線程來校驗緩存是否過時時，咱們能夠指定排隊隊列的大小。

6.5.存儲介質

默認，HttpClient緩存機制將緩存條目和緩存的response放在本地程序的jvm內存中。這樣雖然提供高性能，可是當咱們的程序內存有大小限制的時候，這就會變得不太合理。由於緩存的生命中期很短，若是程序重啓，緩存就會失效。當前版本的HttpClient使用EhCache和memchached來存儲緩存，這樣就支持將緩存放到本地磁盤或者其餘存儲介質上。若是內存、本地磁盤、外地磁盤，都不適合你的應用程序，HttpClient也支持自定義存儲介質，只須要實現HttpCacheStorage接口，而後在建立HttpClient時，使用這個接口的配置。這種狀況，緩存會存儲在自定義的介質中，可是you will get to reuse all of the logic surrounding HTTP/1.1 compliance and cache handling. 通常來講，能夠建立出支持任何鍵值對指定存儲（相似Java Map接口）的HttpCacheStorage，用於進行原子更新。

最後，經過一些額外的工做，還能夠創建起多層次的緩存結構;磁盤中的緩存，遠程memcached中的緩存，虛擬內存中的緩存，L1/L2處理器中的緩存等。

第七章  高級主題

 

7.1 自定義客戶端鏈接

 

在特定條件下，也許須要來定製HTTP報文經過線路傳遞，越過了可能使用的HTTP參數來處理非標準不兼容行爲的方式。好比，對於Web爬蟲，它可能須要強制HttpClient接受格式錯誤的響應頭部信息，來搶救報文的內容。

一般插入一個自定義的報文解析器的過程或定製鏈接實現須要幾個步驟：

提供一個自定義LineParser/LineFormatter接口實現。若是須要，實現報文解析/格式化邏輯。

 

 

  1. <span style="font-family:SimSun;">class MyLineParser extends BasicLineParser {  
  2.   
  3.     @Override  
  4.     public Header parseHeader(  
  5.             CharArrayBuffer buffer) throws ParseException {  
  6.         try {  
  7.             return super.parseHeader(buffer);  
  8.         } catch (ParseException ex) {  
  9.             // Suppress ParseException exception  
  10.             return new BasicHeader(buffer.toString(), null);  
  11.         }  
  12.     }  
  13.   
  14. }</span>  


提過一個自定義的 HttpConnectionFactory 實現。替換須要自定義的默認請求/響應解析器，請求/響應格式化器。若是須要，實現不一樣的報文寫入/讀取代碼。

 

 

 

  1. <span style="font-family:SimSun;">HttpConnectionFactory<HttpRoute, ManagedHttpClientConnection> connFactory =  
  2.         new ManagedHttpClientConnectionFactory(  
  3.             new DefaultHttpRequestWriterFactory(),  
  4.             new DefaultHttpResponseParserFactory(  
  5.                     new MyLineParser(), new DefaultHttpResponseFactory()));</span>  


爲了建立新類的鏈接，提供一個自定義的ClientConnectionOperator接口實現。若是須要，實現不一樣的套接字初始化代碼。

 

 

  1. <span style="font-family:SimSun;">PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(  
  2.     connFactory);  
  3. CloseableHttpClient httpclient = HttpClients.custom()  
  4.         .setConnectionManager(cm)  
  5.         .build();</span>  

7.2 有狀態的HTTP鏈接

HTTP規範假設session狀態信息一般是以HTTP cookie格式嵌入在HTTP報文中的，所以HTTP鏈接一般是無狀態的，這個假設在現實生活中一般是不對的。也有一些狀況，當HTTP鏈接使用特定的用戶標識或特定的安全上下文來建立時，所以不能和其它用戶共享，只能由該用戶重用。這樣的有狀態的HTTP鏈接的示例就是NTLM認證鏈接和使用客戶端證書認證的SSL鏈接。

 

7.2.1 用戶令牌處理器

HttpClient依賴UserTokenHandler接口來決定給定的執行上下文是不是用戶指定的。若是這個上下文是用戶指定的或者若是上下文沒有包含任何資源或關於當前用戶指定詳情而是null，令牌對象由這個處理器返回，指望惟一地標識當前的用戶。用戶令牌將被用來保證用戶指定資源不會和其它用戶來共享或重用。

若是它能夠從給定的執行上下文中來得到，UserTokenHandler接口的默認實現是使用主類的一個實例來表明HTTP鏈接的狀態對象。UserTokenHandler將會使用基於如NTLM或開啓的客戶端認證SSL會話認證模式的用戶的主鏈接。若是兩者都不可用，那麼就不會返回令牌。

若是默認的不能知足它們的須要，用戶能夠提供一個自定義的實現：

  1. <span style="font-family:SimSun;">CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. HttpClientContext context = HttpClientContext.create();  
  3. HttpGet httpget = new HttpGet("http://localhost:8080/");  
  4. CloseableHttpResponse response = httpclient.execute(httpget, context);  
  5. try {  
  6.     Principal principal = context.getUserToken(Principal.class);  
  7.     System.out.println(principal);  
  8. } finally {  
  9.     response.close();  
  10. }</span>  

若是默認的不能知足需求，用戶能夠提供一個特定的實現：

 

  1. <span style="font-family:SimSun;">UserTokenHandler userTokenHandler = new UserTokenHandler() {  
  2.   
  3.     public Object getUserToken(HttpContext context) {  
  4.         return context.getAttribute("my-token");  
  5.     }  
  6.   
  7. };  
  8. CloseableHttpClient httpclient = HttpClients.custom()  
  9.         .setUserTokenHandler(userTokenHandler)  
  10.         .build();</span>  

7.2.2 持久化有狀態的鏈接

請注意帶有狀態對象的持久化鏈接僅當請求被執行時，相同狀態對象被綁定到執行上下文時能夠被重用。因此，保證相同上下文重用於執行隨後的相同用戶，或用戶令牌綁定到以前請求執行上下文的HTTP請求是很重要的。

 

  1. <span style="font-family:SimSun;">CloseableHttpClient httpclient = HttpClients.createDefault();  
  2. HttpClientContext context1 = HttpClientContext.create();  
  3. HttpGet httpget1 = new HttpGet("http://localhost:8080/");  
  4. CloseableHttpResponse response1 = httpclient.execute(httpget1, context1);  
  5. try {  
  6.     HttpEntity entity1 = response1.getEntity();  
  7. } finally {  
  8.     response1.close();  
  9. }  
  10. Principal principal = context1.getUserToken(Principal.class);  
  11.   
  12. HttpClientContext context2 = HttpClientContext.create();  
  13. context2.setUserToken(principal);  
  14. HttpGet httpget2 = new HttpGet("http://localhost:8080/");  
  15. CloseableHttpResponse response2 = httpclient.execute(httpget2, context2);  
  16. try {  
  17.     HttpEntity entity2 = response2.getEntity();  
  18. } finally {  
  19.     response2.close();  
  20. }</span>  

7.3. 使用FutureRequestExecutionService

經過使用FutureRequestExecutionService，你能夠調度HTTP調用以及把response看成一個Future。這是很是有用的，好比當屢次調用一個Web服務。使用FutureRequestExecutionService的優點在於您可使用多個線程來調度請求同時，對任務設置超時或取消，當response再也不須要的時候。

FutureRequestExecutionService用HttpRequestFutureTask（繼承FutureTask）包裝request。這個類容許你取消Task以及保持跟蹤各項指標，如request duration。

7.3.1. 構造FutureRequestExecutionService

futureRequestExecutionService的構造方法包括兩個參數：httpClient實例和ExecutorService實例。當配置兩個參數的時候，您要使用的線程數等於最大鏈接數是很重要的。當線程比鏈接多的時候，鏈接可能會開始超時，由於沒有可用的鏈接。當鏈接多於線程時，futureRequestExecutionService不會使用全部的鏈接。

 

  1. <span style="font-family:SimSun;">HttpClient httpClient = HttpClientBuilder.create().setMaxConnPerRoute(5).build();  
  2. ExecutorService executorService = Executors.newFixedThreadPool(5);  
  3. FutureRequestExecutionService futureRequestExecutionService =  
  4.     new FutureRequestExecutionService(httpClient, executorService);</span>  

 

7.3.2. 安排requests

 

要安排一個請求，只需提供一個HttpUriRequest，HttpContext和ResponseHandler。由於request是由executor service處理的，而ResponseHandler的是強制性的。

 

  1. <span style="font-family:SimSun;">private final class OkidokiHandler implements ResponseHandler<Boolean> {  
  2.     public Boolean handleResponse(  
  3.             final HttpResponse response) throws ClientProtocolException, IOException {  
  4.         return response.getStatusLine().getStatusCode() == 200;  
  5.     }  
  6. }  
  7.   
  8. HttpRequestFutureTask<Boolean> task = futureRequestExecutionService.execute(  
  9.     new HttpGet("http://www.google.com"), HttpClientContext.create(),  
  10.     new OkidokiHandler());  
  11. // blocks until the request complete and then returns true if you can connect to Google  
  12. boolean ok=task.get();</span>  

7.3.3. 取消tasks

預約的任務可能會被取消。若是任務還沒有執行，但僅僅是排隊等待執行，它根本就不會執行。若是任務在執行中且mayInterruptIfRunning參數被設置爲true，請求中的abort（）函數將被調用;不然response會簡單地忽略，但該請求將被容許正常完成。任何後續調用task.get()會產生一個IllegalStateException。應當注意到，取消任務僅能夠釋放客戶端的資源。該請求可能其實是在服務器端正常處理。

 

  1. <span style="font-family:SimSun;">task.cancel(true)  
  2. task.get() // throws an Exception</span>  

7.3.4. 回調

不用手動調用task.get()，您也能夠在請求完成時使用FutureCallback實例獲取回調。這裏採用的是和HttpAsyncClient相同的接口

  1. <span style="font-family:SimSun;">private final class MyCallback implements FutureCallback<Boolean> {  
  2.   
  3.     public void failed(final Exception ex) {  
  4.         // do something  
  5.     }  
  6.   
  7.     public void completed(final Boolean result) {  
  8.         // do something  
  9.     }  
  10.   
  11.     public void cancelled() {  
  12.         // do something  
  13.     }  
  14. }  
  15.   
  16. HttpRequestFutureTask<Boolean> task = futureRequestExecutionService.execute(  
  17.     new HttpGet("http://www.google.com"), HttpClientContext.create(),  
  18.     new OkidokiHandler(), new MyCallback());</span>  

7.3.5. 指標

FutureRequestExecutionService一般用於大量Web服務調用的應用程序之中。爲了便於例如監視或配置調整，FutureRequestExecutionService跟蹤了幾個指標。

HttpRequestFutureTask會提供一些方法來得到任務時間：從被安排，開始，直到結束。此外，請求和任務持續時間也是可用的。這些指標都彙集在FutureRequestExecutionService中的FutureRequestExecutionMetrics實例，能夠經過FutureRequestExecutionService.metrics()獲取。

 

  1. <span style="font-family:SimSun;">task.scheduledTime() // returns the timestamp the task was scheduled  
  2. task.startedTime() // returns the timestamp when the task was started  
  3. task.endedTime() // returns the timestamp when the task was done executing  
  4. task.requestDuration // returns the duration of the http request  
  5. task.taskDuration // returns the duration of the task from the moment it was scheduled  
  6.   
  7. FutureRequestExecutionMetrics metrics = futureRequestExecutionService.metrics()  
  8. metrics.getActiveConnectionCount() // currently active connections  
  9. metrics.getScheduledConnectionCount(); // currently scheduled connections  
  10. metrics.getSuccessfulConnectionCount(); // total number of successful requests  
  11. metrics.getSuccessfulConnectionAverageDuration(); // average request duration  
  12. metrics.getFailedConnectionCount(); // total number of failed tasks  
  13. metrics.getFailedConnectionAverageDuration(); // average duration of failed tasks  
  14. metrics.getTaskCount(); // total number of tasks scheduled  
  15. metrics.getRequestCount(); // total number of requests  
  16. metrics.getRequestAverageDuration(); // average request duration  
  17. metrics.getTaskAverageDuration(); // average task duration</span>  
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程