为什么开启 ipv6 就会有大量 tcp 重传,兄弟们也这样吗?

10 天前
 sartner
开启 ipv6 就会有大量 tcp 重传(有公网 v6 地址),卡的要死。关了 v6 就正常,几乎没有重传。

mtu 1492
mss 1360

测试方式:
curl -6 https://test.ipw.cn ,抓包
基本上 5 次里面就有 1 次大量重传。
兄弟们也这样吗?
武汉电信
2457 次点击
所在节点    宽带症候群
21 条回复
buf1024
10 天前
因为有针对 ipv6 的 tcp 阻断
Int100
10 天前
@buf1024 ?这么搞意义何在
heiher
10 天前
进一步降低 mtu 试试?
iijboom
10 天前
xqzr
10 天前
提供抓包截图/文件
liuyee
10 天前
同电信,一模一样,现在已经把 IPv6 关了
465456
10 天前
主路由 openwrt ,刚试了抓包,没问题
miaomiao888
10 天前
曾经遇过 IPV6 路由黑洞,原本用的很旧的路由器里有个 MTU 设置,改了也不行,后来怀疑这个设置应该只针对 IPV4 而对 IPV6 无效,最终换了个华硕路由器就没问题了。
xqzr
10 天前
> 原本用的很旧的路由器里有个 MTU 设置,改了也不行

正常的路由器都是这样
https://yangjunhui.monster/t/1125564?p=1#r_16144828
pagxir
10 天前
DNS 作下处理,IPv4 优先就好了。v6 目前路由还是不太行
c398425861
10 天前
开启 MSS 钳制
TonyBoney
10 天前
由于 ipv6 不能在中途分片,而且某些运营商会丢弃提示包过大的 ICMP 信息,导致了许多包石沉大海,最终连接失败。看看这篇 cloudflare 的博客文章,按照他们的测试结果不断调整自己的 mtu 和 mss ,直到连接正常,他们观察到 89.8%对端的 MTU 大于 1380+40=1420 ,75%的 MTU >= 1452:
https://blog.cloudflare.com/increasing-ipv6-mtu/
swananan
9 天前
tcp 重传会持续很久吗?给个复现的抓包看看?
理论上 TCP 协议栈早早支持了 https://datatracker.ietf.org/doc/html/rfc4821
所以哪怕有 ICMP 黑洞,也能依赖 TCP 数据段快速探测出来真实的 MTU ,然后自动调整
JensenQian
8 天前
上网的话直接屏蔽 ipv6 解析算了
sartner
8 天前
截图和抓包文件在这,实在没招了
https://github.com/Sartner/share/tree/main/20240428


@swananan
@xqzr
xqzr
8 天前
抓包文件只有,客户端发送(上行)包,反方向的(下行)包没有。
ping 会丢包吗?
sartner
8 天前
抱歉,刚又重新抓包重传了一下。 @xqzr
试了一下,ping 也丢
直接在主路由( ikuai )上 ping6 ,也丢

root:~# dig AAAA www.baidu.com
www.a.shifen.com. 493 IN AAAA 240e:ff:e020:99b:0:ff:b099:cff1

root:~# ping 240e:ff:e020:99b:0:ff:b099:cff1
PING 240e:ff:e020:99b:0:ff:b099:cff1(240e:ff:e020:99b:0:ff:b099:cff1) 56 data bytes
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=2 ttl=53 time=20.8 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=4 ttl=53 time=20.8 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=5 ttl=53 time=21.0 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=6 ttl=53 time=20.9 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=7 ttl=53 time=20.7 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=8 ttl=53 time=20.8 ms
64 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=11 ttl=53 time=20.8 ms
^C
--- 240e:ff:e020:99b:0:ff:b099:cff1 ping statistics ---
11 packets transmitted, 7 received, 36.3636% packet loss, time 10134ms
rtt min/avg/max/mdev = 20.724/20.842/21.036/0.095 ms

