SMB 实际上早于IP 在 LAN 上的广泛使用（它的创建时间与 IPv4 大致相同）。在 Windows NT 4.x 时代，同一个文件服务器可能可以通过 IPv4、NetWare 的 IPX 和/或 MAC 级别的“NetBEUI”访问。（AFAIK，在某些情况下，甚至无法仅通过地址访问服务器——您必须使用名称。）
基于 NetBIOS 的 SMBv1 支持“虚拟主机”，即客户端总是发送一个数据包来指示它想要访问的主机名。（这对于某些 LAN 协议可能是强制性的，但无论如何仍保留在 IPv4/TCP 中。）
存储凭证的层不知道主机的 IP 地址——它只给出您输入的名称，并仅在该名称下存储凭证。它自己不进行任何地址查找。
只有微软确切地知道它为什么会这样工作。但是，这可能有几个原因：
IP 地址可能是动态的。在所有名称都通过 NetBIOS 或 LLMNR 解析的简单工作组 LAN 上，您可能甚至不会注意到一些廉价路由器会忘记以前的租约并每次都为您提供不同的 IP 地址。因此，上周属于主机 A 的地址现在可能属于主机 B，但凭据不同。
SMB 不仅限于 IPv4。今天可以通过 IPv4 访问同一个文件服务器，明天可以通过 IPv6 访问（在后一种情况下，服务器将有两个地址可用）。将凭据存储在主机名下会使事情变得更容易。
SMB 实际上早于IP 在 LAN 上的广泛使用（它的创建时间与 IPv4 大致相同）。在 Windows NT 4.x 时代，同一个文件服务器可能可以通过 IPv4、NetWare 的 IPX 和/或 MAC 级别的“NetBEUI”访问。（AFAIK，在某些情况下，甚至无法仅通过地址访问服务器——您必须使用名称。）
基于 NetBIOS 的 SMBv1 支持“虚拟主机”，即客户端总是发送一个数据包来指示它想要访问的主机名。（这对于某些 LAN 协议可能是强制性的，但无论如何仍保留在 IPv4/TCP 中。）
这个 NetBIOS 会话协议功能理论上可以允许同一系统充当具有不同凭据的不同服务器，具体取决于您用来访问它的名称，而且我个人怀疑它可能已被协议网关实际使用，例如允许 IPv4-只有客户端才能访问仅限 IPX 的服务器，反之亦然。网关在两边只有一个地址，并且会根据名称改变其行为，就像现在的 HTTP“反向代理”一样。
（SMBv3 支持类似的东西，我读到 Azure Cloud 实际上使用依赖它的负载均衡器。）
最后，它类似于 HTTP 虚拟主机和 cookie。仅仅因为浏览器存储了一个 cookie 表明您在 登录，
https://superuser.com如果您访问它，它就不会给出它https://151.101.1.69。