下一代超大规模软件定义网络技术实践

云计算的 IT 架构已经在企业应用中表现出明显优势，但网络设计理念却必须是一种推倒重来的思想。为了适应云计算的灵活、弹性扩展、高效和低成本，网络设计要进化为集中式软件管理，可编程化，控制转发层面分离等。本次陈海泉分享了关于下一代超大规模软件定义网络技术实践。

以下是本次分享的内容整理。

————————————————————————————————————————————

大家好，我是 QingCloud 的工程师陈海泉，今天给大家分享一些 SDN/NFV 2.0 架构的网络技术。我解释一下什么是 SDN，SDN 就是软件定义网络。当然也不是所有网络定制一定要软件来实现，因为有很多硬件方案也可以做到 SDN 的效果。

青云QingCloud 用软件定义来实现虚拟网络，我们 2013 年的时候，在公有云上线了第一代产品。当时 SDN 还是一个比较新鲜的事情，用户用的还比较少。到了今天，SDN已经开始普及，连私有云用户也在使用基于SDN的VPC。

随着用户量越来越大，第一版的 SDN 提供的私有网络里面的 VM 超过一定的数量的时候，我们发现性能就有一个比较大的损失，已经无法满足企业用户的需求。所以我们在去年下半年的时候，花了很大功夫去做 SDN/NFV 2.0 的事情。

考虑到很多人对计算机网络不熟悉，我先补充下网络基本原理：计算机网络分 7 层。 SDN 相关的主要是二层和三层网络。二层是数据链路层，使用 MAC 为地址通信，二层网络中的成员通过交换机连接起来。成员间的应用软件虽然以 IP 为地址通信，但是通信之前，操作系统会通过 ARP 协议，把目标 IP 转换成 MAC 地址，然后再发送数据包。交换机根据数据包的目标 MAC 地址，进行数据包的投递。二层网络中，会用到单播，广播和组播三种方式。

三层是网络层，使用 IP 为地址通信。三层网络就是用路由器将不同的二层网络连接在一起，形成一个可扩展的网络。通信方式可以是单播和组播，但不能是广播。路由器的作用就是根据路由表，找出目标 IP 对应的 MAC 地址。数据包往往通过多个路由器之间转发，才会送到目标地址。

基本知识介绍到这里，现在说一下为什么需要 SDN 。

首先，虚拟化技术带来的好处是用户的 VM 分布在物理机集群上面，出于负载均衡，和服务高可用的目的，需要在物理机之间迁移 VM ，并且迁移之后 IP 地址不变。

在早期的虚拟化方案中，物理机集群比较小，全部是一个二层网络， VM 使用物理设备分配的 IP 地址时，发生迁移之后， IP 本身就不会变化。但是随着云计算的发展，虚拟化的物理集群需要被部署在更大的三层网络上，这时候 VM 再使用物理 IP 地址，是不能够保证 IP 不变的，因为迁移到了别的二层网络，对应的路由器就不认识原来的地址了， VM 要继续工作，必须更换成当前网络的 IP 地址。

这个时候，就需要网络虚拟化技术，也就是通过 SDN 给 VM 定义虚拟的 IP 段，这个虚拟的网络可以分散在整个三层网络上，使得 VM 迁移后， IP 地址不变。这个IP地址跟物理的路由器，交换机没什么关系，可以随便定义。随着云计算的发展，单靠网络虚拟化技术，仍然满足不了用户大规模部署的需求，这时就需要有 VPC 。

VPC 是什么意思呢？ VPC 是用户定义的一个专属的大型三层网络。在 VPC 网络内，用户可以自定义 IP 地址范围、创建子网，并在子网内创建主机/数据库/大数据等各种云资源。

简单的说，虚拟网络指的是虚拟二层网络， VPC 指的是虚拟三层网络。在 VPC 里面，还需要能做到不同 VPC 之间， IP 地址复用。因为私有 IP 段有限制，不同的用户，可以使用相同的 IP 地址，却不互相影响。

正是因为云计算需要虚拟网络，也需要 VPC 。所以需要一个 SDN 方案解决这两个需求，现有的 SDN 方案主要分成两个方向：

1. 用软件来定义，但是用硬件来实现。比如某些带 SDN 功能的交换机，把它采购进来，部署到产品里，用硬件厂商提供的 API ，就能定义虚拟网络，实现 VPC 功能。

