我草,刚买的国补 mac mini m2 16+256 4799 妈的 如果加量不加价的话 我是不是亏了

Joplin

试试 云骏时代的 nat 机器 带宽大

最终结果, 线程开到 200 下载速度就到 1G 了, 太离谱了

但是具体原因还是没有深究出来, 稀里糊涂的就跑上去了

[]( https://imgse.com/i/pAYwcPU)

我问了一下 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)