在上一篇文章“主流公有云产品功能性分析”中，我们对这些云主机厂商自身发布的功能性指标进行了一次简单的分析对比。而公有云主机的实际应用性能，还是无法从中进行体现。为此至顶网又策划了本次国内主流公有云主机的网络应用性能测试活动。在本次活动中，至顶网同样选择的是对阿里云、百度云、腾讯云和青云这几家主流云计算厂商的公有云产品进行评测。

 骨感的云主机网络应用性能评测

 网络应用性能测试，是通过模拟真实的网络应用请求，对网络产品的实际网络应用处理能力进行评测。通过网络应用测试，应该可以完全真实的评估出网络产品在现实应用中的实际应用情况。当前全球主流的网络应用性能测试仪表提供商，有思博伦和IXIA两家。

早在十几年前，这两个厂商就开始向网络及网络安全厂商提供网络应用性能的测试解决方案。当云计算、SDN/NFV技术兴起后，思博伦和IXIA公司也相应推出了针对虚拟化产品的网络应用性能测试产品。

在本次测试初期，也曾规划将他们推出的虚拟化网络应用测试工具安装到本次测试的云主机之中。（可参见“公有云主机网络应用性能公开测试方案”）从而可以对“应用请求处理速率”、“应用请求响应时延”、“并发用户数”、“应用流量”这些应用性能评估的关键指标进行最直接的评测。

 然而理想很丰满，现实太骨感。在经过了多次尝试之后，这两款软件在云主机上的安装还是以失败告终。无奈之下，只能退而求其次，采用在Linux上使用的Netperf工具完成本次测试工作。

云主机网络带宽性能

公有云网络应用，首先要考虑到的就是带宽。不同配置云主机，所能提供的网络数据转发能力，自然也就成了云主机网络应用测试的首选项目。

在本次测试中，至顶网将测试的重点放在了云主机的虚拟网络端口之上。

（无论是在公有还是私有的云计算系统之中，均离不开虚拟网络端口对应用数据进行转发。了解在不同配置下，云主机虚拟网络端口应用处理能力，以此作为基准，可以对整套云计算系统应用性能进行分析。）

本次测试中，针对目前Web应用中最常用的2核4G、4核8G和这几家公有云厂商不需要提交工单时可选择的最高配CPU核数云主机（核心数与内存比为1：2）进行了测试。

测试的数据包大小定在了64Byet、512Byte、1518Byte和不限数据包大小时最大数据缓冲的文件传输性能。

【附注：考虚到阿里云新建数据中心服务器采用25G网络互连，与其它厂家的万兆（10G）网络性能差距过大。为了公平起见，在本次测试中，未选择阿里云新建25G数据中心的云主机进行评测。】

云主机网络带宽测试结果如下：

云主机网络带宽测试结果线图

云主机网络带宽测试结果（Mbps）

 64Byte：腾讯云与青云不相伯仲，但测试结果存疑

 64Byte是RFC2544测试中所定义的最小测试包长。采用64Byte的包长进行测试，主要目的是来看一下不同配置云主机的数据包转发能力。

从上面的测试图表中我们可以看出，在64Byte网络带宽测试中，最好成绩为腾讯云4核8G云主机，传输带宽可以达到1115.11Mbps。最低为阿里云32核64G云主机，传输带宽为310.86Mbps。除阿里云外，其它三家云主机厂商的云主机64Byte小包的转发性能基本都在1Gbps左右。但这就产生了一个问题：

 数据包转发资源规划问题

 在云计算的虚拟网络之中，数据包的转发是依赖于CPU这个通用处理器进行处理的。然而作为一个通用处理器，CPU在处理数据包转发的时候，效率并不是很高。过高的数据包转发，对CPU的处理能力占用，非常可观。

然而通过随后的大包网络带宽测试可以了解，百度云、腾讯云、青云最高也就是2Gbps左右的水平。小包时如此高的转发性能，对计算资源造成的浪费相对较高。

为了对测试结果进行验证，我们又对阿里云、百度云、腾讯云、青云的虚拟网络端口重新测试并进行端口流量和数据包统计。

阿里云64Byte测试数据包统计截图

