☰

TCP 初始握手不完整（缺少 ACK）

tag-icon • tag-icon iis tcpip mikrotik mvc
TCP 初始握手不完整（缺少 ACK）

我对以下场景感到很恼火：

我正在运行MVC申请IIS 10 Web 服务器调用 URI 时，应用程序需要大约 10 秒钟才能开始被调用（空闲时间）。由于没有真正解释空闲时间的发生，我开始深入研究wireshark并偶然发现以下现象：

初始 TCP 握手不完整（缺少 ACK）

  1. 客户端 -> 服务器 (SYN)
  2. 服务器 -> 客户端 (SYN, ACK)
  3. 客户端 -> 服务器（ACK 永远不会到达服务器）

笔记：拓扑如下所述。客户端在第一个请求后重定向到服务器 2。客户端 -> 网关 -> 路由器 -> 服务器 1 -> 服务器 2

我在客户端和服务器端都使用了 wireshark。服务器重新发送了 SYN、ACK 元组两次，大约 10 秒的空闲时间后，连接仍然建立。查看相应的 RFC，此行为是正常的（ACK 是由客户端在发送数据时间接发送的）。ACK 从未到达路由器，那么它可能在哪里丢失？为什么每次都会丢失？可能是某个路由器（微克罗蒂克) 设置，例如无确认? 缺失的是确认10秒IDLE延迟的原因是什么？

编辑：

我编辑了上面的拓扑。您可以在下面找到 wireshark 跟踪：

由于 TraceWrangler 中的匿名化过程，IP 地址在不同跟踪中存在以下差异：

Client IP: 192.168.248.249 <=> 172.23.147.181 <=> 192.168.201.209 <=> 10.206.108.221
Router IP: 10.194.30.227 <=> 172.17.84.111
Server1 IP: 172.31.124.208 <=> 10.100.24.4
Server2 IP: 172.20.78.56 <=> 192.168.204.149

您可以使用以下过滤器来清楚地了解初次握手：

Filter Client: (((ip.dst ==192.168.248.249) && (ip.src ==10.194.30.227)) || ((ip.dst ==10.194.30.227) && (ip.src ==192.168.248.249))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)

Filter Router: (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)

Filter Server1: (((ip.dst ==172.31.124.208) && (ip.src ==192.168.201.209)) || ((ip.dst ==192.168.201.209) && (ip.src ==172.31.124.208)) || ((ip.dst ==172.31.124.208) && (ip.src ==172.20.78.56)) || ((ip.dst ==172.20.78.56) && (ip.src ==172.31.124.208))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)

Filter Server2: (((ip.dst ==10.100.24.4) && (ip.src ==10.206.108.221)) || ((ip.dst ==10.206.108.221) && (ip.src ==10.100.24.4)) || ((ip.dst ==10.100.24.4) && (ip.src ==192.168.204.149)) || ((ip.dst ==192.168.204.149) &&(ip.src ==10.100.24.4))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)

答案1

你不会相信，但问题在此期间得到了解决，我不太明白，为什么 RouterOS 中的以下更改可确保 ACK 不再丢失，并且应用程序可以快速加载，但我对此感到非常欣慰：在 RouterOS 路由列表中，网关 IP 作为 IP 地址输入，而不是接口名称/DNS 名称。

您对这个问题有什么解释吗？翻译/查找是否需要这么多秒，而在此期间 ACK 被忽略了？我一直觉得这一定是 RouterOS 的问题，但我不知道如何追踪它。我们的管理员正在处理路由器表，并要求我再次检查加载时间，这真是太巧了。这真的是唯一的变化吗？我能够在 wireshark 中确认，ACK 不再丢失。

编辑：

我下面导出了ip路由设置来查看路由的差异：

  • 工作：添加距离=1 dst-address=33.2.1.0/24 网关=33.2.4.1 pref-src=33.2.4.211
  • 旧状态：添加距离=1 dst-address=33.2.1.0/24 网关=ETH2 pref-src=33.2.4.211

网关没有在地址列表中明确定义，只有路由器：

  • 地址：33.2.4.211/24 | 网络：33.2.4.0 | 接口：ETH2

那么，从技术上讲发生了什么，延迟和丢失的 ACK 从何而来？

相关内容