编写者

顾问组成员
阿里云

蒋江伟(小邪) 祝顺民(江鹤)

编写组成员
阿里云

孙成浩(梵叶) 李库(寒天) 宗志刚(瑄珉) 马卿(三卿) 谢伟光(秋光) 孙靖(铂昊) 王嘉杰(Jack) 殷俊(俊少) 谭礼铨(李泉) 潘志新(麟越) 楼燕华(陌弦) 赵炎强(炎强) 顾海东(汉凯) 王欣宇(道情) 周雪庭(亚来) 张大江(忆泉) 常磊(仙侠) 汤勇平(勇平) 郭天晨(霖初) 武晓冉(晓苒) 王佳琪(睿禹) 王勇猛(勇猛) 张红梅(茂漪)

法律声明

本文档的版权归阿里云所有，您应当通过阿里云网站或阿里云提供的

其他授权通道下载、获取本文档，且仅能用于自身的合法合规的业务

活动。

一、文档使用及更新说明

本文档仅作为用户使用阿里云产品及服务的参考性指引，阿里云以产品及服务的“现状”、“有缺陷”和“当前功能”的状态提供本文档。阿里云在现有技术的基础上尽最大努力提供相应的介绍及操作指引，但阿里云对本文档内容的准确性、完整性不作任何明示或暗示的保证。
由于产品版本升级、调整或其他原因，本文档内容有可能变更。阿里云保留在没有任何通知或者提示下，对本文档的内容进行修改的权利，并在阿里云授权通道中不时发布更新后的文档。您应当实时关注用户文档的版本变更，并通过阿里云授权渠道下载、获取最新版的用户文档。

二、知识产权声明

本文档中的材料和信息，包括但不限于文本、产品、图片、数据、档案、建议、资料，均由阿里云和/或其关联公司依法拥有其知识产权，包括但不限于商标权、专利权、著作权等。非经阿里云和/或其关联公司书面同意，任何人不得擅自使用、修改、复制、公开传播、改变、散布、发行或公开发表。

三、如何联系我们

您对本声明内容有任何疑问和意见，或者您发现本文档存在任何错误，您可以登录阿里云官网，点击首页下方“联系销售”与我们联系。

引言

随着互联网的发展，网络已经融入了整个社会发展的进程，如同血液

贯通人类文明的五脏六腑。一旦网络出现故障，将给社会的政治、经

济、文化造成重大损失。

2021年10月4日，Facebook在地球上”消失”了6小时，市值跌掉3000亿人民币，给客户造成的损失更无法估量。

2021年7月22日，Akamai的网络故障长达1小时，导致包括银行和航空公司在内的大量美国本土企业官网无法访问。

当前，国内很多行业企业在一带一路政策的指引下，都在积极布局国

际化和出海战略，向海外用户提供优质的产品和服务。公网作为企业

出海最关键的承载基础设施之一，其质量的好坏会直接影响应用(尤

其是互联网应用)的用户体验。

在这种大背景下，一个强有力的网络基础设施，将更加有利于国内出

海企业快速构建出有竞争力的服务。

本文基于用户体验，将云数据中心的公网质量从理论上拆解为多个可

量化的维度进行分析，再结合具体的实践，为国内企业出海提供理论

和实践方面的参考。

什么是云计算公网

我们可以做一个比较形象的比喻，云数据中心就像是一个大型购物中心，在这个购物中心中开设了各种类型的商铺(应用)，为了让顾客可以便捷的到商铺(应用)中购物消费，云厂商需要构建从顾客家到购物中心的高速公路(公网 )。

通过公网这个桥梁，最终用户和云上的应用联接了起来，让最终用户可以随时随地的享受云上应用提供的服务。得益于公网这个桥梁，云上应用可以实现实时在线，并且基于数据不断优化服务，提升用户体验。

云厂商的公网都是构建在互联网上面的，主要是从本地运营商、Tier 1和Tier2骨干网运营商购买直连线路，和互联网交换中心(Internet eXchange Point:IXP)拉通互联线路的方式构建出自己的公网。

整个公网系统分为云数据中心的出口网络，运营商网络和用户本地网

络三部分。

用户本地网络相对简单，主要是最后一公里的接入网络，包括家庭和

企业的固定接入网络和2G/3G/4G/5G移动接入网络。

数据中心出口网络负责将流量在不同线路上进行调度。

运营商网络是公网系统中最复杂的部分。经过多年的行业积累，我们

希望把一些运营商网络的经验分享给大家。

