最近在測(cè)試一個(gè)第三方API，準(zhǔn)備集成在我們的網(wǎng)站應(yīng)用中。API的調(diào)用使用的是.NET中的HttpClient，由于這個(gè)API會(huì)在關(guān)鍵業(yè)務(wù)中用到，對(duì)調(diào)用API的整體響應(yīng)速度有嚴(yán)格要求，所以對(duì)HttpClient有了格外的關(guān)注。

開始測(cè)試的時(shí)候，只在客戶端通過HttpClient用PostAsync發(fā)了一個(gè)http post請(qǐng)求。測(cè)試時(shí)發(fā)現(xiàn)，從創(chuàng)建HttpClient實(shí)例，到發(fā)出請(qǐng)求，到讀取到服務(wù)器的響應(yīng)數(shù)據(jù)總耗時(shí)在2s左右，而且多次測(cè)試都是這樣。2s的響應(yīng)速度當(dāng)然是無法讓人接受的，我們希望至少控制在100ms以內(nèi)。于是開始追查這個(gè)問題的原因。

在API的返回?cái)?shù)據(jù)中包含了該請(qǐng)求在服務(wù)端執(zhí)行的耗時(shí)，這個(gè)耗時(shí)都在20ms以內(nèi)，問題與服務(wù)端API無關(guān)。于是把懷疑點(diǎn)放到了網(wǎng)絡(luò)延遲上，但ping服務(wù)器的響應(yīng)時(shí)間都在10ms左右，網(wǎng)絡(luò)延遲的可能性也不大。

當(dāng)我們正準(zhǔn)備換一個(gè)網(wǎng)絡(luò)環(huán)境進(jìn)行測(cè)試時(shí)，突然想到，我們的測(cè)試方式有些問題。我們只通過HttpClient發(fā)了一個(gè)PostAsync請(qǐng)求，假如HttpClient在第一次調(diào)用時(shí)存在某種預(yù)熱機(jī)制（比如在EF中就有這樣的機(jī)制），現(xiàn)在2s的總耗時(shí)可能大多消耗在HttpClient的預(yù)熱上。

于是修改測(cè)試代碼，將調(diào)用由1次改為100次，然后恍然大悟地發(fā)現(xiàn)——只有第1次是2s，接下來的99次都在100ms以內(nèi)。果然是HttpClient的某種預(yù)熱機(jī)制在搞鬼！

既然知道了是HttpClient預(yù)熱機(jī)制的原因，那我們可以幫HttpClient進(jìn)行熱身，減少第一次請(qǐng)求的耗時(shí)。我們嘗試了一種預(yù)熱方式，在正式發(fā)http post請(qǐng)求之前，先發(fā)一個(gè)http head請(qǐng)求，代碼如下：

_httpClient.SendAsync(new HttpRequestMessage {
? ? ? ? ? ? ? ? ? ? Method = new HttpMethod("HEAD"),?
? ? ? ? ? ? ? ? ? ? RequestUri = new Uri(BASE_ADDRESS + "/") })
? ? ? ? ? ? ? ? .Result.EnsureSuccessStatusCode();

經(jīng)測(cè)試，通過這種熱身方法，可以將第一次請(qǐng)求的耗時(shí)由2s左右降到1s以內(nèi)（測(cè)試結(jié)果是700多ms）。

在知道第1次HttpClient請(qǐng)求耗時(shí)2s的真相之后，我們將目光轉(zhuǎn)向了剩下的99次耗時(shí)100ms以內(nèi)的請(qǐng)求，發(fā)現(xiàn)絕大部分請(qǐng)求都在50ms以上。有沒有可能將之降至50ms以下？而且，之前一直有這樣的糾結(jié)：每次調(diào)用是不是一定要對(duì)HttpClient進(jìn)行Dispose()？是不是要將HttpClient單例或者靜態(tài)化（聲明為靜態(tài)變量）？借此機(jī)會(huì)一起研究一下。

在HttpClient的背后，有一個(gè)對(duì)請(qǐng)求響應(yīng)速度有著不容忽視影響的東東——TCP連接。一個(gè)HttpClient實(shí)例會(huì)關(guān)聯(lián)一個(gè)TCP連接，在對(duì)HttpClient進(jìn)行Dispose時(shí)，會(huì)關(guān)閉TCP連接（我們用Wireshark進(jìn)行網(wǎng)絡(luò)抓包也驗(yàn)證了這一點(diǎn)）。

在之前的測(cè)試中，我們每次用HttpClient發(fā)請(qǐng)求時(shí)，都是新建一個(gè)HttpClient實(shí)例，用完就對(duì)它進(jìn)行Dispose，代碼如下：

using (var httpClient = new HttpClient() { BaseAddress = new Uri(BASE_ADDRESS) })
{
? ? httpClient.PostAsync("/", new FormUrlEncodedContent(parameters));
}

