我对 TCP 深度分析还不熟悉，我需要它来解决当前的问题。
连接：
- 客户端 = 主机 PC，Ubuntu 22.04.4 LTS（IP：...60）
- 交换机（tp-link 的 TL-SG1016D，Gbit）
- 服务器 = 专有嵌入式设备（IP：...61）（我们称之为ED)。ED 中有一个 BeagleBone Green V1.1。据我所知，它上面没有运行任何操作系统。所有嵌入式编程，高度时间关键的程序。
- Wireshark 在客户端运行，无法在服务器端捕获。
- 交换机已连接到我们 IT 网络的其余部分
软件：
- ED 供应商提供用于 PC<->ED 通信的 API。对于我来说，作为用户，对 TCP 堆栈的访问是隐藏的。
- 我在主机 PC 上运行了一个自己的软件，它在 ED 上执行各种程序。在这种情况下，它正在轮询一些数据，循环时间为 150 毫秒。每个轮询帧的段大小为 3 字节，每个答案的大小为 49 字节。
问题：
- 有时候，ED 不再做出反应。A 可以调用任何 API 函数，但它什么也不做。
- 调用 API 函数返回“全部正常”，没有错误/超时/任何内容。API 文档显示，有“无连接”或“传输错误”的返回值，我实际上可以通过在 ED 通信初始化期间拔掉电缆来触发这些返回值。（但我没有调用我在 Wireshark 日志中使用的那些函数）
我通过 Wireshark 进行的分析以及以粗体显示的问题：
- 一般来说，该端口上的流量并不大。
- RTT 非常低：小于 1 毫秒。
- 发生错误后，我仍然可以 ping ED，但那是 ICMP 而不是 TCP，对吗？所以我想这无关紧要。
- Wireshark 显示 ED 冻结的那一刻正是 TCP 级别发生不正常事情的时刻：
- 第 19 帧：常规通信的最后一帧。但是没有收到任何答复。
- 第 21 帧：根据我的轮询周期的下一个常规数据请求。
- 第 22 帧：ED 的回答：序列号显示似乎丢失了 1 个数据包（序列号为 148）。它确认了最后两个请求。很好。这种情况可能发生。
- 第 23 帧：主机向该帧发送 ACK，但带有最后一个 ACK（帧中没有 SACK 信息）。因此 Wireshark 将此标记为“重复 ACK”。我对此仍然满意。
- 事情就是这样的。ED 确认所有传入请求并正确回答它们。问题 1：但是，难道不应该重新传输未完成的数据包吗？这是否违反了 RFC9293？我认为有足够的时间。
- 然后，从第 92 帧开始，ED 将其答案更改为“零内容”... 好吧，这可能不是 TCP 问题。但是：问题2：为什么接下来的几个ACK没有被标记为“DUP ACK”？
- 然后通信就完全停止了。我猜这是 API 中的问题，因为我的软件一直在轮询。问题 3：这仍然是正确的 TCP 吗（意思是：连接仍然建立但没有流量）或者应该有 FIN 等？