国内:相比其他国家，中国的互联网基础设施建设和运营商网络架构设计都比较先进，唯一的问题是中国电信，中国联通，中国移动这三大运营商之间互联的带宽不是特别大。为缓解互联带宽不足的问题，云厂商可以通过购买三大运营商的直连公网带宽的方式，为国内跨运营商用户提供比较好的服务。
欧美:互联网基础设施建设起步早，运营商之间的互联带宽比较大，虽然每个国家大大小小的运营商也比较多，但云厂商只要和该国几个大的Tier 1的运营商互联，就可以让该国大部分用户获得比较好的用户体验。
对于其它海外公网来讲，情况就会复杂很多。比如东南亚地区，印尼，泰国，越南，菲律宾等国的互联网基础设施建设相对落后，并且每个国家的运营商也很多，网络环境和网络架构相对复杂。例如，泰国国内移动运营商有5家，印尼国内较大的移动运营商就有 6家，越南有7家移动运营商。在这种复杂的网络环境下，云厂商要想构建出质量比较好的公网，相对于国内，在互联线路建设成本上和流量调度技术上面临着更大的挑战。

云计算公网质量与用户体验之间的关系

从一定程度上看，公网和交通系统是类似的。

在公路上跑的是汽车，在公网上跑的是数据包或称之为流量。公路有

早晚高峰，公网也存在潮汐和闲时忙时的现象。

公路会堵车，公网也会出现拥塞。

公路有普通道路和高速道路，公网也存在一般线路和精品线路。

在生活中，道路拥堵会造成很差的出行体验。同样，如果公网质量不好，对上层应用的使用体验会造成很大的影响。

在现实世界中，我们可以通过导航软件规避轻度的拥堵，而在虚拟世

界中，我们也可以通过上层协议的优化，来减缓轻度的公网拥塞。

但如果交通重度拥堵，那么再好的导航软件所起的作用也是有限的。同样，如果底层的网络质量很差，那么再好的协议优化算法也无济于事。

因此，提升底层基础设施的网络质量，将会显著优化上层的数据访问

和应用体验。

具体来说，公网的如下几个指标对上层应用的体验会产生直接影响。

1、可用性(Availability)

可用性(availability)一般为一个比率，指的是系统正常工作的时间/(系统正常工作的时间+系统不可用时间)。

可用性越高越好，可用性高代表的是正常工作的可用时间长，不可用

的故障时间短。

对于公网来讲，可用性是特别关键的一个指标，如果公网不可用了，那么应用大概率也就不可用了。近期比较大的网络不可用的事件包括:

2021年10月4日，Facebook在地球上消失了6小时，市值跌掉 3000亿人民币，给客户造成巨大损失。
2021年7月22日，Akamai的网络故障长达1小时，导致包括银行和航空公司等大量美国本土企业官网无法访问。
2020年8月30日，CenturyLink网络故障6个多小时导致全球流量骤减3.5%
2020年8月26日，新西兰证券交易所由于DDoS攻击关闭三天。

网络故障和具体的设备故障不同，单点的设备故障影响有限，

但网络一旦出故障，往往会导致大面积瘫痪，影响的范围很大。

对于重大的网络故障而言，可以总结为“天灾”和“人祸”。

“天灾”指的是一些不可抗力导致的网络故障，比如水灾，地震等自

然灾害导致数据中心机房受损。

“人祸”主要有几种情况，重大的网络故障往往是由于运维操作错误造成的，例如路由发布错误，DNS配置错误等等。还有就是遭到了恶意攻击，黑客攻击最常见的手段是发送大量数据包，让服务商不能正常提供服务。当然，也有可能是建筑施工时挖断了光缆。

可用性是影响用户体验最关键和最基础的一个指标。选择运维经验丰

富，变更管理流程专业的云厂商显得尤为重要。

对于公网的可用性指标，一般要求不低于99.95%，也就是一年中不可用时长不超过5小时。

2、时延(Latency)

时延，或者称为延时或延迟，这是大部分人都熟知的一个指标。比如 ping一下某个网站所需要的时间就是双向时延，即发送的报文从客户端到服务器，然后从服务器再返回客户端所需要的时间。

时延越短，说明获得服务的网络路径越短。

从应用层面看，不同的应用对时延的要求也不一样。

下面这个表是电信标准化组织总结的不同应用的端到端的双向时延的

量化需求。

简单来讲:

实时竞技类游戏的时延要求是50ms
实时交互类游戏的时延要求是100ms
实时交互语音类的时延要求是100ms
实时交互视频类的时延要求是150ms
非实时大部分互联网应用时延要求是300ms
工业自动化控制的时延要求是小于10ms
远程/遥控驾驶的时延要求是小于10ms
远程超声波检测的时延要求是小于10ms