百度云64Byte测试数据包统计截图

 腾讯云64Byte测试数据包统计截图

青云64Byte测试数据包统计截图

通过虚拟端口数据包统计我们可以了解，64Byte文件传输中带宽最低的阿里云云主机的数据包转发速率反而最高，达到30万PPS左右。转发带宽最高的腾讯云主机的数据包转发速率只能列到第二位，转发速率在15.6万PPS左右。按照物理千兆带宽64Byte小包线速1.488MPPS（148.8万PPS）计算，除阿里云外，其它公有云厂商64Byte小文件数据传输带宽与其转发速率并不相符。

 问题分析

 实际上，当前的测试结果已经是至顶网第二次对这几家公有云主机进行测试而取得的。在第一次时，64Byet小包测试中，阿里云云主机也曾得到过1.1Gbps左右的测试成绩，但在向各家云主机厂商反馈测试结果时，阿里云就即刻指出，测试结果与阿里云云主机处理性能不符。

原因是为减轻虚拟网络数据转发负担，在数据包转发时，虚拟网络会自动对数据包进行合并（将TCP的较小数据包合并成一个大数据包后向目的地址发出）这样在进行小包测试时，就会出现这种“扩包”现象，一个小数据包被虚拟网络打成一个大数据包转发，因此虚拟网络传输时网络带宽自然就大大增加。

在UDP传输时，由于不带传输状态，所以UDP传输时不存在这种数据包归并现象，这一点同样可以在TCP与UDP的传输性能对比中加以佐证，在进行同样包长的虚拟网络性能测试中，TCP传输性能往往要好于UDP传输性能；而置于传统网络环境中，UDP的传输性能则会表现的更好。

然而考虑到在当前的网络环境下，数据传输还是以TCP协议为主，而UDP则更多的用于一些对网络传输可靠性要求不高的音、视频数据传输之中。因此，在本次测试中，还是选用了在TCP协议中的网络转发性能进行评估。

在本次测试中，我们试图通过Netperf加上-D参数（-D 参数的含义是：对本地与远端系统的socket设置TCP_NODELAY选项，其目的是快速准确发包），对这个问题进行规避。但是从当前的测试结果来看，除阿里云在测试中的转发速率与转发带宽相匹配外，其它云主机小包数据传输还有很明显的数据包合包（小包合并成大包）现象出现。因此在测试中，出现了64Bytes小包测试时数据包转发性能与传输带宽不匹配的情况。（有关转发速率与数据包合包的关系，至顶网还会再找个时间，更进一步去进行了解。）

  512Byte-Max：云主机网络带宽应当如何规划

 在虚拟网络中，云主机的网络带宽应当如何设置才会比较合理？为此，至顶网又分别对512Byte、1518Bytes以及虚拟网络可允许的最大数据缓冲文件传输性能进行了测试。

采用512Byte数据包长进行测试，是因为在以往传统网络及网络安全产品测试中发现，512Byte最接近实际网络应用中的平均数据包长（约700-800Byte）。用它测试，可以比较真实反映传统网络中实际的带宽处理能力。于是在虚拟网络测试中，还继续沿用了这个测试包长进行测试。但虚拟网络TCP传输具有合包现象、而且最大包长也和传统网络有所不同。因此虚拟网络平均包长还有待今后进行更多的虚拟网络应用分析来确定。期望那时候，可以得到更加明确的虚拟网络数据包转发速率实际应用情况。

从512Byet开始，这些云主机网络带宽性能明显分为两种类型：阿里云云主机与非阿里云云主机。

 阿里云

 从512Byte起，本次测试中的阿里云主机网络带宽就开始出现分层，2核4G云主机的网络带宽始终保持在1.1Gbps左右，4核8G云主机的网络带宽在1.6Gbps左右，而32核64G云主机在512Byte时在2Gbps左右（注：在本项测试中，只开启Netperf的单进程进行测试，导致测试压力的不足，小数据包流量有所下降），1518-Max时达到6.5Gbps左右。从当前测试结果来看，阿里云对不同配置的云主机网络带宽，进行了细致的划分，云主机的配置越高，分配的网络带宽也得到了相应的增长。

 从作者个人角度来看，拖服务器后腿最严重的，实际上要数网络带宽。早在03、04年的时候，本人开始对服务器的网络应用能力进行测试，那个时候千兆网络接口就已经出现了。而到现如今，服务器的处理器无论是从主频，还是从处理器核数上，都有了飞速的增长，而千兆的网络接口却依然雷打不动的固化在服务器之上。在作者看来，网络传输能力与应用处理性能的不匹配是间接推动服务器虚拟化，乃至于目前云计算技术发展的一个重要原因……