2. NFV，就是网络功能虚拟化，用软件的方式来实现虚拟的交换机和路由器，把他们组织，并管理起来，让上层应用能够定义虚拟网络。其代表有 VMware NSX 、 JuniperOpenContrail、OpenStackDVR 等等。

QingCloud 在 SDN 方案的选型上也做过讨论，用软件还是用硬件方案？其中考虑的问题主要是以下三个方面：

1. 成本。在公有云上面大家拼的是成本，谁的硬件成本低，谁就能把价格降到最低。如果我们采用硬件方案，在网络设备上面需要增加了很多投资，要替换掉几乎所有的网络设备。
2. 设备依赖。我们的私有云卖的是软件，客户可以按照偏好选择自己的硬件，假如 QingCloud 的 SDN 绑定了某款硬件产品，那我们在面对企业客户的时候，可能连招标的机会都没有，因为客户往往有自己的采购渠道，指定的硬件品牌。
3. 情怀。对于工程师来说，自然是想把产品做得更优秀。参考下优秀的传统行业，就能明白这一点。

其实，计算机网络跟传统快递行业非常的接近，我在后面解释网络知识时，也会拿快递打比方。

为什么说快递跟计算机网络接近呢？因为网络中的交换机、路由器，其实跟快递行业里的快递员和包裹集散中心非常相似，用户发包裹给快递员以后，快递员会送到快递集散中心，这里可以查询包裹应该被送到哪个地方，然后再将包裹经过多个快递集散中心层层转运，才会送到收件人那里。

顺丰在中国应该是最好的快递公司之一，因为它把转运环节都做全了，只有方方面面都能够控制才能实现压倒性的优势。

上面的插图给了顺丰航空的一个截图。我是看到了这张图，才明白为什么他们能够比别家送得快。因为他们不仅有自营的快递转运点，连飞机都是自己买的。

因此，我们如果把数据包转发的每个流程都控制到，就有可能在整体系统上面做到最优，而采用硬件设备实现这些功能的话，最后带来的是同质化，跟竞争对手相比不会有任何的优势。

综合以上三方面的原因，我们决定开发一套新的 SDN/NFV2.0 方案，取代 1.0 。

开发一套新的SDN/NFV 2.0 方案， 也就是自营航空公司。既然定了要自己做一套新的方案，怎么去实现？我们做了一些总结，新的产品首先需要满足传统 SDN 的功能。需要做到三点：

1. 数据封装。也就是实现一个虚拟网络；
2. 实现控制平面。对二层、三层的网络数据进行转发和路由规则的同步，然后下发到虚拟的交换机和路由器里面去，同时需要做到 ARP 泛洪抑制；
3. 实现数据平面。我们使用了叫做 DVR 的linux kernel模块实现的数据平面，同时还提供了虚拟边界路由器，提供，隧道等高级功能。

下面分别解释这三点：

首先解释下虚拟网络。 虚拟网络直接说比较难以理解，但是类比到传统行业，就好解释了。

在一些大公司里会提供一种叫内部邮件的服务给员工，比如要给财务部门某同事发一个报销单，会查他的工位，比如 2pw067 。然后准备一个信封，把要填的单子放在里面, 收件人地址就填 2pw067 。我不需要知道这个人是在北京，还是在上海，直接用工位号就能发件。我把这个信封交给公司的收发室。收发室其实不具备邮递能力，但是他们也能做快递业务，方法就是对这个信封进行重新封装，收发室有个地址本，能查到 2pw067 这个工位对应的办公楼具体地址。

然后用一个大信封，把我原来的信封装进去，收件人填目标办公楼的收发室员工名字，收件地址是实际的街道地址，然后把具有新地址的信封交给真正的快递公司，比如顺丰。快递公司会把信封发送到对应的办公楼，然后那边的收发室把外层信封拆掉，将里面的信封交给具体的收件人。

拿计算机的术语来讲，内部邮件系统就是虚拟快递公司，真正派件的快递公司，叫做物理快递公司。虚拟网络非常类似，允许用户通过自己定义的地址，进行传输。这个地址用户随便定义，反正物理网络看不到这个地址，也就不受任何限制。