大部分场景下，时延只要能在如上表格的范围内即可满足应用的体验需求。

如果时延不在上面的范围内，稍微大一些，比如高20%，其实大部分应用的用户体验产生的负面影响也不是特别大。

网络可用率比较高的情况下，真正对应用用户体验影响大的是丢包率

和抖动，这两个因素会给上层应用的处理产生很大的不确定性，进而

最终影响应用的用户体验。

3、丢包率(Packet Loss)

通过历史的经验数据看，公网的丢包率和用户的使用满意度是强相关的。

我们对日平均丢包率的一些经验是:

如果丢包率小于5%，用户体验基本满足需求，大部分用户不会对公网质量进行投诉。
如果丢包率大于10%，会对用户体验产生较大的影响，会引发较多用户对公网质量的工单投诉。
如果丢包率大于20%，会对用户业务造成较严重的负面影响，用户的业务甚至可能出现不可用现象，同时用户投诉量也会急剧上升。

从简单的实验上我们也可以看到，丢包率为1%时，TCP类应用完成一个具体任务从端到端的时延甚至会比无丢包时增加10倍。

具体的实验操作是在两台服务器之间通过FTP传输一个153MB的文件，两台服务器之间带宽设置为50Mbps。

在网卡上通过 Traffic Control 工具模拟网卡丢包。每种丢包率下做 5 次测试后，计算出丢包率、完成时间以及应用层带宽均值。

通过上面图表可以看出，应用层带宽随丢包率增加而急速下降。进而我们可以得出结论:丢包率对TCP类应用的影响是特别显著的，上层应用任务的完成时间随着丢包率的增加而显著增加。

此外从市场的选择看，丢包率也是企业客户十分看重的一个指标。

除了公网可以将用户和云上应用联接起来外，专线网络也可以将用户和云上应用联接起来。专线网络的最大特点就是物理带宽独享，极少出现拥塞，可以有效避免丢包率上升的问题。

这种和现实世界中的路面公共交通和轨道专用交通类似，在不堵车的

情况下，相同距离的情况下选择路面的汽车可能更快的到达目的地(

时延小)，但一旦堵车(拥塞)，则所花费的时间就会急剧上升。

整体上看，公网的丢包率是越小越好，最好在5%以内。

4、抖动(Jitter )

访问互联网如同游览一座城市，所谓条条大路通罗马，由于网络的两点之间往往存在多条路径，每条路径的底层线路长度不同，“路况” 也不同，这导致了网络时延并不是一条直线，而是存在着一定的波动，我们称之为网络抖动。

抖动对实时语音，竞技类游戏影响较大。

标准差方式的抖动定义

一般情况下，用时延偏离均值的大小来定义抖动。在统计学中，标准

差通常能有效的衡量样本中偏离均值的程度。

比如一小时有6个时延采样值分别是100ms，120ms，90ms，110m s，106ms，116ms。则均值为(100+120+90+110+106+116)/6= 107ms抖动为(((100-107)2 + (120-107)2 + (90-107)2 + (110- 107)2 + (106-107)2 + (116-107)2)/6)1/2 = 10ms

抖动会造成音视频类业务在呈现时出现忽快忽慢的现象，影响用户体验。实际上，对于实时音视频类应用，抖动现象造成的影响甚至比丢包还要严重。

一般情况下，抖动是可以通过应用层增加抖动缓存来缓解的，但抖动缓存也不能太大，太大会影响上层业务的实时性。

整体上看，网络抖动在一定程度上是网络路径不确定性的一种体现，网络如果存在不确定性则必然会增加上层应用的复杂性。

综合看，网络抖动是越小越好，最好是在50ms以内。

5、带宽(Bandwidth)

带宽是大家都很熟悉的一个概念，带宽越大，完成一个应用层任务所

花费的时间就越短。

一个中小型实时交互类的应用，在数据中心的公网带宽一般 100Mbps 左右就足够用了，当然带宽大一些会是更好的。

类似阿里云等TOP云厂商，云数据中心的公网出口带宽可以达到 Tbps或几十Tbps级。如此大体量的带宽给云上用户带来了超强的弹性能力，这种能力传统的线下IDC是难以企及的。

对于云数据中心的公网出口带宽来讲，公网带宽大都不会存在瓶颈，

所以一般情况下，不会因为带宽不足而影响应用的用户体验。

但涉及到应用层的端到端的带宽就可能没有那么充足了，有可能会现

带宽瓶颈，尤其是在涉及跨国和跨运营商的场景。