能力越大，责任也就越大。如果用户云主机主要是进行Web类应用处理的时候，云主机的计算能力越高，所需要的网络带宽自然也需要相应的增加。这样一来也就不难理解阿里云云主机的网络带宽，在不同的配置之下也会有所不同的原因了。至于这个带宽配置是否合理，在接下来的应用连接性能测试中，我们至顶网还会更进一步的去进行分析。

（*有关阿里云32核云主机的网络带宽在512Bytes时，仅达到了2Gbps的问题，我们会在下面“多队列网卡与单进程测试”的技术分析时会再详细进行分析。）

  百度云、腾讯云、青云

之所以将其它三家云主机厂商放到一起进行分析，是因为从512Bytes起，这些云主机厂商不同配置的云主机网络带宽就基本处于“一个水平线”上，基本都在1Gbps到2Gbps之间徘徊。

实际上在第一次对云主机网络性能测试的时候，百度云云主机的网络带宽是呈现全放开的一种状态，各种配置云主机的最大网络带宽均可以达到5Gbps以上。但是当第一次结果反馈回去之后，现在已经迅速将网络带宽调整到了950Mbps左右。

 百度云云主机第一次网络带宽测试结果

 上面谈到过，更高性能的云主机，需要有更高的网络带宽对其应用进行保障。但百度云、腾讯云和青云并未向云主机提供更高的网络带宽是出于什么样的考虑呢？在这里想对云主机网络带宽设置，更进一步的来讨论一下：

还是以目前常见的Web应用为例，在目前的云计算系统中，要想对大流量、高并发的网络应用请求进行处理的时候，通常是采用负载均衡的方式，将应用请求平均分配到多个云主机上分别进行处理。在具有多个计算核心的云主机内部也是一样，需要将应用请求分发到每个计算核心之上，才可以将多核云主机的处理能力充分的发挥出来。

是通过一条高带宽的虚拟网络将应用请求发送到一个高处理能力的多核云主机上进行处理？还是通过多条较低带宽的虚拟网络，将应用请求分发到多个处理能力较低的云主机上通过负载均衡的方式处理？这个问题还需要根据具体的应用需求去具体的分析。

相对来说，经过多年技术发展完善的负载均衡技术，在网络传输稳定性和可靠性方面都有很好的技术保障。如果用户应用的计算量并不是很大的话，通过负载均衡将访问流量分配到较低配置和带宽的云主机上，在技术可行性上会更加的适宜。

当然，像腾讯云32核心64G内存云主机配置下，还只为云主机配置1Gbps左右的带宽，是为了解决什么应用需求，还需要更进一步去研究一下。

此外，由于青云高配置云主机需要另外提交“工单”进行配置，与此次想对各厂家云主机“本色”进行测试的目标不符，因此未进行测试。

 多队列网卡与单进程测试

在上面的结果分析中，还有一个细节没有分析到，那就是选测的青云云主机虽然只有两种配置，确有4个测试成绩，其中两个标注了“多网卡”。

这里的“多网卡”全称应是“多队列网卡”：多队列网卡技术，最初是用来解决网络IO QoS （quality of service）问题的，后来随着网络IO带宽的不断提升，单核CPU不能完全满足网卡的需求，通过多队列网卡驱动的支持，将各个队列通过中断绑定到不同的核上，以满足网卡的需求。

