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

1 天前
 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 太难受了,宁愿被限速,想知道我这是触发了什么机制,应该怎么办

863 次点击
所在节点    宽带症候群
21 条回复
Bullpen3891
1 天前
第一次发帖,格式好像乱掉了,对不起大佬们的眼睛,求耐心看完 orz
djw123
1 天前
典型的 UDP 限速
Bullpen3891
1 天前
@djw123 老哥,方便细说一下吗
ZZ74
1 天前
OP 麻烦说下怎么拿到的公网 ipv4
Bullpen3891
1 天前
@ZZ74 参考这个帖子,直接找装维说要 v4 远程访问 nas ,就给了,杭州萧山区,仅供参考 https://www.v2ex.com/t/1061036#reply62
ZZ74
1 天前
@Bullpen3891 谢谢
Bullpen3891
1 天前
@djw123 老哥,刚刚查了一下,speedtest 测速默认是使用 tcp 上传测速的,这种情况我还是 udp 限速吗
peterli427
1 天前
同在杭州,分享两个信息,不一定相关。
1.国庆之前我自建的 cloudflare 域名优选节点非常稳定,国庆期间到现在,变得完全不可用,杭州移动家宽、联通商业普通宽带,均失效;杭州电信商业宽带、电信手机流量部分节点可用。据说是在搞反诈误杀了很多正常的流量。
2.国庆回杭州后,和朋友开黑打 cs2 ,完美世界平台,家宽移动网络下,上下行都丢包严重,电信手机开热点,上行偶尔丢包,下行稳定。
FabricPath
1 天前
连接数限制,找一下连接数测试工具测试一下。
Bullpen3891
1 天前
@FabricPath 之前有怀疑过相关,ikuai 里看连接数 1000 出头,就没去测试了,有看过说软路由里显示不准,夜晚回去再排查一下连接数相关的可能性
Bullpen3891
1 天前
@peterli427 感谢分享
xubeiyou
1 天前
@peterli427 移动打游戏就是这样的- - 所以虽然我现在不怎么玩游戏了 但是还是选的电信 有一说一电信确实贵很多
renyi1986
1 天前
这个叫做 SA 科技板,很多人知道不说造成了很多人不懂不知道包括装维
Bullpen3891
1 天前
@renyi1986 不懂的词越来越多了,搜了一下还是没看懂,大佬我这种情况有的救吗
wtsamuel
1 天前
@peterli427 #8 我在上海和内蒙古玩的时候都遇到了,电信和移动都一样,cf 节点都不能用,只有开启 IPV6 时,才能连接
FabricPath
1 天前
@Bullpen3891 ikuai 如果都只有 1000 多,那你连接数大概率被限制到 500 了。bras 的连接数限制是 lru 置换,你的 pt 一直在新建连接,所以你其他应用的 tcp 连接就被置换出去,就不通了
peterli427
1 天前
@wtsamuel #15 湖南也是,北京、武汉目前正常
peterli427
1 天前
@xubeiyou #12 就我实际体验,国庆前一直很好,这次感觉是上头有什么调整,墙再次增高,而且是优先稳定的丢包,不是以前因为移动线路烂偶尔丢包。
Bullpen3891
1 天前
@FabricPath 老哥,刚刚跑了一个连接数测试的网站 https://qps.itzmx.com/ ,把 ikuai 里显示连接数跑到两万多,网络稳定未出现丢包可以正常打开网页,但是一跑上传就丢,这能说明什么吗
FabricPath
1 天前
@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

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

https://www.v2ex.com/t/1080304

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

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

© 2021 V2EX