物理机收到 VM 发的包后，会对数据包做封装，再套一个信封，也就是加个包头，写上目标物理机的地址。物理网络设备，根据新的包头把这个数据包发送到对应的物理机，然后物理机那边的终端会把数据包拆开，将里面的数据包转发到目标 VM 。

这里的封包，拆包就是 Overlay 技术，也叫数据封装。听起来很高大上，其实传统行业几百年前就实现了。

下面就是具体的计算机技术细节：实现虚拟网络，比较流行的数据封装协议是 VXLAN ，因为 VXLAN 相比传统的 GRE 协议有一系列的优势。

1. 隧道连接一组物理机。 VXLAN 发包时，可以任意指定目标物理 IP 地址和 ID ，不像 GRE 那样，要在两边配置点对点的连接；
2. 使用 UDP 协议。 UDP 协议的特点是有端口。发包时每个连接都使用不同的源端口。当数据包交给目标服务器网卡的时候，网卡根据这个数据的包头的 IP/端口做 HASH 运算，用于选择不同的网卡队列。而每个网卡队列会绑定到一个 CPU 上面，这样把包会交给不同的 CPU 处理，提升总体性能；
3. 使用基于组播的 Flood & Learn 模式自动管理虚拟网络。这个功能会大幅降低组件虚拟网络的复杂度，因为 VXLAN 的终端，会根据数据包包头的内容，自动建立，并维护一个转发表。回包的时候，根据转发包找到目的物理机的地址。

这里的转发表，拿之前的例子说明，就是企业内部邮件收发室的地址本，把虚拟地址和物理地址对应上。 VXLAN 的这个特殊功能，就是能够自动建立地址本。

基于以上几点，我们觉得 VXLAN 不错，但是仔细的去想，就发现它有两个非常大的不足：

1. 发送广播包时，使用了组播协议，大规模部署会受硬件设备组播路由限制。它在二层网络中使用时，没什么问题，但是在三层网络中使用时，物理路由器上会建立大量的组播路由条目，影响路由器性能，并且增加了路由器运维的难度。
2. Flood& Learn 的机制，会把原来在二层广播的 ARP 包扩大到三层网络。

第二点解释起来比较复杂，先从 ARP 原理讲起。 ARP 的作用是把 IP 地址转换成 MAC 地址。在发包方，如果遇到不认识的 IP 地址，会发个广播包到当前的二层网络，内容大概是：谁的 IP 是 1.2.3.4 ，请告诉 1.2.3.5 。所有网络成员都会收到这个包，但是只有 1.2.3.4 会回包给 1.2.3.5 。这样， 1.2.3.5 就知道了 1.2.3.4 的 MAC 地址，接下来他们就能够通过 MAC 地址互相通信。 Flood & Learn 的原理就是学习 ARP 广播包的行为，建立转发表。

拿之前的企业内部邮件做例子，收发室收到目标地址是 2pw067 的邮件时，他一开始不知道这个地址在几楼的哪个办公室，他会群发 Email 到写字楼的全体员工，说有 2pw067 的包裹。这样收件人会到收发室取邮件，同时把自己的 Email 告诉收发室。

此时，收发室的这个人，会默默在自己的小本上加一行： 2pw067 的 Email 是 [email protected] 。这样下次在有到 2pw067 的邮件，他直接给 [email protected] 发邮件，通知他来取件，而不是群发所有人。这个方式最大的问题是，收发室老会群发邮件，而且他每隔一段时间，就要确认下 2pw067 的 Email 有没有发生变化。这样随着规模扩大，广播越来越多，会严重的浪费带宽资源。

虽然物理网络也会使用 ARP 广播，但是广播被限制在二层网络里面。而虚拟网络的载体，实际是三层的物理网络，广播实际上可能被发送到整个数据中心的所有物理机。在大规模部署虚拟网络时，ARP 浪费的带宽可能占网络流量的一半以上。

要解决这个问题，需要做到两点：

• 拦截 ARP 广播，避免发送到全局；
• 使用控制器同步地址本，代替 Flood & Learn 功能。

所以，需要有 SDN 控制器，通过同步规则，取代 VXLAN 自有的 Flood& Learn 功能。

也就是说，有个 HR ，每当有员工人入职，工位变动时，就把他的工位发到公司所有写字楼的收发室，不让他们用广播的方式学习地址。而且收发室收到群发邮件时，会主动回包，而不是把广播包转发到别的收发室。