从上图可以看到，从用户到云数据中心中间的网络路径还是比较长的，包含用户本地网络，一个或多个运营商网络，最后才会到达云数据中心网络。其中，用户本地网络的出口带宽和数据中心网络的出口带宽一般情况下都不会存在太大的瓶颈。从多年的运维经验看，公网带宽的瓶颈是往往会出现在运营商之间的互联带宽，包括国内运营商间互联和跨国运营商之间的互联。

6、覆盖(Coverage)

对于云原生应用而言，其发布之初的目标就是覆盖一个或多个区域的

多个运营商内的用户。

比如一个云原生游戏应用部署在新加坡，其目标就是覆盖新加坡，马

来西亚，泰国，印度尼西亚等区域的玩家。

对于云厂商来讲，其网络覆盖的最终用户越多，云上应用的用户体验

就会越好。

覆盖能力一般用云厂商接入的线路数量来衡量。

云厂商与运营商建立的直连线路越多，则覆盖的运营商越多，进而可

以触达更多不同运营商网内的最终用户。

云厂商构建公网覆盖能力的方式一般分为直接覆盖和间接覆盖两种。直接覆盖:购买直连运营商的付费线路。间接覆盖:通过互联网交换中心IXP和运营商互联。

下表是我们整理出来的亚太区域和欧美区域的TOP运营商，这些 TOP运营商内的在网用户量一般都在百万到千万的数量级。对这些运营商覆盖的好坏程度会直接影响用户访问云上应用的体验。

7、云公网质量的的关键量化指标

应用层的目标是业务永续，永远在线。

想要实现这个终极目标，首先靠的是高可用、高可靠的公网来保障。高可用性和高可靠性是基础，在此基础上，广覆盖，大带宽，低时延，低丢包率，低抖动这些指标才有意义。

对用户而言，稳定性更强，确定性更高的公网才是好公网。

对于排名靠前的云厂商，可用性和可靠性以及大带宽基本上都不存在太大的问题。

在这个基础上，丢包率和时延两个指标对于企业选择云厂商和多种不同类型的公网产品选型就显得比较重要。

优秀:如果时延小于200ms，丢包率小于5%，这种质量的公网可以满足大部分应用的需求。我们把这种质量的公网划到优秀的级别中。

良好:如果时延大于200ms，丢包率小于5%，这种质量的公网表现会稍微差一些，但仍然是可以使用的。

不推荐:如果丢包率率大于5%，不管时延低还是高，对上层应用的影响都比较大，这种质量的公网是不推荐的。

云计算公网质量度量的方法

管理大师彼得克鲁克说过“你如果无法度量它，就无法管理它”。

对于公网质量也是如此，如果我们想要让云计算公网质量能变得更有竞争力，让上层应用获得更好的用户体验，那么必然要有一套科学的方法去量化和度量公网质量，之后才能去有效的提升和管理公网质量。

与点到点的物理专线不同，云计算的公网是一个海量多点到单点的模

型，即数以万计的海量终端用户访问某一个具体云上应用。

在这种庞大的通信模型下，用户体验的衡量标准和公网质量的量化标

准变得极具挑战性。在公网质量的量化中包括样本选取，测量方法，

结果分析以及最终测试结论的生成。

1、样本选取

由于云的特点是通过公网/Internet覆盖数以千万计的海量用户，在这种背景下，量化公网质量看起来是一个不可能完成的任务。

幸运的是统计学给我们提供了选样的科学统计方法，通过对有限样本的测评，也可以对总体得出比较准确的结论。

这种抽样进行统计的案例很多。

在进行产品用户体验调研中，400个高质量问卷就可以衡量出百万级用户规模的产品的使用体验。

在统计电视收视率时，300户的调研就可以获取一个千万级人口城市的收视率信息。

另外从统计学理论上看，如果总体数据呈正态分布，在一定的置信水平内，在一定的允许误差范围内，仅需要有限的几个采样样本就可以计算出来总体数据的均值，具体所需要采样样本的数量公式如下图。

其中 a为总体数据的标准差，E 为所能接受的误差范围。是在确定的置信水平查表得到的固定值，比如置信水平在95%该值为1.96。

比如如果能接受置信水平在95%，且误差能和总体数据标准差一样，最小需要1.96*1.96=3.84，即4个采样样本即可。

在上述理论支撑和行业实践经验基础上，通过选取样本和科学的算法即可量化出公网质量。

云上应用的服务模型如下图所示。

云上应用所覆盖的用户，实际上是分布在多个运营商中。每个运营商内部的用户，通过该运营商和云建立的通道访问云上应用。

