[[403899]]

本文轉載自微信公眾號「JeffckyShare」，作者Jeffcky 。轉載本文請聯系JeffckyShare公眾號。

下面我們結合如下兩個異常信息進行大致排查分析，到底什么時候會拋出這兩個異常信息呢?

異常信息分析

上述異常說到底還是連接問題導致，但是連接超時有很多種情況，比如客戶端主動關閉連接，又比如服務端對請求應答超時等等，這里給出僅我個人理解的常見情況，大家可以作為基本參考

大前提：根據項目實際情況，分析實際業務對應場景，主要考慮以下最后兩個因素

一是，適當觀察下數據量大小，萬一偶爾出現數據量達到M級別呢，當然既然考慮HTTP，這種情況可以基本忽略

二是，HTTP是否還能承載對應業務，排除性能瓶頸

三是，評估考慮是否增加自身平臺請求超時時間設置?同時也清楚自身平臺是否存在請求非常頻繁?以及也一定要了解對接方是否存在處理請求非常耗時?

首先，若以上兩者都不是，可以從網絡原因開始分析，比如防火墻設置(根據操作系統不同而采取對應方案)、DNS解析設置(有參數可配置刷新DNS解析)、IP設置、代理設置(有參數可配置忽略代理)等等

其次，保證啟用客戶端持久化連接以及增加連接數限制

//增加保活機制，表明連接為長連接 
client.DefaultRequestHeaders.Connection.Add("keep-alive"); 
 
//啟用保活機制（保持活動超時設置為 2 小時，并將保持活動間隔設置為 1 秒。） 
ServicePointManager.SetTcpKeepAlive(true, 7200000, 1000); 
 
 //默認連接數限制為2，增加連接數限制 
ServicePointManager.DefaultConnectionLimit = 512; 

然后，依然不能解決問題，嘗試使用Socket通信連接

var client = new HttpClient(new SocketsHttpHandler() 
{ 
    //考慮忽略使用代理 
    UseProxy = false, 
    //考慮增加連接數配置 
    MaxConnectionsPerServer = 100, 
    //考慮忽略重定向響應 
    AllowAutoRedirect = false, 
    //考慮忽略SSL證書驗證 
    SslOptions = new SslClientAuthenticationOptions() 
    { 
        RemoteCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) => true 
    }, 
    //考慮數據壓縮設置 
    AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip, 
  }) 
  { 
      BaseAddress = new Uri(""), 
      Timeout = TimeSpan.FromSeconds(30), 
  }; 

最后，還不能解決問題，若是Windows通過WireShark抓包分析，若是Linux使用tcpdump抓包，結合WireShark分析

如果其他干擾因素都已經基本排除，同時通過WireShark抓包一切正常，是不是沒轍了

自信一點，適當懷疑一下HttpClient本身可能就存在這樣的問題呢?

考慮在Windows和Linux系統分別測試驗證，最終確認是否是HttpClient底層在兩者系統上機制的有些不同，導致存在的bug呢?