那么这个控制器需要多少个呢？我之前曾经了解过一些 SDN 方案，通常只有一个。它负责同步整个集群中所有节点的规则，这么做带来一个问题，当 VM 创建、销毁、迁移的时候，控制器需要把新的规则同步到整个集群所有的节点中。

而优秀的云计算平台，能够让用户秒级创建资源。 VM 创建、销毁、迁移这种事情，在集群中无时无刻都存在，同步规则会变得相当频繁。所以我们做了一个分布式控制器，不仅把控制器分布到每个 VPC ，还分布到每个虚拟网络里。

刚才说了虚拟网络和控制器，第三点 SDN 需要做的就是控制数据平面，其作用就是把数据包从网卡拷贝到 VM 。

传统的数据平面，比如 OpenStack 通常会用 OVS 。 OVS 会有一个问题，它会把数据包传到 UserSpace ，因为有个应用程序，根据流表决定数据包如何转发，这样会带来性能的下降。

而我们的方案完全避免了这个问题，使用自己研发的 DVR 取代 OVS ，所有数据转发都在 LinuxKernel 中完成。 DVR 就是分布式虚拟路由器。它实际上是一个带路由器的交换机，同时具有二层交换，和三层路由的功能。

DVR 这个概念，几乎在所有先进的 NFV 方案的 SDN 中都有，比如 OpenStack 的 DVR ， VMware NSX 的逻辑路由器，OpenContrail 的 vRouter 。

他们名字虽然不同，但是本质是相同的，也就是说，让每个计算节点都拥有虚拟的交换机和路由器。听起来很简单，但是实现它有很大困难，其中之一就是：同一个网络的 DVR， MAC，IP 地址都是相同的，这在物理网络里面是无法想象的，因为打破了网络的基本规律。

但是 DVR 却是 NFV 方案的一个关键。

如上图所示，我们解释一下为什么需要 DVR 。左边是这张是物理拓扑图，物理世界中 A 和 B 通信，需要把信息发送到 A 的交换机，然后到路由器，然后路由器转给 B 的交换机，B 的交换机再发送给 B ，A 和 B 通常需要 4 跳才能发一个数据包。

我们 1.0 的时候，也是用 NFV 实现的 SDN ，我们会模仿物理世界，发明出虚拟的路由器和交换机提供给用户。请看中间这张图，如果 A、B、C、D、E 这五个设备分别位于五个不同的物理机上，在逻辑上，A-> B 的包经过 C、E、D 才能到 B ，逻辑上是 4 跳。但是虚拟设备每一跳都要通过物理机去转发，而物理机之间发包都需要 4 跳，这样总得转发量实际上需要 16 跳。

这也就是为什么我们 SDN 1.0 的性能总是上不去。随着规模增加，逻辑上每增加 1 跳，物理上就增加 4 跳，性能随规模衰减得厉害。

为了解决这个问题，我们引入了 DVR 。请看右边这张图， A 和 B 的物理机都有 DVR ，从 A 到 B 只在两个 DVR 之间直接交换一下数据就可以了，这样在逻辑上只有一跳。所以物理层面上跟左边的图一样， 4 跳完成一个数据包的转换，这样就可以非常接近物理机的性能，在大规模部署时，保持高性能。

使用 DVR 的另外一个原因，就是虚拟网络设备性能弱于物理设备，在物理设备部署拓扑上，经常有汇聚节点，成为网络瓶颈。由于物理设备能力很强，很容易就能达到 40 G ，或更高带宽，汇聚几次没什么关系；而虚拟设备作为汇聚节点时，往往就限制了它管理的网络整体能力，因为虚拟汇聚设备会成为性能瓶颈。使用 DVR 同时意味着不再有汇聚节点，因为所有成员都是点对点直接通信。

这个在物理设备上无法实现，因为不可能把所有设备连成一个大网，而虚拟网络设备上，是可以实现的，因为他们相连，只是加几条转发规则而已，而不是真的需要去点对点地连接网线。

有了上面三个功能，就是通常意义上的 SDN 了。然而我们在做云计算平台时，通过长时间的积累，还发现了很多需求：

1. VPC，并且 VPC 主机直接绑定公网 IP 。
2. 负载均衡器。可在公网网关上对入流量进行分流，转发到多个负载均衡器节点。
3. VM 使用基础网络时，也就是物理网络的 IP 地址在迁移后不变。
4. VPC 和物理网络高效连接。

