长文多图 看到一篇关于大陆跨境网速性能问题和 Great Bottleneck of China 的论文,翻译分享一下

2022-03-30 16:32:32 +08:00
 AlphaTauriHonda
今天在 ACM 期刊上看到一篇论文。墙内的跨国网络性能烂到和非洲最差的五个国家有得一拼。

Characterizing Transnational Internet Performance and the Great Bottleneck of China
论文 PDF https://dl.acm.org/doi/pdf/10.1145/3379479
网页摘要 https://dl.acm.org/doi/abs/10.1145/3379479
演讲视频 https://dl.acm.org/doi/10.1145/3393691.3394180
看演讲视频最直观最容易看懂


墙内的下载比非洲最差的几个国家(尼日利亚、南非、肯尼亚、加纳、埃及)差不多,上传却接近于其他不慢的国家。


墙内跨国网速慢的特征和非洲最慢的几个国家不同,有高峰期非常慢的规律。在慢的时候比埃及还慢不少,接近 0 。


研究者定义了一个低速时间。20 分钟内平均速度小于 1Mbps(我觉得等于不可用时间)。他们在墙内的测速点都有平均 5-17 小时的低速时间。

电信,联通,阿里,腾讯,清华教育网。com 指北京一个大型企业网,大概是电信吧。

下载最受欢迎网站的大文件测速。 每天有一半以上的低速时间。Apple.com 因为用了境内服务器,基本上没有低速时间。境内互联没有低速时间。

拿 M-Lab 的 NDT 测速研究结果交叉验证。墙内测速,7.5 万次中有 64%下载速度小于 500Kbps ,结果类似。

两端不同服务器低速的规律不同。(这个北京的家宽真可怜,每天大部分时间下行都是接近 0 )


对于不同协议,低速时间没有区别。


只有下行慢,境内互联不慢。慢的地方主要(>71%)在墙内(不在墙上)


研究者提到了 CN2 精品网和墙内跨国速度分配不均等。说 3 家国企运营商都有精品网络。(移动的我不知道,电信有 163 和 CN2 ,联通有 169 和 9929 )(论文里提到 CN2 第一次见)


了解低速的原因大概需要内幕消息,不管什么原因 Great Bottleneck of China 让境内的服务远远超过国际的,因为国际服务一天有一半的时间不可用。


最后给这个现象一个名字 Great Bottleneck of China
4065 次点击
所在节点    宽带症候群
18 条回复
wty
2022-03-30 17:01:28 +08:00
居然与协议无关。我自己的服务器,用 https 就只有几百或者几十 k ,http 就有几 M 。一直以为是 https 会被针对干扰来着。
Danswerme
2022-03-30 18:09:35 +08:00
记得本站之前有人发帖分析过,主要是原因是境外服务商无法在国内就近部署 CDN 以及出口带宽太少。
AlphaTauriHonda
2022-03-30 18:24:36 +08:00
@wty 有可能是触发了移动的干扰。这篇 ACM 论文里没有移动的测速点,所以你观察到的现象研究里没有出现。
阿里用 169 和 163 跨国,腾讯用 163 跨国,没有用移动的。

可以尝试联系作者,他们是这方面的专家。(有可能作者就在 V2EX 上)
AlphaTauriHonda
2022-03-30 18:29:44 +08:00
@Danswerme 论文里有写这个理论,人均出口带宽很小,我觉得这理论也很合理。
但是墙内跨国网速在全世界倒数前六,和尼日利亚、南非、肯尼亚、加纳、埃及一个水平,我真没想到。
看图表尼日利亚的表现还比大陆好一些,特别是低速表现,可用性上应该远超大陆了。
neiltroyer849
2022-03-30 20:21:32 +08:00
看了源论文设计的覆盖方向还是比较全的,但如果考虑更多的一些环境变量(比如审查诸如重放攻击探针干扰,加上协议类别比如 tcp 和 udp 应当有所不同)应该会更完善一些。另外运营商设计的人为 QoS 在同一张网上的表现应该也会天差地别;比如优化 163 和普通 163 的差别还是蛮明显的虽然跟 CN2 仍有所不同。而就算是 CN2 仍然不同 ip 段也不一样。另外考虑到移动的 CMI 在亚洲的资源优势和教育网与移动在南方的接入,没有讨论到移动感觉也是一个可以改进的点。毕竟据我所知国内大网里接 HKIX ,CMI 的带宽应该算是最可观的了,特别是 ipv6
neiltroyer849
2022-03-30 20:22:45 +08:00
另外进一步探讨 v6 和 v4 会不会有所不同也有点意思。毕竟从架构上 v6 似乎是有单独新出口的
CharlesGray
2022-03-30 20:38:15 +08:00
是不是为了让境内服务体验优于境外服务,我瞎猜的
datocp
2022-03-30 20:45:12 +08:00
这种事情,比如电信联通互联,它们要跑到省会城市完成中转。而且此时已经 50kb/s,根本没有墙的事。
再比如上海电信,访问某某知名 vps 的测速链接,直接丢来 N 个 tcp reset 。

