TCP / IP传输速度的奇怪下降

网络工程 tcp
2022-02-08 07:11:58

免责声明:我是一名软件开发人员,所以这些低级的东西不是我的专业领域!我希望我在正确的 Stack Exchange 网站上回答这个问题。

我正在开发一个通过 TCP/IP 与硬件设备通信的 Windows 应用程序。该设备是一个 FPGA 板,我相信它运行 Linux。交互涉及 PC 向设备发送一个小的“请求”消息,该消息以大约 32kb 长的数据块进行响应。

到目前为止,我已经编写了一个非常基本的 PC 客户端来测试通信。我单击一个向 FPGA 发送请求的按钮,然后读回响应。整个过程(从单击按钮到接收整个 32kb 响应)通常需要大约 2-3 毫秒。我可以每隔一两秒点击一次按钮,时间将保持在这个水平。

但是我发现如果我开始更快地单击按钮(每秒几次),那么几秒钟后这个时间将下降到大约 12 毫秒。即使我放慢按钮点击速度,它也会保持在这个水平。如果我断开/重新连接客户端*,然后再试一次,时间会回到 2-3 毫秒的水平。(* 我只是关闭连接然后重新连接,我实际上并没有重新启动应用程序)。

我尽我所能确信这不是 PC 或 FPGA 上的软件,两者都非常简单。直觉是它是“协议”的东西吗?下面是 Wireshark 屏幕截图,显示了“快速”响应的痕迹,以及它下降到 12 毫秒时的痕迹。有什么想法吗?

在此处输入图像描述

在此处输入图像描述

1个回答

将在那里抛出一个部分答案。数据包跟踪显示,从您的 PC 向 FPGA 发送 ack 到 FPGA 开始发送更多流量大约需要 1 毫秒。第一个示例显示 FPGA 将更多字节“在飞行中”(在 ack 之前发送),这意味着 ACK 延迟损失只出现了两次。第二个示例显示每 2 个数据包后一个 ack,然后是 1ms 延迟。这很快加起来,因此在 32kb 传输结束时,10 个额外的 ack 将其减慢了大约 10ms。为什么 FPGA 更频繁地等待应答尚不清楚,但如果它是基于 Linux 的,则有控制窗口大小、缩放、并在内核中确认您可能应该尝试以获得更多确定性的行为(默认值通常会尝试通过观察延迟、缓冲区容量、丢弃的数据包等内容来自动调整网络条件)。如果您怀疑 PC 由于某种原因出现故障,您可以通过特定的注册表项控制 Windows 中的行为。要查看的另一件事是主机/客户端对 Nagle 算法的使用/效果。