我问了一下 AI 给的结论是下面这个:

从你提供的 Wireshark 捕获数据中，我们可以观察到以下情况：

1. **TCP 三次握手和数据传输**：数据包显示了源 IP 地址 `192.168.102.200` 在端口 `8080` 和目的 IP 地址 `192.168.102.12` 在端口 `36850` 之间的 TCP 通信。数据包的序列号（ Seq ）在增加，表明数据正在被传输。

2. **重复确认（ Duplicate ACKs ）**：日志中出现了多个重复确认（例如 `[TCP Dup ACK 752#23]`），这通常意味着接收方（`192.168.102.12`）没有收到预期的数据包，因此它发送重复的确认来提示发送方（`192.168.102.200`）重传丢失的数据包。

3. **快速重传（ TCP Fast Retransmission ）**：数据包 `#819` 显示了一个快速重传，这表明发送方在收到三个或更多的重复确认后，重传了丢失的数据包。

4. **乱序数据包（ TCP Out-Of-Order ）**：数据包 `#775` 和 `#823` 显示了乱序的数据包，这意味着接收方收到了不是按顺序到达的数据包。

5. **大窗口大小**：发送方的窗口大小（ Win ）是 `30080`，这表明发送方有足够的接收缓冲区来接收数据。

6. **大的数据包大小**：一些数据包的长度（ Len ）相当大，例如 `2962` 和 `27578` 字节，这表明有大量的数据正在被传输。

7. **时间戳（ TSval 和 TSecr ）**：时间戳用于测量往返时间（ RTT ）和确保数据包的顺序。它们在数据包之间是一致的，表明通信是连续的。

8. **TCP 窗口缩放（ TCP Window Scaling ）**：数据包 `#847` 显示了一个非常大的窗口大小，这可能是使用了 TCP 窗口缩放选项。

从这些信息中，我们可以推断出可能存在网络延迟或丢包问题，导致接收方没有按预期收到数据包，因此发送了重复的确认。发送方随后执行了快速重传来尝试解决这个问题。乱序的数据包也可能表明网络中的延迟或重传问题。

要解决这个问题，你可能需要检查网络连接的质量，包括路由器、交换机和物理连接。此外，检查是否有网络拥塞或带宽限制也很重要。如果问题持续存在，可能需要进一步的网络诊断，包括使用 Wireshark 捕获更长时间的数据包来观察是否有持续的模式。

我用 tcpdump 导出了一下日志, 有大佬能给帮忙看下吗? 感激不尽
https://wwiq.lanzoue.com/ix6sE2c6rj9g

感谢大家回复,我来挨个试试 🤏🤏

@elechi #29 感谢 我看看

@Vitumoc 给我活的人,就是想卖钱的,他咋可能去采购呢 🤣🤣

@mengzhuo 嗯 不基于他们, 他们也是 C 写的打包成了系统, 我的软件是在 Linux4.9 上面跑, 就是使用 go 语言实现他们类似的功能,采集数据+告警+上报 就行了

@qq316107934 我的逻辑比较简单,就是采集数据,上报数据, 没有其他更复杂的逻辑, 想着应该够用吧

@hefish 我说嵌入式可能不准确,这个盒子厂家提供编译好的 Linux 系统, 我只要写软件跑在上面就行, 我的想法是, 解决我的软件与串口之间的通讯,以及如何将数据上报到数据中心(就是中国铁塔的 B 接口)就行了, 担心的点也就是会不会最后我写完了, 跑起来发现系统资源不够,毕竟才 128M 内存

我草, 没完没了了
[]( https://imgse.com/i/pAi6Ygs)

冷知识, 现在 Office 安装之后 不激活也不能编辑只能查看

本质就是通过 http 调用,至于你说的 VO,DTO 那些东西,可以放在 api 里面让其他服务依赖,也可以不放,调用方自己实现,反正最后都是会被序列化和反序列化的

另外可以不使用 OpenFeign, 实现一个纯 resttemplate 去调用服务,这样你就能理解的更深了

@dd0754 好东西 star 了

感谢各位大佬,问题解决了, vue 前端打包的时候要支持 部署二级目录

可以参考: https://www.cnblogs.com/architectforest/p/16241060.html
发现 V2 有类似问题,也可以参考: https://www.v2ex.com/t/1024262#reply14

20W