用于解析实例名称的端口号的 SQL Server Browser 服务的缓存在哪里？答案

【问题标题】：Where is the cache of SQL Server Browser service for resolving Instance name's port number?用于解析实例名称的端口号的 SQL Server Browser 服务的缓存在哪里？
【发布时间】：2019-05-23 05:01:05
【问题描述】：

来自here：

当 SQL Server 客户端请求 SQL Server 资源时，客户端网络库使用端口 1434 向服务器发送 UDP 消息。SQL Server 浏览器使用所请求实例的 TCP/IP 端口或命名管道进行响应。

显然，当 UDL 或 SSMS 用于远程连接到 SQL Server 实例名称时，解析实例名称的端口号的查询存储在客户端计算机的某个位置。

我在两台客户端机器上对此进行了测试。当 1434 UDP 端口打开时，第一台机器可以连接到 SQL Server 实例名称。然后我关闭了端口并用那台机器再次尝试。第一个客户端仍然可以在没有打开端口的情况下连接。然后我尝试了第二台机器，但它无法连接。

我只是想知道这个缓存是如何以及在哪里发生的？

【问题讨论】：

可能是标准客户端连接池？
@DanGuzman 你能详细解释一下吗？
如果你重启服务器，端口会改变，第一个客户端将无法连接到它。
@SalmanA 不，我在 TCP/IP 配置中定义了静态端口 1433。
@Ahmad，我添加了更多解释的答案。

标签： sql-server windows sqlbrowser

【解决方案1】：

像 SqlClient 这样的客户端 API 默认使用 connection pooling 来避免每次打开连接时的名称解析、物理网络连接和身份验证的开销。当初始连接关闭时，该连接将被添加到连接池中，下次打开具有相同属性的另一个连接时可以重用该连接池。在这种情况下，客户端 API 只是从池中检索和未使用的连接，避免了建立物理连接的大量开销。

使用命名实例，连接池还避免了每次打开连接时都需要查询 SQL Server Browser 服务，因此这解释了您的观察结果。我怀疑如果您在阻止 UDP 端口 1434 后退出并重新启动应用程序，则命名实例的 SQL 连接将由于初始连接打开期间 SQL Server Browser 数据报查询失败而失败。

【讨论】：

不@DanGuzman。阻塞 1434 UDP 后连接仍然成功。
@Ahmad，您的意思是在重新启动应用程序后（例如 SSMS）？
是的。在客户端上，我关闭了 UDL 应用程序并再次打开它。使用封闭端口，我可以连接实例名称。