下面分别解释。

首先是 VPC ，青云QingCloud VPC 功能是 1 月 6 号上线的，我们只上线了一周就卖掉了第一批上线的所有物理资源。因为我们公有云的大用户已经深深的认识到必须要有一个 VPC 才能支持自己的海量的资源。业务真的到了一千个 VM 以上的时候，就需要有一个高效的三层网络，取代二层网络。

我们 VPC 设计是支持 64000 台虚拟机，代表着我们控制器控制规则有可能是 6 万条，假如我们把跟 6 万条规则同步到每个 DVR 上去，这同步量非常大。

相信靠我写的代码完全不可能实现。所以设计一开始就给他设计了一个学习的能力。学习不是是基于泛洪的学习，而是根据用户的行为对他进行学习。

这个学习功能，还是拿快递打比方。

快递员通常收到邮件时，会把邮件发到邮件集散中心，那里有人去查地址本，决定邮件对应的下一个邮件集散中心是哪个。然后会交给邮递员经行投递。我们假设每个快递员都能够把包裹投递到任何一个地方，也就是拥有 DVR 的能力。

当发件邮递员投送发给oc的包裹到北辰购物中心 2 号楼时，他多做一件事情，给收件的快递员打个电话，告诉他说：哥们，你以后再收到发给 oc 的包，直接交给我，不用送到邮件集散中心。这样收件快递员更新自己的地址本，记上： oc 的包，给快递员老王，让他直接去派送。下次，再有包给 oc 时，他把包交给老王，老王直接派送给 oc ，不必去邮件集散中心绕路。

这就是 VPC 主动学习功能的基本原理，能够实现超大规模的三层网络，却不必同步大量的转发规则。

请看上面的图。有两个虚拟网络，都在同一个 VPC 之间，当他们建立之后，两个 VM 分别加入两个网络，它们没有任何的沟通。最开始通信的时候，左边 VM 跟右边的 VM 发包，通过默认路由线路（邮件集散中心），经过两个节点中转，当 DVR 发现这两个虚拟机真的要互相访问的时候，才会把规则同步过去。

虽然一开始的时候性能稍微差一点。但是用着用着就快了，因为 DVR 学习到了规则。这样，不需要真的同步 6 万条规则到 6 万个 DVR 节点，真正的用户即使有了 6 万台虚拟机，也不可能时时刻刻都进行着点对点互相访问，一定会按照自己的业务往下拓展，某些 VM 之间才需要互相访问，大部分 VM 之间其实不需要互相访问。这样看来，完全没必要同步所有 6 万条规则，只需要学到其中几千条有用的就行了。

DVR 除了实现 VPC 功能之外，还有许多别功能。请看上面这张图，除了 VPC ，还有其他四个方向。

• 第一个就是公网网关，为了提高公网访问性能，DVR 跟公网网关可以直连；
• 第二是 VPC 的虚拟机要能跟硬件设备进行高度的互访，因为我们私有云用户的机房里，不止有虚拟机，还有 Oracle 的数据库、F5 的路由器等等，假如我们让用户把这些业务放到虚拟网络里，虚拟网络就要跟硬件网络进行高速的互访，VPC 跟物理网络互访通过给 VM 绑定物理网络 IP 实现，也就是说一个 VPC 的虚机，除了有自定义的虚拟 IP 地址外，还能有一个对应的物理网络 IP ， DVR 会做地址转换，把物理 IP 转换成私有 IP ，实现跟硬件网络高速互联。
• 第三是 VPC ，可以让用户定义 255 个 C 段，加起来可以有 60000 多个虚拟机。
• 第四，我们还提供了一个边界路由器，可以让用户虚拟资源跟远程的 IDC 之间做一个互通。

除了 VPC ，我们为私有云用户设计了 VBC 功能。 VBC 的特点是里面的 VM ，全部可以直接使用物理网络定义的 IP 地址，而且具备 VPC 的所有功能。 VBC 是一个私有网络和物理路由器的混合网络，能够做到使用物理IP地址的同时，能让 VM 在集群中任意迁移，有保持 IP 地址不变。

