页面

分类

上海电信网络丢包数据分析

2015/8/14, by wingfire ; 分类: 计算机技术; 16 comments

作为上海电信的宽带用户,从14年年末开始,访问海外网站就开始不太稳定。我在Linode上本来有台虚拟主机,位于达拉斯的,主要是用来上上Google Play,免费听听Spotify什么的,当然也翻墙。但是不久网络就卡成翔了,不得已,转移到了Linode的东京机房。东京机房实际上很快,但是GFW水平更高。虽然我能通过东京的机器翻个墙什么的,但是看Youtube很卡。至于我怎么能确定是GFW搞的破坏,说来话长,就不展开了。

到了今年,尤其是5、6月份以后,访问东京机房,卡得不成样子,晚上根本无法访问国外网站,连个COC游戏,也没法好好玩了。ping了一下Linode的机器,发现晚间丢包率高达40%上下,早晨最好的时候也有7%~14%。mtr简单测试了一下网络,发现丢包是在上到电信骨干网之后,在到达日本侧路由之前。这中间做过多次测试,发现一些很有意思的地方。

  1. 一次拨号后,路由变动比较频繁。不同时间段traceroute路由,得到的结果不太一样,而且不像是负载均衡,因为偶尔见到某些路由绕道大半个中国。
  2. 拨号后得到的ip一般都在常用的地址段,但有时候会属于一个罕见的地址段,这些罕见地址的通信质量及其恶劣,国内的ping延时非常高,丢包率高达50%。具体数据当时忘记记录了。
  3. 上海范围内的电信宽带质量也有问题。两周前,我从松江(电信)ping徐汇电信宽带的ip,晚上的丢包率也高达24%,且rtt非常高,很大比例500和700以上的延时。这显然和海外站点没有关系。
  4. 电信宽带质量基础很好。不仅仅是rtt低,而且rtt标准差也非常低。差不多在最堵的时间段,访问东京linode机器,47.5ms的平均rtt,5.5ms的标准差,这种质量比我以前单位用的业务专线还要好,运维狗们先感受一下!

我于6月份向电信报修,师傅来家里看了一下,要求把宽带直接接在windows电脑上。因为我家里唯一的Windows是台式机,用的wifi,没拉网线,不方便直接接电信的光猫,就用Linux跑了一下mtr的测试。当时的测试数据也是没保存,但是和最近的倒也差别不大,将就看一下 。

表1,从国内访问国外:

mtr -n -c 100 --report 106.186.YYY.XXX

HOST: MyLinux Loss% Snt Last Avg Best Wrst StDev

1.|-- 114.88.204.1 0.0% 100 2.5 8.9 1.5 42.6 11.0

2.|-- 124.74.59.49 0.0% 100 2.5 2.0 1.4 6.0 0.7

3.|-- 124.74.209.173 0.0% 100 5.3 5.7 2.3 71.5 7.2

4.|-- 202.101.63.166 0.0% 100 5.8 5.7 2.2 46.3 5.8

5.|-- 202.97.33.158 92.0% 100 5.1 5.1 3.5 10.3 2.2 电信骨干网

6.|-- 202.97.35.26 92.0% 100 7.3 9.1 7.3 12.5 1.6 电信骨干网

7.|-- 202.97.61.77 49.0% 100 7.5 9.9 7.3 39.5 4.4 电信骨干网

8.|-- 203.181.102.41 39.0% 100 44.6 45.6 42.9 65.7 3.0 东京KDDI

9.|-- 106.187.3.33 36.0% 100 43.7 46.0 43.2 66.2 3.5

10.|-- 124.215.194.181 42.0% 100 56.8 51.6 44.0 61.1 4.5

11.|-- 124.215.199.126 54.0% 100 45.5 48.2 44.3 123.9 12.7

12.|-- 106.186.YYY.XXX 34.0% 100 45.4 46.1 45.1 50.6 0.9

(表1)

表2,从东京访问徐汇:

mtr -n -c 100 --report 114.88.205.213

Start: Fri Aug 7 09:21:04 2015

HOST: linuxserver Loss% Snt Last Avg Best Wrst StDev

1.|-- 106.187.33.3 0.0% 100 0.6 0.7 0.5 2.2 0.1

2.|-- 124.215.199.125 1.0% 100 11.9 5.8 0.4 16.3 4.5

3.|-- 124.215.194.177 0.0% 100 2.0 3.0 2.0 9.8 1.7

4.|-- 106.187.3.38 0.0% 100 1.5 1.6 1.5 3.6 0.2

5.|-- 203.181.102.42 0.0% 100 38.4 43.4 38.2 160.4 15.8 东京KDDI

6.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0

7.|-- 202.97.91.45 0.0% 100 41.2 40.4 38.3 45.3 1.1 电信骨干网

