将 Web 服务器升级到 .net 框架 4.6.1 时与远程 SQL 服务器的连接中断答案

【问题标题】：Connection to remote SQL server breaks when upgrading web server to .net framework 4.6.1将 Web 服务器升级到 .net 框架 4.6.1 时与远程 SQL 服务器的连接中断
【发布时间】：2016-04-09 14:36:06
【问题描述】：

我们目前正在努力将我们的 asp.net Web 应用程序（托管在 IIS 7.5 上）从 .net framework v4.5 更新到 v4.6.1。在 SQL Server 与 IIS 在同一个机器上运行的小型较低环境/本地开发中，此更新工作正常并且不会破坏任何内容。但是，一旦我们在测试环境中更新了从我们的 Web 服务器远程托管 SQL Server 的 Web 服务器，我们的应用程序就无法再建立到数据库的连接。我们收到此错误：

Connection Timeout Expired. The timeout period elapsed while attempting to
consume the pre-login handshake acknowledgement. This could be because the
pre-login handshake failed or the server was unable to respond back in time.

SQL Server 使用 CLR 版本 v4.0.30319 运行。我们使用 Entity Framework 6.0.0.0 版本进行数据访问，连接字符串都使用集成安全性。我们是否还需要将托管 SQL 服务器的盒子更新为 .net 4.6.1？我不明白为什么我们的应用程序需要建立与数据库的连接，但我在 MSDN 上找不到任何关于此的指导。

编辑：

在此故障之后，我们将 Web 服务器降级回 .net v4.5，并且能够重新建立与 SQL 服务器的连接。重新升级到 v4.6.1 再次导致损坏。因此，我们相对确定问题在于升级，而不是应用程序代码和/或 IIS 设置的更改。

【问题讨论】：

检查 SQL 服务器上的事件查看器框以查看在错误发生时是否在应用程序或安全选项卡上生成了任何日志。还要检查端口是否打开，或者是否有阻止连接的访问控制列表。
另外，自上次运行以来，Web 服务器发生了哪些变化？
Web 服务器上的应用程序代码/IIS 设置没有变化。我们已将 Web 服务器降级回 .net 4.5，并且我们已与 SQL 服务器重新建立连接。重新升级到 4.6.1 会导致相同的损坏。这也表明端口是开放的。不过，我会检查 SQL 服务器框上的事件日志。
那么也可以将 SQL 框升级到 .net 4.6.1。本文指出处理 SQL 连接的方式在 4.6.1 中发生了更改：visualstudiomagazine.com/articles/2015/12/11/… 不过还没有找到确切的更改。
我们在生产中升级到 .NET 4.6.1 时遇到了同样的问题。我们在 DEV、QA 或 Staging 中没有发现这个问题。更糟糕的是，我们有 3 个 SQL Server (2008 R2)，只有访问其中一个总是失败。回滚到 .NET 4.5.1 后，问题就消失了。我们 100% 确定此问题与 .NET 4.6.1 中超过 4.5.x 的连接更改有关。

标签： c# asp.net .net sql-server

【解决方案1】：

更新 - 所以看起来我们已经找到（至少是解决方案）问题。结果——正如异常所暗示的——通过增加连接字符串的连接超时属性（默认为 15 秒，我们将其设置为 60 秒），我们能够通过我们的 Web 应用程序连接到我们的数据库。然而，打开这个连接需要很长的时间，所以我们开始寻找解决方案来让我们的连接打开得更快。我们发现我们的数据库服务器上启用了基于 TCP/IP 的 Netbios，并且通过在我们的网络上打开 UDP 端口（137、138）以供 Netbios 访问，我们能够以更快、更及时的方式打开与数据库的连接在 15 秒。我们仍然不确定.net 升级为什么会暴露这个问题。通过使用 UDL 文件进行测试，我们能够确定与数据库的网络连接在 .net 4.5 上的 Web 服务器上与在 .net 4.6.1 上的 Web 服务器上的性能大致相同。因此，似乎我们的连接打开得如此缓慢，以至于我们已经非常接近超时，并且 4.6.1 中的某种额外的逻辑/缺陷使我们处于边缘。如果我们对此有更清楚的了解，我会更新。

【讨论】：

为什么您认为这是 4.6.1 的问题，而不是导致连接超过阈值的某些随机网络条件？看起来您使用的是 NETBIOS 名称而不是 IP 或 FQDN，因此迫使 ADO.NET 尝试多种协议，直到找到有效的协议。为什么一开始不使用 TCP/IP 和 IP 或 FQDN？
我们使用 IP，而不是 NETBIOS 名称。我们认为这是 4.6.1 的问题，因为通过将 .net 框架升级回滚到 4.5，我们可以解决该问题。所以我们/相当有信心升级导致失败。然而，就像我上面提到的，听起来升级只是暴露了一个现有的瓶颈。
我们看到与 4.6.1 完全相同的行为。

【解决方案2】：

以下文章介绍了 .net 4.6.1 中 SQL Server 连接的新默认连接字符串设置。

https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/

这是为了解决某些环境中的一个问题，但也导致了您在其他环境中遇到的问题。

基本上，您需要添加以下连接字符串：

TransparentNetworkIPResolution=False;

【讨论】：

【解决方案3】：

您可能需要检查 windows\micorsoft.net\framework64\v######\config 文件夹中的 machine.config 和 web.config 文件。每个版本的 .NET 在不同的配置文件上运行。由于在两个环境中使用相同的代码，它必须来自从这里继承的配置。我猜 4.6.1 被设置为默认连接字符串到 localhost 并且由于本地和开发中的 SQL 在同一台服务器上，所以这不是问题。您可能会发现 .NET 4.5 版本中的配置有一个超出 localhost 定义的连接字符串。

如果 4.5 和 4.61 使用相同的配置文件，请确保在该 web.config 中定义实体框架使用的默认连接字符串。

【讨论】：

【解决方案4】：

首先 - 此问题仅在您使用 Active Directory 身份验证时出现。

我已经管理了脏修复：将您的 MSSQL 服务器添加到您的本地（无法连接到 MSSQL 服务器的机器）主机文件 (%windir%\system32\drivers\etc\hosts)。

例如： 192.168.0.5 mssqlserver

名字真的不重要。如果您在一个 IP 地址上有多个 SQL 服务器（通过 NAT 连接），它也能很好地工作。

这个脏修复也将修复使用 SQL Management Studio 加载缓慢的问题。

【讨论】：

hosts文件与AD认证无关。超时也与身份验证无关。此“修复”只是在尝试确定要使用的协议时尝试短路 ADO.NET 的逻辑。远更好的选择是简单地使用 FQDN 或 IP。或者在连接字符串中指定协议
这真的很奇怪，在我的测试中，我只能使用 AD auth 和使用 IP、PORT 组合的连接来重现此问题。 FQDN 对我来说不是可用的选项。
那么您应该检查您的域设置。您所做的是将 NetBIOS 名称隐藏在主机名后面。您没有解决导致超时的问题。 Windows 身份验证是 SQL Server 的默认并且可能是最安全的机制，广泛用于服务、网站等。如果不能使用，问题就更大了
我已经为我自己和我所有的同事修复了它 - 通过 NAT 连接到 SQL 服务器，在它/dev pc 上安装后它被破坏了。
真正的“修复”是在连接字符串中使用正确的 FQDN，例如 myserver.mydomain.local。