在青云通过控制台创建云主机的时候，可以很轻易的通过点选“网卡多队列”选项的方式，对多队列网卡功能进行应用。

 可是从当前对青云云主机的测试结果来看，青云云主机在加载多队列网卡功能后，64Byte小包带宽提升有限，但大包网络带宽反而受到了影响。

 初步分析，这是由于Netperf这个测试命令在测试过程中，只打开了一个进程，因此无法将数据转发请求平均分配到多个网卡上进行处理的原因。但是当我们准备加大测试时长，并开启多个Netperf进程进行测试的时候，却被青云的网络安全策略所拦阻，无法继续进行评测。

多进程——来自阿里的复测

 在第一次测试结束后，我们曾将结果发给这几家云计算厂商进行确认。没想到很快阿里方面就传来了反馈“测试方法不能反映阿里云云主机采用多队列网卡技术后的最大性能，并愿意提供阿里内部测试方法进行复测”。可以接触到更多评测技术，当然是我们至顶网所喜闻乐见的一个事情，于是又开始了一次针对阿里云32核64G内存云主机网络带宽和连接的复测活动。

原本我们考虑到多线程问题，也曾经尝试启用多个云主机并使用iperf测试工具来对网络带宽进行测试，然而这样测试的结果统计问题并没有很好的得到解决。因此这种测试的成绩也未对外放出。而且由于是在公有云上进行测试，在现网环境中进行性能测试，更需要小心翼翼，即便是在一个VPC网络内部，也怕会对公有云网络造成什么不良的影响。

 可阿里提供的测试方案要激进的多，通过编写脚本起100个netperf测试线程，在200秒的测试时间内，同时对被测端进行测试。而结果统计是通过查看被测端口流量的方式。

Netperf单字节TCP转发性能测试虚拟端口数据包速率统计

Netperf单字节UDP转发性能测试虚拟端口数据包速率统计

为了方便直观的对数据包转发性能进行统计，在本项测试中，将数据包转发速率的测试字节大小定在了1Byte，通过被测端口数据包转发统计可以了解，阿里云32核64G云主机虚拟网络端口的TCP转发性能平均在2.2Mpps以上，UDP的数据包转发性能更可以提升至2.5Mpps。这样的转发性能基本上可以满足64Byte小包接近2G带宽的数据转发需求。以此推断，在256Byte就可以满足8G网络带宽数据传输。阿里云32核64G云主机的网络带宽限制是在6.5Gbps（在上面不同云主机网络带宽测试中已经验证，就不再重复测试了）左右来分析，其可以提供充足的数据包转发能力满足网络数据传输需求。

通过这个测试，也让我们对阿里云的虚拟网络，在高转发速率下的网络健壮性，有了更加充分的体验。

云主机网络连接能力评估

 当前云计算网络系统，是基于软件定义网络（SDN）进行的“转发”与“控制”分离。对于上述几个公有云的云主机转发能力，通过网络带宽我们已经有了一个大致的了解。而控制能力还需要去更进一步进行研究。

 对于“控制”而言，实际上就是在带宽这条大马路上划出一条条行车的车道。车道太少，需要上路的车都要排队，会影响传输效率。车道太多，马路上车辆拥挤，同样会对网络传输造成不良的影响。

 当前这几个云厂商的网络控制能力如何？至顶网通过云主机的网络连接建立能力同样进行了一次检测。

 在测试中，至顶网选用的是Netperf加载TCP_RR和TCP_CRR参数，对云主机的网络连接能力进行测试。为了了解在不同文件大小情况下，云主机的连接建立情况，本次测试还将本地和远端系统的Socket发送与接收缓冲大小分别设置为64Bytes、1024Byte、10240Byte、102400Byte以及1024000Byte。

 首先要来谈一下的是Netperf测试所存在的问题：各厂商云主机配置不同，网络连接测试的成绩十分相近。在大文件应用传输时，如果网络带宽相同，受到带宽的限制，云主机的网络连接测试成绩相近这很好理解。但是不同配置不同带宽的云主机，网络连接性能如此相近就只能说明一件事情：应用请求没有平均分配到各个计算核心上去。这个测试所体现的，很有可能只是单个CPU内核的网络应用处理能力。

 即便是单个核心，也不妨碍我们去对这个云主机的网络连接处理情况进行一下分析。下面我们就去具体的分析一下：

 Netperf加载TCP_RR参数测试

