.NET 6 HttpClient请求IIS托管网站出现1秒延迟，.NET Framework 4.8无此问题

这种情况我之前排查过类似的案例，结合你描述的现象——同服务器上.NET 4.8正常、.NET 6连IIS才出问题、连OWIN应用无延迟，大概率是.NET 6 HttpClient的底层实现变化，和IIS的默认配置交互时踩了坑，给你几个接地气的排查方向：

• 先验证是否是SocketsHttpHandler的锅
  .NET 6起HttpClient默认用SocketsHttpHandler替代了老的HttpClientHandler，这也是和.NET Framework最核心的差异点。你可以先强制让.NET 6退回到老的处理逻辑试试，在代码开头加一行：

  AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);
  

  如果加完延迟消失，那百分百是新的SocketsHttpHandler和IIS的适配问题。

• 排查IIS的身份验证协商延迟
  只有IIS站点出问题、OWIN应用正常，这很可能和IIS默认开启的**Windows身份验证（NEGOTIATE协商）**有关。.NET 6的HttpClient在处理NEGOTIATE握手时，可能会因为自动协商失败卡在NTLM回退步骤上，刚好就是1秒左右的等待时间。
  你可以先做两个小测试：

  1. 临时把IIS站点的Windows身份验证关掉，只开匿名认证，看看延迟是否消失
  2. 要是必须保留Windows认证，就在HttpClient里显式指定用NTLM，跳过协商步骤：

     var handler = new HttpClientHandler
     {
         Credentials = new NetworkCredential("你的账号", "密码", "域名"),
         PreAuthenticate = true
     };
     using var client = new HttpClient(handler);
     

• 检查DNS解析的差异
  .NET 6的DNS解析逻辑和.NET Framework完全不同，你可以试试在代码里强制指定DNS服务器，或者在服务器的hosts文件里把IIS站点的域名和IP硬绑定，要是绑定后延迟消失，就是DNS解析的超时问题。

• 核对两台服务器的补丁和Runtime版本
  你说两台VM系统和IIS版本一致，但说不定有问题的那台没装最新的.NET 6 Runtime补丁，或者差了某个Windows KB更新。.NET 6后续补丁修复过不少HttpClient和IIS交互的性能bug，把有问题的服务器的.NET 6 Runtime更到最新版，再对比两台服务器的更新记录试试。

另外，用Wireshark抓个网络包，能直接看到那1秒延迟到底耗在哪个阶段——是DNS解析、TCP握手还是认证协商，抓包后问题根源会一目了然。

备注：内容来源于stack exchange，提问作者Ihor Marenych