有没有人留意过运营商策略丢包的情况？

负载高了之后，硬件设备自主丢弃低优先级的包吧，我瞎猜的。

有点看不懂入站还是出站，
不是限制速度而是丢弃?

一般对于 openwrt 来说。connmark 表会受 tcp/udp 消亡时间影响，目前自己设置的网络最高的一个是 600ms 。这些会导致并发数不断的累积，直到触碰到它的上限。这个上限，比如 256MB 的 erx 刚刚这个月从 16384 改为 32768 。这是路由硬件的限制，据说受制于内存。至于触碰到 ISP 的上限，那还是使用 4/8M ADSL 时。

网络不通确实会导致一些异常问题，比如内网一些 PLC 设备连接外部的 auth 网站，给它网络它的并发下降到 20 以内。不给它网络全部发起的是 dns 查询，竟然每 ip 高达 1400+查询并发出现在主路由 connmark 表上。最后只能在接入交换机上屏蔽。

即然你已经发现了，不同地级的人根本没有权限问这个问题。只能投诉，有用嘛?一般不会这么不聪明，有流量刚好匹配这个策略，会导致网络 100%丢包，这不是给自己找投诉。

600 秒。。。

华为，为了限制 PCDN 专门做了板卡，卖的挺贵的。

去年上半年的时候，电信的省公司买起来肉疼，想找开源方案。因为跨省结算，穷省本来薅羊毛，后来被反薅了

@jciba5n4y6u
上海电信一开始买不起板卡，只能搞一堆 X86 服务器 找开源方案做流量识别。

然而开源的 NAT1 没有高性能的方案，于是进小黑屋的统统送公网 IP 。

跨省结算开始之后这个现象还是蛮普遍的吧

四川电信有过，对某些政务云的某些机房有丢包。
当时我们的应用电信经常访问超时，但是同时我们用其他运营商的网络就没问题，所以排除了服务器上程序负载的问题。
然后我们进行了 tcp 抓包，发现确实手机发送了请求以后，服务器有时候都没收到。
但是电信这边工作人员一会儿派无线部门（手机信号），一会儿派宽带部门的人来，都没解决。后面我们只有在 app 端做重试+缓存来缓解用户体验。。。

上海移动的策略是，在这个时间段内压制上传速度，直接压到 1M 以下

而且很鸡贼的，周五到周日是放开的

呵呵！关于四川的丢包问题，以及省级互联互通限制，有快 3 年了吧？

没有🙂‍↔️

碰到过海外方向的，触发特定流量特征直接 ip 黑洞一段时间，ipv4 很严，ipv6 基本没有。至于国内的基本没有

@wtks1 这边是每天到点就开始压制，你的情况也是一样的吗？

@datocp 比如你在上传东西，但是上传 100%丢包，导致连接数暴涨，然后会话满了会导致你的出站也无法建立新连接。具象化的表现就是你会感觉你的网络越来越卡，直到最后 ping 不通公网，重置连接数会立即恢复。

@jciba5n4y6u SA 板卡是吧，反正最后都是华为赚，用户运营商一起受伤。

@AS58453 #12

是的，观测下来大约是周一到周四每天 18 点至 23 点半之间压制上传，周五到周日对应时段的限速时有时无，对单个地址无论开多少线程总上传速度恒定在 1M 以下，总体来说是每秒 500 到 800k 的样子，出了这个时间段就恢复满速，能从 ping 值上很明显看出来，限速时对目标地址 ping 高达 25 至 35ms ，而非限速状态都在 10ms 以下

@CodersZzz 他们在和你装傻，永远不把流程转到对应的部门，这种问题找省公司集客支撑就行，他们知道去看策略是不是有问题，当然，绝对不会给你承认有问题，怕被起诉

@xyz3210 对的，结算出来后问题就越来越严重了，最开始是温水煮青蛙，现在是直接魔怔了，就等着有人起诉。比较四川没有客户起诉过。他们也想倒逼集团公司取消结算。

@wtks1 看来和这边是同种类限制，可能就是 SA 板卡或者看起上传高了手工标记直接拉去流量清洗设备上弄出来的操作，这边就是到店了上传断崖式下跌，限速值没有一个恒定的值，都是动态的，一半不超过满速的 20%,然后时间过了就放开。

四川移动宽带我这里一到晚上京东 APP 点都点不动，让 AI 写了个脚本试了下，发现 ipv6 到京东线路有问题还是啥，我现在直接关了 ipv6 用单栈 ipv4 了

AI 了一下，认为是上传方向 syn tcp 重传导致的并发数暴涨。

解决方案包括设定，这些参数得小心测试，当年将一个参数有 65 降为 60 就影响 ios 的在线更新。

# 1. 扩大连接跟踪表上限，防止表满断网
sysctl -w net.netfilter.nf_conntrack_max=524288
sysctl -w net.netfilter.nf_conntrack_buckets=131072

# 2. 极致缩短建立连接和关闭连接的超时时间（单位：秒）
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent=10
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=10
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_fin_wait=15
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=15
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=15

# 3. 大幅缩短正常通行的 TCP 连接在无流量时的存活时间（默认 5 天，改为 10 分钟）
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600

# 4. 优化 TCP Keepalive 保活探测，死连接快速释放
sysctl -w net.ipv4.tcp_keepalive_time=180
sysctl -w net.ipv4.tcp_keepalive_intvl=10
sysctl -w net.ipv4.tcp_keepalive_probes=3

进行上传方向 syn 限制，limit 这个模块还是非常温和的，不会是那种断开的感觉

# 全局限制转发的 TCP SYN 并发速率
iptables -I FORWARD -p tcp --syn -m limit --limit 150/s --limit-burst 200 -j ACCEPT
# 超额的直接通过 tcp-reset 熔断，强制客户端释放连接
iptables -I FORWARD -p tcp --syn -j REJECT --reject-with tcp-reset

清空，从来没试过，也没必要
# 1. 假设丢包在晚上发生，在丢包期间的 20:30, 21:30, 22:30 分别暴力清空一次连接跟踪表
30 20,21,22 * * * conntrack -F

# 2. 在丢包预计结束的时间点（例如 23:05 ），彻底清空一次连接表，让网络瞬间满血复活
5 23 * * * conntrack -F


看起来对于 openwrt ，这些方法都是可以应用的。

应该优先测试 iptables limit+tcp-reset ，这个基本是秒级的断开连接回应。平时会这样给内网丢包。

-A BLOCK_CHECK -p tcp -j REJECT --reject-with tcp-reset
-A BLOCK_CHECK -j REJECT --reject-with icmp-net-unreachable

晚高峰有限制 估计是

@wy315700 不是买不起吧，应该是总师或者网发有人想练练手吧。

上海电信的 sdn 网关和云宽，真的一言难尽呢。

这个我研究过

坐标山东，前段时间腾讯会议感觉卡顿，双向的卡顿

丢包倒是不丢，但是延迟的波动很大。比如这一个包 30ms 的延迟，下一个直接干到 300 ，体验直接爆炸

而且这个只在 19 点-23 点这个区间里有

后来深入调查，是家里手机中的阿里系应用每天凌晨高速跑上传，能跑 4 个多 G 出去。路由器禁掉这个上传流量后，我再用腾讯会议就没这个问题。

我怀疑我的延迟波动是运营商针对我大上传量的精准 QOS

运营商都有各种 QOS 限制策略

19:33-22:06 分压制上传流量，这个时间段就是被 QOS 丢包了，外加移动就是烂的宽带，还经常超售宽带套餐，高峰期挂个游戏都会 连接超时 ，丢包