同带宽测试一样，在应用连接中，64Byte的数据传输也是属于“神话”这个级别——只会在传说中存在，在实际应用中用户是万万不可能见到的。（如果真出现的话，那就是CC或DDoS了。）之所以64Byte甚至1Byte的应用连接测试至今还在使用，是因为通过对作为TCP/IP定义的最小包长测试，可以了解产品的最大处理性能。在网络带宽的测试中，了解的是数据包转发的处理能力。而在连接性能测试中，同样也可以对网络连接建立能力进行评估。并且由于连接建立通常是交由CPU进行处理，因此在网络应用性能测试中，最大连接处理能力，同样也是对服务器网络应用计算能力的一项重要评估。

现在我们就通过Netperf加载TCP_RR和TCP_CRR参数来了解一下这几个云主机“疑似”单核的最大网络连接处理性能。

为什么说是“疑似”单核，是因为测试结果有些让人困惑。首先看连接建立能力最强的阿里云主机，64Byte时连接建立能力均在每秒1万连接以上这让其当仁不让的站上了连接处理能力最强的第一梯队。然而随着内核数量的提升，云主机处理性能会有一定幅度的下降，不过这到可以理解，多核处理器在处理应用请求的时候本身就要先做一个判定，是用哪一个内核去进行处理，即便是一个单进程的处理任务只划分到其中一个内核去进行处理，也需要进行一下判断和计算资源分配，这自然也会消耗掉一定的处理时间，处理能力自然会有所下降。

但是在青云的云主机上，情况正好相反，4核8G云主机的连接处理能力好于2核4G的云主机，但性能又不是成倍的提升，64Byte每秒1万连接所占带宽仅在5Mbps左右，也远没有超出网络带宽限制范围之外，这样的结果到底是在云系统中进行了连接数限制，还有有其它原因？还有待进一步去进行了解。

从云主机网络连接TCP_RR测试结果线图可以看出，除阿里云云主机外，其他云主机网络连接建立能力从2048Byte开始出现大幅下降。而此时，即便是按连接处理能力最高的阿里云6500以上的网络连接建立能力计算，其网络传输带宽也未能超过540Mbps，可以确定并不是因为网络带宽的限制导致了网络连接建立能力的下降。

那么是由于数据包转发性能设置过高，造成的应用连接处理能力下降，还是这些云主机在处理多数据包时CPU处理能力降低？（10240Byte及以后的测试文件大小超出了虚拟网络的最大数据缓冲文件大小，会分成多个数据包进行转发）。这种情况对实际网络应用会造成什么样的影响？这些问题还需要在今后深入研究。

Netperf加载TCP_CRR参数测试

按照Netperf的解释，采用TCP_CRR参数，会在连接数据传输完毕后，将连接进行断开。更像是实际网络中HTTP协议传输数据时的情况。由于每次连接都需要重新进行建立，对服务器的应用负载会更大一些。

在TCP_CRR的测试过程中我们发现在64Bytes到10240Byte时，不同云主机的连接处理性能出现了明显的“分层”现象。从云主机网络连接TCP_CRR测试结果线图中我们可以清楚的看出，处于最顶层的是阿里云2核4G、4核8G、32核64G云主机。下方是青云的4核8G和2核4G云主机。再下面是腾讯云的32核64G、4核8G和2核4G云主机。而百度云的云主机处于最低下的位置。

这个排序，应该可以比较清晰的体现出不同云主机在“单核”时的网络应用处理能力了。

原本计划通过1024Byte-1024000Byte这些不同大小文件，在进行连接测试的过程中，同样对云主机的数据传输性能再进行一下分析。然而由于测试工具Netperf的单线程测试能力，并不能将应用连接很好的分配到云主机的多核处理器之上，因此云主机有限的处理能力，不能很好的对网络数据传输进行处理。

但是1024000Byte这种接近1MBytes的文件大小对于云主机的处理能力要求已经是十分的有限了，可是在测试结果中百度云和腾讯云的云主机依然未达到1000Mbps的网络传输带宽，这样的应用处理能力就让人十分费解了。而且在这种大文件之下，腾讯云的连接处理能力会被百度云进行反超，这个问题，还有待更进一步了解。