所以每次請(qǐng)求時(shí)都要經(jīng)歷新建TCP連接->傳數(shù)據(jù)->關(guān)閉連接（也就是通常所說的短連接），而且雪上加霜的是請(qǐng)求用的是https，建立TCP連接時(shí)還需要一個(gè)基于公私鑰加解密的key exchange過程：Client Hello -> Server Hello -> Certificate -> Client Key Exchange -> New Session Ticket。

如果我們想將請(qǐng)求響應(yīng)時(shí)間降至50ms以下，就必須從這個(gè)地方下手——重用TCP連接（也就是通常所說的長(zhǎng)連接）。要實(shí)現(xiàn)長(zhǎng)連接，首先需要的就是在HttpClient第1次請(qǐng)求后不關(guān)閉TCP連接（不調(diào)用Dispose方法）；而要讓后續(xù)的請(qǐng)求繼續(xù)使用這個(gè)未關(guān)閉的TCP連接，我們必須要使用同一個(gè)HttpClient實(shí)例；而要使用同一個(gè)HttpClient實(shí)例，就得實(shí)現(xiàn)HttpClient的單例或者靜態(tài)化。之前的3 個(gè)問題，由于要解決第1個(gè)問題，后2個(gè)問題變成了別無選擇。

為了實(shí)現(xiàn)長(zhǎng)連接，我們將HttpClient的調(diào)用代碼改為如下的樣子：

然后測(cè)試一下請(qǐng)求響應(yīng)時(shí)間：

  Elapsed:750ms
  Elapsed:31ms
  Elapsed:30ms
  Elapsed:43ms
  Elapsed:27ms
  Elapsed:29ms
  Elapsed:28ms
  Elapsed:35ms
  Elapsed:36ms
  Elapsed:31ms
  ....

除了第1次請(qǐng)求，接下來的99次請(qǐng)求絕大多數(shù)都在50ms以內(nèi)。TCP長(zhǎng)連接的效果必須的！

通過Wireshak抓包也驗(yàn)證了長(zhǎng)連接的效果：

Wireshak抓包

這時(shí)，你

public class HttpClientTest
{?
? ? private static readonly HttpClient _httpClient;

? ? static HttpClientTest()
? ? {
? ? ? ? _httpClient = new HttpClient() { BaseAddress = new Uri(BASE_ADDRESS) };

? ? ? ? //幫HttpClient熱身
? ? ? ? _httpClient.SendAsync(new HttpRequestMessage {
? ? ? ? ? ? ? ? Method = new HttpMethod("HEAD"),?
? ? ? ? ? ? ? ? RequestUri = new Uri(BASE_ADDRESS + "/") })
? ? ? ? ? ? .Result.EnsureSuccessStatusCode();
? ? }

? ? public async Task<string> PostAsync()
? ? {
? ? ? ? var response = await _httpClient.PostAsync("/", new FormUrlEncodedContent(parameters));

? ? ? ? return await response.Content.ReadAsStringAsync();
? ? }
}

也許會(huì)產(chǎn)生這樣的疑問：將HttpClient聲明為靜態(tài)變量，會(huì)不會(huì)存在線程安全問題？我們當(dāng)時(shí)也有這樣的疑問，后來在stackoverflow上找到了答案：

As per the comments below (thanks @ischell), the following instance methods are thread safe (all async):
CancelPendingRequests
DeleteAsync
GetAsync
GetByteArrayAsync
GetStreamAsync
GetStringAsync
PostAsync
PutAsync
SendAsync

HttpClient的所有異步方法都是線程安全的，放心使用。

到這里，HttpClient的問題是不是可以完美收官了？。。。稍等，還有一個(gè)問題。

客戶端雖然保持著TCP連接，但TCP連接是兩口子的事，服務(wù)器端呢？你不告訴服務(wù)器，服務(wù)器怎么知道你要一直保持TCP連接呢？對(duì)于客戶端，保持TCP連接的開銷不大；但是對(duì)于服務(wù)器，則完全不一樣的，如果默認(rèn)都保持TCP連接，那可是要保持成千上萬客戶端的連接啊。所以，一般的Web服務(wù)器都會(huì)根據(jù)客戶端的訴求來決定是否保持TCP連接，這就是keep-alive存在的理由。

所以，我們還要給HttpClient增加一個(gè)Connection:keep-alive的請(qǐng)求頭，代碼如下：

_httpClient.DefaultRequestHeaders.Connection.Add("keep-alive");

現(xiàn)在終于可以收官了。但是肯定不完美，分享的只是解決問題的過程。

到此這篇關(guān)于C#中HttpClient使用注意(預(yù)熱與長(zhǎng)連接)的文章就介紹到這了,更多相關(guān)C# HttpClient內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論