从网络覆盖和网络质量的角度看，每个运营商内的用户可以看成是相

互独立的用户群，具有不同的特征。在通过抽样覆盖时，需要采用分

层抽样的理论，来覆盖不同运营商中的用户群。

例如，如果要度量北京市的云数据中心公网质量，则样本至少要覆盖

北京电信，北京联通，北京移动运营商内的用户，这样得出来的结果

才比较全面。

要获取比较全面的网络质量量化结果，需要包含目标区域内多个重要的运营商的样本，这是很明确和直观的结论。接下来的问题就是每个运营商内需要多少个采样样本。

一般情况下，有大样本和小样本两种思路。

大样本

大样本即通过数以万计的海量用户的应用层数据，如应用层访问日志，来度量应用的网络访问质量。这种方法由于用户数比较多，用户在目的区域的多个运营商网内都有分布，每个运营商都有充足的样本数据，运营商内头部与中长尾用都可以覆盖。在样本量足够大的情况下，理论上置信度是较高的，而且可以进行端到端的完整的网络质量的度量。

但问题是，这种方法中涉及的海量数据的获取成本和分析成本都比较高。一般情况下只有为数不多的超级APP才具备这种海量数据的获取和分析的能力。

小样本

对于大部分初创型的企业和中型企业，要想获取应用的网络质量覆盖情况，也可以采用小样本的方案。即在目标区域的重点运营商内找到探针节点，通过这些探针节点对应用进行网络质量探测。

根据统计学的抽样理论，个位数的随机抽样样本也可以获取比较好的统计结果，所以这种方式也是可行的。

而且，目前业界有多个商业公司提供这种拨测服务，所覆盖的运营商

也是比较全面的，也可以基于拨测结果生成多种维度的分析报告。整

体上看，这种方案的落地难度和成本相对大样本方案都是比较低的。

大样本和小样本的对比

2、度量

网络层度量指标
page22image39487936

云数据中心的公网质量的度量，简单来讲就是将质量量化为一个可观

测，可量化的指标。一般分为网络层的度量和应用层的度量。

网络层的度量相对简单，应用层的度量会更复杂一些。

对于云数据中心而言，上文提到带宽一般不是问题，所以一般情况下不需要对带宽做吞吐量测量。

对于网络层面的公网质量，时延和丢包率是两个基础的维度。

抖动可以通过时延数据计算出来的。可用性在一定程度上可以通过丢包率来计算。

应用层的度量指标

应用层程序一般非为两类，一类是TCP类应用，一类是UDP类应用。

TCP是面向连接的，构建出的应用可提供可靠的数据连接和传输服务。UDP是非面向连接的，支持构建出对实时性要求更高的应用。

对于应用层指标的度量，以TCP类的应用为例做简单的介绍。

TCP类最知名的应用应该是https了，对于https其网络过程包括域名解析，TCP握手，TLS握手，数据交互几部分。

业界一般用首屏打开时间的长短来量化https类的应用，也就是上面几部分的时延的总和再加上应用层等待时延。

应用层的性能指标一般是完成一项具体任务的时间长短。

如果网络层的指标较差，比如说时延高或丢包率高，则应用层的时延

指标也会变高很多。

除了看整体的首屏打开时间外，细节的指标还包括

1. 域名解析时间

2. TCP连接建立时间

3. TLS/SSL协商时间

4. 数据交互时间

应用层的性能指标要比网络层的要多很多，但可以肯定的是网络层指

标的好坏会直接影响应用层指标。

3、结果分析和监控

有了具体的云公网质量数据后，就可以通过量化的数据将云网络质量

进行有效的管理。

比较好的一个实践是基于历史的数据制定出质量的基线数据，比如具

体运营商的时延和丢包率的基线数据。一般情况下基线数据代表不会

影响用户体验的阈值。如果没有基线数据，可以基于自己业务特点将

阈值设置为经验值。

当前实时监控的时延或丢包率数据持续超过阈值数据时，此时应该注意应用的用户体验可能会受到影响。

通过主动的分析和监控，可以比较精细的分析到哪些运营商和哪些区

域的质量需要提升，进而可以达到实现主动管理用户体验的目的。

当发现具体的质量的薄弱点之后，就可以通过下面章节中的一些最佳

实践手段去有的放矢的优化网络质量，有效的提升用户体验。

云计算公网质量优化的最佳实践

1、可用性提升:冗余资源和高可靠机制

为了实现可用性的提升，要有冗余的资源和行之有效的故障切换机制。

冗余资源和高可靠机制