最后一个就是负载均衡器集群，设计是这样，我们有一个网关集群连着因特网。比如我有一个 IP 1.2.3.4 ，入流量发送到 VG 1 这里。VG 1 会做第一次的流量转发，把流量转发到用户自己私有的负载均衡器节点里（LB node1、2、3）。它的特点是，返回流量不需要经过进来的 VG 1，而是经过 LB node 对应的不同物理网关发送到因特网。

因为当 VG1 能力受到限制的时候，假如我们所有流量都从它回去的时候，它自己的网络带宽实际上就是整个集群的能力，而我们把它分散之后，就可以做到，出去的流量几乎是没有限制，只要我们的 VG 设备有多少，它的带宽就会有多少，因为流量不需要从默认的线路回去。同时随着用户拓展负载均衡器节点的数量，也扩展了 HTTPS 的卸载能力。

并且我们做到了 4 层/ 7 层的完全透明，也就是说用户通过因特网访问到他们业务的时候，我们在所有转发过程中，都会保留其原地址，用户这边得到的包是直接来自因特网用户的 IP 地址。

QA

1、问题：有的 SDN 必须更换新的物理服务器；有的 SDN 不需要。请帮忙分析一下。

必须更换新的物理服务器的这种 SDN ，属于硬件方案，软件定义网络，硬件实现网络。典型的产品是思科N9000 系列交换机。有的 SDN 不需要换设备，因为代码跑在 X86 服务器上，也就是 NFV 实现。

2、问题：据了解你们新的 SDN 里面 VM 迁移可以保持 IP 不变，你是怎么实现的？

因为 VM 的 IP 在二层网上，使用了虚拟网络，将分散在不同物理机上的 VM ，都连成了一个二层网，但是路由器使用的是物理路由器，做到了迁移后，IP 不变，也就是虚拟交换机+物理路由器。

3、问题：LB 能否直接连接后端服务器？

可以，不管是 VPC ，还是基础网络，都可以，而且 TCP/HTTP/HTTPS 全透明，后端直接获得客户端源地址。

4、提问：刚才提到 DVR ，能不能详细介绍一下。怎么实现？

具体实现比较复杂，我们改了 LinuxKernel ，让它能够适应 DVR、MAC、IP 重复的情况。因为同一个网段的 VM ，网关的 MAC、IP 都的是一样，而这些 VM 又需要有各自的 DVR 。我们改了很多虚拟交换机的逻辑，也发明了一些功能才做到，但是不太容易解释。而且虚拟网络还能让用户使用虚 IP ，这也是 DVR 的一个难点。我之后还看了下 AWS 的 VPC 功能，他们还不能允许用户定义随便 VIP 。

5、提问：计算机都是和本地 L3 出去，在两个网端，那你这个从本地的 L3 到外网那个 L3 这怎么算？

从本地的 L3 到外网那个 L3 ，在 DVR 层面就是两个虚拟路由器之间的转发，逻辑上也是一跳。

6、提问：SDN和NFV有啥区别？

SDN 只要求软件定义网络，可以是硬件实现， NFV 表示用软件实现虚拟网络，属于 SDN 的一种。

7、提问：一个 VPC 对应一个 VXLANID ？可以对应多个吗？

青云QingCloud 的 VPC 可以包含 253 个 VXNET ，就是虚拟网络，每个 VXNET 对应一个 VXLAN ID 。 VXLAN 网关是分布式，一个 VXLAN 有很多 DVR 。

8、提问：一个 VPC 内网关是不是分布式的，同一个 HOST 内的两台 VM ，不同网段互访可以本地 DVR 转发，还是要到专门的网关设备？

本地 DVR 转发，通过学习功能建立路由表。

9、提问：VXLAN 控制平面的自动学习是怎么实现的？

我们自己发明的一个学习方法，要求 DVR 之间能够互相沟通。之前有讲过，就是那个快递员之间打电话的例子。

10、提问：SDN Controller 是你们自己研发的，还是开源的？

是我们研发的

11、提问：DVR 的配置下发是怎么实现的，是由 SDN Controller 下发的嘛？南向用了什么协议？

Controller 下发部分规则，建立默认的路由表，更多是靠 DVR 的学习功能，里面学习机制的通信是我们定义的，路由同步是标准的 BGP/OSPF 这些。

原文链接： https://community.qingcloud.com/topic/336

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26916835/viewspace-1983904/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26916835/viewspace-1983904/