使用HTTPclient保持長(zhǎng)連接
HTTPclient保持長(zhǎng)連接
首先解釋一下什么是長(zhǎng)連接
當(dāng)我們向一臺(tái)服務(wù)器發(fā)起請(qǐng)求時(shí),我們需要和對(duì)方建立一條通道,去傳輸數(shù)據(jù),所謂的短連接,就是說我們建立起了通道,然后在傳輸完數(shù)據(jù),就把通道摧毀,下次需要的時(shí)候再重新去建立通道。
長(zhǎng)連接呢,就是指,我們建立了一條通道,傳遞完數(shù)據(jù)后,先不摧毀,下次如果還需要傳輸數(shù)據(jù),就復(fù)用這條通道。
因?yàn)橥ǖ赖慕⑹切枰ㄙM(fèi)時(shí)間的,所以長(zhǎng)連接的優(yōu)勢(shì)就在于響應(yīng)速度快,但是服務(wù)器壓力大,因?yàn)橥瑫r(shí)有很多人在向服務(wù)器建立通道,即便有些通道已經(jīng)傳輸完數(shù)據(jù)了,由于長(zhǎng)連接的原因,通道也不會(huì)被摧毀;短連接呢,則是,響應(yīng)速度慢,服務(wù)器壓力小。
由于現(xiàn)在更多的是強(qiáng)調(diào)用戶的體驗(yàn),所以長(zhǎng)連接目前是最常見的。
如何在java中實(shí)現(xiàn)一個(gè)長(zhǎng)連接呢
其實(shí)很簡(jiǎn)單,只需要在請(qǐng)求的請(qǐng)求頭中加入特定的參數(shù) :“Connection”:"keep-alive"即可。這樣如果對(duì)方支持長(zhǎng)連接的話,那么這個(gè)連接就會(huì)保持長(zhǎng)連接了。
問題的關(guān)鍵就來了,在一次壓測(cè)某個(gè)https請(qǐng)求響應(yīng)速度的代碼中,我發(fā)現(xiàn)了,當(dāng)對(duì)方響應(yīng)數(shù)據(jù)為null,也就是responseBody中帶的數(shù)據(jù)為null時(shí),響應(yīng)速度特別快,大概在5ms左右,但是一旦對(duì)方返回了響應(yīng)數(shù)據(jù),本次響應(yīng)就可能達(dá)到了20ms。
然后請(qǐng)運(yùn)維同事抓包,發(fā)現(xiàn)每次連接,都會(huì)耗費(fèi)時(shí)間在用戶認(rèn)證上,其實(shí)也就是從某個(gè)方面反應(yīng)出,每次都是新建立了一個(gè)連接。
HttpPost httpPost = new HttpPost("xxxxx");
httpPost.addHeader("Connection", "keep-alive");
CloseableHttpClient httpClient = null;
for(int i =0 ;i<5000;i++){
long t1 = System.currentTimeMillis();
CloseableHttpResponse response = httpClient.execute(httpPost);
long t2 = System.currentTimeMillis();
}
上了一段簡(jiǎn)單的代碼,表示一下大概的邏輯,實(shí)際的壓測(cè)代碼還包括了線程池,連接池的完整參數(shù)等等,如果需要的可以留言或者翻看本人的其他的博客,有寫線程池和連接池。
就是這樣一段代碼,導(dǎo)致每次連接都是新建立的連接,那么原因是什么呢,我們先上代碼:
for (int i = 0; i<5000;i++){
long t1 = System.currentTimeMillis();
CloseableHttpResponse response = httpClient.execute(httpPost);
if(null != response.getEntity()){
EntityUtils.consume(response.getEntity());
}
long t2 = System.currentTimeMillis();
}
我們只需要簡(jiǎn)單加上三行代碼,就可以解決這個(gè)問題了,這是為什么呢,讓我們點(diǎn)進(jìn)去源碼看一下