对于云数据中心的公网来讲，首先和每个运营商的互联带宽都至少是2根物理线路，这两跟物理线路之间互相备份，当一条线路故障后，可以将流量切换到另外一条线路上实现灾备和故障逃逸。一般情况下，每条线路的实际带宽利用率都不高于50%，以保证切换后业务流量也仍然能无丢包的收发。

其次，云数据中心还会和多个运营商互联并通过BGP协议交互路由信息。当一个运营商的两条物理线路都故障后，会通过BGP的路由收敛机制让到达云上的流量从另外一个无故障的运营商进入到云数据中心，对于出云数据中心方向流量也会被调度到无故障的运营商的线路上去。

最后，为了进一步提升可用性，大部分云数据中心还有多机房/多AZ 方案，将资源分布两个或多个地理位置不同的机房，避免火灾，水灾，断电等不可控的因素所带来的云数据中心可用性的下降。

感知—定位—恢复的高可靠机制闭环

感知:

主动感知:通过对海量路径组合的多协议探测，尝试发现网络连通性方面的异常。

被动感知:通过对海量日志、性能参数的采集和算法聚合，尝试发现网络自身行为的异常。

综合两个维度，最终实现对网络故障的快速发现。

定位和恢复:

通过智能算法快速定位故障节点，并计算得出潜在可用的冗余路径。对于可通过冗余路径切换恢复的故障，使用系统化能力执行快速恢复切换，进一步提升网络整体稳定性。

通过上述的资源冗余建设和流量灾备调度机制，云数据中心的公网产品的可用性一般至少可以达到99.95%的高可用性。

2、可用性提升:抗DDos攻击能力优化

DDos攻击会严重影响云上应用的可用性，是一种简单但强大的攻击方式。

举个简单的例子，一个小区的快递收发点，在正常情况下老板每天开

开心心的收快递，送快递。

突然有一天，一大卡车的空包快递突然堆到了快递收发点的门口，快

递点的老板大概率就“投降了”，快递点老板将没法处理任何正常的

快递收发业务。

对于需要收发快递的人来说，这个快递点是停止服务的状态。

针对云上应用的DDOS也很常见，截止目前，业界最大的攻击规模记录是2.4Tbps。

这就意味着云数据中心的抗DDos的能力要达到Tbps的水平。

要实现如此大规模的抗攻击能力并实现业务的持续在线，有两个方案:

1. 具备比攻击流量大数倍或数十倍的数据中心网络出口。

2. 另外一种方式是在识别出攻击流量后，通过IP任播技术将攻击流量引流到和云数

据中心物理位置不一样的高防处理中心进行攻击流量的清洗。

对于第一个方案来讲，建设成本比较高。但如果凭借多年的业务持续增长，云厂商的某些特大云数据中心出口带宽已经有很大规模的情况下，就天然具备了抗Tbps攻击流量的能力。

对第二个方案来讲，是一个比较通用的方案。

当云上产生超大规模攻击时，比如500Gbps的攻击流量，云数据中心内的安全组件会瞬间检测到攻击，并触发防攻击机制。

具体的防攻击机制就是高防机房放通更高优先级的路由，将被攻击IP 的流量“劫持”到高防机房，高防机房有超大带宽容量可以轻松“消化”Tbps的攻击流量。高防机房第二步会做流量清洗工作，将攻击流量丢弃，将正常流量识别出来并送回给云数据中心。

高防机房的带宽较云数据中心的带宽的等级要稍微低一些，但成本比较低，所以可以建到很高的容量，这样就可以抵御更高的攻击。

上面的方案对云上应用来讲时延和丢包率可能会有所上升，但业务的

可用性可以得到很好的保障。

需要说明的是:

对于规模比较小的DDOS攻击，如小于5Gbps的攻击流量，云厂商会为用户提供免费的安全防护和流量清洗。

对于规模比较大的DDOS攻击，如大于5Gbps的攻击流量，如果云上用户没有购买云厂商的安全防护产品，为避免对云上其他用户的影响，云厂商会把云上被攻击的公网IP流量拉入黑洞。如果云上用户购

买了云厂商的安全防护产品，云厂商会对攻击进行防护并对攻击流量进行清洗，将攻击流量过滤掉并将清洗后的流量回注到服务器。这样从应用层看来，攻击好像未发生，业务将不受任何影响。

3、减少拥塞和丢包:确定场景专项优化

对于一些比较确定的场景，比如国内的最终用户访问香港或新加坡的

一些金融类的云上应用，这种情况下如果不做任何优化的情况下，公

网质量是很差的。

