V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  florentino  ›  全部回复第 1 页 / 共 7 页
回复总数  131
1  2  3  4  5  6  7  
14 小时 25 分钟前
回复了 Lisa9527 创建的主题 问与答 国补真的便宜了吗?
@mars2023 #134 所以啊 这种格局的 zf , 只能发发不痛不痒的消费券了
14 小时 45 分钟前
回复了 yuan321 创建的主题 Apple 刚刚看了新款的 mac mini 在京东上上架了,但是不支持国补
@zhaidoudou123 #44 没有 24 + 256 不开心
15 小时 2 分钟前
回复了 yuan321 创建的主题 Apple 刚刚看了新款的 mac mini 在京东上上架了,但是不支持国补
@zhaidoudou123 怎么买 在哪里买呀
15 小时 53 分钟前
回复了 Lisa9527 创建的主题 问与答 国补真的便宜了吗?
@mars2023 #112 而且 这些人本来就是需要钱的啊, 让他们存起来未尝不可
15 小时 54 分钟前
回复了 Lisa9527 创建的主题 问与答 国补真的便宜了吗?
@mars2023 #112 目的是促消费 那就降到 200,100 ,小水漫流就行
17 小时 23 分钟前
回复了 Lisa9527 创建的主题 问与答 国补真的便宜了吗?
@mars2023 #48 必须驳斥一下了,如果每个月发 5000, 你可能会存, 但是你每个月发 500,或者每周发 100, 我就不信会存,大部分人都是花掉 如果这点钱他都存 那说明他真的缺钱
嗷 我说贝贝今天怎么到不了 50 都是你们在砸啊, 还我贝贝
如果是代码托管 gitlab 很稳定的,而且数据丢失也不存在的 服务器找个文件夹定期打包代码,能解决 99.99%的数据丢失风险,除非你的服务器硬件炸了,不然很难丢失
1 天前
回复了 GeekGuru 创建的主题 Apple 听说今晚发售 M4 Mac mini 和 MacBook Pro
@Bingo1234 这我就不知道了 我是让我朋友帮我收的
2 天前
回复了 GeekGuru 创建的主题 Apple 听说今晚发售 M4 Mac mini 和 MacBook Pro
@jesuxe 北京,开模拟器领券, 然后找个北京熟人给你代收
2 天前
回复了 GeekGuru 创建的主题 Apple 听说今晚发售 M4 Mac mini 和 MacBook Pro
@GDance 沃日 幸好没拆 马上申请退货
2 天前
回复了 GeekGuru 创建的主题 Apple 听说今晚发售 M4 Mac mini 和 MacBook Pro
我草,刚买的国补 mac mini m2 16+256 4799 妈的 如果加量不加价的话 我是不是亏了
5 天前
回复了 zs3128589 创建的主题 macOS 求个 Mac 好用的 Markdown 软件
Joplin
15 天前
回复了 beryl 创建的主题 服务器 双十一,大家买服务器选择哪个?
试试 云骏时代的 nat 机器 带宽大
最终结果, 线程开到 200 下载速度就到 1G 了, 太离谱了

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

[![pAYwcPU.png]( https://s21.ax1x.com/2024/10/12/pAYwcPU.png)]( 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
感谢大家回复,我来挨个试试 🤏🤏
1  2  3  4  5  6  7  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1311 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 23:29 · PVG 07:29 · LAX 16:29 · JFK 19:29
Developed with CodeLauncher
♥ Do have faith in what you're doing.