這么一看, 其實(shí)這個(gè)方法也并沒有做什么,只是簡(jiǎn)單的取到了流去關(guān)閉,為什么就保持長(zhǎng)連接了呢。
后來仔細(xì)讀http連接的原理才得知,當(dāng)一個(gè)連接建立,響應(yīng)數(shù)據(jù)時(shí),會(huì)封裝CloseableHttpResponse這個(gè)對(duì)象里面,其中的Entity對(duì)象就是包含著響應(yīng)體的數(shù)據(jù),我們需要用流去獲取。如果你不去獲取,那么這個(gè)數(shù)據(jù)就會(huì)存在于這個(gè)對(duì)象中,連接池就會(huì)認(rèn)為,這個(gè)通道里有未處理的數(shù)據(jù),然后它不會(huì)去復(fù)用這個(gè)通道,而是選擇重建一個(gè)通道。這就完美解釋了為什么壓測(cè)時(shí),對(duì)方返回null時(shí),響應(yīng)速度特別快,而攜帶返回?cái)?shù)據(jù)時(shí),響應(yīng)速度特別慢了。
那么再仔細(xì)想想,為什么我們平常不知道這個(gè)知識(shí)點(diǎn),卻從來沒有報(bào)過錯(cuò)呢,那是因?yàn)檎G闆r下,我們都是需要會(huì)對(duì)response做處理,比如String responseContent = EntityUtils.toString(response.getEntity(), StandardCharsets.UTF_8); 類似這種,我們點(diǎn)進(jìn)源碼看,其實(shí)也是取到了流,并做了關(guān)閉操作。平常還是要多閱讀源碼,想想源碼。
httpclient因?yàn)楸3钟谰瞄L(zhǎng)連接造成連接吊死的問題
httpclient使用了連接池,如果沒有設(shè)置keep-alive策略,PoolingHttpClientConnectionManager會(huì)默認(rèn)使用永久連接。
最近在調(diào)用京東api時(shí),發(fā)現(xiàn)一個(gè)請(qǐng)求開始是可以獲取到數(shù)據(jù)的,但隔了兩分鐘后再請(qǐng)求就會(huì)出現(xiàn)read timeout異常。
對(duì)比請(qǐng)求成功和請(qǐng)求失敗的日志后發(fā)現(xiàn),請(qǐng)求成功的有以下日志“Connection: keep-alive”,“Connection can be kept alive indefinitely”;但請(qǐng)求失敗的卻打印“Shutdown connection”,“Connection discarded”。
每次失敗后再請(qǐng)求都會(huì)成功。因此推測(cè)中應(yīng)該是對(duì)方服務(wù)器端禁止長(zhǎng)連接,當(dāng)連接到達(dá)一定時(shí)間會(huì)就會(huì)斷開。
后來上網(wǎng)找到keep-alive策略的代碼。
添加策略后,問題解決
ConnectionKeepAliveStrategy keepAliveStrategy = new ConnectionKeepAliveStrategy() {
@Override
public long getKeepAliveDuration(HttpResponse response, HttpContext context) {
HeaderElementIterator it = new BasicHeaderElementIterator(response.headerIterator(HTTP.CONN_KEEP_ALIVE));
while (it.hasNext()) {
HeaderElement he = it.nextElement();
String param = he.getName();
String value = he.getValue();
if (value != null && param.equalsIgnoreCase("timeout")) {
try {
return Long.parseLong(value) * 1000;
}
catch (NumberFormatException ignore) {
}
}
}
HttpHost target = (HttpHost) context.getAttribute(HttpClientContext.HTTP_TARGET_HOST);
if ("bizapi.jd.com ".equalsIgnoreCase(target.getHostName())) {
return 60 * 1000;
}
else {
return 300 * 1000;
}
CloseableHttpClient httpClient = httpClientBuilder.setConnectionManager(pollingConnectionManager)
.setKeepAliveStrategy(keepAliveStrategy).setDefaultRequestConfig(defaultRequestConfig).build();
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
如何用Java?幾分鐘處理完?30?億個(gè)數(shù)據(jù)(項(xiàng)目難題)
現(xiàn)有一個(gè) 10G 文件的數(shù)據(jù),里面包含了 18-70 之間的整數(shù),分別表示 18-70 歲的人群數(shù)量統(tǒng)計(jì),今天小編通過本文給大家講解如何用Java?幾分鐘處理完?30?億個(gè)數(shù)據(jù),這個(gè)問題一直以來是項(xiàng)目難題,今天通過本文給大家詳細(xì)介紹下,感興趣的朋友一起看看吧2022-07-07
Java項(xiàng)目中防止SQL注入的四種方案總結(jié)
SQL注入是一種代碼注入技術(shù),通過把SQL命令插入到Web表單遞交或輸入域名或頁面請(qǐng)求的查詢字符串,最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令,下面我們就來看看如何在項(xiàng)目中防止SQL注入吧2023-10-10
java中brew安裝rabbitmq以及簡(jiǎn)單實(shí)例
RabbitMQ是基于AMQP協(xié)議,由Erlang語言開發(fā)的開源消息隊(duì)列系統(tǒng),廣泛應(yīng)用于分布式系統(tǒng)中,用于應(yīng)用程序間的消息傳遞,它支持多種交換機(jī)類型,如直連交換機(jī)、扇形交換機(jī)和主題交換機(jī)等,能夠滿足不同的消息路由需求2024-10-10
Springboot發(fā)送郵件功能的實(shí)現(xiàn)詳解
電子郵件是—種用電子手段提供信息交換的通信方式,是互聯(lián)網(wǎng)應(yīng)用最廣的服務(wù)。本文詳細(xì)為大家介紹了SpringBoot實(shí)現(xiàn)發(fā)送電子郵件功能的示例代碼,需要的可以參考一下2022-09-09
JavaCV簡(jiǎn)介與環(huán)境搭建詳細(xì)步驟
JavaCV是一個(gè)開源的Java接口,它為幾個(gè)著名的計(jì)算機(jī)視覺庫(如OpenCV、FFmpeg)提供了Java封裝,這篇文章主要給大家介紹了關(guān)于JavaCV簡(jiǎn)介與環(huán)境搭建的相關(guān)資料,需要的朋友可以參考下2024-04-04

