.NET中HttpClient.GetStreamAsync与GetAsync批量下载行为差异问询

该差异本质是.NET Framework 4.7.2及更低版本中，GetStreamAsync和无参GetAsync使用了不同的HTTP请求完成选项，进而导致连接池占用逻辑完全不同：

• HttpClient.GetStreamAsync(url) 内部调用GetAsync时指定的是HttpCompletionOption.ResponseHeadersRead：只要服务端返回响应头，方法就会立即返回Stream对象，此时整个响应体还未完成下载，底层HTTP连接会一直被占用，直到Stream被读取完毕并显式/隐式释放，才会归还到连接池复用。
  示例代码中Option1拿到Stream后直接返回，没有做任何读取、释放操作，相当于每个请求都占住一个HTTP连接不释放。而.NET Framework 客户端程序的默认ServicePointManager.DefaultConnectionLimit值仅为2，15个并发请求发起后，很快就会耗尽连接池配额，后续请求排队超过超时阈值就会报错。
• 无参HttpClient.GetAsync(url) 默认使用的是HttpCompletionOption.ResponseContentRead：方法会等待整个响应体全部下载完成、缓冲到内存后，才会返回HttpResponseMessage，此时底层HTTP连接已经被释放归还到连接池，后续读取Content.ReadAsStreamAsync()拿到的是内存缓冲的流，不会占用网络连接。
  所以哪怕默认连接池配额只有2，请求可以依次完成下载、释放连接，不会出现连接耗尽排队超时的情况。

1. 为什么.NET Core不会复现该问题：.NET Core重构了HttpClient的连接池逻辑，默认的单域名连接限制远高于.NET Framework的默认值，且连接回收逻辑更激进，所以不会轻易触发连接耗尽的问题。
2. 为什么调高DefaultConnectionLimit到30就不再报错：15个并发请求需要的连接数低于30的阈值，连接池足够分配，哪怕请求占着连接不释放也不会触发排队超时。

无论使用哪个API，拿到网络流后都应该在读取完成后立即释放，避免连接泄漏：

using var stream = await httpclient.GetStreamAsync(imageUrl);
// 后续读取流的逻辑

内容的提问来源于stack exchange，提问作者Mike B