8.|-- 202.97.33.65 33.0% 100 47.3 47.2 43.9 60.1 2.6 电信骨干网

9.|-- 101.95.120.145 31.0% 100 68.5 47.1 44.8 68.5 2.8 电信骨干网

10.|-- 124.74.215.158 43.0% 100 45.0 45.1 44.3 48.4 0.6

11.|-- 124.74.59.50 35.0% 100 99.2 80.1 45.8 297.4 47.8 卢湾/徐汇区电信?

12.|-- 114.88.205.213 32.0% 100 46.1 47.5 45.0 75.1 5.5

表1数据显示,丢包主要发生在节点202.97.61.77之前(第7跳,中国电信侧),日本侧(第8跳,203.181.102.41起)之后增加的丢包率有限。表2数据显示,丢包发生在202.97.33.65(第8跳)及之后,则完全是在中国电信侧。注意,参照表1,第六跳应该是电信国际入口的路由。6月份的报修,电信是这么解释的:

“您好,非常抱歉给您带来不便。由于国际出口至海外节点部分方向访问繁忙,影响部分用户在繁忙时段访问某些海外站点的感知,且近期无扩容计划,敬请谅解。”

这是电话里念给我听的,所以记录可能不太准确。师傅还给我说什么“你懂的”,我还真以为我懂了。但是为什么说“近期无扩容计划”这么理直气壮的答复呢?你解决不了我的问题就赔我钱嘛,我也是个搞技术的,不会让你做技术上解决不了的事啊。所以,要么解决问题,要么赔钱!赔钱!赔钱!重要的事情说三遍。

之后因为忙,没有继续追究。到了最近,仍然没有好转。打算到工信部申诉,工信部要求先从通信投诉开始。那就先上电信网站投诉吧,同时,也在微博上@ 了中国电信和上海电信的客服。

电信投诉反应最快,当天就和我联系了,态度也很好。我远程mtr做了上面的报告,并且写明不接受“国际出口拥堵的解释”。第二天上午,周六,师傅就打电话给我,又是电话念一下结果,说是市局的回复说是徐汇某某节点到某某节点之间网络质量故障。我虽然觉得显然不是徐汇的问题,但是万一某骨干网路由就在徐汇境内呢?我又不知道内幕,姑且听之。和上次不同的是,这次说年底之前会完成扩容。我要求发一份处理结果的电子邮件给我,或者书面处理结果,那边就开始扯皮了,说什么“我只是口头的得到答复,也没拿到市局回复”来拖延。

周一下午,中国电信客服转的投诉也打电话过来了,但是声音不太清楚,但处理结论都一样,只是这次又说是8月底会扩容。真是见鬼了。到底哪个说的是靠谱的?昨天,上海电信客服在微博上私信回复了我:

“您好,非常抱歉给您带来不便。由于国际出口至海外节点部分方向访问繁忙,影响部分用户在繁忙时段访问某些海外站点的感知,中国电信上海公司正在积极协调进行链路扩容,但因涉及海外运营商、互联互通等众多因素和环节,解决该问题需要一定时间,敬请谅解”

我想,这也凑合可以作为电信的官方解释了吧,可以去上海经信委网站投诉了。传送门在这里: http://www.sheitc.gov.cn/wsbs/deptWeb_toZxtsLink.do?bean.menu=9

回顾一下上面的两张表。为什么我不认可电信丢包是因为国际出口拥堵的说法呢?首先,互联网上的路由器本来就是种尽力而为的工作模式,如果是出口拥堵,那么应该表现为出口最后一跳没足够能力转发,导致没发出去,或者发出去了,但是对端处理不了而丢弃。如果是前者,ping出口路由就可能导致高丢包率。如果是后者,ping出口路由的丢包率应该不高,因为这个过程还不涉及出口,ping国外第一跳应该丢包率高。

路由器的工作模式是存储转发,存储转发就意味着在路由器内部数据包还是需要队列的,也就会存在队列排队时间。在流量大的时候,在队列中排队时间会比较长,而实际测到的情况并非如此。几乎在所有情况下,rtt都相当稳定。这就说明流量并未影响到路由器的正常工作。那么,对于出口的包,在国际出口前就限速,丢掉一些,从而避免国际线路拥堵,不是合理的做法吗?我首先承认,在进入国际线路前,就把“超载”的流量选择性地丢掉一些,比到了国际线路再挤掉要合理。但是,这种行为叫什么?QoS啊!电信一方面保留了大量的传输能力,另一方面采用丢弃这一暴力的方式,减少进入国际出口的包流量。却遮遮掩掩,因为QoS就直说嘛,害我浪费那么多时间。

