作者简介

    郭瑞景：从事网络与存储开发工作，活跃于OpenStack OpenDaylight、OPNFV等开源项目。

    陆连浩：ONAP项目积极贡献者，此前长期从事Linux驱动、嵌入式系统开发工作。

    秦凯伦：OpenStack Neutron项目的活跃贡献者。

    徐琛杰：从事边缘计算项目StarlingX网络方面的开发。

    应若愚：从事网络相关软件开发和优化工作，目前主要负责ONAP平台开发。

    丁亮：从事云ONAP相关的开发和集成工作。

    朱礼波：活跃于OPNFV、ONAP等开源项目，此前从事虚拟化技术与GPU底层的开发与维护。

    黄海滨：ONAP项目积极贡献者，其中Multi-Cloud和VFC的Committer，在虚拟化和智能监控领域有6

    篇专利。

    任桥伟：从事Linux内核、OpenStack、Ceph等开源项目的开发，著有《Linux内核修炼之道》《Linux

    那些事儿》系列。

    梁存铭：软件架构师，网络数据面专家。主要从事研究数据面优化、网络设备虚拟化及系统架构优

    化。

    胡雪煜：专注于虚拟化技术和基于IA架构的数据面性能优化，具有丰富的SDNNFV商业实践。

    胡嘉瑜：主要从事网络IO虚拟化方面的工作。

    王潇：主要从事网络虔拟化，云网络硬件加速等技术的开发。

    何少鹏：专注于网卡和IO虚拟化，之前在云服务和网络设备行业有十多年的从业经验。

    姚磊：主要从事DPDK虚拟化以及OVS的性能评估和分析工作。

    倪红军：VPP Maintainer，Sweetcomb和NSH_SFC项目负责人。

    吴菁菁：主要从事Intel平台上网络包处理加速的工作。

    陈兆彦：主要从事基于IA架构的DPDK网络系统的性能测试和分析，以及研究SDNNFV方案，如对

    Tungsten Fabric vRouter的性能分析。Linux开源网络全栈详解 从DPDK到OpenFlow

    英特尔亚太研发有限公司 编著

    电子工业出版社

    Publishing House of Electronics Industry

    北京·BEIJING内容简介

    本书基于Linux基金会划分的开源网络技术层次框架，对处于主导地位的、较为流行的开源网络项目

    进行阐述，包括DPDK、OpenDaylight、Tungsten Fabric、OpenStack Neutron、容器网络、ONAP、OPNFV

    等。本书内容主要围绕各个项目的起源与发展、实现原理与框架、要解决的网络问题等方面展开讨论，致力于帮助读者对Linux开源网络技术的实现与发展形成完整、清晰的认识。本书语言通俗易懂，能够带

    领读者快速走入Linux开源网络的世界并做出自己的贡献。

    本书适合参与Linux开源网络项目开发的读者阅读，也适合互联网应用的开发者、架构师和创业者参

    考。

    未经许可，不得以任何方式复制或抄袭本书之部分或全部内容。

    版权所有，侵权必究。

    图书在版编目(CIP)数据

    Linux开源网络全栈详解：从DPDK到OpenFlow英特尔亚太研发有限公司编著.—北京：电子工业出版

    社，2019.7

    ISBN 978-7-121-36786-1

    Ⅰ.①L… Ⅱ.①英… Ⅲ.①Linux操作系统 Ⅳ.①TP316.85

    中国版本图书馆CIP数据核字(2019)第108126号

    责任编辑：孙学瑛

    文字编辑：宋亚东

    印刷：

    装订：

    出版发行：电子工业出版社 北京市海淀区万寿路173信箱

    邮编：100036

    开本：720×1000 116

    印张：16.75

    字数：429千字

    版次：2019年7月第1版

    印次：2019年7月第1次印刷

    定价：79.00元

    凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本社发行部联

    系，联系及邮购电话：(010)88254888，88258888。

    质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。

    本书咨询联系方式：010-51260888-819,faq@phei.com.cn。推荐序一

    Network functions are rapidly transforming from being delivered on proprietary,purpose-built hardware to

    capabilities running on intelligent and composable infrastructure.We are transforming the network from a

    statically configured and inflexible offering,to a network which can be provisioned to specific end users,specific

    verticals and specific needs on a standard server-based infrastructure.Greater customer value is being derived

    from this flexibility and programmability.

    The foundation of the 5G network requires an intelligent infrastructure built on NFV and SDN-based

    architecture that takes advantage of server volume economics,virtualization and cloud technologies.This enables

    new services to be deployed more quickly and cost effectively.Intel has a growing portfolio of products and

    technologies that deliver solutions to help network transformation,bringing advanced performance and

    intelligence from the network edge to the core of the data center.

    Open source software is one key part of the portfolio,which unlocks the platform capabilities of the network

    for packet processing.Intel invented the Data Plane Development Kit(DPDK),later co-founded as an open

    source project,and currently leads its growth with the community,helping make DPDK a de-facto standard for

    packet processing.In addition to DPDK,Intel has significantly contributed to other important open source

    projects,including Open Virtual Switch(OVS),FD.io,Vector Packet Processing(VPP)for network

    stack,Tungsten Fabric(TF)for virtual router,and HYPERSCAN for pattern matching.

    We have a skilled and committed team in China who have contributed to these open source projects over the

    years,and continue to collaborate with our partners in these communities to solve challenging network

    problems.As a good linkage with the Chinese ecosystem,it is with great pride that the team presents this book as a

    resource to help contributors who want to get involved,influence communities,and drive continued innovation.

    Sandra Rivera

    Senior Vice President and General Manager

    Network Platforms Group

    Intel 5G Executive Sponsor推荐序二

    The rise of Cloud and Edge computing has brought about a shift in networking

    technology.Increasingly,purpose-built physical systems are being replaced with flexible,adaptable solutions built

    on open source technology.Open software is driving the innovation that powers this evolution,with Software-

    Defined Networking(SDN)and network function virtualization paving the way for tremendous growth in

    connected services.

    Intel is a strong contributor to open source software across technologies and market segments.Intel has been

    a leader in advancing the open networking ecosystem,contributing to projects such as the Data Plane Development

    Kit(DPDK)for data plane acceleration; Open Virtual Switch(OVS)and Vector Packet Processing(VPP)

    for virtual switch; OpenStack Neutron,OpenDaylight(ODL)and Tungsten Fabric(TF)for SDN; the Open

    Networking Automation Platform(ONAP)for orchestration and automation; and Open Platform Network

    Function Virtualization(OPNFV).

    This book draws from the deep experience of Intel software engineers who work in open source networking

    communities and discusses how these projects fit as part of a complete stack for cloud infrastructure.We are proud

    to offer this resource to help contributors who want to get involved,influence communities,and drive continued

    innovation.

    Imad Sousou

    Corporate Vice President,Intel Corporation

    General Manager,Intel System Software Products前言

    自1991年Linux 诞生，时间已经走过了接近三个十年。即将而立之年的 Linux早已没有了初生时的稚

    气，正在各个领域展示自己成熟的魅力。

    以Linux为基础，也衍生出了各种开源生态，比如网络，比如存储。而生态离不开形形色色的开源项

    目，在人人谈开源的今天，一个又一个知名的开源项目正在全球野蛮生长。当然，本书的主题仅限于

    Linux开源网络生态，面对其中一个又一个扑面而来而又快速更迭的新项目新名词，我们会有一定的紧迫

    感想去了解这些他们背后的故事，也会有一定的动力去踏上Linux开源网络世界之旅。面对这样的一段旅

    途，我们心底浮现的最为愉悦的开场白或许应该是“说实话，我学习的热情从来都没有低落过。Just for

    Fun.”，正如Linus在自己的自传《Just for Fun》中所希望的那样。

    面对Linux开源网络这么一个庞大而又杂乱的世界，让人最为惴惴不安的问题或许是：我该如何更快

    更好的适应这个全新的世界？人工智能与机器学习领域里研究的一个很重要的问题是“为什么我们小时候

    有人牵一匹马告诉我们那是马，于是之后我们看到其他的马就知道那是马了？”针对这个问题的一个结论

    是：我们头脑里形成了一个生物关系的拓扑，我们所认知的各种生物都会放进这个拓扑的结构里，而我

    们随着年纪不断成长的过程就是形成并完善各种各样或树形或环形等拓扑的过程，并以此来认知我们所

    面对的各种新事物。

    由此可见，或许我们认知Linux开源网络世界最快也最为自然的方式就是努力在脑海里形成它的拓

    扑，并不断的进行细化。比如这个生态里包括了什么样的层次，每个层次里又有什么样的项目去实现，各个项目又实现了哪些服务以及功能，这些功能又是以什么样的方式实现的，等等，对于我们感兴趣的

    项目又可以更为细致的去勾勒它其中的脉络。就好似我们头脑里形成的有关一个城市的地图，它有哪些

    区，区里又有哪些标志建筑以及街道，对于我们熟悉的地方可以将它的周围进行放大细化，甚至于一个

    微不足道的角落。

    本书的组织形式

    本书的内容组织正是为了尽一切能力帮助读者能够形成有关 Linux 开源网络世界比较细致的拓扑。

    首先是前两章，对Linux开源网络的生态以及Linux本身对网络的支持与实现进行了阐述，希望能够帮助读

    者对Linux开源网络有个全面的基本的认识和了解。

    第1章主要基于Linux基金会划分的开源网络技术层次框架，对Linux开源网络生态进行整体的介绍。

    此外，也介绍了网络有关的开源组织与标准架构。

    第2章详尽的介绍了Linux虚拟网络的实现，包括Linux环境下一些网络设备的虚拟化形式，以及组建

    虚拟化网络时涉及到的主要技术，为更深一步对Linux开源网络生态下的开源项目展开讨论打下基础。

    然后第3～7章的内容对Linux开源网络生态各个层次中处于主导地位的、较为流行的项目进行介绍。

    按照认识的发展规律，通过前面两章的介绍我们已经对Linux开源网络世界有了全局的认识和了解，接下

    来就可以以兴趣或工作需要为导向，选择一个项目进行深入的钻研和分析。这些章节的内容也是希望能

    够尽量帮助读者形成对相应项目的比较细致的拓扑，并不求对所有实现细节的详尽分析。网络数据平面的性能开销复杂多样且彼此关联，第3章即对相关的优化技术与项目进行讨论，包括

    DPDK、OVS-DPDK、FD.IO等。

    第4章讨论网络的控制面，并介绍主要开源 SDN(软件定义网络)控制器，包括OpenDaylight与

    Tungsten Fabric等。

    第5章与第6章分别对OpenStack与Kubernetes两种主要云平台中的网络支持进行讨论。没有网络，任

    何虚拟机或者容器都将只是这个虚拟世界中的孤岛，不知道自己生存的价值。

    第7章讨论网络世界中的大脑——编排器。内容主要涵盖两种开源的编排器，包括ONAP与OPNFV。

    感谢

    作为英特尔的开源技术中心，参与各个Linux开源网络项目的开发与推广是再为自然不过的事情。除

    了为各个开源项目的完善与稳定贡献更多的思考和代码，我们也希望能通过这本书让更多的人更快捷的

    融入Linux开源网络世界的大家庭。

    如果没有 Sandra Rivera(英特尔高级副总裁兼网络平台事业部总经理)、Imad Sousou(英特尔公司

    副总裁兼系统软件产品部总经理)、Mark Skarpness(英特尔系统软件产品部副总裁兼数据中心系统软件

    总经理)、Timmy Labatte(网络平台事业部副总裁兼软件工程总经理)、练丽萍(英特尔系统软件产品

    部网络与存储研发总监)、冯晓焰(英特尔系统软件产品部安卓系统工程研发总监)、周林(网络平台

    事业部中国区软件开发总监)、梁冰(英特尔系统软件产品部市场总监)、王庆(英特尔系统软件产品

    部网络与存储研发经理)的支持，这本书不可能完成，谨在此感谢他们的关怀与帮助。

    也要感谢本书的编辑孙学瑛老师与宋亚东老师，从选题到最后的定稿，整个过程中，都给予我们无

    私的帮助和指导。

    然后要感谢参与各章内容编写的各位同事，他们是郭瑞景、陆连浩、秦凯伦、徐琛杰、应若愚、丁

    亮、朱礼波、黄海滨、任桥伟、梁存铭、胡雪焜、胡嘉瑜、王潇、何少鹏、姚磊、倪红军、吴菁菁、陈

    兆彦。为了本书的顺利完成，他们付出了很多努力。

    最后感谢所有对Linux开源网络技术抱有兴趣或从事各个Linux开源网络项目工作的人，没有你们的源

    码与大量技术资料，本书便会成为无源之水。

    作者目 录

    封面

    作者简介

    扉页

    推荐序一

    推荐序二

    前言

    第1章 Linux开源网络

    1.1 开源网络组织

    1.1.1 云计算与三大基金会

    1.1.2 LFN

    1.2 网络标准及架构

    1.2.1 OpenFlow

    1.2.2 SDN

    1.2.3 P4

    1.2.4 ETSI的NFV参考架构

    1.3 Linux开源网络生态

    1.3.1 开源硬件

    1.3.2 虚拟交换

    1.3.3 Linux操作系统

    1.3.4 网络控制

    1.3.5 云平台

    1.3.6 网络编排

    1.3.7 网络数据分析

    1.3.8 网络集成

    第2章 Linux虚拟网络

    2.1 TAPTUN设备

    2.2 Linux Bridge

    2.3 MACVTAP

    2.4 Open vSwitch

    2.5 Linux Network Namespace

    2.6 iptablesNAT

    2.7 虚拟网络隔离技术

    2.7.1 虚拟局域网(VLAN)

    2.7.2 虚拟局域网扩展(VxLAN)

    2.7.3 通用路由封装GRE

    2.7.4 通用网络虚拟化封装(Geneve)

    第3章 高性能数据平面3.1 高性能数据面基础

    3.1.1 内核旁路

    3.1.2 平台增强

    3.1.3 DPDK

    3.2 NFV和NFC基础设施

    3.2.1 网络功能虚拟化

    3.2.2 从虚拟机到容器的网络IO虚拟化

    3.2.3 NFVi平台设备抽象

    3.3 OVS-DPDK

    3.3.1 OVS-DPDK 概述

    3.3.2 OVS-DPDK性能优化

    3.4 FD.IO：用于报文处理的用户面网络协议栈

    3.4.1 VPP

    3.4.2 FD.IO子项目

    3.4.3 与OpenDaylight 和OpenStack集成

    3.4.4 vBRAS

    第4章 网络控制

    4.1 OpenDaylight

    4.1.1 ODL社区

    4.1.2 ODL体系结构

    4.1.3 YANG

    4.1.4 ODL子项目

    4.1.5 ODL应用实例

    4.2 Tungsten Fabric

    4.2.1 Tungsten Fabric体系结构

    4.2.2 Tungsten Fabric 转发平面

    4.2.3 Tungsten Fabric实践

    4.2.4 Tungsten Fabric应用实例

    4.2.5 Tungsten Fabric与OpenStack集成

    第5章 OpenStack网络

    5.1 OpenStack网络演进

    5.2 Neutron体系结构

    5.2.1 网络资源模型

    5.2.2 网络实现模型

    5.2.3 Neutron软件架构

    5.3 Neutron Plugin

    5.3.1 ML2 Plugin

    5.3.2 Service Plugin

    5.4 Neutron Agent

    第6章 容器网络

    6.1 容器6.1.1 容器技术框架

    6.1.2 Docker

    6.1.3 Kubernetes

    6.2 Kubernetes网络

    6.2.1 Pod内部的容器间通信

    6.2.2 Pod间通信

    6.2.3 Pod与Service之间的网络通信

    6.2.4 Kubernetes外界与Service之间的网络通信

    6.3 Kubernetes CNI

    6.4 Service Mesh

    6.4.1 Sidecar模式

    6.4.2 开源Service Mesh方案

    6.5 OpenStack容器网络项目Kuryr

    6.5.1 Kuryr起源

    6.5.2 Kuryr架构

    第7章 网络编排与集成

    7.1 ETSI NFV MANO

    7.1.1 ETSI标准化进展

    7.1.2 OASIS TOSCA

    7.1.3 开源编排器

    7.2 ONAP

    7.2.1 ONAP基本框架

    7.2.2 ONAP应用场景

    7.3 OPNFV

    7.3.1 OPNFV上游

    7.3.2 OPNFV项目

    7.3.3 OPNFV CI

    7.3.4 OPNFV典型用例第1章 Linux开源网络

    在人人谈开源的今天，看着一个又一个知名的开源项目在全球快速发展，开发者会非常想去了解这

    些开源项目。囿于本书的主题，我们只会努力去对Linux开源网络道出个一二三来。1.1 开源网络组织

    1.1.1 云计算与三大基金会

    在形形色色的开源组织里，有三个巨无霸的角色，就是Linux基金会、OpenStack基金会和Apache基金

    会。而三大基金会又与盛极一时的云计算有着千丝万缕的关系。

    整体而言，云计算的开源体系可以分为硬件、容器虚拟化与虚拟化管理、跨容器和资源调度的管理

    和应用。在这几个领域里，Linux基金会关注硬件、容器及资源调度管理，在虚拟化层面，也有KVM和

    Xen等为人熟知的项目。在容器方面，Linux基金会和Docker联合发起了OCI(Open Container

    Initiative)；在跨容器和资源调度管理上，Linux 基金会和 Kubernetes 发起了 CNCF(Cloud Native

    Computing Foundation)。相比之下，OpenStack基金会更为聚焦，专注于虚拟化管理。

    (1)Linux基金会

    Linux基金会的核心目标是推动Linux的发展。我们耳熟能详的Xen、KVM、CNCF等，都来自Linux基

    金会。

    Linux基金会采用的是会员制，分为银级、金级、白金级三个等级，白金级是最高等级。Linux 基金

    会的会员数量不胜枚举，不过由于白金级高达50万美元的年费门槛，白金级会员却是一份短名单，仅包

    括思科、富士通、惠普、华为、IBM、Intel、NEC、甲骨文、高通、三星和微软等知名企业。

    值得一提的是，作为白金级会员的华为，在Linux基金会成功建立了一个项目——OpenSDS，这是首

    个由我国主导的 Linux 基金会项目。OpenSDS 旨在为不同的云、容器、虚拟化等环境创建一个通用开放

    的SDS(Software Defined Storage)解决方案，提供灵活的按需供给的数据存储服务。

    另外，2018年3月，由英特尔开源技术中心中国团队主导的车载虚拟化项目ACRN也被Linux基金会接

    受并发布。ACRN是一个专为物联网和嵌入式设备设计的管理程序，目标是创建一个灵活小巧的虚拟机管

    理系统。通过基于 Linux 的服务操作系统，ACRN 可以同时运行多个客户操作系统，如 Android、Linux

    其他发行版或RTOS，使其成为许多场景的理想选择。

    (2)OpenStack基金会

    近些年，在开源的世界，OpenStack应该是最为红火的面孔之一。OpenStack基金会就是围绕

    OpenStack项目发展而来的。2012年9月，在OpenStack发行了第6个版本Folsom的时候，非营利组织

    OpenStack基金会成立。OpenStack基金会最初拥有24名成员，共获得了1000万美元的赞助基金，由

    RackSpace的Jonathan Bryce担任常务董事。OpenStack社区决定OpenStack项目从此以后都由OpenStack基金

    会管理。

    OpenStack基金会的职责为推进OpenStack的开发、发布以及能作为云操作系统被采纳，并服务于来自

    全球的所有28000名个人会员。

    OpenStack基金会的目标是为OpenStack开发者、用户和整个生态系统提供服务，并通过资源共享，推

    进 OpenStack 公有云和私有云的发展，辅助技术提供商在OpenStack中集成新兴技术，帮助开发者开发出

    更好的云计算软件。OpenStack 基金会在成立之初就设立了专门的技术委员会，用来指导 OpenStack技术相关的工作。对

    于技术问题讨论、某项技术决策和未来技术展望，技术委员会负责提供指导性建议和意见。除此之外，技术委员会还要确保OpenStack项目的公开性、透明性、普遍性、融合性和高质量。

    一般情况下，OpenStack技术委员会由13位成员组成，他们完全是由OpenStack社区中有过代码贡献的

    开发者投票选举出来的，通常任职6个月后需要重选。有趣的是，其中的6位成员是在每年秋天选举产生

    的，另外7位是在每年春季选举产生的，通过时间错开保持了该委员会成员的稳定性和延续性。技术委员

    会成员候选人的唯一条件是，该候选人必须是OpenStack基金会的个人成员，除此之外无其他要求。而

    且，技术委员会成员也可以同时在OpenStack基金会其他部门兼任职位。

    而随着越来越多的用户在生产环境中使用OpenStack，以及OpenStack生态圈里越来越多的合作伙伴在

    云中支持OpenStack，社区指导用户使用和产品发展的使命就变得越来越重要。鉴于此，OpenStack用户委

    员会应运而生。

    OpenStack用户委员会的主要任务是收集和归纳用户需求，并向董事会和技术委员会报告；以用户反

    馈的方式向开发团队提供指导；跟踪OpenStack部署和使用，并在用户中分享经验和案例；与各地

    OpenStack用户组一起在全球推广OpenStack。

    (3)Apache基金会

    Apache基金会简称为ASF，在它支持的Apache项目与子项目中，所发行的软件产品都需要遵循

    Apache许可证。

    对于开发者来说，在Apache的生态世界中，有“贡献者→提交者→成员”这样的成长路径。积极为

    Apache社区贡献代码、补丁或文档就能成为贡献者。通过会员的指定，能够成为提交者，就会拥有一

    些“特权”。提交者中的优秀分子可以“毕业”成为成员。

    Apache 基金会为孵化项目提供组织、法律和财务方面的支持，目前其已经监管了数百个开源项目，包括Apache HTTP Server、Apache Hadoop、Apache Tomcat等。其中，Kylin就是中国首个Apache顶级项

    目。

    1.1.2 LFN

    为了解决项目太多、协调性太差，从而导致的整个生态系统不协调的问题，2018年年初，ONAP、OPNFV、OpenDaylight、FD.IO、PDNA和SNAS等Linux基金会旗下的六大网络开源项目聚集在一起，创

    立了用于跨项目合作的 LFN(LF Networking Fund)。

    LFN 的这六大创始开源项目，覆盖了从数据平面到控制平面、编排、自动化、端到端测试等领域，为跨项目协作提供了一个平台。通过统一的董事会管理，LFN消除不同项目之间的重叠或冗余，创建更

    高效的流程，加快开源网络的发展进程。

    LFN 仅仅为各个项目之间的合作提供一个平台，其中的每个项目都将继续保持技术独立和发布蓝

    图，六个项目的技术指导委员会(TSC)保持不变，但是将由一个技术咨询委员会(TAC)监管。此外，还有一个营销顾问委员会(MAC)，统一负责六个项目的市场活动。

    新的组织结构解决了各个成员项目之间重复收费的问题，在LFN成立之前，成员想要加入任何一个

    项目都需要缴纳会员费，但是LFN成立之后只需要缴纳LFN的会员费，就可以参加已经加入及未来即将加

    入的任何LFN项目。1.2 网络标准及架构

    1.2.1 OpenFlow

    作为SDN的主要实现方式，OpenFlow发展史就是SDN的发展史，对整个SDN的发展起着功不可没的

    作用。

    1.OpenFlow起源

    OpenFlow起源于斯坦福大学的Clean Slate项目组，Clean Slate项目的最终目的非常大胆，是要“重新发

    明因特网(Reinvent the Internet)”，改变被认为已经略显不合时宜且难以进化发展的现有网络基础架

    构。

    Clean Slate项目的学术主任(Faculty Director)——Nick McKeown教授，与他的学生Martin Casado发

    现，如果将传统网络设备的数据平面(Data Plane，数据转发)和控制平面(Control Plane，路由控制)

    相分离，通过集中式的控制器(Controller)以标准化的接口对各种网络设备进行管理和配置，那么将为

    网络资源的设计、管理和使用提供更多的可能性，从而更容易推动网络的革新与发展。于是，他们于

    2008年4月在ACM Communications Review发表了题为OpenFlow:enabling innovation in campus networks的

    论文，首次提出了OpenFlow的概念。

    OpenFlow将控制逻辑从网络设备中剥离出来，形成了如图1-1所示的控制转发分离架构。

    图1-1 OpenFlow控制转发分离架构

    在OpenFlow发展的初期，为了达到更好利用现有硬件的目的，需要网络设备中内置一种稀有且昂贵

    的特殊内存TCAM(Ternary Content-Addressable Memory)来保存流表。

    设计OpenFlow 的初衷是无须更改已搭载TCAM 的网络设备硬件，仅通过软件升级即可实现网络行为

    变更，能够一边考虑应用现有架构，一边构建虚拟网络，也是OpenFlow广受业界关注的原因所在。

    TCAM 在初期的 OpenFlow 设计思想中占有非常重要的地位，很多网络设备中也确实都搭载了

    TCAM,Nick McKeown教授的论文中就有这样的表述：“目前最先进的以太网交换机和路由器都包含一个

    能够以线速实现防火墙、NAT、QoS 等功能并收集统计信息的流表(通常是基于TCAM 构建)，而我们

    正是利用了这一点。”

    2.OpenFlow版本变迁OpenFlow 自产生以来，一直由开放网络基金会(ONF,Open Networking Foundation，一个致力于开放

    标准和 SDN 应用的用户主导型组织)管理，OpenFlow协议也经历了很多个版本。

    2009年年底发布的1.0版本相对比较弱，只是奠定了OpenFlow协议的基调，它反映的是早期学者对网

    络设备的一种理想模型假设。这种假设认为交换机有很大的TCAM表项。

    但是这种假设脱离了实际，TCAM 表项资源非常宝贵，能够保存的流表非常有限，很难满足现实生

    产环境的需要。

    分别于2011年2月与5月发布的OpenFlow1.1和1.2版本增加了很多特性，其中最重要的是引入了Group

    和Multi Table概念。Group是对一个或者多个端口的抽象，应用于组播或者广播，多个流表可以引用同一

    个组。Multi Table指的是多级流表。Group和Multi Table的提出可以很大地减少流表数量，更加贴近实际

    的交换机模型。

    OpenFlow 1.3于2012年发布，是对1.1和1.2版本的升级，特性变得更为丰富，主要增加了 Meter 和

    QOS，可以对网络带宽进行限速并进行有效的管理，从而保证服务质量。

    3.OpenFlow设计思路

    OpenFlow协议的思路是网络设备维护一个FlowTable，并且只通过FlowTable对报文进行处理，FlowTable本身的生成、维护和下发完全由外置的控制器实现。此外，OpenFlow 交换机把传统网络中完全

    由交换机或路由器控制的报文转发，转换为由交换机和控制器共同完成，从而实现报文转发与路由控制

    的分离。控制器则通过事先规定好的接口操作OpenFlow交换机中的流表，达到数据转发的目的。

    在 OpenFlow 交换机中，包含了安全通道、多级流表和组表。通过安全通道，OpenFlow 交换机可以

    和控制器建立基于 OpenFlow 协议的连接；而流表则用来匹配OpenFlow交换机收到的报文；组表用来定

    义流表需要执行的动作。

    4.FlowTable

    OpenFlow 通过用户定义的或预设的规则匹配和处理网络包。一条 OpenFlow 的规则由匹配域、优先

    级、处理指令和统计数据等字段组成，如图1-2所示。

    图1-2 OpenFlow规则

    在一条规则中，可以根据网络包在L2、L3或者L4等网络报文头的任意字段进行匹配，比如以太网帧

    的源MAC地址、IP包的协议类型和IP地址或者TCPUDP的端口号等。目前OpenFlow的规范中还规定了

    Switch设备厂商可以有选择性地支持通配符进行匹配。OpenFlow未来还计划支持对整个数据包的任意字

    段进行匹配。

    所有OpenFlow的规则都被组织在不同的FlowTable中，而在同一个FlowTable中，按规则的优先级进

    行先后匹配。一个 OpenFlow Switch 可以包含一个或者多个FlowTable，从0开始依次编号排列。

    OpenFlow规范中定义了流水线式的处理流程，如图1-3所示。当网络数据包进入Switch后，必须从

    table 0开始依次匹配，table可以按从小到大的次序越级跳转，但不能从某一table向前跳转至编号更小的

    table。当数据包成功匹配一条规则后，将首先更新该规则对应的统计数据(如成功匹配数据包总数目和

    总字节数等)，然后根据规则中的指令进行相应操作，比如跳转至后续某一table继续处理，修改或立即

    执行该数据包对应的Action Set等。当数据包已经处于最后一个table时，其对应的Action Set中的所有Action将被执行，包括转发至某一端口、修改数据包的某一字段、丢弃数据包等。OpenFlow规范对目前

    所支持的Instructions和Actions进行了完整详细的说明和定义。

    图1-3 数据包处理流程

    5.OpenFlow通信通道

    OpenFlow 协议主要通过对不同类型消息的处理来实现控制器与交换机之间的路由控制。目前，OpenFlow 主要支持三种消息类型，分别是 Controller-to-Switch、Asynchronous(异步消息)及

    Symmetric(对称消息)。

    ● Controller-to-Switch：指由 Controller 发起，Switch 接收并处理的消息，主要包括Features、Configuration、Modify-State、Read-Stats和Barrier等消息。这些消息主要由Controller对Switch进行状态查

    询和修改配置等操作。

    ● Asynchronous：由Switch发送给Controller，用来通知Switch上发生的某些异步事件的消息，主要包

    括Packet-in、Flow-Removed、Port-Status和Error等。例如，当某一条规则因为超时而被删除时，Switch 将

    自动发送一条Flow-Removed消息通知Controller，以方便Controller进行相应的操作，比如重新设置相关规

    则。

    ● Symmetric：主要用来建立连接，检测对方是否在线等，都是些双向对称的消息，包括Hello、Echo

    与厂商自定义消息。

    Hello、Features、Echo又分别包含了Request与Reply消息，每一对Request与Reply的Transaction ID相

    同，交换机通过ID进行识别对应事件端口。图1-4所示即为在通常的交换机事件发生时，主要经过的几个

    交互步骤。

    图1-4 OpenFlow交换机与控制器的交互过程

    6.OpenFlow应用随着OpenFlow以及SDN的发展和推广，其研究和应用领域也得到了不断拓展，比如网络虚拟化、安

    全和访问控制、负载均衡、绿色节能，以及与传统网络设备交互和整合等。下面重点介绍网络虚拟化和

    负载均衡。

    (1)网络虚拟化——FlowVisor

    网络虚拟化的本质是对底层网络的物理拓扑进行抽象，在逻辑上对网络资源进行分片或整合，从而

    满足各种应用对于网络的不同需求。为了达到这个目的，FlowVisor实现了一个特殊的OpenFlow

    Controller，可以看作其他不同用户或应用的Controller与网络设备之间的一层代理，如图1-5所示。因此，不同用户或应用可以使用自己的Controller来定义不同的网络拓扑，同时FlowVisor又可以保证这些

    Controller之间能够互相隔离且互不影响。

    图1-5 FlowVisor

    FlowVisor 不仅是一个典型的 OpenFlow 应用案例，同时还是一个很好的研究平台，目前已经有很多

    基于FlowVisor的研究和应用。

    (2)负载均衡——Asterx

    传统的负载均衡方案一般需要在服务器集群的入口处，通过一个gateway监测、统计服务器的工作负

    载，并据此将用户请求动态地分配到负载相对较轻的服务器上。既然网络中的所有网络设备都可以通过

    OpenFlow进行集中式的控制和管理，同时服务器的负载又可以及时地反馈给OpenFlow Controller，那么

    OpenFlow就非常适合做负载均衡的工作。

    如图1-6所示，基于OpenFlow的负载均衡模型Asterx通过Host Manager和Net Manager来分别监测服务

    器和网络的工作负载，然后将这些信息反馈给FlowManager，这样 Flow Manager 就可以根据这些实时的

    负载信息，重新定义网络设备上的OpenFlow规则，从而将用户请求(即网络包)按照服务器的能力进行

    调整和分发。

    图1-6 Asterx1.2.2 SDN

    基于OpenFlow为网络带来的可编程的特性，斯坦福的Nick McKeown教授和他的团队进一步提出了

    SDN(Software Defined Network，软件定义网络)的概念。

    SDN 将控制功能从交换机中剥离出来，形成了一个统一的、集中式的控制平面，而交换机只保留了

    简单的转发功能，从而形成了转发平面(数据平面)。通过控制平面对数据平面的集中化控制，SDN 为

    网络提供了开放的编程接口，并实现了灵活的可编程能力，从而使网络能够真正地被软件定义，达到按

    需定制服务、简化网络运维、灵活管理调度的目标。

    在SDN中，网络设备只负责单纯的数据转发，可以采用通用的硬件。如果将网络中所有的网络设备

    视为被管理的硬件资源，参考操作系统的设计原理，则可以抽象出一个网络操作系统(Network OS)的

    概念。这个网络操作系统一方面抽象了底层网络设备的具体细节，负责与网络硬件进行交互，实现对硬

    件的编程控制和接口操作，同时还为上层应用访问网络设备提供了统一的管理视图和编程接口。基于这

    个网络操作系统，用户可以开发各种网络应用程序，通过软件定义逻辑上的网络拓扑，以满足对网络资

    源的不同需求，而无须关心底层网络的物理拓扑结构。

    1.SDN架构

    SDN 采用了如图1-7所示的基本架构，集中式的控制平面和分布式的转发平面相互分离，控制平面利

    用控制器、转发通信接口对转发平面上的网络设备进行集中式管理。

    图1-7 SDN基本架构

    ● 基础设施层(Infrastructure Layer)：主要承担数据转发功能，由各种网络设备构成，如数据中心

    的网络路由器，支持OpenFlow 的硬件交换机等。

    ● 控制层(Control Layer)：网络转发的控制管理平面，负责管理网络的基础设施，主要组成部分为

    SDN控制器。SDN控制器是整个网络的大脑、控制中心，主要功能是按照配置的业务逻辑，产生对应的

    数据平面的流转发规则，通过下发给网络设备，控制其进行数据转发。

    ● 应用层(Application Layer)：指商业应用。开发者可以通过SDN控制器提供的北向接口，如 REST

    接口实现应用和网络的联动，例如网络拓扑的可视化、监控等。

    ● 南向接口(Sorthbound Interface):SDN 控制器对网络的控制主要通过OpenFlow、NetConf等南向接

    口实现，包括链路发现、拓扑管理、策略制定、表项下发等。其中，链路发现和拓扑管理主要是控制其

    利用南向接口的上行通道对底层交换设备上报信息进行统一的监控和统计，而策略制定和表项下发则是

    控制器利用南向接口的下行通道对网络设备进行统一的控制。

    ● 北向接口(Northbound Interface)：北向接口是通过控制器向上层应用开放的接口，其目标是使得应用能够便利地调用底层的网络资源和能力。因为北向接口是直接为应用服务的，因此其设计需要密切

    联系应用的业务需求，比如需要从用户、运营商或产品的角度去考量。

    在SDN发展初期，控制平面的表现形式更多是以单实例的控制器出现，实现SDN的协议也以

    OpenFlow 为主，因此 SDN控制器更多指的是 OpenFlow 控制器。随着SDN的发展，ONF也在白皮书中提

    出了SDN的架构标准。广义的SDN支持丰富的南向协议，包括OpenFlow、NetConf、OVSDB、BGPLS、PCEP及厂商协议等，可实现灵活可编程和灵活部署，支持网络虚拟化、SR路由、智能分析和调度。

    与南向接口方面已有OpenFlow等国际标准不同，目前还缺少业界公认的北向接口标准。因此，北向

    接口的协议制定成为当前SDN领域竞争的一大焦点，不同的参与者或从各种角度提出了很多方案。据

    悉，目前至少有20种控制器，每种控制器都会对外提供北向接口，用于上层应用开发和资源编排。当

    然，对于上层的应用开发者来说，RESTful API是比较乐于采用的北向接口形式。

    2.SDN实现

    SDN需要某种方法使控制平面能够与数据平面进行通信。OpenFlow就是这样一种方法机制，但

    OpenFlow并非实现SDN的唯一途径。

    (1)IETF定义的开放SDN架构

    如图1-8所示，IETF定义的开放SDN架构的核心思路是重用当前的技术而不是OpenFlow，比如利用

    Netconf和已有的设备接口。IETF的Netconf使用XML来配置设备，旨在减少与自动化设备配置有关的编程

    工作量。这种架构充分地利用了现有设备，能够更大限度地保护已有的投资。

    图1-8 IETF定义的开放SDN架构

    (2)Overlay网络技术

    如图1-9所示，是在现行的物理 IP 网络基础上建立叠加逻辑网络(Overlay Logical Network)，屏蔽

    底层物理网络差异，实现网络资源的虚拟化，使得多个逻辑上彼此隔离的网络分区，以及多种异构的虚

    拟网络可以在同一共享的物理网络基础设施上共存。图1-9 Overlay网络

    在网络技术领域，Overlay 是一种网络架构上叠加的虚拟化技术模式，是指建立在已有网络上的虚拟

    网，由逻辑节点和逻辑链路构成。其大体框架是对基础的物理IP 网络不进行大规模修改的条件下，实现

    应用在网络上的承载，并能与其他网络业务分离。

    Overlay 网络的主要思想可被归纳为解耦、独立、控制三个方面。解耦是指将网络的控制从网络物理

    硬件中脱离出来，交给虚拟化的Overlay逻辑网络处理。

    独立是指Overlay网络承载于物理IP网络之上，因此只要IP可达，那么相应的虚拟化网络就可以被部

    署，而无须对原有物理网络架构(例如原有的网络硬件、原有的服务器虚拟化解决方案、原有的网络管

    理系统、原有的IP地址等)做出任何改变。Overlay网络可以便捷地在现网上部署和实施，这是它最大的

    优势。

    控制是指叠加的逻辑网络将以软件可编程的方式被统一控制，网络资源可以和计算资源、存储资源

    一起被统一调度和按需交付。

    Overlay网络叠加的实现方案包括VXLAN、NVGRE、NVP等，主要由虚拟化技术厂商主导，比如

    VMware在其虚拟化平台中实现了VxLAN技术、微软在其虚拟化平台中实现了NVGRE技术，其中最典型

    的代表是Nicira公司提出的NVP(Network Virtualization Platform，网络虚拟化平台)。NVP支持在现有的

    网络基础设施上利用隧道技术屏蔽底层物理网络的实现细节，实现了网络虚拟化，并利用逻辑上集中的

    软件进行统一管控，实现网络资源的按需调度。

    Overlay 网络叠加方案与虚拟化的整合比较便捷，但是在实际应用中，效果会受到底层网络质量的影

    响。同时，基于网络叠加的技术也会增加网络架构的复杂度，并降低数据的处理性能。

    Overlay与SDN可以说天生就是适合互相结合的技术组合。对Overlay网络中的虚拟机进行管理和控

    制，而SDN恰好可以完美地做到这一点。

    (3)基于专用接口

    基于专用接口的方案的实现思路是不改变传统网络的实现机制和工作方式，通过对网络设备的操作

    系统进行升级改造，在网络设备上开发出专用的 API 接口，管理人员可以通过 API 接口实现网络设备的

    统一配置管理和下发，改变原先需要一台台设备登录配置的手工操作方式，同时这些接口也可供用户开

    发网络应用，实现网络设备的可编程。典型的基于专用接口的SDN实现方案是的思科ONE架构。

    1.2.3 P4

    现有的SDN解决方案将控制平面与转发平面分离，并提供了控制平面的可编程能力。而事实上，这

    种通过软件编程实现的控制平面的功能，在传统的高级交换机和路由器上也都能实现，差别只是厂商把

    这些功能固化在了硬件中，第三方难以介入进行定制或二次开发。虽然一些高级设备提供了 SDK，以便

    用户能够进行一定程度的定制，但也必须受厂商制定的规范限制，能做的事情十分有限。目前SDN所做

    的就是打破这些限制，让设备和网络更加灵活，让用户不被厂商的规范所绑定，从而拥有无限的可能。

    现有的SDN解决方案为用户开放的是控制平面的可编程能力，那么转发平面又如何呢？在正常情况

    下，对于转发设备来说，数据包的解析转发流程是由设备转发芯片固化的，所以设备在协议的支持方面

    并不具备扩展能力。并且，厂商扩展转发芯片所支持的协议特性，甚至开发新的转发芯片以支持新的协

    议，代价非常高，需要将之前的硬件重新设计，这样势必导致更新的成本居高不下、时间周期长等一系列问题。所以，在一定程度上，这种将支持的协议与功能同硬件绑定的模式限制了网络的快速发展。

    因此，新一代的SDN解决方案必须让转发平面也具有可编程能力，让软件能够真正定义网络和网络

    设备。而P4(Programming Protocol-Independent Packet Processors)正是为用户提供了这种能力，打破了

    硬件设备对转发平面的限制，让数据包的解析和转发流程也能通过编程去控制，使得网络及设备自上而

    下地真正向用户开放。

    P4 起源于由 Nick 教授等联合发布的一篇论文 P4: Programming Protocol-Independent Packet

    Processors，该论文在SDN领域引起了极大的反响和关注度。Nick教授等人又发布了“The P4 Language

    Specification”“Barefoot白皮书”等文件。再之后，ONF成立了开源项目PIF，为P4提供配套的中间表示IR。

    P4是一门主要用于数据平面的编程语言，可简单地将 P4 语言与 C 语言进行对比：

    ● C语言程序代码-> gcc 或其他编译器-> 可执行文件，运行在 x86 CPU、ARM等目标上。

    ● P4语言代码-> P4 编译器-> 硬件或其他形式输出，运行在CPU、FPGA、ASIC 等目标上。

    P4解决数据平面的可编程问题，OpenFlow是解决控制平面的可编程问题。它们的关系如图1-10所

    示。

    图1-10 OpenFlow与P4的关系

    由于 P4的定位是高级编程语言，所以 P4可以定义任意自己想要的配置。它可以让设备与SDN控制器

    通过OpenFlow通信，也可以通过本地的交换机操作系统控制，一切皆由P4程序设计而定。在P4语言中，OpenFlow只是一个程序，两者可以协同工作，事实上也已经有了使用 P4语言编写的实现 OpenFlow 功能

    的程序openflow.p4。

    如图1-11所示为P4的架构，P4语言具有下面三个特性：

    ● 协议无关性：网络设备不与任何特定的网络协议绑定，用户可以使用P4语言描述任何网络数据平

    面的协议和数据包处理行为。

    ● 目标无关性：用户不需要关心底层硬件的细节就可实现对数据包处理方式的编程描述。这一特性通

    过P4前后端编译器实现，前端编译器将P4高级语言程序转换成中间表示IR，后端编译器将IR编译成设备

    配置，自动配置目标设备。

    ● 可重构性：允许用户随时改变包解析和处理的程序，并在编译后配置交换机，真正实现现场可重配

    能力。

    为了实现上述特性，P4语言的编译器采用了模块化的设计，各个模块之间的输入输出都采用标准格

    式的配置文件，如p4c-bm模块的输出可以作为载入到bmv2模块中的JSON格式配置文件。图1-11 P4的架构

    P4编译器本质上是将在P4程序中表达的数据平面的逻辑翻译成一个在特定可编程数据包处理硬件上

    的具体物理配置。因此，编译器后端部分自然与其支持的硬件目标紧密结合，而其前端部分则可以在各

    个P4可编程目标之间通用。这就意味着一个P4程序的具体实现可根据被编译的目标而改变。

    P4语言联盟是一个P4开源社区，由工业界和学术界成员组成。它有两个目标：定义P4语言的正式规

    范，维持开放源码的P4开发工具和P4的参考程序。

    P4语言联盟发布了一个P4参考程序“switch.p4”，它能实现各种流行的标准数据平面协议和功能，包括

    L2和L3(IPv4和IPv6)转发、虚拟局域网(vLAN)、生成树协议(STP)、等价多路径、链路聚合、虚

    拟路由和转发(VRF)、IP组播、多协议标签交换、各类隧道协议(如虚拟可扩展局域网、通用路由封

    装、IP-in-IP和Q-in-Q)、数据包镜像、服务质量控制、访问控制、RPF验证、传输协议(TCP、UDP

    等)。

    1.2.4 ETSI的NFV参考架构

    由于电信运营商网络包括大量的专有硬件设备，如果运营商想要推出一个新的网络服务，如负载均

    衡或防火墙，就往往需要购置各种新硬件，之后再为这些新硬件匹配合适的空间和电力。能否以软件的

    方式解决这些问题？NFV(网络功能虚拟化)应运而生。

    NFV 由运营商联盟提出，为了加速部署新的网络服务，运营商倾向于放弃笨重且昂贵的专用网络设

    备，转而使用标准的IT虚拟化技术拆分网络功能模块，如DNS、NAT、Firewall等。通过将硬件与虚拟化

    技术结合，NFV可以实现所有的网络功能。

    一些运营商在欧洲通信标准协会ETSI(European Telecommunications Standards Institute)成立了NFV

    工作组(ETSI ISG NFV)，开展网络功能虚拟化研究、标准制定和产业推动工作，致力于将虚拟化技术

    应用于电信领域。

    NFV 系统中软件、虚拟层和网络功能分层解耦，打破了电信行业原有的“黑盒化”封闭系统，降低了

    电信准入门槛，有利于打造更具活力的生态系统，从根本上改变了 CT 的发展生态。一方面，充分解耦后

    的碎片化网络对运营商的管理和运维带来了巨大的挑战，这需要依赖新型的管理系统；另一方面，NFV

    给网络带来极大的灵活性和敏捷性，但这依赖于新的管理系统和自动化编排系统。

    如图1-12所示为ETSI NFV标准框架。图1-12 ETSI NFV标准框架

    其中，NFV infrastructure(NFVI)、MANO和VNF(Virtual Network Function)是顶层的概念实体。

    NFVI包含了虚拟化层(Hypervisor或容器管理系统，如Docker)及物理资源，如交换机、存储设备

    等。NFVI可以跨越若干个物理位置进行部署，为这些物理站点提供数据连接的网络也成为NFVI的一部

    分。

    VNF与NFV虽然是三个同样的字母调换了顺序，但含义截然不同。NFV是一种虚拟化技术或概念，解决了将网络功能部署在通用硬件上的问题；而VNF指的是具体的虚拟网络功能，提供某种网络服务，是一种软件，利用NFVI提供的基础设施部署在虚拟机、容器或物理机中。相对于VNF，传统的基于硬件

    的网元可以称为PNF。VNF和PNF能够单独或混合组网，形成Service Chain，提供特定场景下所需的

    E2E(End-to-End)网络服务。

    MANO提供了NFV的整体管理和编排，向上接入OSSBSS(运营支撑系统业务支撑系统)，由

    NFVO(NFV Orchestrator)、VNFM(VNF Manager)及VIM(Virtualised Infrastructure Manager)虚拟化

    基础设施管理器三者共同组成。

    编排(Orchestration)一词最早出现于艺术领域，指的是按照一定的目的对各种音乐、舞蹈元素进行

    排列，以期达到最好的效果。而引申到网络的范畴，编排则指以用户需求为目的，将各种网络服务单元

    进行有序的安排和组织，生成能够满足用户要求的服务。在NFV架构中，凡是带“O”的组件都有一定的编

    排作用，各个VNF、PNF 及其他各类资源只有在合理编排下，在正确的时间做正确的事情，整个系统才

    能发挥应有的作用。

    VIM 主要负责基础设施层虚拟化资源和硬件资源的管理、监控和故障上报，并面向上层 VNFM 和

    NFVO 提供虚拟化资源池，负责虚拟机和虚拟网络的创建和管理，OpenStack和VMware都可以作为VIM。

    VNFM负责 VNF 的生命周期管理，如上线、下线，状态监控。VNFM基于VNFD(VNF Descriptor，描述

    一个VNF模块部署与操作行为的配置模板)来管理VNF。NFVO负责NS(Network Service)生命周期的管

    理和全局资源调度。1.3 Linux开源网络生态

    乱花渐欲迷人眼，Linux开源网络世界基本上可以用图1-13理个明白。

    图1-13 Linux开源网络

    1.3.1 开源硬件

    大部分商业交换机是软硬件一体的，买Cisco就自带NX-OSiOS，买H3C就自带Commvare。而白牌交

    换机的出现使得交换机可以选择操作系统成为可能，如同买PC可以安装Windows，也可以安装Linux一

    样。

    在OCP等开放组织、众多芯片商、ODM商、互联网用户的推动下，业界已经在逐步走向开放。在此

    基础上，网络设备硬件的设计也正朝着模块化、开放标准化的方向革新，软硬件分离也成为一种趋势，如图1-14所示。

    图1-14 传统的网络设备硬件转换到软硬件分离的新模式

    OCP在2013年年中左右成立了Networking工作组，致力于构建开放标准化的数据中心网络相关技术。

    当前阶段主要聚焦在TOR上：首先联合芯片及硬件厂商制定TOR硬件标准，并推出开放网络安装环境

    (ONIE,Open Network Install Environment)，试图解除交换机软硬件绑定的黑盒状态，形成硬件标准化、软硬件分离的新模式；其次试图将交换机进行ASIC抽象，去构建一个开放标准的API编程接口，屏蔽硬

    件芯片及平台差异，并最终促成开源网络操作系统的诞生。2016年2月，Facebook成立了新的TIP(Telecom Infra Project)项目，将运营商、基础设施提供商、系

    统集成商及其他的科技企业聚集到一起，共同合作发展新技术，用新技术改变传统的构建部署电信网络

    基础设施的方法，并运用开放的OCP模型刺激创新。

    1.3.2 虚拟交换

    1.DPDK

    DPDK(Data Plane Development Kit)可提供高性能的数据包处理库和用户空间驱动程序。它不同于

    Linux系统以通用性设计为目的，而是专注于网络应用中数据包的高性能处理。具体体现在 DPDK 绕过了

    Linux 内核协议栈对数据包的处理过程，运行在用户空间上利用自身提供的数据平面库来收发数据包。

    在最近的一项研究中，使用DPDK的OVS(Open vSwitch)平均吞吐量提高了75%。该技术被英特尔

    公司推广，可以在多处理器上使用，并作为 EPA(Enhanced Platform Awareness，旨在加速数据平面)技

    术的一部分。EPA除DPDK以外的主要技术是大页、NUMA和SR-IOV：大页通过减少页面查找提高VNF

    的效率；NUMA确保工作负载使用处理器本地的内存；SR-IOV可以使网络流量旁路管理程序，直接转到

    虚拟机。

    2.OVS-DPDK

    DVS是一个具有工业级质量的多层虚拟交换机，它支持OpenFlow和OVSDB协议。通过可编程扩展，可以实现大规模网络的自动化(配置、管理和维护)。最初的OVS 版本是通过 Linux 内核进行数据分发

    的，因而用户能够得到的最终吞吐量受限于Linux网络协议栈的性能。

    OVS-DPDK使用DPDK技术对Open VSwitch进行优化。OVS-DPDK是用户态的vSwitch，网络包直接

    在用户态进行处理。

    3.FD.IO

    FD.IO(Fast Data InputOutput)是Linux基金会旗下的开源项目，LFN六大创始项目之一，成立于

    2016年2月11日。

    FD.IO在通用硬件平台上提供了具有灵活性、可扩展、组件化等特点的高性能IO服务框架，该框架

    支持高吞吐量、低延迟、高资源利用率的用户空间IO服务，并可适用于多种硬件架构和部署环境。

    FD.IO的关键组件来自Cisco捐赠的商用VPP(Vector Packet Processing，矢量分组处理引擎)库。VPP

    和FD.IO其他子项目如NSH_ SFC、Honeycomb、ONE等一起用于加速数据平面。

    所谓 VPP 向量报文处理是与传统的标量报文处理相对而言的。传统报文处理方式的逻辑是：按照到

    达先后顺序来处理，第一个报文处理完，处理第二个，依次类推；函数会频繁嵌套调用，并最终返回。

    相比而言，向量报文处理则是一次并行处理多个报文，相当于一次处理一个报文数组，扩展了整个数据

    包集合的查找和计算开销，从而提高了效率。

    1.3.3 Linux操作系统

    在Linux中，网络分为两个层次，分别是网络协议栈，以及接收和发送网络协议的设备驱动程序。网

    络协议栈是硬件中独立出来的部分，主要用来支持TCPIP等多种协议，而网络设备驱动程序连接了网络

    协议栈和网络硬件设备。Linux中与网络有关的实现主要有：

    ● 网络驱动程序。● Linux VLAN：一种虚拟设备，只有绑定一个真实网卡才能完成实际的数据发送和接收。

    ● Linux Bridge(网桥)：工作于二层的虚拟网络设备，功能类似于物理的交换机。其他Linux网络设

    备可以被绑定到Bridge上作为从设备，并被虚拟化为端口。当一个从设备被绑定到Bridge上时，就相当于

    真实网络中的交换机端口插入了一个连接有终端的网线。

    ● Linux TCPIP协议栈：可以处理IP、ICMP、ARP、TCPUDPSCTP等协议。

    ● Linux Socket函数库：从Berkeley大学开发的BSD UNIX系统中移植而来。网络的Socket数据传输是

    一种特殊的IO。

    ● Linux应用层协议：处理更高层的协议，常用的有DNS、HTTP、SSH、Telnet等。

    1.3.4 网络控制

    为了更简洁、方便、友好地使用各种硬件资源，SDN 把网络设备的控制功能提取出来，统一放到其

    控制器(SDNC,SDN Controller)中，只保留其数据转发的功能，并抽象出一个网络操作系统的概念。

    1.OpenDaylight

    ODL(OpenDaylight)是由 Linux 基金会和多家行业巨头如 Cisco、Juniper 和Broadcom等公司一起创

    立的开源项目，其目的在于推出一个通用的SDN控制平台。

    ODL支持OpenFlow、Netconf和OVSDB等多种南向接口，是一个广义的SDN控制平台。ODL 支持分

    布式集群，不仅可以管理更大的网络，性能更好，还可以相互容灾备份，提升系统的可靠性。它包括一

    系列功能模块，可以动态地组合，提供不同的服务。

    ODL 主要的功能模块有拓扑管理、转发管理、主机监测、交换机管理等。ODL控制平台引入了模型

    驱动的设计思想，构建了服务抽象层 MD-SAL，是控制器模块化的核心，能够自动适配底层不同的设

    备，使开发者专注于业务应用的开发。

    2.ONOS

    ONOS(Open Network Operating System)顾名思义就是要定义一个开放的网络操作系统，其核心的

    服务对象是服务提供商。既然服务对象要达到运营商的级别，那么其重点就需要考虑可靠性与性能，并

    能够在白盒系统上创建高性能可编程的运营商网络。

    ONOS 的北向接口抽象层和 API 可以使得应用开发变得更加简单，而通过南向接口抽象层和API则可

    以管控OpenFlow或传统设备。北向接口基于具有全局网络视图的框架，南向接口包括 OpenFlow 和

    Netconf，以便能够管理虚拟和物理交换机。ONOS的核心是分布式的，因此可以水平扩展，架构如图1-15

    所示。图1-15 ONOS架构

    ONOS 在诞生之初就是为了对抗 ODL，希望能成为控制器的主流。目前主要的参与者包括 ATT、CIENA、VERIZON、NTT、爱立信、华为、NEC、INTEL、富士通等。

    3.Tungsten Fabric

    Tungsten Fabric是由OpenContrail(由Juniper开源的SDN控制器)向Linux基金会迁移并更名而来的。

    Tungsten Fabric是一个可扩展的多云网络平台，能够与包括Kubernetes和OpenStack在内的多个云平台集

    成，并且支持私有云、混合云和公有云部署。

    1.3.5 云平台

    1.OpenStack

    2010年7月，RackSpace和美国国家航空航天局合作，分别贡献出RackSpace云文件平台代码和NASA

    Nebula平台代码，并以Apache许可证开源发布了OpenStack第一个版本 Austin，以 RackSpace 所在的美国

    德州(Texas)首府命名，计划每隔几个月发布一个全新版本，并且以26个英文字母为首字母，从A~Z顺

    序命名后面的版本代号。

    第一版Austin仅有Swift和Nova两个项目，分别来自RaceSpace云文件平台和NASA Nebula平台，目的

    为云计算提供对象存储和计算平台。

    在2012年9月的Folsom版本中，OpenStack社区将Nova项目中的网络模块和块存储模块剥离出来，成

    立了两个新的核心项目，分别是 Quantum 和 Cinder。但由于商标版权冲突问题，后来经过提名投票评选

    Quantum被更名为Neutron。

    Neutron通过插件的方式对众多的网络设备提供商进行支持，比如Cisco、Juniper等，同时也支持很多

    流行的技术，比如Openvswitch、OpenDaylight和SDN等。

    Neutron的插件分为Core Plugin和Service Plugin两类。Core Plugin负责管理和维护Neutron的Network、Subnet和Port三类核心资源的状态信息，这些信息是全局的，只需要也只能由一个Core Plugin管理。

    Havana版本中实现了ML2(Modular Layer 2)Core Plugin用于取代原有的Core Plugin。对三类核心资源进

    行操作的REST API被neutron-server看作Core API，由Neutron原生支持。

    ● Network：代表一个隔离的二层网段，是为创建它的租户而保留的一个广播域。Subnet和Port始终被

    分配给某个特定的Network。Network的类型包括Flat、VLAN、VxLAN、GRE等。

    ● Subnet：代表一个IPv4v6的CIDR地址池，以及与其相关的配置，如网关、DNS等，该Subnet中的

    VM 实例随后会自动继承该配置。Sunbet必须关联一个Network。

    ● Port：代表虚拟交换机上的一个虚机交换端口。VM 的网卡 VIF 连接 Port后，会拥有 MAC 地址和

    IP 地址。Port 的 IP 地址是从 Subnet 地址池中分配的。

    Service Plugin 即为除 Core Plugin 以外其他的插件，包括 l3 router、firewall、loadbalancer、VPN、metering 等，主要实现 L3~L7的网络服务。这些插件要操作的资源比较丰富，对这些资源进行操作的

    REST API 被 neutron-server 看作 Extension API，需要厂家自行进行扩展。

    2.Kubernetes

    以前，想要在线上服务器中部署一个应用，首先需要购买一个物理服务器，在服务器上安装一个操

    作系统，然后安装应用所需要的各种依赖环境，最后才能进行应用的部署。在虚拟化技术出现以后，在本地操作系统之上增加了一个 Hypervisor 层，通过Hypervisor层，可以创

    建不同的虚拟机，限定每个虚拟机能够使用的物理资源，并且每个虚拟机都是分离、独立的。例如，虚

    拟机A使用1个CPU、4GB内存、100GB磁盘，虚拟机B使用2个CPU、8GB内存、200GB磁盘等，从而实现

    物理资源利用率的最大化。如此一来，一台物理机就可以部署多个应用，每个应用都可以独立运行在一

    个虚拟机里。

    但是，因为每一个虚拟机都是一个完整的操作系统，所以需要为其分配一定的物理资源，随着虚拟

    机数量的增多，操作系统本身消耗的资源势必增多。而且开发与运维的环境都比较复杂，比如前后端开

    发及测试，基于服务器或云环境运维等，这就导致了开发环境和线上环境的差异，开发环境与运维环境

    之间无法达到很好的衔接，在部署上线应用时，需要花时间处理环境不兼容的问题。

    容器技术的出现解决了这样的问题。容器可以帮开发者把开发环境及应用整个打包带走，打包好的

    容器可以在任何的环境下运行，从而解决开发环境与运维环境不一致的问题。

    容器技术正在成为对云计算领域具有深远影响的变革技术。作为容器的“重度玩家”,Google 在内部的

    成千上万台服务器上夜以继日地运行着无以计数的容器，并开发了Borg用于管理如此巨量的基础设施，而就在几年前，Borg团队将多年积累的容器运行编排管理经验聚集到了一个名为Kubernetes的新项目之上

    并开源。2015年，Google 将 Kubernetes 项目捐赠给新成立的CNCF基金会。

    为了与Borg主题保持一致，Kubernetes又被命名为“九之七项目”(Project Seven of Nine)，这也是为

    什么Kubernetes的Logo 有七条边。

    Kubernetes，又称为k8s(首字母为k、首字母与尾字母之间有8个字符、尾字母为 s，所以简称为

    k8s)，或者简称为“kube”，设计初衷是在主机集群之间提供一个能够自动化部署、可扩展、应用容器可

    运营的平台。在整个k8s生态系统中，能够兼容大多数的容器技术实现，比如Docker与Rocket。

    如图1-16所示，与网络、存储、安全性、遥测和其他服务整合，Kubernetes可以提供全面的容器基础

    架构。借助 Kubernetes 的编排功能，可以构建跨多个容器的应用服务，并且能够跨集群调度、扩展这些

    容器，长期、持续管理这些容器的健康状况。

    图1-16 Kubernetes与其他服务整合

    1.3.6 网络编排

    NFV 给网络带来极大的灵活性和敏捷性，但它们的实现依赖于新的管理系统和自动化编排系统。在

    NFV 体系中，引入了全新的管理和编排系统——NFV MANO(NFV Management and Orchestration)系

    统，编排器作为其中的核心部件，是网络灵活调整和资源动态调度的关键，是下一代网管系统的核心。

    NFV 编排器由两层构成：服务编排和资源编排，可以控制新的网络服务，并将VNF集成到虚拟架构

    中，NFV编排器还能验证并授权NFV基础设施(NFVI)的资源请求。VNF管理器能够管理VNF的生命周期。VIM能够控制并管理NFV基础设施，包括了计算、存储和网络等资源。为了使NFV MANO行之有

    效，它必须与现有系统中的应用程序接口(API)集成，以便跨多个网络域使用多厂商技术。同样，OSSBSS也需要与MANO实现互操作。

    1.3.7 网络数据分析

    1.PNDA

    2016年8月16日，Linux基金会发布了一个网络数据分析平台PNDA(Platform for Network Data

    Analytics)。较早支持PNDA项目的公司包括Cisco、Deepfield、FRINX、Intersec、Moogsoft、NGENA、Ontology、OpenDataSoft、Tupl等。

    PNDA旨在通过集成、缩放和管理一组公开的数据处理技术，并提供部署分析应用和服务的端到端平

    台来降低复杂性。PNDA 能够支持批量的实时数据流探索和分析，甚至可以达到每秒数百万消息的规

    模。

    2.SNAS

    SNAS(Streaming Network Analytics System)是一个实时跟踪和分析网络路由拓扑数据的框架。系统

    将从网络的第2层和第3层挖掘和收集数据，包括IP信息、服务质量及物理和设备规范。

    如图1-17所示，SNAS 架构主要包括一个高速的收集器、一个高性能的消息总线、消费者应用、数据

    库、RESTful API及用户应用。高性能的收集器生成解析后的数据并发送给消息总线，消费者应用负责通

    过消息总线API将数据存储在数据库里，然后用户应用可以通过RESTful API访问数据库里的数据。

    图1-17 SNAS架构

    1.3.8 网络集成

    OPNFV(Open Platform for NFV)是运营商级的开源网络集成参考平台。NFV架构里包含多个开源组

    件，不同开源组件间的集成和测试非常关键。OPNFV则提供了多组件持续开发、集成和测试的开源方

    案，并不断地向上游组织输出电信级 NFV平台的增强特性。

    OPNFV 目前已经集成了 OpenStack、ODL、ONOS、DPDK、ONAP、FD.IO 等多个关键组件，发布

    了7个版本、超过60多个集成套件和几十个自动化测试工具，为NFV集成和测试提供了大量开源参考方案

    和自动化框架。第2章 Linux虚拟网络

    在一个传统的物理网络里，可能有一组物理Server，上面分别运行着各种各样的应用，比如Web服

    务、数据库服务等。为了彼此之间能够互相通信，每组物理Server都拥有一个或多个物理网卡(NIC)，这些NIC被连接在物理交换设备上，例如交换机(Switch)，如图2-1所示。

    图2-1 传统物理网络结构

    在虚拟化技术被引入后，上述的多个应用可以按虚拟机的形式分享同一物理Server，虚拟机的生成与

    管理由Hypervisor或VMM完成，于是图2-1所示的网络结构被演化为图2-2。

    图2-2 虚拟网络结构

    虚拟机的网络功能由虚拟网卡(vNIC)提供，Hypervisor可以为每个虚拟机创建一个或多个 vNIC。

    站在虚拟机的角度，这些 vNIC 等同于物理的网卡。为了实现与传统物理网络等同的网络结构，与 NIC

    一样，Switch 也被虚拟化为虚拟交换机(vSwitch)。各个vNIC连接在vSwitch的端口上，最后这些

    vSwitch通过物理Server的物理网卡访问外部的物理网络。由此可见，一个虚拟的二层网络结构，主要是

    完成两种网络设备的虚拟化：NIC硬件与交换设备。

    此外，由于网络虚拟化概念的引入，对于原来基于物理二层以太网络和三层 IP网的网络隔离也提出

    了诸多方面新的要求，例如可扩展性、安全性、可管理性等。

    本章即对Linux环境下一些网络设备的虚拟化形式，以及组建虚拟化网络时涉及的主要技术进行介绍，这些内容也是基于Linux更深一步展开一切网络项目的基础。2.1 TAPTUN设备

    TAPTUN是Linux内核实现的一对虚拟网络设备，TAP工作在二层，TUN工作在三层，Linux内核通

    过TAPTUN设备向绑定该设备的用户空间应用发送数据；反之，用户空间应用也可以像操作硬件网络设

    备那样，通过TAPTUN设备发送数据。

    基于TAP驱动，即可以实现虚拟网卡的功能，虚拟机的每个vNIC都与Hypervisor中的一个TAP设备相

    连。当一个TAP设备被创建时，Linux设备文件目录下将会生成一个与之对应的字符设备文件，用户空间

    应用可以像打开普通文件一样打开这个文件进行读写。

    当对TAP设备文件执行write操作时，对于Linux网络子系统来说，相当于位于内核空间的TAP设

    备收到了数据，Linux内核收到此数据后将根据网络配置进行后续处理，处理过程类似于普通的物理网卡

    从外界收到数据。当用户空间应用执行read请求时，相当于向内核查询TAP设备上是否有数据需要被

    发送，有的话则取出到用户空间里，从而完成 TAP 设备发送数据的功能。在这个过程中，TAP 设备可以

    被当成本机的一个网卡，而操作TAP设备的应用程序相当于另外一台计算机，它通过readwrite系统调

    用，和本机进行网络通信。TAPTUN的数据传输过程如图2-3所示。

    实际上，除了虚拟网卡的驱动，TAPTUN 驱动程序还包括一个字符设备驱动，内核通过字符设

    备devnettun与用户空间应用传递网络数据，同时，利用网卡驱动部分接收并发送来自TCPIP协议栈的网

    络数据，或反过来将收到的网络数据传给协议栈处理。

    图2-3 TAPTUN的数据传输过程2.2 Linux Bridge

    Linux Bridge(网桥)是工作在二层的虚拟网络设备，功能类似于物理的交换机。

    对于普通的网络设备来说，只有两端，从一端进来的数据会从另一端出去，如物理网卡从外面物理

    网络收到的数据会转发给内核协议栈，而从内核协议栈过来的数据会转发到外面的物理网络中。而

    Bridge 不同，Bridge 有多个端口，数据可以从任何端口进来，进来之后从哪个端口出去要看MAC地址，和物理交换机的原理类似。

    Bridge可以绑定其他Linux网络设备作为从设备，并将这些从设备虚拟化为端口，当一个从设备被绑

    定到 Bridge 上时，就相当于真实网络中的交换机端口插入了一个连接有终端的网线。

    如图2-4所示，Bridge设备br0绑定了真实设备eth0与虚拟设备tap0tap1。此时，对于Hypervisor的网络

    协议栈来说，只看得到br0，并不会关心桥接的细节。当这些从设备接收数据包时，会将其提交给br0决定

    数据包的去向，br0会根据MAC地址与端口的映射关系进行转发。

    图2-4 Linux Bridge结构

    因为Bridge工作在第二层，所以绑定在br0上的从设备eth0、tap0与tap1均不需要再设置IP地址，对上

    层路由器来说，它们都位于同一子网，因此只需为br0设置IP地址(Bridge设备虽然工作于二层，但它只

    是Linux网络设备抽象的一种，能够设置IP地址也可以理解)，比如10.0.1.024。此时，eth0、tap0与tap1

    均通过br0处于10.0.1.024网段。

    因为具有自己的IP地址，br0可以被加入路由表，并利用它发送数据，而最终实际的发送过程则由某

    个从设备来完成。此时相当于Linux拥有了另外一个隐藏的虚拟网卡和Bridge相连，IP地址可以看成是这

    个网卡的，当有符合此IP地址的数据到达Bridge 时，内核协议栈认为收到了一包目标为本机的数据，此时

    应用程序可以通过Socket接收它。

    Bridge的实现有一个限制：当一个设备被绑定到Bridge上时，该设备的IP地址会变得无效，Linux不再

    使用该IP地址在三层接收数据。比如，如果eth0本来具有自己的IP地址192.168.1.1，在绑定到br0之后，它

    的IP地址会失效，用户程序不再能接收或发送到这个IP地址的数据，只有目的地址为br0 IP的数据包才会被Linux接收。2.3 MACVTAP

    传统的Linux网络虚拟化技术采用的是TAP+Bridge方式，将虚拟机连接到虚拟的TAP网卡，然后将

    TAP网卡绑定到Linux Bridge。这种解决方案实际上就是使用软件，用服务器的CPU模拟网络，但这种技

    术主要有三个缺点：

    ● 每台宿主机内都存在Bridge会使网络拓扑变得复杂，相当于增加了交换机的级联层数。

    ● 同一宿主机上虚拟机之间的流量直接在Bridge完成交换，使流量监控、监管变得困难。

    ● Bridge是软件实现的二层交换技术，会加大服务器的负担。

    针对云计算中的复杂网络问题，业界主要提出了两种技术标准进行扩展：802.1Qbg与802.1Qbh。

    802.1Qbh Bridge Port Extension主要由VMware与 Cisco 提出，尝试从接入层到汇聚层提供一个完整的虚拟

    化网络解决方案，尽可能达到通过软件定义一个可控网络的目的。它扩展了传统的网络协议，因此需要

    新的网络设备支持，成本较高。

    802.1Qbg Edge Virtual Bridging(EVB)主要由 HP 等公司提出，尝试以较低成本利用现有设备改进

    软件模拟的网络。802.1Qbg 的一个核心概念是 VEPA，它通过端口汇聚和数据分类转发，把宿主机上原

    来由 CPU 和软件来做的网络处理工作转移到接入层交换机上，减轻宿主机的CPU 负载。同时，使得在一

    级的交换机上做虚拟机网络流量监控成为可能。

    为支持这种新的虚拟化网络技术，Linux 引入了新的网络设备模型——MACVTAP，用来简化虚拟化

    环境下的桥接网络，代替传统的TAP+Bridge组合，同时支持新的虚拟化网络技术，如 802.1 Qbg。和 TAP

    设备一样，每一个 MACVTAP设备都拥有一个对应的 Linux 字符设备，因此能直接被 KVMQEMU使用，方便完成网络数据交换工作。

    MACVTAP的实现基于传统的 MACVLAN。MACVLAN允许在主机的一个网络接口上配置多个虚拟

    的网络接口，这些网络接口有自己独立的 MAC 地址，也可以配置 IP 地址进行通信。MACVLAN 下的虚

    拟机或者容器和主机在同一个网段中，共享同一个广播域。MACVLAN 和 Bridge 比较相似，但因为它省

    去了 Bridge，所以配置和调试起来比较简单，而且效率也相对更高。

    同一个物理网卡上的各个MACVTAP设备，都可以拥有属于自己的 MAC地址和IP地址。使用

    MACVTAP，实现如图2-4所示的网络拓扑，管理员不再需要建立网桥br0，并且同时把物理网卡eth0、连

    接虚拟机的TAP设备tap0和tap1加入网桥br0中，而只需要在物理网卡eth0上建立两个MACVTAP设备，并

    让虚拟机直接使用这两个MACVTAP设备就可以了。

    MACVTAP设备支持3种操作模式：

    ● VEPA模式：VEPA模式是默认模式。在这种模式下，两个在同一个物理网卡上的 MACVTAP 设备

    (都处于 VEPA 模式)通信，网络数据会从一个MACVTAP 设备通过底层的物理网卡发往外界的交换

    机。此时，外界交换机必须支持Hairpin模式，只有这样才可以把网络数据重新送回物理网卡，传送给此

    物理网卡上的另一个MACVTAP设备。

    ● 桥接模式：在桥接模式下，同一个物理网卡上的所有桥接模式的MACVTAP设备直接两两互通，它

    们之间的通信，网络数据不会经过外界交换机。● 私有模式：在私有模式时，类似于VEPA模式时外界交换机不支持Hairpin模式的情况。此时，同一

    个物理设备上的MACVTAP设备之间不能通信。2.4 Open vSwitch

    Open vSwitch是一个具有产品级质量的虚拟交换机，它使用C语言进行开发，从而充分考虑了在不同

    虚拟化平台间的移植性，同时它遵循Apache2.0许可，因此对商用也非常友好。

    如前所述，对于虚拟网络来说，交换设备的虚拟化是很关键的一环，vSwitch负责连接vNIC与物理网

    卡，同时也桥接同一物理Server内的各个vNIC。Linux Bridge已经能够很好地充当这样的角色，为什么还

    需要Open vSwith呢？

    在传统数据中心中，网络管理员通过对交换机的端口进行一定的配置，可以很好地控制物理机的网

    络接入，完成网络隔离、流量监控、数据包分析、Qos配置、流量优化等一系列工作。

    但是在云环境中，仅凭物理交换机的支持，管理员无法区分被桥接的物理网卡上流淌的数据包属于

    哪个VM、哪个OS及哪个用户，Open vSwitch的引入则使云环境中虚拟网络的管理以及对网络状态和流量

    的监控变得容易。

    比如，我们可以像配置物理交换机一样，将接入到Open vSwitch(Open vSwitch同样会在物理Server

    上创建一个或多个vSwitch供各个虚拟机接入)上的各个VM分配到不同的VLAN中实现网络的隔离。也可

    以在Open vSwitch端口上为VM配置Qos，同时Open vSwitch也支持包括NetFlow、sFlow很多标准的管理接

    口和协议，可以通过这些接口完成流量监控等工作。

    此外，Open vSwitch也提供了对Open Flow的支持，可以接受Open Flow Controller的管理。

    总之，Open vSwitch在云环境中的各种虚拟化平台上(比如Xen与KVM)实现了分布式的虚拟交换

    机，一个物理 Server 上的 vSwitch 可以透明地与另一个 Server上的vSwitch连接在一起，如图2-5所示。

    图2-5 Open vSwitch

    而Open vSwitch软件本身，则由内核态的模块以及用户态的一系列后台程序组成，其结构如图2-6所

    示。图2-6 Open vSwitch软件结构

    其中ovs-vswitchd是最重要的模块，实现了虚拟机交换机的后台，负责与远程的Controller进行通信，例如通过OpenFlow协议与OpenFlow Controller通信，通过sFlow协议同sFlow Trend通信。此外，ovs-

    switchd也负责同内核态模块通信，基于netlink机制下发具体的规则和动作到内核态的 datapath。datapath

    负责执行数据交换，也就是把从接收端口收到的数据包在流表(Flow Table)中进行匹配，并执行匹配到

    的动作。每个datapath都和一个流表关联，当datapath接收数据后，会在流表中查找可以匹配的Flow，执行

    对应的动作，比如转发数据到另外的端口。ovsdb-server是一个轻量级的数据库服务器，主要用来记录被

    ovs-switchd的配置信息。

    Open vSwitch还包括了一系列的命令行工具，主要包括：

    ● ovs-vsctl：查询和更新ovs-vswitchd的配置信息。

    ● ovsdb-client:ovsdb-server的客户端命令行工具。

    ● ovs-appctl：用来配置运行中的Open vSwitch daemon。

    ● ovs-dpctl：用来配置内核模块中的datapath。

    ● ovs-ofctl：通过OpenFlow协议查询和控制OpenFlow交换机和控制器。2.5 Linux Network Namespace

    Linux Namespace提供了对系统资源的封装和隔离，处于不同Namespace的进程拥有独立的全局系统资

    源，改变一个 Namespace 中的系统资源只会影响当前Namespace里的进程，对其他Namespace中的进程没

    有影响。Linux内核实现了多种不同类型的Namespace，提供对不同类型资源的隔离。其中，Network

    Namespace提供了对网络资源的隔离，每一个Network Namespace都拥有自己独立的网络栈、单独的网络

    设备、IP地址和端口号、IP路由表、防火墙规则、procnet目录。

    事实上，如果不考虑内存、CPU等其他共享的资源，仅从网络的角度来看，Network Namespace就和

    一台虚拟机一样，它可以在一台机器上模拟出多个完整的协议栈。如图2-7所示为Linux Nexwork

    Namespace结构。

    图2-7 Linux Network Namespace结构

    每个新的Network Namespace都默认有一个本地回环LO接口，此外，所有的其他网络设备，包括物

    理虚拟网络接口、网桥等，只能属于一个Network Namespace，每个Socket也只能属于一个Network

    Namespace。当新的network namespace被创建时，LO接口默认是关闭的，需要自己手动启动。

    创建 Network Namespace 也非常简单，使用 ip netns add 后面跟着要创建的Namespace 名称，如果相

    同名字的 Namespace 已经存在，会产生“Cannot create namespace”的错误。

    ip netns命令创建的Network Namespace会出现在varrunnetns目录下，如果需要管理其他不是ip netns

    创建的Network Namespace，只要在这个目录下创建一个指向对应 Network Namespace 文件的链接就可

    以。

    ip命令提供了ip netns exec子命令，可以在对应的Network Namespace中执行，比如要看Network

    Namespace 中有哪些网卡。而且，要执行的可以是任何命令，不只是和网络相关(和网络无关的命令执行的结果和在外部执行

    没有区别)。例如在下面例子中，执行 bash 命令之后，后面所有的命令都是在这个Network Namespace中

    执行的，好处是不用每次执行命令都要把ip netns exec NAME补全，缺点是无法清楚地知道自己当前所在

    的shell，容易混淆。

    有了不同的Network Namespace后，也就有了网络的隔离，但如果它们之间没有办法通信，也没有实

    际用处。要把两个网络连接起来，Linux提供了VETH pair。如前所述，可以把VETH pair当作双向的管

    道，从一端发送的网络数据，可以直接被另外一端接收到，也可以想象成两个 Namespace 直接通过一个

    特殊的虚拟网卡连接起来，可以直接通信。

    可以使用ip link add type veth 创建一对VETH pair，系统自动生成VETH0和VETH1两个网络接口，如

    果需要指定它们的名字，则可以使用ip link add vethfoo type veth peer name vethbar，此时创建出来的两个

    名字就是vethfoo和vethbar。需要记住的是VETH pair无法单独存在，删除其中一个，另一个也会自动消

    失。然后，可以把这对VETH pair分别放到创建的两个Namespace里，可以使用ip link set DEV netns

    NAME来实现。

    如图2-8所示，创建两个Network Namespace，分别命名为net0与net1，同时创建了 VETH pair 对 veth0

    与 veth1，将它们分别加入 net0与 net1，将两个 Network Namespace连接起来。

    图2-8 使用VETH pair连接两个Network Namespace

    虽然 VETH pair 可以实现两个 Network Namespace 之间的通信，但是当多个Namespace需要通信的时

    候，就无能为力了。涉及多个网络设备之间的通信，首先想到的是交换机和路由器。因为这里要考虑的

    只是同一个网络，所以只用到交换机的功能，也就是前面所述的网桥。

    和网桥有关的操作可以使用命令brctl，这个命令来自 bridge-utils包。

    然后可以创建VETH pair，比如veth0与veth1，并将一个VETH接口veth0加入Network Namespace，另

    一个VETH接口veth1加入Bridge。如图2-9所示，创建三个Network Namespace分别为net0、net1与net2，同时创建有Bridge br0，以及各

    个Network Namespace与br0之间连接的VETH pair,br0将net0、net1与net2连接起来。

    图2-9 使用Bridge连接Network Namespace2.6 iptablesNAT

    网络地址转换(NAT,Network Address Translation)是一种在IP数据包通过路由器或防火墙时重写来

    源IP地址或目的IP地址的技术。这种技术被普遍使用在有多台主机通过一个公有IP地址访问外部网络的私

    有网络中，NAT也可以被称作IP伪装(IP Masquerading)，可以分为目的地址转换(DNAT)和源地址转

    换(SNAT)两类。

    DNAT 主要用在从公网访问内部私网的网络数据流中。比如从公网访问地址为IP1的公网IP地址，NAT网关根据设定的DNAT规则，把IP数据报文包头内的目的IP地址IP1修改为内部的私网IP地址

    192.168.1.10，从而把IP数据报文发送给地址为192.168.1.10的内部服务器。DNAT可以用来将内部私网服

    务器上的服务暴露给公网使用。

    SNAT 主要应用在从内部私网访问公网的网络数据流中。比如内部私网 IP 地址为192.168.1.20的机器

    想访问外部公网IP地址为IP2的服务，NAT网管根据设定的SNAT规则，把IP数据报文包头内的源IP地址

    192.168.1.20修改为NAT网关自己的公网IP地址IP1。这样内网中没有公网IP地址的机器也能访问外部公网

    中的服务了。

    Linux中的NAT功能一般通过iptables实现。iptables是基于Linux内核的功能强大的防火墙。

    iptablesnetfilter在2001年加入到2.4内核中，netfilter作为iptables内核底层的实现框架而存在，它们之间的

    关系如图2-10所示。

    图2-10 iptables与netfilter的关系

    netfilter提供了一整套对hook函数管理的机制，可以在数据包流经的5处关键地方(Hook点)，分别

    是PREROUTING(路由前)、INPUT(数据包入口)、OUTPUT(数据包出口)、FORWARD(数据包

    转发)、POSTROUTING(路由后)，写入一定的规则对经过的数据包进行处理，规则一般的定义为“如

    果数据包头符合这样的条件，就这样处理数据包”。

    可以说iptablesnetfilter是按照规则来工作的，这些规则分别指定了源地址、目的地址、传输协议(如

    TCP、UDP、CMP)和服务类型(如HTP、FP和SMTP)等。数据包与规则匹配时，iptables 就根据规则

    定义的方法处理这些数据包，比如放行、拒绝和丢弃等。配置防火墙的主要工作就是添加、修改和删除

    这些规则。

    在每个关键点上，有很多已经按照优先级预先注册了的回调函数进行埋伏，设置的这些规则，就形

    成了一条链。INPUT规则链匹配目的地址是本机IP地址的数据报文，OUTPUT规则链匹配由本地进程发出的数据报文，FORWARD规则链匹配流经本机的数据报文，PREROUTING 规则链用来实现目的地址转换

    DNAT,POSTROUTING 规则链可以用来实现源地址转换 SNAT。它们的工作流程如图2-11所示。

    图2-11 iptablesnetfilter的工作流程

    防火墙为了达到“防火”的目的，就需要在内核中设置关卡，所有进出的报文都要通过这些关卡。经

    过检查后，符合放行条件的才能放行，符合阻拦条件的则需要被阻止。而这些关卡就是所谓的规则链。

    每个“链”上都放置了一串规则，但是这些规则有些很相似，例如 A 类规则都是对IP地址或者端囗的

    过滤，B类规则是修改报文。此时能把实现相同功能的规则放在一起组成“表”。如此一来，不同功能的规

    则，可以放置在不同的表中进行管理。

    如图2-12所示，iptables主要包含了FILTER、NAT和MANGLE三张常用表，分别负责数据包的过滤、网络地址转换及数据包内容的修改。

    图2-12 iptables常用表

    下面是一些iptables命令的使用示例：2.7 虚拟网络隔离技术

    随着网络虚拟化概念的引入，从可扩展性、安全性、可管理型性等多方面对网络隔离提出了新的要

    求。应对这些要求，可以使用两种不同类型的技术 VLAN 和隧道网络来实现。

    2.7.1 虚拟局域网(VLAN)

    LAN(Local Area Network，本地局域网)中的计算机通常使用Hub和Switch连接。一般来说，两台计

    算机连入同一个Hub或Switch时，它们就在同一个 LAN 中。一个 LAN 表示一个广播域，含义就是：LAN

    中的所有成员都会收到任意一个成员发出的广播包。

    VLAN(Virtual LAN，虚拟局域网)表示一个带有VLAN功能的Switch能将自己的端口划分出多个

    LAN。计算机发出的广播包可以被同一个LAN中的其他计算机收到，但位于其他LAN的计算机则无法收

    到。简单地说，VLAN将一个交换机在逻辑上分成了多个交换机，限制了广播的范围，在二层将计算机隔

    离到不同的VLAN中。

    比如说，有两组机器Group A和B，我们希望A中的机器可以相互访问，B中的机器也可以相互访问，但是A和B中的机器无法互相访问有两种方法。一种方法是使用两个交换机，A 和 B 分别接到一个交换

    机。另一种方法是使用一个带 VLAN功能的交换机，将 A 和 B 中的机器分别放到不同的 VLAN 中。需要

    注意的是，VLAN实现的只是二层的隔离，A和 B无法相互访问指的是二层广播包(比如arp)无法跨越

    VLAN 的边界，但在三层上(比如IP地址)是可以通过路由器让A和B互通的。

    使用VLAN，能够更好地控制广播风暴，提高网络整体的安全性，也能使网络管理更加简单直观。不

    同的VLAN由VLAN tag(VID)标明，IEEE 802.1Q规定了VLAN tag的格式。因此，在Linux上使用

    VLAN，需要加载8021q的内核模块：

    现在的交换机几乎都是支持 VLAN 的。交换机的端口通常有两种配置模式：Access和Trunk，如图2-

    13所示。

    图2-13 交换机Access端口和Trunk端口其中，Access 端口被打上了 VLAN tag，表明该端口属于哪个 VLAN,Access口只能属于一个 VLAN。

    Access 端口都是直接与计算机网卡相连的，这样从该网卡出来的数据包流入Access端口后就被打上了所

    在的 VLAN tag。

    Trunk 端口一般用于交换机之间的连接，可以允许多个 VLAN 通过，可以接收和发送多个 VLAN 的

    报文。如果划分了 VLAN，但是没有配置 Trunk，那么交换机之间的每个VLAN 间通信都要通过一条线路

    来实现。

    对Linux环境来说，如图2-14(a)所示，可以通过Linux Bridge、物理网卡等模拟交换机的VLAN环

    境。eth0 是宿主机上的物理网卡，有一个命名为eth0.10的子设备与之相连。eth0.10 就是 VLAN 设备，其

    VLAN ID 就是 VLAN 10。eth0.10 挂在命名为 brvlan10 的 Linux Bridge 上，虚拟机 VM1 的虚拟网卡 vent0

    也挂在brvlan10 上。

    这样配置的效果等同于宿主机用软件实现了一个虚拟交换机，上面定义了一个VLAN10,eth0.10和

    vnet0 都分别接到 VLAN10 的 Access端口上。而 eth0 就相当于一个 Trunk 端口，VM1 通过 vnet0 发出来

    的数据包会被打上 VLAN10 的标签。

    但是Linux在VLAN模拟上有一个不足，即需要多少个VLAN，就得创建多少个Bridge,Trunk端口也需

    要创建同样数量的类似eth0.10的虚口。这是由于Bridge的转发表没有VLAN tag的维度，要实现不同VLAN

    独立转发，只能使用多个Bridge实例实现转发表的隔离，如图2-14(b)所示。这里面，eth0.10 的作用是

    定义了VLAN10，而brvlan10 的作用是Bridge上的其他网络设备自动加入到 VLAN10 中。

    图2-14 Linux VLAN

    2.7.2 虚拟局域网扩展(VxLAN)

    VxLAN(Virtual Extensible Local Area Network，虚拟局域网扩展)是基于隧道(Tunnel)的一种网

    络虚拟化技术。隧道是一个虚拟的点对点的连接，提供了一条通路使封装的数据报文能够在这个通路上

    传输，并且在通路的两端分别对数据报文进行封装及解封装。某个协议的报文要想穿越IP网络在隧道中

    传输，必须要经过封装与解封装两个过程。隧道提供了一种某一特定网络技术的PDU穿过不具备该技术

    转发能力的网络的手段，如组播数据包穿过不支持组播的网络。

    VxLAN将二层报文用三层协议进行封装，可以对二层网络在三层范围内进行扩展。如图2-15所示，把二层网络的整个数据帧封装在UDP报文中，送到VxLAN隧道对端。隧道对端的虚拟或者物理网络设备

    再将其解封装，取出里面的二层网络数据帧发送给真正的目的节点。图2-15 VxLAN

    VxLAN协议头使用了24bit表示VLAN ID，可以支持1600多万个VLAN ID。RFC协议7348号中定义了

    VxLAN协议。

    VxLAN应用于数据中心内部，使虚拟机可以在互相连通的三层网络范围内迁移，而不需要改变IP地

    址和MAC地址，保证业务的连续性。

    Linux 对VxLAN协议的支持时间并不是很久，直到2012年Stephen Hemminger才把相关的工作合并到

    内核中，并最终出现在3.7.0内核版本中，应该尽量使用新版本的内核，以免出现因为版本太低导致功能

    或者性能上的问题。

    2.7.3 通用路由封装GRE

    GRE(RFC1701)也是基于隧道的一种网络虚拟化技术。与VxLAN相比，GRE使用的是IP报文而非

    UDP作为传输协议。同时，不同于VxLAN只能封装二层以太网数据帧，GRE可以封装多种不同的协议，包括IP报文(RFC2784,RFC2890)、ARP、以太网帧(NVGRE,RFC 7637)等。

    如图2-16所示，GRE包头中的type字段，可以指明被封装的数据包类型，例如IP报文(0x0800)、以

    太网帧(0x6558)等。同时，使用GRE包头中的key字段，可以区分不同虚拟网络的ID(类似于VxLAN的

    VNI和VLAN中的tag)，从而达到隔离不同虚拟网络的目的。图2-16 GRE

    如图2-17所示，在GRE隧道中，路由器会在封装数据包的IP头部指定要携带的协议，并建立到对端路

    由器的虚拟点对点连接。其中，Passenger 协议表示要封装的乘客协议，比如 IPX、AppleTalk、IP、IPSec、DVMRP 等，Carrier 协议表示封装乘客协议的GRE协议，插入Transport和Passenger协议之间，在

    GRE包头中定义了传输的协议，Transport协议表示IP协议携带了封装的乘客协议，这个传输协议通常实施

    在点对点的GRE连接中(GRE是无连接的)。

    图2-17 GRE隧道

    相比于VxLAN,GRE更加灵活，可以支持的协议也更多。但是目前物理网卡支持GRE协议的还不是很

    多，大部分GRE协议的处理还要依靠主机CPU，会增加CPU的负载。

    2.7.4 通用网络虚拟化封装(Geneve)

    为了应对 VLAN 只能有4094的上限，利用隧道技术，产生了诸如 VxLAN、NVGRE、STT(无状态传输隧道)等多种技术来实现虚拟网络的隔离要求。但是这类技术互相不能兼容，所以提出了通用网络

    虚拟化封装 Geneve(Generic Network Virtualization Encapsulation)。

    Geneve技术的RFC正式标准还没产生，还处于IETF草案的阶段。Geneve主要的目的是适应虚拟网络

    技术的发展和隔离要求，定义一种通用的网络虚拟化隧道封装协议，能够尽可能地兼容目前的VxLAN、NVGRE等正式RFC标准的功能，并且提供高可扩展性来应对以后虚拟网络技术的发展。

    Geneve综合了VxLAN和NVGRE两者的特点，首先使用了UDP作为传输协议，同时吸收了GRE可以封

    装多种不同类型的数据包的优点。Geneve封装以太网帧的案例如图2-18所示。

    图2-18 GENEVE封装以太网帧的案例

    Geneve包头中有一个24bit的VNI字段，可以用来指定不同的虚拟网络ID。同时，包头中也有type字

    段，用来指定封装的内部报文协议。第3章 高性能数据平面

    数据平面的性能在很大程度上取决于网络 IO 的性能，而网络数据包从网卡到用户空间的应用程序需

    要经历多个阶段，如图3-1所示。

    图3-1 Linux网络数据包的处理流程

    当数据包到达网卡后，通过 DMA(Direct Memory Access)复制到主机的内存空间并触发中断，网络

    协议栈处理完数据分组后再交由用户空间的应用程序进行处理，整个过程的多个阶段都存在着不可忽视

    的开销，主要有以下几点。

    (1)网卡中断

    轮询与中断是操作系统与硬件设备进行 IO 通信的两种主要方式。在一般情况下，网络数据包的到来

    都是不可预测的，若采用轮询模式，则会造成很高的CPU负载，因此主流操作系统都会采用中断的方式

    来处理网络的请求。

    然而，随着高速网络接口等技术的迅速发展，10 Gbits、40 Gbits 甚至100 Gbits的网络接口已经出

    现。随着网络IO速率的不断提升，网卡面对大量的高速数据分组将会引发频繁的中断，每次中断都会引

    起一次上下文切换(从当前正在运行的进程切换到因等待网络数据而阻塞的进程)，操作系统都需要保

    存和恢复相应的上下文，造成较高的时延，并引起吞吐量下降。

    (2)内存拷贝

    为了使位于用户空间的应用程序能够处理网络数据，内核首先需要将收到的网络数据从内核空间拷

    贝到用户空间，同样，为了能够发送网络数据，也需要进行从用户空间到内核空间的数据拷贝。每次拷

    贝都会占用大量的 CPU、内存带宽等资源，代价昂贵。

    (3)锁

    在Linux内核的网络协议栈实现中，存在大量的共享资源访问。当多个进程需要对某一共享资源进行

    操作时，就需要通过锁的机制来保证数据的一致。然而，为共享资源上锁或者去锁的过程中通常需要几

    十纳秒。此外，锁的存在也降低了整个系统的并发性能。(4)缓存未命中

    缓存能够有效提高系统性能，如果因不合理的设计而造成频繁的缓存未命中，会严重削弱数据平面

    的性能。以Intel XEON 5500为例，在L3(Last Level Cache)命中与未命中条件下，数据操作耗时相差数

    倍。如果在系统设计时忽视这一点，存在频繁的跨核调用，由此带来的缓存未命中会造成严重的数据读

    写时延，从而降低系统的整体性能。

    接下来，针对这些开销因素，介绍一些主要的优化技术手段和项目。3.1 高性能数据面基础

    对于数据面的包处理而言，使用的主流硬件平台一般大致可分为硬件加速器、网络处理器及通用处

    理器。依据处理复杂度、成本、功耗等因素的不同，这些硬件平台在各自特定的领域发挥着作用。硬件

    加速器和网络处理器由于其专属性，往往具有高性能、低成本的优点。而通用处理器则在复杂多变的数

    据包处理上更有优势。同时，通用处理器由于性能的不断提升及其丰富的生态，为软件定义网络

    (SDN)提供了快速迭代的平台。

    下面就通用处理器上的高性能数据包处理做一些介绍，包含高速数据面的软件开发技术，处理器平

    台上提供的有助于提升数据面处理性能的硬件特性。

    3.1.1 内核旁路

    在通用处理器上开发高性能数据处理应用，首先要考虑的问题是选择一个好的开发平台。现有的主

    流开发平台有两大类：一类是基于操作系统的内核；另一类是内核旁路方案，即绕过内核中的低效模

    块，直接操作硬件资源。在NFV应用中，从性能方面考虑，选择后者的居多。下面就内核的性能问题和

    内核旁路技术做一些介绍。

    1.内核的性能问题

    在操作系统的设计中，内核通过硬件抽象和硬件隔离的方法，给上层应用程序的开发带来了简便

    性，但也导致了一些性能的下降。在网络方面，主要体现在整体吞吐率的减少和报文延迟的增加上。这

    种程度的性能下降对大多数场景来说可能不是问题，因为整体系统的瓶颈更多地会出现在业务处理逻辑

    和数据库上面。但对NFV这样的纯网络应用而言，内核的性能就有些捉襟见肘，性能优化显得很有必

    要。特别是随着网络硬件的发展，10G 网卡是服务器的入门级配置，25G 网卡正在普及，100G网卡和

    200G网卡也在应用中，内核所带来的性能下降是高速网络应用急需解决的问题。

    数据包在内核中的处理如图3-2所示：左下是网络硬件(NIC)，包括网卡传输链表(Descriptor

    Rings)和配置寄存器(CSRs)；左中是内核空间，包括网卡驱动(Driver)、协议栈(Stack)和系统调

    用(System Calls)；左上是用户空间，包括各种应用程序；右边是内核空间和用户空间的内存示意图。

    从中可以看出一个数据包从网卡到应用程序要经过内核中的驱动、协议栈处理，然后从内核的内存复制

    到用户空间的内存中，加上系统调用要求的用户到内核空间的切换，都会导致内核性能的下降。图3-2 数据包在内核中的处理

    2.内核旁路技术

    既然内核的性能不能满足NFV的要求，那么有没有一种方案能够克服这个问题呢？答案就是内核旁

    路技术，就是应用程序不通过内核直接操作硬件。

    如图3-3(a)所示，应用程序在用户空间，而网络驱动在内核空间。每次网络操作的时候都需要从用

    户空间切换到内核空间。

    在应用内核旁路技术之后，图3-3(a)就演变为图3-3(b)，应用程序跨过内核直接和网络硬件通

    信，没有用户空间和内核空间之间的切换，提高了效率。把网络驱动从内核移到用户空间后，即使出问

    题也不会像之前在内核中那样使操作系统崩溃，这是内核旁路技术带来的另外一个好处。

    图3-3 内核旁路技术

    3.开源方案

    内核旁路之后，应用程序直接和硬件打交道，但也需要解决硬件的抽象接口、内存分配和CPU调度

    等问题，甚至还有网络协议栈的处理。这方面有DPDK、Netmap、OpenOnload及XDP等开源框架，在一

    定程度上起到了硬件抽象和隔离功能，简化了应用程序开发。

    (1)DPDK

    DPDK是一个全面的网络内核旁路解决方案，不仅支持众多的网卡类型，也有多种内存和CPU调度的

    优化方案。在DPDK之上还有VPP、fstack等网络应用和网络协议栈的实现。

    (2)Netmap

    Netmap是一个高效的收发报文的 IO 框架，已经集成在 FreeBSD 的内部，也可以在Linux下编译使

    用。和DPDK不同的是，Netmap并没有彻底地从内核接管网卡，而是采用一个巧妙的Netmap ring结构来

    从内核管理的网卡上直接接收和发送数据。

    如图3-4所示，现代网卡一般都使用多个缓冲区(buffer)，并有一个叫NIC ring的环形数组。这些缓

    冲区是操作系统和网卡硬件共享的，网卡将接收的网络数据放到这些缓冲区之后，操作系统能通过相应

    的mbufs指针读出，发包的流程则正好相反。图3-4 传统的网卡缓冲区

    如图3-5所示，Netmap 把网卡的缓冲区从内核映射到用户空间，并且实现了自己的发送和接收报文的

    netmap_ring来对应网卡的 NIC ring。现代网卡一般都支持多队列，每个队列对应着一个netmap_ring。

    图3-5 Netmap ring与NIC ring

    将Netmap接口(netmap_if)绑定到网卡时，应用程序可以选择附加一个或多个Netmap ring。可以提

    高单个进程的吞吐量和灵活性；而如果只使用一个Netmap ring的话，则可以通过每个Netmap ring 对应一

    个进程CPU core的方式来构建多进程的高性能系统。

    (3)OpenOnload

    OpenOnload是一个开源的、高性能的Linux应用程序加速器，可为TCP和UDP应用提供更低的、可预

    测的延迟和更高的吞吐率。和DPDK与Netmap不同的是，前两者都是高性能的 IO 框架，而 OpenOnload

    更多的是一个内核旁路的协议栈。OpenOnload在用户空间实现了TCP和UDP的协议处理，又通过和内核

    共享部分协议栈信息的方式较好地解决了应用程序的兼容性问题，在金融等领域应用较为广泛。

    OpenOnload虽然是开源项目，但由于一些知识产权的限制，现在只能用在Solarflare及获得其许可的网卡

    上。

    OpenOnload的底层IO主要通过EF_VI技术来实现。如图3-6所示，EF_VI绕过内核协议栈把网卡中部

    分网络流量直接发送到用户空间的协议栈中。每个 EF_VI实例可以访问一条特定的 RX 队列，RX队列对

    内核是不可见的。在默认情况下，这个队列也不接收数据，直到创建一个 EF_VI “过滤器”把数据导入队列中。这个过滤器只是一个隐藏的流控制规则。用户用 ethtool等常用工具看不到这个规则，但实际上它

    已经存在网卡中了。对于 EF_VI 来说，除了分配 RX 队列并且管理流控制规则，剩下的任务就是提供一

    个API 让用户空间可以访问这个队列。

    图3-6 OpenOnload

    另外一部分流量仍然保留在内核中进行处理，这种技术能够灵活地利用内核和旁路方案两方面的优

    势，在 DPDK 社区称为“分叉驱动”。要使用这种技术，需要一个支持多队列的网卡，同时也要支持流控

    制和SR-IOV。

    有了这种网卡，可以实现如下功能：

    ● 正常启动网卡，让内核管理一切。

    ● 创建一个SR-IOV中的虚拟网卡(VF)。

    ● 把特定接收(RX)队列如1号加入VF中。

    ● 通过流控制规则将一个特定的网络流引到1号 RX 队列中。

    完成这些，剩下的步骤就是利用DPDK用户空间的 API，从1 号 RX 队列上接收数据包并处理。同

    时，其他任何队列在内核中的正常处理都不会受到任何影响。

    (4)XDP

    对于内核在 IO 和协议栈两个方面的性能问题，内核的开发人员也有清楚的认识，并提出了各种解决

    方案，XDP(eXpress Data Path)就是其中之一。XDP绕过了内核的协议栈部分，在继承内核的IO部分的

    基础上，提供了介于原有内核和完整内核旁路之间的另一种选择。

    如图3-7所示为XDP报文处理流程，中间部分是XDP的包处理引擎。这个引擎采用了一个

    BPF(Berkeley Packet Filter)的程序解释器，能够把XDP的业务逻辑从内核中隔离出来。即使XDP的业务

    代码出现错误，也不会导致内核的崩溃，达到了完整内核旁路技术类似的效果。内核的 IO 部分接收报文

    之后，直接交给 XDP，由XDP的业务逻辑决定报文的下一步是直接丢弃，是转发，还是本地处理。XDP

    绕过了内核原先的协议栈处理之后，性能得到较大的提高，是现在内核NFV高速网络处理方面一个不错

    的选择。图3-7 XDP报文处理流程

    3.1.2 平台增强

    在IA(Intel Architecture)多核通用处理器的平台下，如何实现高速的网络包处理？对传统的操作系

    统而言，跨主机的网络通信都会涉及底层网卡驱动及网络协议栈处理。如前所述，不少内核旁路技术的

    诞生，为在通用处理器下实现高速网络处理提供了可能。除了软件的创新，IA 平台上的许多技术也可以

    被用来提高网络的处理能力，大致可以归纳为以下几个方面：

    1.多核及亲和性

    多核处理器是指在一个处理器中集成两个或者多个完整的CPU核及计算引擎，它的出现使性能水平

    扩展成为可能。原本在单核上顺序执行的任务，可以按照逻辑划分为若干个子任务，分别在不同的核上

    并行执行。那么，按照什么策略将子任务分配到各个核上执行？这个分配工作一般是由操作系统按照复

    杂均衡的策略完成的。

    利用CPU的亲和性能够使一个特定的任务在指定的核上尽量长时间地运行而不被迁移到其他处理

    器。在多核处理器上，每个核自己本身会缓存着任务使用的信息，而任务可能会被操作系统调度到其他

    核上。每个核之间的L1、L2缓存是非共享的，如果任务频繁地在各个核间进行切换，就需要不断地使原

    来核上的缓存失效，如此一来缓存命中率就低了。当绑定核后，任务就会一直在指定的核运行，大大增

    加了缓存的命中率。对网络包处理而言，显然可以提高吞吐量和降低延时。

    2.Intel数据直接 IO 技术

    Intel数据直接 IO(Data Direct IO)技术简称DDIO，是从Intel Xeon E5系列处理器开始引进的功能。

    如图3-8所示，DDIO技术能够支持以太网控制器将IO流量直接传输到处理器高速缓存(LLC)中，缩短

    将其传输到系统内存的路线，从而降低功耗和IO延迟。同时，DDIO不依赖外部设备并不需要任何软件的

    参与。图3-8 DDIO

    在没有DDIO的系统中，来自以太网控制器的报文通过DMA最先进入处理器的系统内存，当CPU核需

    要处理这个报文时，它会从内存中读取该报文至缓存，也就是说在CPU真正处理报文之前，就发生了内

    存的读和写。同样地，如果处理器发送一个报文，需要从内存中读取该报文并写入缓存，再将报文回写

    到内存中，之后通知以太网控制器通过DMA发送出去。

    在具有DDIO的系统中，来自以太网控制器的报文直接传输至缓存，对于报文的数据处理来说，避免

    了多次的内存读写，在提高性能、降低延时的同时也降低了功耗。图3-9与图3-10对比了在网卡收发数据

    包时，在没有DDIO和有DDIO的系统中数据接收和发送的轨迹。

    图3-9 网卡接收数据包无DDIO 对比有 DDIO

    图3-10 网卡发送数据包无DDIO对比有 DDIO

    3.大页(Hugepage)

    提到大页，有必要简短介绍一下内存地址的转换过程。处理器和操作系统在内存管理中采用受保护的虚拟地址模式，程序使用虚拟地址访问内存，而处理器在收到虚拟地址后，先通过分段机制映射转化

    为线性地址，然后线性地址通过分页机制映射转化为物理地址。对于Linux实现而言，只采用了分页机

    制，而没有用分段机制，这样虚拟地址和线性地址总是一致的。

    分页机制是指把物理内存分成固定大小的块，按照页表管理，一般常规页的大小为4KB。以图3-10为

    例，如果按照常规页的大小，将线性地址映射为物理地址，需要读取至少三次页目录表和页表，也就是

    为了完成这个转换需要访问四次内存。为了加快处理器的内存地址转换过程，处理器在硬件上对页表做

    了缓存，就是 TLB(Translation Look-aside Buffer)，它存储了从线性地址到物理地址的直接映射。当处

    理器需要进行内存地址转换时，它先查找TLB，如果TLB命中，则无须多次访问页表就可以直接得到最终

    的物理地址，大大缩短了地址转换的时间。如果TLB不命中，则读取内存中的页表进行图3-11中的地址转

    换，如果在页表中都没找到索引，则产生缺页中断，重新分配物理内存，再进行地址转换。

    图3-11 从线性地址到物理地址转换(4KB页)

    TLB是处理器内部的一个缓存资源，其容量是有限的，以Intel Skylake微架构为例，其4KB页的TLB

    的容量如表3-1所示。

    表3-1 Intel Skylake的TLB容量(4KB页)

    以普通4KB页为例，如果一个程序使用了2MB内存，也就是512个4KB的页，那么TLB中需要存有512

    个页表表项才能保证不会出现TLB不命中的情况。随着程序的变大或者程序内存使用的增加，TLB也就变

    得十分有限，导致TLB不命中的情况出现。

    大页的出现改善了这一状态。大页，顾名思义，就是分页的基本单位变大，如图3-12和图3-13所示，可以采用2MB或者1GB的大页。它可以减少页表级数，也就是地址转换时访问内存的次数，同时减少TLB

    不命中的情况。一个使用了2MB内存的程序，TLB中只需要存有1个页表表项就能保证不会出现TLB不命

    中的情况。对于网络包处理程序，内存需要高频访问，在设计程序时，可以利用大页尽量独占内存防止

    内存溢出，提高TLB命中率。图3-12 从线性地址到物理地址转换(2MB页)

    图3-13 从线性地址到物理地址转换(1GB页)

    4.NUMA

    在多核处理器平台中，有时需要将多个处理器像单一系统那样运转，则需要具备对多个处理器及其

    内存系统进行管理的模式。一般有两个模式：对称多处理(SMP)和非一致性内存访问(NUMA)。

    SMP 模式将多个处理器、内存系统和 IO 设备都通过一条总线连接起来。在SMP模式下，所有的硬件资

    源都是共享的，多个处理器之间没有区别、平等地访问内存和IO外部设备，并且每个处理器访问内存的

    任何地址所需时间是相同的，因此SMP也被称为一致内存访问结构(UMA,Uniform Memory Access

    Architecture)。

    很显然，SMP 的缺点是扩展性有限，每一个共享的环节都可能造成系统扩展的瓶颈，而最受限制的

    则是内存。当内存访问达到饱和的时候，增加处理器并不能获得更高的性能，系统总线成为效率瓶颈；

    处理器与内存之间的通信延迟也增大。

    NUMA(Non-Uniform Memory Access Architecture)即非一致性内存访问技术，它的基本特征是具有

    多个处理器模块(Node)，每个处理器模块具有独立的本地内存、IO 设备等，处理器模块之间通过高速

    互联的接口连接起来。由于 Node 访问本地内存比访问其他节点的内存的速度要快一些，为了解决非一致

    性访问内存对性能的影响，NUMA调度器负责将进程尽量在同一节点的CPU之间调度，除非负载太高，才迁移到其他节点。

    NUMA技术解决了SMP系统可扩展性问题，它已成为当今高性能服务器的主流体系结构之一。如图

    3-14所示为Intel Xeon 5500系列系统，2颗CPU支持NUMA的系统结构，每颗CPU物理上有4个核心。利用

    NUMA技术，在设计数据包处理程序时，在内存分配上使处理器尽量使用靠近其所在节点的内存，可以

    水平扩展包处理能力。

    图3-14 Intel Xeon 5500系列系统3.1.3 DPDK

    DPDK的广泛应用很好地证明了IA多核处理器可以解决高性能数据包处理的需求。其核心思想可以归

    纳成以下几个方面：

    ● 轮询模式：DPDK 轮询网卡是否有网络报文的接收或放送，这样避免了传统网卡驱动的中断上下文

    的开销，当报文的吞吐量大的时候，性能及延时的改善十分明显。

    ● 用户态驱动：DPDK 通过用户态驱动的开发框架在用户态操作设备及数据包，避免了不必要的用户

    态和内核态之间的数据拷贝和系统调用。同时，为开发者开拓了更广阔的天地，比如快速迭代及程序优

    化。

    ● 降低访问存储开销：高性能数据包处理意味着处理器需要频繁访问数据包。显然降低访问存储开销

    可以有效地提高性能。DPDK使用大页降低TLB 未命中率，保持缓存对齐避免处理器之间缓存交叉访问，利用预取等指令提高缓存的访问率等。

    ● 亲和性和独占：利用线程的CPU亲和绑定的方式，将特定的线程指定在固定的核上工作，可以避免

    线程在不同核间频繁切换带来的开销，提高可扩展性，更好地达到并行处理提高吞吐量的目的。

    ● 批处理：DPDK 使用批处理的概念，一次处理多个包，降低了一个包处理的平均开销。

    ● 利用IA新硬件技术：IA的新指令、新特性都是DPDK挖掘数据包处理性能的源泉。比如利用vector

    指令并行处理多个报文，原子指令避免锁开销等。

    ● 软件调优：软件调优散布在 DPDK 代码的各个角落，包括利用 threshhold的提高 PCI 带宽的使用

    率，避免 Cache Miss(缓存不命中)以及 Branch Mispredicts(分支错误预测)的发生等。

    ● 充分挖掘外部设备潜能：以网卡为例，一些网卡的功能，例如 RSS、Flow director、TSO等技术可

    以被用来加速网络的处理。比如RSS可以将包负载分担到不同的网卡队列上，DPDK 多线程可以分别直接

    处理不同队列上的数据包。除以太网设备网卡以外，DPDK现已支持多种其他设备，例如crypto设备，这

    些专用硬件可以被DPDK应用程序用来加速其网络处理。

    1.开发模型

    基于上面的技术点，DPDK建议用户使用两种开发模型：

    ● Run-to-Completion模型

    Run-to-Completion 模型指一个报文从收到、处理结束，再发送出去，都由一个核处理，一气呵成。

    该模型的初衷是避免核间通信带来的性能下降。如图3-15所示，在该模型下，每个执行单元在多核系统中

    分别运行在各自的逻辑核上，也就是多个核上执行一样的逻辑程序。为了可线性扩展吞吐量，可以利用

    网卡的硬件分流机制，如RSS，把报文分配到不同的硬件网卡队列上，每个核针对不同的队列轮询，执行

    一样的逻辑程序，从而提高单位时间处理的网络量。

    ● Pipeline模型

    虽然 Run-to-Completion 模型有许多优势，但是针对单个报文的处理始终集中在一个CPU核，无法利

    用其他CPU核，并且程序逻辑的耦合性太强，可扩展性有限。Pipeline模型的引入正好弥补了这个缺点，它指报文处理像在流水线上一样经过多个执行单元。如图3-16所示，在该模型下，每个执行单元分别运行

    在不同的CPU核上，各个执行单元之间通过环形队列连接。这样的设计可以将报文的处理分为多步，将

    不同的工作交给不同的模块，使得代码的可扩展性更强。图3-15 Run to Completion模型

    图3-16 Pipeline 模型

    2.实现框架

    DPDK由一系列可用于包处理的软件库组成，能够支持多种类型设备，包括以太网设备、加密设备、事件驱动设备等，这些设备以PMD(Polling Mode Driver)的形式存在于DPDK中，并提供了一系列用于

    硬件加速的软件接口。

    ● 核心库(Core Libraries)：这部分是DPDK程序的基础，它包括系统抽象内存管理、无锁环、缓存

    池等。

    ● 流分类(Packet Classification)：支持精确匹配、最长匹配和通配符匹配，提供常用的包处理查表

    操作。

    ● 软件加速库(Accelerated SW Libraries)：一些常用的包处理软件库的集合，比如IP分片、报文重

    组、排序等。

    ● Stats：提供用于查询或通知统计数据的组件。

    ● QoS：提供网络服务质量相关组件，比如限速(Meter)和调度(Scheduler)。

    ● 数据包分组架构(Packet Framework)：提供了搭建复杂的多核Pipeline模型的基础组件。

    接下来对核心库稍做展开。

    3.核心库

    核心库是DPDK程序的核心也是基础，几乎所有基于DPDK开发的程序都依赖它。核心库包括系统抽

    象层、内存管理、无锁环、缓存池等。

    系统抽象层屏蔽了各种特异环境，为开发者提供了一套统一的接口，包括DPDK的加载启动；支持

    多进程和多线程；核亲和绑定操作；系统内存的管理；总线的访问，设备的加载；CPU特性的抽象；跟

    踪及调试函数；中断的处理；Alarm处理。

    除系统抽象层以外，无锁环、MemPool及Mbuf的管理也是DPDK的核心所在。

    DPDK的rte_ring结构提供了一个支持多生产者和多消费者的无锁环。它是一个先进先出(FIFO)队列，简单且高速，支持成批进队列和出队列。它已用于Memory Pool 的管理，同时也可以作为不同执行单

    元间的通信方式。其结构可以简单地表示为如图3-17所示的形式，生产者和消费者逐自进入各自的Head

    和Tail指针控制环中对象的移动(入队列，出队列)。

    图3-17 rte_ring结构

    DPDK的rte_mempool是负责管理从内存中分配mempool的库。mempool是一个对象池，如图3-18所

    示，池中的对象用rte_ring管理。在mempool中还引入了Object Cache(对象缓存)的概念，用于加速对象

    的分配和释放过程。具体可参见DPDK的开发者手册。

    图3-18 mempool及其对象ring

    DPDK的rte_mbuf则提供了一种数据结构，如图3-19所示，它可用于封装网络帧缓存或控制消息缓

    存。rte_mbuf以ring的形式存在于MemPool中，rte_mbuf就是mempool中的对象。mbuf的结构经过精心设

    计，其头部大小为两个Cache Line(缓存行)，原则上将基础性的、频繁访问的数据放在第一个Cache

    Line，而将功能扩展性的数据放在第二个Cache Line。如图3-20所示，对于单个mbuf存放不下的大数据

    包，mbuf还有指向下一个mbuf结构的指针来形成帧链表的结构。

    图3-19 rte_mbuf结构图3-20 mbuf链组成大数据包

    4.一个简单的DPDK程序

    在 DPDK 代码的 samples 目录下有一个简单的实例，它实现了一个基于 DPDK的简单转发的程序。

    main函数是程序的入口，首先，argc和argv参数初始化系统抽象层(EAL,Environment Abstraction

    Layer)。

    然后，创建存有一定量mbuf的mempool。

    接着，初始化每一个端口。

    端口对应的是以太网设备，对一个以太网设备进行收发包前的初始化时，需要经过以下几步：

    ● rte_eth_dev_configure：基于应用所需的收发数据包队列数及一些特定的配置信息配置设备。

    ● rte_eth_tx_queue_setup：创建发送队列，对于硬件设备，驱动需要为其分配DMA ring用于发送

    数据包。

    ● rte_eth_rx_queue_setup：创建接收队列，对于硬件设备，驱动需要为其分配DMA ring用于接收

    数据包。

    ● rte_eth_dev_start：启动该设备，在启动后，该设备就可以用于收发数据包了。在端口初始化完成后，main函数为每个逻辑core启动执行转发程序。转发程序lcore_main如下所

    示。可见，该执行程序从端口上通过 rte_eth_rx_burst 收到数据包后，再由rte_eth_tx_burst将数据包发送出

    去。3.2 NFV和NFC基础设施

    如前所述，DPDK 为高性能数据面的处理提供了可能。DPDK 已作为 NVF 和NFC(网络功能虚拟化

    和容器化)的重要组件，参与到NFV和NFC的基础设施建设中。下面就从NFV、NFC和平台设备抽象两

    方面展开描述NFV和NFC基础设施的特质，以及DPDK对其支持的情况。

    3.2.1 网络功能虚拟化

    网络功能虚拟化的一个重要特征是软硬件解耦。当网络功能从专用硬件向通用硬件平台乃至虚拟通

    用硬件平台转移时，作为承载各种网络功能的基础设施层(NFVi)，其重要性也越发突出。

    当使用普通的服务器平台作为运行网络功能的目标平台时，每一个网络功能业务都希望通过基础设

    施层获得最大可能的网络带宽。基础设施层通常用PCIe网络设备将数据包引入通用处理器，当然，这样

    的PCIe网络设备在裸机上是物理设备，而在虚拟机上则是虚拟设备。

    1.NFVi数据平面加速

    对于一个VNF(虚拟化网络功能)应用，快速地从NFVi获取网络帧是后续业务逻辑的基础，这就涉

    及虚拟主机接口(Host IO Interface)。从NFVi的视角来看，虚拟主机接口是其面向虚拟主机提供的北向

    虚接口；从VNF的视角来看，虚拟主机接口是承载其运行的主机IO设备。

    配合不同类型虚拟主机接口，NFVi 提供了不同的数据面策略，Bypass 和 Relay就是两种比较典型的

    数据面策略。从数据面的角度，前者依赖外部系统提供NFVi数据面，绕过了整个Host软件部分，后者则

    由Host软件提供NFVi数据面。

    再回过头看虚拟主机接口。网络设备按照不同的虚拟化实现方式，可以粗略地分为全模拟(Fully-

    Emulated)、半虚拟化(Para-Virtualized)和硬直通(Pass-thru)。对于主流的VMM及其网络设备，DPDK支持相对都比较完善。全模拟和半虚拟化类型的虚拟主机接口主要与 NFVi 的 Relay 策略一起工

    作，而硬直通 NFVi 一般采用Bypass 策略。如图3-21所示，E1000就是由 VMM 全模拟的设备接口，Virtio

    是QEMUKVM下的半虚拟化设备，VF则是基于SR-IOV的功能，可用于硬直通。图3-21 不同的虚拟主机接口实现方式

    在网络功能虚拟化场景下，对网络带宽都有一定的要求。相对于全模拟设备方式，半虚拟化和硬直

    通是更为主流的使用方式。下面以QEMUKVM开源VMM为例，分别介绍这两种方式的特点和优势。

    2.半虚拟化

    Virtio是QEMUKVM下的半虚拟化设备框架，支持多种设备类型，设备定义规范也以开源社区的方

    式维护。

    virtio-net是网卡设备类型的代表。该设备整体由QEMU模拟，例如当Virtio-net基于PCIe总线时，QEMU通过Trap-Emulation的方式模拟了访问PCIe Bus、PCIe CSR、BAR Registers、Interrupt等行为。设备

    中传输的网络帧，本质是通过共享内存的方式，由虚拟主机内的前端设备驱动和后端设备双方按照队列

    规范进行入队列和出队列的操作。

    QEMU为Virtio后端设备的实现提供了一层vHost抽象，这样无论QEMU进程本身、Kernel，还是另外

    的独立进程，都可以有不同的适配。vHost-user 就是一个独立于QEMU进程的Virtio设备后端的实现接

    口，QEMU进程和独立进程按照vHost协议通过Unix Socket互相交互。

    如果给这些交互分类，可以分为与设备业务相关部分和无关部分。与设备相关的部分包括功能协

    商、设置多队列、MTU等。与设备业务无关的部分，主要是搭建前后端共享数据通道，即前端设备如何

    与后端设备共享内存并互相通知。在这部分工作完成之后，后端设备软件就可以向共享的队列里进行入

    队列和出队列的操作。

    通过 DPDK 的 vHost-user 库，用户可以在自己的进程中轻松地与虚拟机进行网络帧的传输。在Open

    vSwitch中，DPDK模式的NETDEV(即OVS-DPDK)便是使用vHost-user构建其面向虚拟主机的虚接口。

    由于Virtio的设备驱动默认后端是由软件在相同架构的CPU上进行数据入队列和出队列的操作，故而

    被归到半虚拟化设备中。而随着Virtio硬化的出现，这种分类方式的边界也会逐渐变得模糊，这在后续的

    章节中会继续展开。

    总的来说，类似Virtio的这种半虚拟化设备有如下一些特点：

    ● 开放的标准化设备。

    ● 相对较好的性能。

    ● 硬件设备无关性。

    由于该类虚拟主机接口需要接入软件定义的 NFVi 数据面，这样天然地将 VNF与硬件设备解耦。另一方面，由于其设备完全由软件模拟，状态热迁移也更可实现。在使用DPDK vHost后端实现对接QEMU

    的vHost-user后，其IO性能提高了一个数量级，并可以随着CPU的数量线性提升，使得其在NFV场景下的

    可用性大大提升。

    3.硬直通

    硬直通将一个硬件设备的能力直接赋予某一个虚拟主机，使得虚拟主机可以获得和裸机下极其相近

    的性能。但一台设备如果需要被赋予多个虚拟主机，就需要设备能够被切片，或者说能有设备及总线级

    别的多路复用技术。

    这是为什么硬直通通常和SR-IOV联系在一起的原因，SR-IOV是一种PCIe总线多路复用技术。支持

    SR-IOV的设备，可以将自身切分成多个VF(Virtual Function)，它们与PF(Physical Function)一样，在

    主机侧呈现为独立标准的PCIe设备。SR-IOV是一种总线虚拟化技术，或者多路复用技术，VF本身并不一

    定必须使用在虚拟人机里。真正将其与虚拟机结合的，是硬直通技术本身。

    那硬直通的本质是什么呢？其主要解决了三部分的问题：设备BAR配置空间的访问、DMA 内存请求

    的直达、中断请求的送达。第一部分有很多方法解决，比如trap-emulation的方式，或通过MMIO的页表映

    射。第二部分和第三部分需要平台特性的支持，这个特性就是IOMMU(比如Intel VT-d、AMD-Vi)。

    IOMMU支持DMA重映射和中断重映射。DMA重映射支持一级甚至二级地址重映射，使得DMA请求

    可以使用虚拟IO地址访问主存，不再要求DMA地址的物理连续性。中断重映射支持将设备中断重定向到

    vCPU的虚拟中断控制器。所以，可以说，硬直通是直接得益于平台IO虚拟化技术的。

    DPDK驱动对网卡设备的驱动支持非常全，支持SR-IOV的大多数厂商都提供了VF驱动，可以在厂商

    驱动目录下找到相关文件。

    使用硬直通和SR-IOV技术的VF在VM中有一些特点：

    ● 几乎和裸机一致的性能。

    ● 设备驱动对运行环境(VM或Bare-Metal)无感知。

    ● 硬件设备依赖。

    硬直通在带来出色性能的同时也引入了另一个课题，就是硬直通如何友好地支持云化。首当其冲的

    挑战是如何支持热迁移。

    另一个课题由PFVF模型引入，VF往往不被赋予一些改变设备全局设置的能力，它需要 PF 作为代理

    操作，这样就需要一个 VF 和 PF 之间的消息通道。VFD(VF Daemon)是由ATT公司发起的一个开源

    项目，该项目给出了一种实现方式，统一抽象不同厂商可能共同面临的一个 VF 代理请求的工作，它的工

    作方式如图3-22所示。DPDK各驱动也对该方案提供全面的支持。图3-22 VFD的工作方式

    4.下一代虚拟主机接口

    NFV 剧烈地重构着网络形态，并依旧不断地生长着。从技术角度讲，有两个关键的因素驱使着各项

    技术发展，分别是更高的速度和更好的云化。这两个因素有时又是一对矛盾体，更高的性能往往需要更

    多的硬件亲和，而云化从某种角度又要淡化硬件的特性。

    如果硬件规范是统一的，或能抽象统一在一个协定下，则是解决这对矛盾体的一种方式。先不说去

    除多样性本身是否好，现实中在业界要达成一致的抽象困难重重。

    另一种方式，或许就是不同技术向着相同的方向各自演进、互相融合，最终产生新的满足下一代

    NFV要求的虚拟主机接口。

    对于半虚拟化虚拟主机接口，其本身云化能力已经非常完善。所以，其改进方向主要集中在追求更

    好的网络带宽性能。以Virtio为例，最新的v1.1 Spec引入Packed Ring Layout，主要是以减少内存访问次数

    为核心的优化方式。由于硬件通过总线访问内存延迟要远高于CPU访问内存，新Layout的引入同样也使得

    Virtio的Ring格式对于硬件访问更友好。

    那最终Virtio是否可以像硬直通一样，由硬件设备直接向虚拟主机提供IO呢？vDPA(vHost Data Path

    Acceleration)便是这样的实践。它并不改变Virtio设备模拟的特征，PCIe总线、设备的CSR、BAR 配置寄

    存器等依旧通过陷入模式的方式委托vHost处理。VDPA加速vHost如图3-23所示。

    图3-23 VDPA加速vHost

    针对vHost的数据平面，利用之前提到的平台IO虚拟化特性、IOMMU的DMA和中断重映射，使得设

    备可以直接读写虚拟主机内存和投递中断。这样地址转换、帧buffer的复制及额外的中断中继开销至少可

    以进一步降低，比纯软件的零拷贝的中继效率更高。倘若硬件本身还能按照 Virtio 规范中定义的方式操

    作 Ring，则整个数据平面就完全地“硬直通”了。

    虚拟主机接口数据平面的软硬之间无缝切换成为可能，硬件提供的是加速能力，而且被特定的硬件

    规范约束。当然，这里NFV仍旧对Virtio Spec有依赖，但对于NFVi是否使用特定的硬件已经没有了依赖。

    那硬直通呢？半虚拟化大多是VMM原生的，硬直通具有跨VMM的一致性。硬直通虽然具有最接近

    裸机的性能，但也有硬件解耦性不够和云化关键特质热迁移能力的不足的问题。这个课题是否可解？答

    案也是肯定的，硬直通也在慢慢变得软化。从Linux中VFIO模块支持VFIO-PCI到VFIO-MDEV，一个明显

    的特征就是VF的PCIe的CSR和配置管理不一定需要和硬件一一对应，控制面可以由陷入模式的方式完成，是不是和半虚拟化很像？再进一步，硬直通的数据平面是否可以软化呢？一旦数据平面可以由软件

    提供，并接入 NFVi在Host 的数据平面，厂商硬件依赖的硬直通也完成了去设备硬件依赖的属性。

    可以看到，虚拟主机接口正在以不同的路径，朝着更好的NFV奔向同一个目标——下一代虚拟主机

    接口。其特征是NFVi根据VNF的选择提供虚拟主机接口，双方遵照服务质量协议，NFVi运营商可以根据

    自身需要使用额外无缝硬件加速功能。

    3.2.2 从虚拟机到容器的网络IO虚拟化

    相比于基于ASIC等专有硬件的网络功能，虚拟化技术将网络功能与底层硬件彻底解耦，不仅为开发

    人员提供了更加灵活的开发环境，为产品更新提供了更短的迭代周期，更保证了网络功能的高度隔离

    性、易用性及安全性。凭借这些优势，基于Hypervisor的虚拟化技术，比如KVM、HyperV，已广泛应用

    于NFV环境中。然而，近两年随着网络速度的不断上升、互联网数据量的不断膨胀，一种更加轻量级的

    虚拟化技术——容器虚拟化，正逐渐广泛应用于NFV场景中。

    如图3-24所示，基于Hypervisor的虚拟化技术与容器虚拟化技术有一定区别。基于 Hypervisor 的虚拟

    化技术通过一层中间软件将固定的硬件资源抽象为众多的虚拟化资源(通常称为虚拟机)。每一个虚拟

    机都具有独立的操作系统，运行于完全独立的上下文中。因此，通常一台主机上运行有多个操作系统。

    而与完全模拟硬件资源的Hypervisor虚拟化不同，容器虚拟化是一种资源隔离技术。利用操作系统的命名

    空间和Cgroups资源分配，容器虚拟化将用户程序隔离于不同的资源实体中运行，而每一个资源实体就称

    为容器。在容器虚拟化中，同一主机上的所有容器共享主机操作系统，不对底层的硬件资源进行模拟。

    相比于虚拟机，容器是一种更加轻量级的虚拟化，能更高效地利用系统资源，有更快的启动时间，更易

    于部署和维护。

    图3-24 基于Hyperviso ......