对于网络质量的提升最核心的是找影响网络质量下降的最重要的点并

解决。

跨境公网质量差的主要原因是无直连回国公网线路导致的时延高，以

及普通的跨国线路拥塞严重导致的丢包率高。

在问题的根源定位清楚之后，解决方案就很简单了，可以在香港或新加坡的云数据中心购买国内运营商在香港和新加坡提供的精品直连回国的公网线路，比如最高端的中国电信精品网，中国联通的国际精品线路。

这种精品公网线路的拥塞要比普通线路的拥塞轻微的多。

当拥塞问题解决后，云数据中心的公网质量就会显著提升，应用的用

户体验也会明显提升。

上图是优化前和优化后的一个网络层时延和丢包率的对比，可以明显的看到:优化后的时延和丢包率较之前都有显著的下降。

4、降低时延:"一跳"入云

将实时交互类应用部署到离用户最近的物理位置，是最有效的降低时

延的方式。

比如如果一款实时竞技类游戏要重点提升菲律宾玩家间的用户体验，

那么最好的方式是把游戏服部署到菲律宾本地。

海外的网络环境要远比国内复杂，为了让海外的当地用户获得好的网络体验，除了在当地建设本地化的云数据中心外，还需要接入本地排名靠前的多家运营商，进而让本地大部分最终用户能在自己的运营商网内"一跳"访达云数据中心上的应用，减少因不必要的跨运营商绕行造成的时延上升。

以菲律宾为例，PDLT和Globe两大运营商覆盖了菲律宾90%以上的用户，云数据中心和这两个运营商建立直连公网线路，理论上可以让菲律宾的90%的用户通过自己所在的运营商就可以直接访问云数据中心上的应用，如果云数据中心和最终玩家在同一个城市的话，网络层的双向时延甚至可以控制在10ms以内。

5、降低时延:"一跳"入网

将应用部署到最靠近玩家的位置，是时延降低最有效的方式，但需要

本地有对应的计算资源，此外应用部署到本地需要花费一定的成本。

除此之外，把应用部署在一个核心节点，让玩家通过本地网络接入点接入网络后，以专线的方式回源到应用所在的源站，也是一个能有效降低实时交互类时延的方式。虽然时延降低的效果不如应用本地部署，但付出的成本较低。

将网络接入点通过专线的方式和应用的源站连接起来，可以有效的解

决跨国互联网线路的不稳定和不确定带来的时延不确定和丢包率不确

定的问题。

总结下来这种方式就是让用户"一跳"入网，就近接入，专线回源。

云厂商在POP点提供公网IP，让最终玩家可以通过该公网IP可以就近接入，并通过专线和云上的游戏服务器进行实时的交互，进而达到降低时延，提升最终玩家体验的效果。

6、降低时延:协议优化

在“一跳”入网的基础上，还可以通过协议优化的方式进一步降低玩家的交互时延。对于TCP类的应用，一次完整的典型交互包括:

1. 域名解析

2. TCP握手

3. SSL握手

4. 数据交互

域名解析是获取URL对应的后端的服务器的公网IP地址。 TCP握手是为了和应用服务器建立可靠的传输通道。

SSL/TLS握手完成https协议里加密传输的密钥的协商和Session ID的生成。在上述

过程完成后才能进行数据交互。

通过把网络层代理就近部署在靠近最终玩家的位置，可以实现

1. TCP的快速握手

2. SSL的快速握手

3. 数据的高效传输

引入代理后，让数据的交互从原来最终玩家和源站服务器直接交互变

为了:最终玩家和代理交互，代理再和源站应用服务器交互的模型。

在这个模型中，代理网关上可以通过协议优化技术实现时延的降低和

数据的更高效的传输。

比如面对高并发、短连接场景，在代理上可以实现快速的TCP和SSL 握手，并和源站应用服务器建立长连接的方式实现请求的快速响应。

此外代理到后端的应用服务器的路径是通过专用的最优路径算法计算

得出的，可以选取质量更高的链路进行更有保障更高效的数据传输。

7、智能运维的最佳实践

云网络质量相关问题和分层

对于云数据中心公网的问题，由于整个交互链条较长，造成问题和故障定位困难。

通过梳理业务交互流程和问题拆解，整体的责任域和故障域包括:

1. 最终用户本地网络责任域

2. 运营商责任域
3. 云数据中心责任域

最终用户本地网络中比较常见的问题包括手机终端或家庭路由器硬件问题和APP的软件问题;运营商的本地网络和骨干网络的问题;云数据中心内部则包括安全设备阻断，限速丢包，以及黑白名单，安全组配置错误等。整体上网络丢包，网络不通等问题的定位难度是较高的。在这种背景下，对云数据中心公网部分的高效智能运维的需求是特别强烈的。