为了证明是不是QoS,我有做了一些试验。因为我不是什么vip,只好从流量类型上尝试。之前看过北邮方校长有篇综述论文,提到gfw的一个重点是流量特征分析,其中voip的流量是高优先级通过的。于是找来这篇文章:国际VoIP流量特征分析. 我写了个程序测试了一下。500字节以下均匀分布的包,发送速度每秒1000个,丢包率在十几,而选择一些特定长度的包如,77,82,106 byte,丢包率可以降到个位数,但是这些包的负载能力太弱了,用这么小的包收发数据并不特别快。真正让我惊讶的是TCP syn的丢包率, 0%!你要跟我说这不是QoS,那肯定是丢的包都被我吃了。注意,我说这些并不是否定用QoS限流。

我不去谈什么我不懂的商业和业务,只谈谈技术好了。既然国内全程都是走你电信的网络,这种“超额”出口数据包为什么要到出口节点前才丢弃?家庭宽带基本都是要拨号且限速的,在接入层路由器里面判断一下某个包的目的地是国外还是国内也是很容易的(因为无需很精确,几十条规则即可),只要在接入层路由(或者接入服务器)判断出是访问国外,然后限速就好了,这样大家都有得玩。上海电信一边叫出口拥堵,那为什么又要到骨干网上绕一圈,快出口了,然后才做丢包处理?是为了炫耀你电信骨干网的带宽吗?还有脸说总公司给的带宽不够?上海电信的技术人员都是吃屎的吗?说你们吃屎的别不服气,我从松江访问徐汇的机器质量差得令人发指,晚间丢包24%, rtt 700ms以上,stddev 超过200ms。要不是你上海电信的市场垄断地位,我看连屎都吃不上热乎的!


昨晚感觉到访问国外网站似乎很顺畅,今天上午测试到linode的机器,丢包率为0了。测试到github,msdn,debian.org,boost.org等网站,丢包率最差也都在5%以下了。松江的家里上上周换了了个路由器,现在的线路质量也比较稳定了。应该是扩容生效了?虽然之前闹得很不愉快,但是现在既然问题解决了,我还是要表示感谢一下,尤其是相关的技术人员。 -- 9/16/2015

评论

est, at 2015/8/18 上午7:49

沙发。微博 & v2ex 观光团。

dispensable, at 2015/8/18 上午8:48

微博观光团

这操蛋的网络让人恨死。

风间雨, at 2015/8/18 上午9:04

微博观光团 +1 因为这个问题年初只好加了条移动下的有线通... (好在有限通访问外网还行)

关关, at 2015/8/18 上午9:14

微博观光团

zy.liu, at 2015/8/18 上午10:47

微博观光团,手动点赞

一像素, at 2015/8/18 下午2:45

solidot观光团+1 成都电信一个鸟样

Lialosiu, at 2015/8/19 上午2:10

G+观光团来观摩

电信, at 2015/8/19 上午2:19

广州电信一样鸟速度,就是不让我们上国外网站而已。

gogo, at 2015/8/19 上午5:03

文章倒是有诚意,技术上完全是外行。很多东西从原理和思路上都是错的。

Steinhardt, at 2015/8/20 上午3:20

占位

Hugo, at 2015/8/23 上午6:10

觉得作者技术外行,原理和思路都是错的话,怎么不指出错在哪里?

否则,颇有洗地的嫌疑。

freperl, at 2015/8/23 上午6:51

同样东京主机,同样抽风掉包,声援!

gogo 滚犊子, at 2015/8/24 上午8:58

有个GOGO的话挺恶心,只想说GOGO 你行你来,不行别BB。

Joseph, at 2015/8/28 上午10:02

Guys, If you're looking for netflix unblocking for a specific country. Don't miss the chance. I have had real experience for unblocking netflix. I think this might help you a lot. Here you go http://www.vpncomparison.org/country/usa/

KeyboardError, at 2015/9/18 下午12:35

"幾乎在所有情況下,rtt都相當穩定。" --不知作者指的是IP層的rtt還是TCP層的rtt?對於出口流量,由於要經過網監系統過濾,不同層上的rtt表現有時會有明顯不同,作者最好能提供測試的數據和代碼。另外,我在八月份的時候曾經嘗試過將MTU調整為576,發現沒有任何改觀,這與你測試過程中採用小包獲得優秀聯通率的情況不相符合,不知你對此有何看法。最後感謝作者為我們提供了一種分析丟包原因的思路。

wingfire, at 2015/10/2 下午3:13

@KeyboardError, 所有情况是指mtr工具分别采用icmp,udp和tcp syn 探测对端主机。稳定是指rtt标准差很小。我贴出的数据表中StDev一列就是标准差。

对于数据包大小,特殊值是指77,82,106 byte这样的特定值,不是简单地降低。而且,我的文章解释了,“这些包的负载能力太弱了”。因此,即使你将MTU调整为我这里给出的值,也不会对TCP有所改善。

添加评论:

 
 the email would not displayed
 

您可以使用 Markdown 语法。

您必须启用浏览器的 JavaScript 功能才能发表评论。