root:~# ping -s 1300 240e:ff:e020:99b:0:ff:b099:cff1
PING 240e:ff:e020:99b:0:ff:b099:cff1(240e:ff:e020:99b:0:ff:b099:cff1) 1300 data bytes
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=4 ttl=53 time=20.9 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=5 ttl=53 time=21.0 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=6 ttl=53 time=20.9 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=7 ttl=53 time=20.6 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=9 ttl=53 time=20.7 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=13 ttl=53 time=20.7 ms
1308 bytes from 240e:ff:e020:99b:0:ff:b099:cff1: icmp_seq=14 ttl=53 time=21.0 ms
^C
--- 240e:ff:e020:99b:0:ff:b099:cff1 ping statistics ---
14 packets transmitted, 7 received, 50% packet loss, time 13237ms
rtt min/avg/max/mdev = 20.640/20.834/21.045/0.148 ms
swananan
8 天前
看了抓包,我觉得不是 mtu 的问题,中间有丢包和乱序,但是对端最后都 ack 了,所以长度比较大的包(比如 1414 字节的)还是最终到了对端。

我更感觉是 ipv6 链路有问题,在主路由上面 ping6 也丢包,是不是主路由的网线松了(考虑到 ipv4 不受影响,感觉概率很低)。。。或者你再梳理下家里的网络拓扑线路,排除法看看哪个线路有问题。
xqzr
8 天前
运行 mtr
xqzr
7 天前
从外部运行 mtr ,显示从城域网开始丢包

目标:240e:368:20b:44c:e036:7a94:8c06:971a
Host % Sent Recv Best Avrg Wrst Last
2409:8080:0:2:306:372:: [中国 中国移动骨干网] 0 543 543 6 6 28 7
2409:8080:0:1:306:504:1:1 [中国 中国移动骨干网] 0 543 543 21 22 40 23
2409:8080:0:1:504:5e2:0:1 [中国 中国移动骨干网] 50 185 94 21 21 28 27
2409:8080:0:3:5e2:580:17:1 [中国 中国移动骨干网] 74 140 37 22 24 50 24
240e::d:5:5100:402 [中国 中国电信 163 骨干网] 1 539 538 22 23 50 23
240e:d:1001:f018::3 [中国 湖北省 武汉市 中国电信城域网] 58 168 72 0 26 30 27
240e:d:1001:fd2::3 [中国 湖北省 武汉市 中国电信城域网] 46 195 106 24 24 30 25
240e:368:20b:44c:e036:7a94:8c06:971a [中国 湖北省 武汉市 江汉区 中国电信公众宽带] 41 211 126 0 25 27 25

目标:240e:36d:304:3801::3ee
Host % Sent Recv Best Avrg Wrst Last
2409:8080:0:2:306:372:: [中国 中国移动骨干网] 1 283 282 6 6 20 7
2409:8080:0:1:306:504:0:1 [中国 中国移动骨干网] 0 287 287 25 26 36 26
2409:8080:0:1:504:5e2:0:1 [中国 中国移动骨干网] 87 66 9 21 21 24 22
2409:8080:0:3:5e1:581:0:1 [中国 中国移动骨干网] 68 78 25 0 27 28 27
240e::d:5:7100:302 [中国 中国电信 163 骨干网] 3 266 260 34 35 51 35
240e:d:1001:f024::3 [中国 湖北省 武汉市 中国电信城域网] 27 142 104 0 24 27 26
240e:d:1001:fd2::3 [中国 湖北省 武汉市 中国电信城域网] 50 98 49 24 24 27 25
240e:368:20b:44c:e036:7a94:8c06:971a [中国 湖北省 武汉市 江汉区 中国电信公众宽带] 44 106 60 24 25 28 25
Destination host unreachable. 100 61 0 0 0 0 0
Destination host unreachable. 100 62 0 0 0 0 0
Destination host unreachable. 100 62 0 0 0 0 0
Destination host unreachable. 100 61 0 0 0 0 0
Destination host unreachable. 100 61 0 0 0 0 0
Destination host unreachable. 100 61 0 0 0 0 0
Request timed out. 100 61 0 0 0 0 0
Request timed out. 100 61 0 0 0 0 0
Request timed out. 100 61 0 0 0 0 0
Request timed out. 100 62 0 0 0 0 0

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://yangjunhui.monster/t/1128196

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX