杭州移动、qos、上传相关疑问

[Bullpen3891]

第一帖就是求助贴。 宽带情况：4 月办理宽带，500/50 ，实测能跑 600/80 ，6 月接触 pt ，6 、7 两月上传跑了 20t+，8 月初刷到帖子杭移可以要到公网 v4 ，去尝试，顺利要到，截止 8 月底，pt 上传已达到 30t ，未接触过任何 pcdn 相关。 限速情况：8 月底突然被踢下线重新拨号一次换了个网段，一开始没太注意，过两天开始被限制，上传冗余取消最高只能跑到 50 ，且上传（测速、pt 、一切上传活动）速度越来越快伴随的高延迟丢包越来越严重，停止上传马上恢复正常，长时间上传跑满会被机房踢下线重新拨号，后续重新拨号回之前网段。 上网方式：光猫桥接，pve 底层 ikuai 虚拟机拨号。 尝试方法： 1 、之前要公网 ip 跟装维关系不错，再三帮我确认网络部对我没有任何限制。 2 、pt 开始限速上传，每个月只跑 2-3t 上传，未自动恢复 3 、测试光猫直接拨号，没有任何限制（测试次数少，不太确认），换普通硬路由拨号，限制依然存在，普通硬路由和 ikuai 分别克隆光猫 mac 地址拨号，限制依然存在 求助：看别人大多都是直接限速，然后上门签保证书解除的，我这种情况没搜到任何相关案例，没有麻烦装维上门查看，他也不太懂我搞的虚拟机拨号啥的，而且担心弄到最后公网 ip 被收回，现在就是一跑上传就被 qos 太难受了，宁愿被限速，想知道我这是触发了什么机制，应该怎么办

[Bullpen3891]

第一次发帖，格式好像乱掉了，对不起大佬们的眼睛，求耐心看完 orz

[djw123]

典型的 UDP 限速

[Bullpen3891]

@djw123 老哥，方便细说一下吗

[ZZ74]

OP 麻烦说下怎么拿到的公网 ipv4

[Bullpen3891]

@ZZ74 参考这个帖子，直接找装维说要 v4 远程访问 nas ，就给了，杭州萧山区，仅供参考 https://www.v2ex.com/t/1061036#reply62

[ZZ74]

@Bullpen3891 谢谢

[Bullpen3891]

@djw123 老哥，刚刚查了一下，speedtest 测速默认是使用 tcp 上传测速的，这种情况我还是 udp 限速吗

[peterli427]

同在杭州，分享两个信息，不一定相关。
1.国庆之前我自建的 cloudflare 域名优选节点非常稳定，国庆期间到现在，变得完全不可用，杭州移动家宽、联通商业普通宽带，均失效；杭州电信商业宽带、电信手机流量部分节点可用。据说是在搞反诈误杀了很多正常的流量。
2.国庆回杭州后，和朋友开黑打 cs2 ，完美世界平台，家宽移动网络下，上下行都丢包严重，电信手机开热点，上行偶尔丢包，下行稳定。

[FabricPath]

连接数限制，找一下连接数测试工具测试一下。

[Bullpen3891]

@FabricPath 之前有怀疑过相关，ikuai 里看连接数 1000 出头，就没去测试了，有看过说软路由里显示不准，夜晚回去再排查一下连接数相关的可能性

[Bullpen3891]

@peterli427 感谢分享

[xubeiyou]

@peterli427 移动打游戏就是这样的- - 所以虽然我现在不怎么玩游戏了 但是还是选的电信 有一说一电信确实贵很多

[renyi1986]

这个叫做 SA 科技板，很多人知道不说造成了很多人不懂不知道包括装维

[Bullpen3891]

@renyi1986 不懂的词越来越多了，搜了一下还是没看懂，大佬我这种情况有的救吗

[wtsamuel]

@peterli427 #8 我在上海和内蒙古玩的时候都遇到了，电信和移动都一样，cf 节点都不能用，只有开启 IPV6 时，才能连接

[FabricPath]

@Bullpen3891 ikuai 如果都只有 1000 多，那你连接数大概率被限制到 500 了。bras 的连接数限制是 lru 置换，你的 pt 一直在新建连接，所以你其他应用的 tcp 连接就被置换出去，就不通了

[peterli427]

@wtsamuel #15 湖南也是，北京、武汉目前正常

[peterli427]

@xubeiyou #12 就我实际体验，国庆前一直很好，这次感觉是上头有什么调整，墙再次增高，而且是优先稳定的丢包，不是以前因为移动线路烂偶尔丢包。

[Bullpen3891]

