I've observed some unusual SSL tunnel behavior when asynchronously sending multiple requests from System.Net.Http.HttpClient. I've isolated the problem to the following minimal working example (MWE):
public async Task MinimalExample()
{
var c = new HttpClient
{
BaseAddress = new Uri("https://www.google.com")
};
var l = new List<Task<HttpResponseMessage>>();
for (int i = 0; i < 5; i++)
{
l.Add(c.GetAsync(""));
}
await Task.WhenAll(l);
}
This code hits Google five times in parallel.
Running this code and inspecting traffic in Fiddler shows the following:
The client issues five SSL tunnels, one for each request. This is unusual, since typically HttpClient reuses SSL tunnels to the same host. Indeed, running the synchronous version of the MWE:
public void MinimalExampleSynchronous()
{
var c = new HttpClient
{
BaseAddress = new Uri("https://www.google.com")
};
var l = new List<HttpResponseMessage>();
for (int i = 0; i < 5; i++)
{
l.Add(c.GetAsync("").Result);
}
}
... shows the following in Fiddler:
A single SSL tunnel is established, and used to transmit the 5 requests (which is typically how well-behaving HTTP clients and browsers act).
My question is:
- Why does the parallel version not create and reuse a single SSL tunnel?
My MWE only issues 5 requests, but for larger tasks HttpClient ends up creating thousands of redundant SSL tunnels, which significantly slows things down and creates lots of waste. Is this a bug, or is my parallel implementation just using HttpClient stupidly?
