我们在 DMZ 中有一个 IIS 网络场，连接到 MSSQL DB（Windows 群集）。在排除一些性能问题后，我们偶然发现了奇怪的网络行为。
我们想测试两台服务器之间的网络延迟，但防火墙阻止了 ping，因此我们尝试使用tcp连接专门测试端口 1433 上的数据库服务器的延迟。TCPing 报告延迟约为 20ms。从我的工作站到数据库服务器的相同 TCPing 为约 2ms。我的第一个想法是这是 Web 和数据库服务器之间的防火墙，因此，为了证实我的怀疑，我从网络内的另一个应用程序服务器运行了另一个 TCPing，它也报告了 20ms 的延迟。然后我开始从其他一些服务器运行相同的 TCPing。有些报告延迟为 2ms，有些报告延迟接近 20ms。
网络操作告诉我，差异很可能是由于操作系统配置造成的，因为我测试的服务器位于相同的网络段中（Web 服务器除外）。
在 TCPing 报告 2ms 延迟的服务器上，我们看到性能显著改善。
Windows 中是否存在可能导致此行为的任何类型的网络配置？有没有人有其他建议（其他监控工具、其他可能的原因等）？
更新 刚刚尝试 TCPing 到本地 IP，不是 127.0.0.1，而是机器的实际 IP，我也看到了延迟（大约 15-18 毫秒）。我查看了几台服务器，注意到了类似的行为。这似乎不正常，有什么想法吗？并非所有服务器都表现出这种行为。
答案1
胡说，网络运营无能。
2ms不算小但是还可以。
20ms 太离谱了。这是 WAN 链接，或者是线路过载之类的。
即使你使用六个路由器，建筑物内的任何 LAN 技术都无法给你 20 毫秒的时间。
我不知道有任何配置错误。
但是，阻止 ICMP 可能会产生副作用 - 例如丢弃 TCP 数据包。关闭该功能的人在配置防火墙之前应该了解 TCP/IP。根据 TCP 标准，网络中断是由于缺少 ICMP（例如，它用于查找可以安全传输的最大段大小）。
答案2
操作系统配置？当交换机端口和 NIC 在速度和双工方面不一致时，我见过这种延迟。这是在 NIC 端的操作系统中设置的。但是，如果发生这种情况，他们应该在相关的交换机端口上遇到错误。
操作系统配置在性能方面发挥作用的地方是 SMB，因为操作系统版本之间存在差异，操作系统配置可能会导致 Windows Server 2003 和 Windows Server 2008 无法很好地协同运行。但是，这与网络延迟无关，这是一种与您用于连接 SQL Server 的协议或可能用于 TCPing 的协议完全不同的协议。
答案3
问题出在硬件上，要么是硬件本身不足，要么是配置错误。问题出在第一层或第二层，要么是防火墙规则集，祝你好运。
当您从 IIS 服务器对 SQL 进行 TCP 连接时，请使用安装在 SQL 上的 wireshark 捕获流量。捕获所有内容，然后使用显示过滤器将其过滤掉。或者您可以执行捕获过滤器，例如：TCP 端口 1433，右键单击数据包并跟踪 TCP 流...
让你的 FW 管理员看看这个：http://support.microsoft.com/kb/968872
需要打开的端口不只是 1433，而且他们似乎不太擅长这个，在这种情况下，他们的规则集值得怀疑，应该阻止来自 DMZ 的 icmp 入口。不应该使用它。在您的工作站和 SQL 所在的核心内就可以了。我猜您的网络在逻辑上分为两层，一个是公共层，IIS 位于该层，另一个是核心层，SQL 位于该层。
所谓分段，是指子网还是 VLAN？如果是 VLAN，那么那里就有规则……您可以让“分段”对 TCP 1433 开放，而不是对 UDP 开放，或者您有一个 VLAN，其中缺少主机或不包含主机，而该主机应该位于另一个 VLAN 中。
您是否将操作系统配置为不执行计算机浏览器服务、WINS 等服务，以便它不会尝试通过 netbios 识别您的 SQL？这可能会减慢速度。
我会在您的 SQL 框上打开 wireshark 捕获，然后查看您看到的内容。您可以在实时捕获中关闭自动滚动数据包，这样它们就不会尖叫着飞过。让它捕获一些事务，然后停止它并使用显示过滤器进行深入研究，我认为可以像 tpc.port eq 1433 那样操作。捕获过滤器将是：端口 1433，这样可以获取该机器所属子网上所有发往和来自 1433 的协议。
您很可能会看到很多重传、重复确认和类似的东西。查看 ARP，看看是否正常，如果您看到 netbios 流量，请执行操作以在操作系统中将其关闭。例如在 IIS nic 上，您未选中 windows 客户端或在网络堆栈中共享文件，我忘记了具体是什么。您只需要 sql 和 IIS 之间的 TCP 和 UDP。没有 NetBT、NetBios 或其他任何东西。所有 DNS，没有 WINS 等...祝您的网络工作人员好运。