.NET Core HttpClient请求异常详细情况分析

前言

最近项目上每天间断性捕获到HttpClient请求异常，感觉有点奇怪，于是乎观察了两三天，通过日志以及对接方沟通确认等等，查看对应版本源码，尝试添加部分配置发布后，观察十几小时暂无异常情况出现，貌似问题已得到解决，若有后续继续更新。HttpClient来源：netstandard2.0

异常问题

场景：将相关厂家地磁设备（停车进出场）推送数据，转发至对接方。最近一个星期经过观察会出现两种异常情况，一种是请求连接操作被取消，另外一种则是请求处理过程中操作被取消，具体异常信息请见如下图

 

我们知道HttpClient默认超时时间为100s，但项目默认设置请求超时时间为30s，初次分析异常情况来看，请求超时导致请求连接被取消异常，首先我telnet对接方端口通畅，于是乎与对接方交涉，是否存在从请求到对接方接口有额外前置处理，以及网络是否存在波动等等，排查得知相关猜测都予以否决，网络无任何问题

问题排查分析

既然网络没有任何问题，难道是对接方即服务端处理数据量巨大，导致请求应答超时？于是乎对接方甩出几张最近消息接收数据

 

从上述两张图来看，最多的一天也才90来万，最近几天请求失败的数据大概2百来条，从我们平台打印日志来看，每秒请求大致是10个左右，通过HTTP对接完全可以承载。然后，因为我们将数据（JSON，数据大小几乎可以忽略不计）转发到对接方，对接方拿到数据后不会进行任何额外处理，直接存储，所以我们请求超时时间30s，怎么会导致超时而引发异常呢？很奇怪，没辙了，只能拿起终极武器，tcp抓包分析，重新学习了tcp/ip协议族一波

WireShark抓包分析

为打开分析上述pcap文件，提前安装抓包软件WireShark最新版本，由于软件项目部署在Linux上，我们通过如下命令进行抓包

tcpdump -i any port 1443 -w exception.pcap

从如下抓包信息可以直接知道，对接方使用了HTTPS协议，具体请看如下图

 默认打开如上图所示，其中time为时间戳，为找到我们指定时间点（2021-06-04 15:46:17.296），通过tab：视图-时间显示格式-日期和时间

 接下来我们找到包文件中导致请求被取消异常的具体时间节点（2021-06-04 15:46:17.296）

在TCP协议中RST表示复位，用于异常时关闭连接。在发送RST包关闭连接时，不必等待缓冲区的包都发出去，直接丢弃缓冲区的包而发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。好像有点眉头了，继续往下看

 好家伙，结合这张图来看，基本上可以得出结论：原来是我们平台主动重置了连接，紧接着又开始了多次进行三次握手连接即（SYN、SYN/ACK、ACK）

示例代码分析

推送逻辑是在类库中使用HttpClient，所以没有使用HttpClientFactory，因此定义静态变量来使用HttpClient，而非每一个请求就实例化一个HttpClient，

接下来我们来详细分析项目示例代码并对其进行改进

static class Program
{
    static HttpClient httpClient = CreateHttpClient();
    static Program()
    {
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

        ServicePointManager.ServerCertificateValidationCallback = (message, cert, chain, error) => true,
    }

    static async Task Main(string[] args)
    {
        await httpClient.PostAsync("", new StringContent(""));
    }

    static HttpClient CreateHttpClient()
    {
        var client = new HttpClient(new HttpClientHandler
        {
            ServerCertificateCustomValidationCallback = (message, cert, chain, error) => true
        })
        {
            Timeout = TimeSpan.FromSeconds(30)
        };

        client.DefaultRequestHeaders.Accept.Clear();

        client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
        client.DefaultRequestHeaders.Add("ContentType", "application/json");
        return client;
    }
}

若对接方仅使用HTTPS协议，无需验证证书，最好是忽略证书验证，否则有可能会引起建立验证证书连接异常，即添加

ServerCertificateCustomValidationCallback = (message, cert, chain, error) => true

我们观察上述代码，有两个地方都对证书验证进行了设置，一个是在静态构造函数中ServicePointManager（简称SP），另外则在实例化HttpClient构造函数中即HttpClientHandler（简称HCH），那么这二者是否有使用上的限制呢？

在.NET Framework中，内置的HttpClient建立在HttpWebRequest之上，因此可以使用SP来配置

 