注：阿里云在2核4G云主机上133TPS的成绩应该是受到其1.1Gbps网络带宽的影响，青云的处理情况应当也是同理。（1024000*8*133=1089536000bps），腾讯云与青云传输带宽相仿，但连接处理速率相差比较明显。

阿里的多线程网络连接性能测试

同样，在阿里技术人员的肯定与支持下，至顶网也对阿里云32核64G云主机的多线程网络连接处理能力进行了测试：通过编写脚本起大量netperf -TCP_RR与netperf -TCP_CRR测试线程的方式，在200秒的测试时间内，对被测端进行测试。

同样为了方便进行统计，对网络连接性能的测试字节大小定在了1Byte，尝试着通过统计收、发端口的数据包传输速率，对TCP的连接建立速率进行统计。

通过收集被测端口数据包转发统计可以了解：在Netperf TCP_RR测试中，阿里云32核64G云主机网络连接处理能力达到了74万PPS以上的成绩。而在Netperf TCP_CRR测试中，连接处理能力有所下降，达到44万PPS的处理成绩。（注：这里统计的还是云主机虚拟网口的数据包转发，在连接建立时还会有建立连接的握手等数据包同样统计在其中，其实际处理能力有待今后采用更专业的测试工具或方法再进行验证。）

 netperf  TCP_RR

netperf  TCP_CRR

考虑到上面这种测试方案过于“激进”，为避免对其他公有云厂商虚拟网络造成过大影响，这个测试就没有在其它公有云上进行复测。希望今后有机会可以对更多公有云网络系统进行更全面的性能展示。

对于上面的应用测试结果，至顶网想表达的观点有两点：

1、对阿里云云主机的网络连接处理能力表示肯定。强大的网络连接处理能力，为网络应用传输提供了充分的计算能力保障。

2、现阶段给每个应用请求分配10Mbps的网络带宽，基本上可以保障常见网络应用的流畅运行。即便是减少到1Mbps带宽时，对于以图文为主的应用，用户也并非不可以接受。但是在每兆带宽上有10个以上的新建连接请求时，最好还是进行“报警”处理的比较好。无法及时处理的应用请求会迅速产生应用请求的堆积，对应用和网络系统产生无法预测的应用压力。

小结：应用与带宽

本次至顶网对公有云云主机网络应用性能的“摸底”测试活动至此就告一段落了。现在将本次测试活动发现的问题在这里小结一下：

健壮性值得肯定，应用与带宽处理尚待完善

首先值得肯定的是，在本次评测活动中，这几家公有云厂商的云主机产品，都十分顺利的完成了网络带宽与应用处理能力的评测。对现实中正在使用的网络进行评测和实验室网络评测不同，一不小心，就会对现网应用造成无法估量的重大影响。因此，至顶网这次评测，也是十分的小心翼翼，生怕会出现什么纰漏。但根据目前测试情况来看，虽然测试的这几个公有云厂商的云主机网络管理机制有所不同，但对网络流量隔离处理的都十分理想，云主机虚拟网络健壮性都经受住了这次考验。

其次是计算能力与网络带宽的匹配。在这方面阿里云确实带了一个好头，随着计算能力提升，网络带宽也提供了相应的保障，希望其它云计算厂商在网络带宽设置上也可以更加多样一些，为不同网络应用提供更加灵活的带宽选择。

最后想谈一下应用连接与网络带宽匹配问题。应用连接对网络传输影响问题的发现，应该可以追溯到网络安全的传奇企业Netscreen，因此在传统的网络及网络安全产品中，都对网络应用性能测试十分的重视。而依据现在的测试情况来看，公有云厂商对虚拟网络的网络应用连接处理能力认识，还不是十分深入。一味追求连接性能，或者对应用连接放任不理都有可能会引发网络传输的故障出现。希望今后云计算厂商可以提供出更加合理的网络带宽与应用连接匹配规范。便于用户在突然出现高并发、大流量网络应用情况时，可以及时进行处理，避免网络连接拥塞问题的出现。

云主机网络应用优势总结