@FabricPath 老哥，刚刚跑了一个连接数测试的网站 https://qps.itzmx.com/ ，把 ikuai 里显示连接数跑到两万多，网络稳定未出现丢包可以正常打开网页，但是一跑上传就丢，这能说明什么吗

[FabricPath]

@Bullpen3891 他这个是一直在新建连接，并且新建之后就关闭了，对于 bras 来说，会直接靠 fin 或者 reset 释放连接，所以不会占用“连接数”。
ikuai 的连接数来自 netfilter 的 conntrack ，conntrack 的条目是靠报文触发创建，靠 timeout 来 gc ，他和 bras 的连接数没有必然关系。ikuai 的连接数主要来自下面这些超时时间；调大下面的 timeout 可以让 ikuai 的连接数显示得更大
$ sysctl -a |grep conntrack|grep timeout
net.netfilter.nf_conntrack_dccp_timeout_closereq = 64
net.netfilter.nf_conntrack_dccp_timeout_closing = 64
net.netfilter.nf_conntrack_dccp_timeout_open = 43200
net.netfilter.nf_conntrack_dccp_timeout_partopen = 480
net.netfilter.nf_conntrack_dccp_timeout_request = 240
net.netfilter.nf_conntrack_dccp_timeout_respond = 480
net.netfilter.nf_conntrack_dccp_timeout_timewait = 240
net.netfilter.nf_conntrack_frag6_timeout = 60
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_gre_timeout = 30
net.netfilter.nf_conntrack_gre_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_sctp_timeout_closed = 10
net.netfilter.nf_conntrack_sctp_timeout_cookie_echoed = 3
net.netfilter.nf_conntrack_sctp_timeout_cookie_wait = 3
net.netfilter.nf_conntrack_sctp_timeout_established = 432000
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_acked = 210
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_sent = 30
net.netfilter.nf_conntrack_sctp_timeout_shutdown_ack_sent = 3
net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0
net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 3600
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120

[FabricPath]

https://v2ex.com/t/972245 你看看这个，我没用过，但是他这个思路是正确的，要看能“稳定发送数据”的“长连接”数量

[tommytroy]

同杭移，500/50 之前实测 大约 650/100 。
8 月 21 日左右开始严格限速。50 出头上行 + 吃满上行后上下行均丢包。

我之前没改桥接，用光猫拨号的。只是进光猫把 ipv6 防火墙关闭了。

楼主确认下你改回光猫拨号就没有上行限制了？

感觉像是 bras 那边更新了限速模板之类的。

我这边和装维关系不好，要个桥接都不给。



我目前解决方法是桥接之后用 opnsense 流量整形严格限制在 55mbps 上行左右。跑满之后延迟没太大变化。继续用着了。

反正合同上也是 50 上。冗余没了我也没办法去挑毛病

[Bullpen3891]

@tommytroy 老哥平时上传跑得多吗，我也是 8 月底开始出现这个限速的，一个多月前我测试的是用光猫拨号就没限制了，现在还是换回路由器拨号了，不怎么跑上传，一跑就开始 qos ，你这个方法跑满上传能避免限制吗？我了解一下去

[tommytroy]

@Bullpen3891 多。满载时间至少 60%70%。

也不一定用 opnsense 。ikuai 应该也有流控。你摸索下最大上传到多少速度之后就开始丢包。。然后整体控一下

[dizhang]

杭州移动有没有什么携转进去的特惠吗，上海联通/电信携转到上海移动是三折套餐，比如 199 套餐打三折，60 元钱，60g+1000 分钟+1000m 宽带，杭州移动问了下好像没有类似活动，有也是两年期的那种，上海移动的话是永久的。

[tommytroy]

更新下。目前观察到的行为是

在完全满速上传时，

ONITOR: WAN_DHCP6 (Addr: down -> loss RTT: 3.4 ms RTTd: 1.0 ms Loss: 20.0 %)

[tommytroy]

手滑打出去了。

更新下。目前观察到的行为是

在完全满速上传时，opnsense 网关监控显示会有丢包。但是我实际 ping 网关。丢包率很少。

日志如下

WAN_PPPOE (Addr: 10.89.0.1 Alarm: loss -> none RTT: 1.7 ms RTTd: 0.2 ms Loss: 10.0 %)
WAN_DHCP6 (Addr: down -> loss RTT: 3.4 ms RTTd: 1.0 ms Loss: 20.0 %)

同时个人体感网络质量不高。直播等下行应用会出现卡顿。

在使用流控严格限制 wan 口流量到 49Mbit/s 上传后。问题消失。

像是移动启用了更严格的流量控制。超过阈值后直接随机丢包？