在.NET Core中，通过SP配置证书信息仅影响HttpWebRequest，而对HttpClient无效，需通过HCH配置来达到相同目的

所以去除在静态构造函数中对忽略证书的配置，改为在HttpClientHandler中

var client = new HttpClient(new HttpClientHandler
{
    ServerCertificateCustomValidationCallback = (message, cert, chain, error) => true,
    SslProtocols = SslProtocols.Tls12
})

回到本文的话题，为什么会重置连接即主动关闭连接呢？我们已分析过，和上述配置30s超时没有关系，主要有两方面原因

翻开并温习《图解HTTP》一书，如果请求频繁，最好建立持久连接，减少TCP连接的重复建立和断开所造成的额外开销，从而减轻服务端负载即重用HTTP连接，也称为Http keep-alive，持久连接的特点是，只要任意一方没有明确提出断开连接，否则保持TCP连接状态

配置keep-alive我们俗称为保活机制，所以在默认请求头中添加如下一行

 //增加保活机制，表明连接为长连接
 client.DefaultRequestHeaders.Connection.Add("keep-alive");

上述只是在报文头中添加持久化连接标识，但不意味着就一定生效，因为默认是禁用持久化连接，所以为了保险起见，添加如下代码

  //启用保活机制（保持活动超时设置为 2 小时，并将保持活动间隔设置为 1 秒。）
  ServicePointManager.SetTcpKeepAlive(true, 7200000, 1000);

有个让我很疑惑的问题，通过查看设置启用持久化连接源码得知，这样设置意义在哪里？没弄明白，源码如下

public static void SetTcpKeepAlive(bool enabled, int keepAliveTime, int keepAliveInterval)
{
    if (enabled)
    {
        if (keepAliveTime <= 0)
        {
            throw new ArgumentOutOfRangeException(nameof(keepAliveTime));
        }
        if (keepAliveInterval <= 0)
        {
            throw new ArgumentOutOfRangeException(nameof(keepAliveInterval));
        }
    }
}

最关键的一点则是默认持久化连接数为2，非持久化连接为4

  public class ServicePointManager
  {
      public const int DefaultNonPersistentConnectionLimit = 4;
      public const int DefaultPersistentConnectionLimit = 2;

      private ServicePointManager() { }
  }

那么问题是否就已很明了，项目中使用非持久化连接，即连接为4，未深究源码具体细节，大胆猜想一下，若连接大于4，是否会出现将此前连接主动关闭，重建新的连接请求呢？最终我们将原始代码修改为如下形式

static class Program
{
    static HttpClient httpClient = CreateHttpClient();

    static Program()
    {
        //默认连接数限制为2，增加连接数限制
        ServicePointManager.DefaultConnectionLimit = 512;

        //启用保活机制（保持活动超时设置为 2 小时，并将保持活动间隔设置为 1 秒。）
        ServicePointManager.SetTcpKeepAlive(true, 7200000, 1000);
    }

    static async Task Main(string[] args)
    {
        await httpClient.PostAsync("", new StringContent(""));

        Console.WriteLine("Hello World!");
    }

    static HttpClient CreateHttpClient()
    {
        var client = new HttpClient(new HttpClientHandler
        {
            ServerCertificateCustomValidationCallback = (message, cert, chain, error) => true,
            SslProtocols = SslProtocols.Tls12
        })
        {
            Timeout = TimeSpan.FromSeconds(30)
        };

        client.DefaultRequestHeaders.Accept.Clear();
        //增加保活机制，表明连接为长连接
        client.DefaultRequestHeaders.Connection.Add("keep-alive");
        client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
        client.DefaultRequestHeaders.Add("ContentType", "application/json");
        return client;
    }
}

进行如上设置后，通过一天观察，再未出现相关异常，至此问题解决告一段落，希望没有后续......

总结

强烈建议：利用HttpClient发送请求设置持久化连接和根据实际业务评估增加连接数，而非默认的持久化连接为2，非持久化连接为4，否则极易出现相关异常。

若非常清楚默认连接数限制，可能并算不上什么问题，也不存在如此诸多分析，不过对于我而言，收获的是在问题排查过程中，对可能干扰信息的过滤、筛选、确认以及对网络协议进一步的加深。 

引发思考：利用HttpClientFactory创建HttpClient是否有默认连接限制，据我所知，好像可以通过属性MaxConnectionsPerServer来配置

💡 在.NET Core和.NET Framework中相关配置还是有些变化，最好是根据对应版本在官网上确认下