在本次评测过程中发现，各个公有云厂商在应用处理时，有自身不同的特色，在这里也为大家来小结一下：

阿里云：综合应用处理能力出色

在本次测试中，网络及应用处理能力最出色的，当数阿里云的云主机产品。在网络层上，与物理网络相仿的数据包转发处理能力设计。在传输层上，十分强悍的网络连接处理性能。比较完美的体现出，阿里云云主机对不同网络应用的全面综合考量。由此可以更好的适用于各类不同云计算的网络应用之中。

将以前作者心目中像豆腐渣一样的虚拟网络，做到与物理网络同样的稳定，在其中必然有非常大的艰辛付出。

青云：更适于Web应用处理

良好的连接建立能力，是网站应用访问的基本保障。传输带宽虽然没有很高的设置，但与系统的负载均衡产品结合也可以很好的解决传输带宽的问题。这样虚拟网络设计，应该可以较好的保障Web类应用处理效果。

未来如果可以将多队列网卡的网络带宽进行更合理的规划，应该可以释放出更理想的网络应用处理能力。

腾讯云：适合网游及小文件传输

在网络游戏应用中，用户每一个操作所产生的数据量并不很大，但操作频次会非常密集。这也就意味着，在云计算虚拟网络中，需要为其提供更强的数据包转发能力，但未必会需要有很高的网络带宽（微信、QQ等即时通讯产品实际上也有着相似的网络应用需求）。从这个角度来考虑，就不难理解腾讯云为什么没有为云主机设计很高的网络带宽，而提供了较强的数据包转发能力了。

如果可以进一步提升大文件时的网络连接建立性能，应该可以释放出更好的网络应用处理能力。

百度云：可用在文件存储类网络应用

对于网络存储产品而言，本身不需要很高的数据包转发及应用连接处理能力，但需要有很高的网络传输带宽进行保障，百度云的低转发、低连接和高带宽虚拟网络设计，可以很好满足网络数据存储的应用需求。

但是在第二次测试中将其带宽大幅度降低，这样可以适用于何种网络应用，还需要再具体去研究一下。

对于云计算的虚拟网络而言，网络带宽、转发性能乃至于网络连接的管理控制，都是可以根据用户需求去进行调整的。之所以在本次测试中没有用“工单”去打搅这些云主机厂商，就是希望对他们云主机的“原始”云主机性能进行一个了解。从测试所得数据来看，也比较符合这些公有云厂商自身主营网络业务特色。

但是，技术这种“东西”并不是“说有”就可以有的，需要通过应用能力的展示，才可以让用户去真实了解。在今后还希望各家公有云厂商可以更加开放一些，可以更加主动的对自身技术性能进行展示。这样也可以让用户更加有针对性的对公有云产品去进行选择。

测试的问题与不足

下面总结一下本次测试中的不足：

在本次测试中，深深感受到现有Linux中的测试工具对多核心、大规模云计算系统评测和统计能力不足。而且测试指标和测试方法也存在不完善的地方。但是目前专业的虚拟化测试工具现在还很难在各公有云厂商的云计算环境中进行部署。

希望今后专业测试仪表厂商能与公有云厂商相互配合，在公有云厂商的云市场上也提供出专业的虚拟化网络测试工具，方便用户直接进行使用。从而使用户可以更有效的对自身云计算系统应用处理能力有直观的了解。

测试仪表厂商最好也可以提供一些更加精简的、可以轻松在Linux上进行安装的测试工具，方便用户在不同云系统上进行测试。

在这里想告诉大家的是：网络的世界是一个连接的世界。无论是物理还是虚拟、有线或是无线，在网络中进行合理的连接管理控制，是网络应用顺畅进行的重要保障。也期望今后可以有更多云计算厂商，能将他们的网络带宽与应用连接管理控制能力，更多的向用户展示出来，为今后的云计算、物联网乃至于人工智能提供更坚实的网络基础保障。

公有云主机的技术性能评估，就暂时告一段落了，有机会的话，我们还会再更进一步的对公有云厂商的质量控制能力和产品服务水平进行一个评估。当然还希望各个云计算厂商继续给予配合。