☰

TCP Dup ACK/重传，配置错误？

tag-icon • tag-icon networking tcp wireshark
TCP Dup ACK/重传，配置错误？

我目前正在调查朋友局域网的网络问题（再次）。互联网连接非常慢且不可靠，有时服务根本无法使用。

我使用 Wireshark 监控流量已有一段时间了。我终于发现了一个可重现的问题，一个不起作用的git pull程序。Wireshark 日志如下所示：sshgit pull

wireshark 日志

TCP 重传总是在密钥交换开始时开始。要么是服务器没有收到来自我的机器的数据包，要么是我的机器没有收到它的答案。我觉得这个问题的原因也是 LAN 所有其他网络问题的原因。

我想到的是，1514虽然设置了不分段位，但这里所有坏数据包的数据包长度为，但 LAN 路由器的 MTU 配置为1492。我无法将路由器的 MTU 配置为大于1500。数据包是否太大，以至于卡在路由器上？

此外，大多数安全连接（https，ssh）似乎都受到了影响，但这些连接也总是需要更大的数据包大小。

你看，我在网络方面没有太多的经验，所以我希望你们中一些更有经验的人能够更好地理解这一点。

编辑：刚才，git pull又正常工作了。MTU 配置不可能是导致问题的原因……

答案1

带有“不分段”标记的大数据包很正常。这就是操作系统执行 MTU 发现的方式 - 它不会让网络悄悄地分段数据包，而是期望返回 ICMP“需要分段”错误（这将具有正确的 MTU）。

如果您看到大数据包被重新传输，则意味着中间的某个路由器配置错误，要么阻止了 ICMP 错误数据包，要么在需要时不发送它们。

答案2

我认为发生了重复确认仅有的当接收方看到序列号中有间隙时，这意味着数据包在到达它的途中被丢弃了；因此问题从 192.168.0.8 到远程服务器的方向开始。尽管多次重新传输，但没有收到任何确认（甚至没有重复确认），这可能意味着该方向完全出了问题。（这可能意味着远程端无法发送，但这与之前的重复确认不一致，也与之后的 fin-ack 不一致。这意味着存在 2 个问题，而不是 1 个。）

以下是一些想法：

  • 如果连接是通过质量较差的公共 wifi 或 3G 进行的，那么您可能会在短时间内出现 100% 的数据包丢失。请同时使用其他服务进行检查，看看它是否也受到中断的影响。
  • 有些防火墙可以感知协议，它们可能需要一点时间才能弄清楚你在做什么，然后才决定丢弃特定连接上的数据包。你的朋友是否正在运行可以关闭的奇特防火墙？ISP 是否有一些使用规则？
  • 尝试更新驱动程序或从 Linux Live CD 启动，看看是否会发生同样的事情。尝试更改连接的其他方面，使用其他服务，以缩小错误范围。

相关内容