云数据中心网络的智能诊断

对于云数据中心内部的网络问题，其中大部分是由于配置不当造成的。而这种配置错误通过人工的方式去检查和排查是十分耗时和低效的。提供能够快速排错的工具则显得尤为关键。

云厂商一般有指定任意一个实例进行一键诊断的能力，能够通过工具对这个实例进行体检一样的全面体检和诊断。可以通过一键诊断工具将可以将各种配置错误，状态异常检测出来，并且告知具体的修复建议。

运营商网络故障的主动通告

对于运营商责任域内的问题，包括

1. 预期内的运营商网络变更

2. 非预期内的运营商网络故障

针对运营商计划内的网络变更，云厂商都会对其用户进行主动告知，包括以官网公告，企业服务群，定向通知的方式通告。并且会有各种应对各种问题的预案。这类问题基本上都不会产生最终用户体验的下降。

但对于运营商侧非预期内的网络故障，则是比较有挑战的问题。按上述高可用性部分的描述，云厂商会监控和每个运营商互联的线路质量并采取对应的故障切换预案。对于这类问题，云厂商也会将事件和影响以公告，企业服务群，定向通知的方式告知客户。

此外也可以借助拨测产品部署在运营商中的探针实时探测到云上应用服务器的网络质量，并设置对应的告警阈值，实现主动感知和管理运营商网络到云网络侧的网络质量的目的。

最终用户本地网络责任域

对于最终用户本地网络和终端的问题的定位也特别有挑战。

一种方式是通过在APP的SDK中设置对应的检测功能，另外一种方式是通过排除法的方式在出问题后逐步排查。

目前看比较好的方式是将性能分析类产品集成到移动终端的SDK中实现网络性能的监控和问题的分析。如果没有在移动终端中集成对应的SDK分析工具就只能用排除法来排除问题了。

未来发展趋势

云数据中心公网的发展追寻着奥林匹克的精神——“更快，更高，更强”。

更高:越来越高的可靠性，让云上应用能永远在线，业务永续。

更快:更低时延、更大带宽，让云上应用和最终用户能实现更快的实时数据传输和业务交互。

更强:更智能、更易用的网络，让云上应用能借助先进的云网络智能化技术进而得到快速发展。

1、更高:业务永续的云网络

对于云数据中心的公网来说，可用性和可靠性是最基础的保障，也是

至关重要的，这就需要持续投入资源和人力进行提升。

从可用性的公式:可用性=正常工作的时间/(系统正常工作的时间+系统不可用时间)可以得到一个结论是要提升系统的可用性应该尽可能的降低系统不可用的时间。

降低系统不可用时间，一方面是需要采用更先进的自动化运维手段来减少或消除错误变更导致的故障，并快速发现和快速恢复故障;另外一方面，需要采用更先进的技术让整个系统的可用性更高，比如采用分布式部署提高容灾能力，进而可以抵御更极端的灾害和更猛烈的攻击。

2、更快:低时延和确定性的云网络

对于工业互联网，车联网等时延要求苛刻的业务，应用就近部署是降低时延的重要手段之一。如果再结合5G的低时延接入技术和切片技术，端到端的时延控制到10ms以内都是可行的。

3、更强:智能流量调度和路径优化

云厂商一般在全球有多个数据中心，每个数据中心都覆盖了多个本地

运营商和国际运营商，多个数据中心之间还通过专线进行互联。

通过这些分布在全球的资源构成了一张可以覆盖全球的网络。

这张网如果能够实现智能化，将大幅提升生产效率，产生巨大的经济

效益。

如果要实现网络业务的智能化，首先要在基础设施层面做到网络业务

的数字化，只有数字化之后才能够做到业务的感知。

在网络业务数字化之后，要实现业务数据化就需要能理解各项数字指标的含义和对上层应用的关联关系。比如丢包率5%以上就会对上层应用体验造成较严重的负面影响。

最后，通过各种自动化的流程和决策机制来实现网络业务的智能调度

和调优，为用户提供多维度的定制化网络服务。

云计算公网质量白皮书

编写者

顾问组成员 阿里云

编写组成员 阿里云

法律声明

一、文档使用及更新说明

二、知识产权声明

三、如何联系我们

目录

一. 引言

二. 什么是云计算公网

三. 云计算公网的质量和用户体验的关系

四. 云计算公网质量度量的科学方法

五. 云计算公网质量优化的最佳实践

六. 未来发展趋势

引言