昨天注意到 Cloudflare Radar 更新了 TCP RST 和 Timeout 的数据,于是我就找了整个🧱内和几个有代表性的 ASN ,来和美国宽带对比。

整个🧱内: https://radar.cloudflare.com/security-and-attacks/cn?dateRange=52w
电信: https://radar.cloudflare.com/security-and-attacks/as4134?dateRange=52w
联通: https://radar.cloudflare.com/security-and-attacks/as4837?dateRange=52w
移动: https://radar.cloudflare.com/security-and-attacks/as9808?dateRange=52w
教育: https://radar.cloudflare.com/security-and-attacks/as4538?dateRange=52w
科技: https://radar.cloudflare.com/security-and-attacks/as7497?dateRange=52w
上海电信: https://radar.cloudflare.com/security-and-attacks/as4812?dateRange=52w
上海联通: https://radar.cloudflare.com/security-and-attacks/as17621?dateRange=52w
上海移动: https://radar.cloudflare.com/security-and-attacks/as24400?dateRange=52w

美国: https://radar.cloudflare.com/security-and-attacks/us?dateRange=52w
Verizon: https://radar.cloudflare.com/security-and-attacks/as6167?dateRange=52w
https://radar.cloudflare.com/security-and-attacks/as701?dateRange=52w
AT&T: https://radar.cloudflare.com/security-and-attacks/as7018?dateRange=52w
RCN: https://radar.cloudflare.com/security-and-attacks/as6079?dateRange=52w

Cloudflare Blog 上的文章很值得一读,作者是 Luke Valenta 。
Luke ( https://lukevalenta.com/about )的见解: https://blog.cloudflare.com/tcp-resets-timeouts/ https://blog.cloudflare.com/connection-tampering/
Cloudflare Research:
https://files.research.cloudflare.com/publication/SundaraRaman2023.pdf

说说我对这些数据的看法。整个🧱内大约有 9%的 TCP 连接会在 Post PSH 阶段被 RST/Timeout ,然而 Post PSH 数据是被移动拉高的。电信和联通都在 5%左右,也就是大约 5%的 TCP 连接会因为 SNI 被 RST/Timeout 。这 5%中也有一部分是地方性的干扰或阻断,比如上海的电信和联通只有 3%的连接会触发 RST/Timeout ,同样教育网和科技网也在 2.5%左右。
移动是绝对的🧱中🧱,AS9808 有 17.5%的 Post PSH RST/Timeout ,上海移动有 14.3%,山东移动 AS24444 有 16.8%,广东移动 AS56040 有 15.4%,北京移动 AS56048 有 11.6%,浙江移动 AS56041 有 18.7%,辽宁移动 AS56044 有 16.5%。
然而最让我吃惊的是江苏移动和河南移动。AS56046 近期有 50%的 Post PSH ,AS24445 近期有 38.6%。江苏移动有一半的 TCP 连接触发了 SNI RST/Timeout ,并且有 80%的 TCP 连接被 RST/Timeout 。
也就是说,江苏移动只有 20%的 TCP 连接是正常的,What the hell is going on?
美国宽带的 Post PSH 数据大约在 0.5%上下,总共 RST/Timeout 大约是 10%,Verizon 的 Celluar Data ( AS6167 )会高一些,在 20%左右。

SNI RST/Timeout 只出现在没有被 DNS 污染或 DNS 污染失败的目标上,理论上这种 tampered TCP connections 不常见,但是 Cloudflare Radar 的数据表示阻断率不低。
举报· 58 次点击
登录 注册 站外分享
5 条回复  
la0wei 小成 2024-9-23 09:44:37
江苏移动宽带用起来就是这样,感觉被拿来做实验场
AlexPUBLIC 初学 2024-9-23 10:18:04
@la0wei 当年江苏移动的运维来处理了几次网络不稳定,直接跟我说,你办电信吧,我自己家用的是 x 套餐挺不错的
villivateur 小成 2024-9-23 10:28:28
这个数据是不是只能代表 cloudflare 的访问情况?最近似乎 CF 的链路被针对性劣化,其他的服务商可能还好。
june4 小成 2024-9-23 10:31:25
更可怕的是没听说江苏移动的人说有这种情况,网络遥遥 x 领先实体基本已经彻底脱钩了
XIU2 小成 2024-9-23 10:40:31
@villivateur 最早在 2022 年 5 月 24 日左右,我这边联通就遇到了针对 Cloudflare CDN IP 的 HTTPS 干扰(只要与 CF 的 IP 建立 HTTPS 连接,就有概率被阻断,IP 的 443 端口就会超时 3 分钟整),和 Steam 、Github 的 SNI 干扰比较类似(但他们两个这个是根据域名来超时 IP 的,不在乎是什么 IP 。而 Cloudflare 这个是针对其 CDN IP 的,暂时称为 IP 干扰吧)。

而在此之前,其实就已经有人陆续在我项目反应该问题了(可能有半年了?),只不过之前我这边联通一直没遇到过,我遇到之后自己简单检查并可以稳定复现确认问题后,就发了个 Issues 已经累计了两百多条讨论,很多人也表示遇到了。

另外,后来我也观测到 AWS CloudFront CDN 、Gcore CDN 、Fastly CDN 也出现了类似情况,不过相对较轻?时有时无的样子。
返回顶部