问题变成为什么买的宽带不达标?现在电信借道移动专线,出国顺畅了。
AlphaTauriHonda
2022-03-31 00:56:13 +08:00
@datocp 境内互联没有这么烂,不会出现像跨国互联一样,每天绝大多数时间小于 4Mbps 。

论文中电信的(因为没有被审查的 HTTPS 都被 reset )无差别干扰应该算进 Great Bottleneck of China 。和低速时间相比是种更严重的人为拥塞,更适合 Great Bottleneck of China 这个大名了。
AlphaTauriHonda
2022-03-31 00:58:32 +08:00
@CharlesGray 是的,研究者排除了第一个猜想(因为审查的拥塞),倾向于你的猜想。
AlphaTauriHonda
2022-03-31 01:25:26 +08:00
@neiltroyer849 不同协议论文里有测试。发现不同协议的低速时间没有显著区别。

对于精品网络的跨国性能区别,在第 19 页开始有提到。测试了搬瓦工美国 GIA 和香港 PCCW 的丢包率。

但是由于比较难找到墙内的精品网,所以没有这方面的测试数据。研究者提前下结论 Great Bottleneck of China 影响所有的墙内网络。

在测试墙内低速时间时发现清华的教育网和天津联通的低速时间少,也发现腾讯云香港(当时就是 CN2 吧)在境外服务器中和墙内互联低速时间很短。得出结论香港的服务器适合代理,第 20 页举出了一些用香港服务器开代理或者服务墙内用户的例子。(其实香港没有专门优化的服务器互联速度很烂,他们找了香港腾讯云,以为香港都快)
AlphaTauriHonda
2022-03-31 01:36:28 +08:00
当时教育网还没有用 CMI 跨国。

我们相比研究者知道 Great Bottleneck of China 会更少影响墙内的精品网全是因为 V2EX 的 insider knowledge 。按照家庭用户来看,这个低速确实是普遍的。他们对于整个香港和墙内互联速度受 Bottleneck 的影响小是错误的,根据 insider knowledge 只有香港为墙内优化过的才快,只接入 NTT 的香港服务器肯定测试下来和其他地区的没区别。
flynaj
2022-03-31 09:06:52 +08:00
可能只是国家防火墙处理不过来,拖着速度了。
KoMAsS121
2022-04-05 00:15:44 +08:00
@flynaj GFW 不是说是旁路的嘛,旁路不是不拖速度的嘛。很多被检测出特征的协议,不也是开始能用,后面就慢慢被封 IP 或端口嘛,要是直接处理,那应该就不会有这种情况吧。不过我不是专业人士,瞎说的。
AlphaTauriHonda
2022-04-05 01:29:41 +08:00
@KoMAsS121 在旁路也要确保对于主链路检测的高成功率。成功率过低,会降低主链路的速度来弥补。

见论文 PDF https://www.cs.umd.edu/~dml/papers/backup_foci21.pdf
AlphaTauriHonda
2022-04-05 01:35:37 +08:00
@KoMAsS121 https://therecord.media/academics-discover-hidden-layer-in-chinas-great-firewall/

审查 HTTPS 的总成功率在 98%左右。如果太低了,审查者可能会要求降低 /不扩容跨国容量。
KoMAsS121
2022-04-06 19:38:06 +08:00
谢谢大佬解答。
chenxuhua
2022-07-22 18:07:52 +08:00

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

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

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

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

© 2021 V2EX