你 (192.168.0.164) 直接连接到交换机 (10.168.0.106) 你通过 SSH'in 进入，你得到 dup ACK 并重新传输......有些不对劲，似乎 Network Gremlins 饿了。

开关错误计数器显示什么？

另请注意，某些设备将进出控制平面的流量置于比数据平面更低的优先级。SSH 直接连接到交换机可能不会揭示您认为它揭示的问题。连接到交换机上的其他东西怎么样，您是否看到相同的症状？

我可能会将此作为评论发布，但这是我在 stackexchange 上的第一篇文章，它不会让我发布。

由于其交互性，ssh 不是测试性能的最佳应用程序。除非你说你看到角色回响给你的延迟。在不了解您使用 ssh 做什么的情况下，我注意到的事情是：

1. 一般来说，重传的次数不会困扰我。然而，这是您的笔记本电脑直接插入交换机而没有路由器或其他设备丢弃数据包的事实确实存在潜在问题。
2. 重传很奇怪。我查看的每个标记为重传的都在捕获中存在原始 TCP 段，即数据没有被丢弃。在某些情况下，您的笔记本电脑会确认该段，但交换机仍会重新传输。也许来自您的笔记本电脑的 ACK 被丢弃了。在其他情况下，交换机发送一个段，比如 50 个字节，然后在 10 毫秒左右的时间内再次发送它，但在有效载荷中包含更多数据，例如 100 个字节。这是重新打包并且很好。但是您的笔记本电脑还没有确认，并且交换机的重传超时时间为~10ms 是非常值得怀疑的。
3. 一开始，我以为你的交换机很忙，因为原始段和重传之间的IP ID差异很大。有时，您可以通过查看机器发送的连续数据包的 IP ID 差异来判断机器的繁忙程度。例如，您的笔记本电脑使用的是连续 IP ID，例如 1234、1235、1236。但是交换机的 IP ID 变化很大，我想它正在使用 IP ID 随机化。所以它可能不会疯狂忙碌。
4. 根据wireshark，来自交换机的一些ACK有以太网校验和错误。我不太精通以太网，所以我不知道它什么时候有校验和，什么时候没有，因为当我在 Wireshark 中检查它时，显然不是每一帧都有一个。有错误的是 0x00000000。所以从某种意义上说它是错误的，它使用了校验和但没有计算它。但是，如果校验和确实不正确，除非您在两个端点之间的线路上进行捕获，否则您将不会在捕获中看到该帧。

所以这些都不是根本原因，它们只是我注意到的事情。

展望未来，我建议：

1. 明确说明 ssh 的性能问题是什么。由于它是一个交互式应用程序，因此预计会有延迟。
2. 使用其他一些协议/应用程序进行测试并获取捕获信息。
3. 检查交换机是否存在该接口上的物理层问题。