一、DPDK
简介
DPDK全称Intel Data Plane Development Kit，是intel提供的数据平面开发工具集，为Intel architecture（IA）处理器架构下用户空间高效的数据包处理提供库函数和驱动的支持。通俗地说，就是一个用来进行包数据处理加速的软件库。
DPDK不同于Linux系统以通用性设计为目的，而是专注于网络应用中数据包的高性能处理。具体体现在DPDK应用程序是运行在用户空间上利用自身提供的数据平面库来收发数据包，绕过了Linux内核协议栈对数据包处理过程。它不是一个用户可以直接建立应用程序的完整产品，不包含需要与控制层（包括内核和协议堆栈）进行交互的工具。
相比原生 Linux（Native Linux），采用Intel DPDK技术后能够大幅提升IPV4的转发性能，可以让用户在迁移包处理应用时（从基于NPU的硬件迁移到基于Intel x86的平台上），获得更好的成本和性能优势。同时可以采用统一的平台部署不同的服务，如应用处理，控制处理和包处理服务。
GitHub【冲破内核瓶颈，让I/O性能飙升】DPDK工程师手册
应用
dpdk 作为优秀的用户空间高性能数据包加速套件，现在已经作为一个“胶水”模块被用在多个网络数据处理方案中，用来提高性能。如下是众多的应用。
1、数据面（虚拟交换机）：
- OVS
Open vSwitch 是一个多核虚拟交换机平台，支持标准的管理接口和开放可扩展的可编程接口，支持第三方的控制接入。
https://github.com/openvswitch/ovs
- VPP
VPP 是 cisco 开源的一个高性能的包处理框架，提供了 交换/路由 功能，在虚拟化环境中，使它可以当做一个虚拟交换机来使用。在一个类 SDN 的处理框架中，它往往充当数据面的角色。经研究表明，VPP 性能要好于 ovs+dpdk 的组合，但它更适用于NFV，适合做特定功能的网络模块。
https://wiki.fd.io/view/VPP
- Lagopus
Lagopus 是另一个多核虚拟交换的实现，功能和 OVS 差不多，支持多种网络协议，如 Ethernet，VLAN，QinQ，MAC-in-MAC，MPLS 和 PBB，以及隧道协议，如 GRE，VxLan 和 GTP。
https://github.com/lagopus/lagopus/blob/master/QUICKSTART.md
- Snabb
Snabb 是一个简单且快速的数据包处理工具箱。
https://github.com/SnabbCo/snabbswitch/blob/master/README.md
2、数据面（虚拟路由器）：
- OPENCONTRAIL
一个集成了 SDN 控制器的虚拟路由器，现在多用在 OpenStack 中，结合 Neutron 为 OpenStack 提供一站式的网络支持。
http://www.opencontrail.org/
- CloudRouter
一个分布式的路由器。
https://cloudrouter.org/
3、用户空间协议栈
- mTCP
mTCP 是一个针对多核系统的高可扩展性的用户空间 TCP/IP 协议栈。
https://github.com/eunyoung14/mtcp/blob/master/README
- IwIP
IwIP 针对 RAM 平台的精简版的 TCP/IP 协议栈实现。
http://git.savannah.gnu.org/cgit/lwip.git/tree/README
- Seastar
Seastar 是一个开源的，基于 C++ 11/14 feature，支持高并发和低延迟的异步编程高性能库。
http://www.seastar-project.org/
- f-stack
腾讯开源的用户空间协议栈，移植于 FreeBSD协议栈，粘合了 POSIX API，上层应用（协程框架，Nginx,Redis），纯 C 编写，易上手。
https://github.com/f-stack/f-stack
总结
dpdk 绕过了 Linux 内核协议栈，加速数据的处理，用户可以在用户空间定制协议栈，满足自己的应用需求，目前出现了很多基于 dpdk 的高性能网络框架，OVS 和 VPP 是常用的数据面框架，mTCP 和 f-stack 是常用的用户态协议栈。很多大公司都在使用 dpdk 来优化网络性能。
二、流媒体音视频
音视频传输协议众多， 不同业务应该如何选择？ RTSP、RTMP、RTP/RTC、HLS、MSS、DASH、WEBRTC、RIST、SRT；在此我们就从业务发展的视角来理解各种流媒体协议，帮助大家有更加清晰的理解，选择时做出更理性的判断。
音视频流媒体权威资料整理，500+份文章，论文，视频，实践项目，协议，业界大神名单
IPTV
IPTV 是由运营商主导建设的一套系统，他的主要对标对象是传统广电的数字电视。所以这套系统首要解决的是大规模直播的问题，在此基础上还需要支持点播、时移、回看等新业务。运营商的优势就是可以自建一套可管理的网络，所以直播就基于组播技术进行大规模分发。主要技术栈是RTP+TS over multicast，这个技术大大降低了直播峰值对流媒体服务器的压力。而点播、时移、回看业务由于必须使用单播传输，所以当时选择的技术栈是使用RTSP 进行流媒体控制，使用RTP+TS over UDP（少量基于TCP）进行数据传输。
现在这套系统服务了全国接近1.7 亿多用户。这套技术栈面临的挑战和对应的解决方案主要包括几点： 解决单播基于UDP 传输丢包的问题，丢包会导致用户观看花屏或爆音，我们基于RTSP 协议扩展制定了一套规范，基于RTSP 的GET_PARAMETER扩展了重传数据报文的信令，主要是基于NACK 原理进行设计，通知流媒体服务器哪个报文没有接收到，流媒体服务器根据请求中携带的RTP 序号进行重发。
解决组播传输丢包问题，组播报文丢包会导致直播花屏或爆音，我们采用了2 个手段解决这个问题： · FEC · ARQ
通过FEC 技术增加等步长的冗余报文，可以解决随机丢包问题，但是无法解决突发连续丢包问题，这个时候就需要ARQ 技术，我们在系统中增加一个RETServer，RET Server 也会加入组播组接收和机顶盒收到的相同的组播报文，机顶盒在检测到丢包后，会向这台服务器发起NACK 报文，RET Server 收到请求后根据请求的RTP 需要将对应的报文发送给机顶盒。
解决组播传输下频道快速启动问题，终端加入组播组的时间是随机的，无法保证每次加入组播组后接收到的报文就可以理解用于解码并显示，所以我们通过在系统中增加一个FCC Server，解决该问题，终端在起播观看一个频道的时候，优先向FCC Server 请求一条单播流，FCC Server 会以1.X 倍的速率将I 帧和解码所需的报文发给终端，配合终端快显技术可以实现300ms 以内的频道切换速度。
IPTV多屏
随着移动终端的发展，运营商希望在IPTV 业务基础上，发展手机等多屏业务，开始支持HLS（主流）、MPEG DASH（部分海外运营商，支持MultiDRM）流媒体协议。这套系统在流媒体协议层面临的问题是不同屏幕，不同DRM 格式，多种格式带来了存储空间成倍的上升，特别是NPVR 个人录制业务，对存储的需求非常大。主要解决思路就是JITP（Just In Time Package），即只要存储一份内容，根据用户观看的内容格式进行实时格式转换。
OTT点播
伴随着以Youtube，Netflix，爱奇艺，优酷，腾讯视频为代表的OTT 视频点播平台的崛起，以及苹果手机的普及和HLS 协议的出现，流媒体协议从HTTP渐进式下载发展到ABR Streaming，HLS 是其中最为主流的一种ABR 协议，HLS 也成为了各个OTT视频平台的首选视频传输协议。这套系统在流媒体协议层面临的问题和解决方案如下：
1、 解决基于互联网的大规模分发问题。CDN 技术可以很好的解决这个问题，这也是OTT 流媒体协议基本上在设计之初就考虑对CDN 友好的原因。 2、 Netflix 由于业务量的规模发展到一定规模，从最开始选择第三方CDN，走向了自建CDN（Open Connect）的道路，但是他的技术栈依旧是HLS 和DASH 这类对CDN 友好的流媒体协议。
OTT 直播
细分为事件类（新闻/ 赛事/ 演唱会）直播、个人（游戏/ 网红/ 秀场）直播。满足这类直播业务的流媒体协议层面临的问题和解决方案如下：
1、首先他们和OTT 点播一样，需要解决基于互联网的视频大规模分发问题。
2、其次直播相较于点播需要额外考虑的一点就是直播时延，第一类：电视台/ 事件（新闻/ 赛事/ 演唱会）直播基本没有和观众互动的要求。所以它们依然选择对CDN 友好的HLS 和DASH 协议，但是时延会高达10-30s，随着CMAF 格式的出现，根据我们在实验室的测试数据表示时延可以小于5s。第二类：个人（游戏/ 网红/ 秀场）直播，以国内直播平台为例，商业模式主要靠打赏分层，所以要求直播的E2E 时延必须低于5s，否则观众与主播的互动效果非常差，直接影响直播平台的收入。这类厂家选择的技术栈为延迟更低的RTMP 和HTTP FLV。
3、随着手机和4G 网络的普及，部分主播也开始尝试在户外进行开播，由于户外直播的网络条件不可控，而RTMP 是基于TCP 传输的，导致在户外4G网络条件不稳定的环境下，直播效果很差，所以针对弱网环境下的直播上行效果差成为直播平台需要解决问题。为了解决这个问题，大家把眼光转向UDP，基于UDP 的直播传输技术逐步进入人们的视野。常见的有ZIXI、SRT 和RIST。ZIXI 属于纯商业化公司，显然不合适大量个人直播上传这类商业模式的直播平台。SRT 有相对成熟的开源社区支持，所以在国内应用较为普遍。RIST 是由Video Services Forum (VSF)于2017 年初开始制定的可靠的互联网流传输协议（Reliable Internet Stream Transport，RIST），相较于SRT，基于UDT 非实时流媒体的技术栈构建，RIST 一开始便使用较为成熟的RTP+RTCP 技术，而且他只定义了标准化的语法，允许实厂家在此基础上进行创新，而又不影响互相操作。经过近几年的发展RIST 支持的场景越来越多，也越来越成熟。
4、直播业务发展越来越繁荣后，又出现了多主播PK，主播与观众连麦等场景，这些对时延的要求直接从5s 变成1s 以内， 甚至小于400ms， 为了满足业务的发展，直播平台选择了实时通信的技术栈RTP+RTCP over UDP。一旦引入UDP，就需要解决丢包带来的视频体验问题，这里常见的技术有FEC、ARQ 等。
实时音视频 RTC
随着5G 网络的普及，以及疫情带来的影响，人们对实时音视频技术的应用场景会越来越多，主要包括：会议、连麦、音视通话、视频通话、在线教育、远程医疗等。由于这些应用场景对时延的要求<400ms，所以从技术栈选择来看，基本上都是选择RTP/RTCP over UDP 的方式进行音视频数据的输出。
如果把流媒体协议做三个维度划分：质量（画质/帧率）、平滑、延迟。实时音视频通信和OTT 直播上传场景相比，对低质量的容忍度更高，即允许降低一定的质量，下降（降帧率等）来换取更加平滑的体验和更低的延迟。这个选择上的差异，导致在技术设计上需要打通网络传输系统和音视频编解码系统，实现根据网络传输质量实时动态调整音视频编码参数，在质量、时延、平滑三个维度上进行权衡得出最优解。
流媒体新的发展方向
1、 新的媒体表现形式包括VR、自由视角、点云；他们与传统视频的最大区别在于，传统视频主要支持时间维度的定位，而新的媒体，除了支持时间维度的定位，还支持空间维度的定位。当前主要在MPEG 标准组织中进行讨论，基于MPEG DASH 规范进行演进。以VR 为例，一般人类的FOV 视场角<140°，新的流媒体协议利用这个特性，可以实现根据观众观看的视频范围，进行部分传输，从而降低的对带宽的诉求，这也很好的解决了传输的数据量越来越大对带宽要求苛刻的问题。华为云视频的Cloud VR 产品已经支持8K VR、自由视角的直播和点播服务。
2、 全互联实时音视频直播，随着在线教育和在线办公的普及，越来越多客户对具备大规模分发能力的低时延互动视频服务有着强烈的诉求，当前的架构要么支持大规模分发，要么支持低时延、互动，无法同时具备三者的能力。我们认为未来的主流架构需要同时满足这三样能力，华为的实时音视频服务已经完成这套架构的实现，致力于在流媒体领域持续深耕，让我们共建流媒体的未来。
三、云原生
简介
云原生从字面意思上来看可以分成云和原生两个部分。 云是和本地相对的，传统的应用必须跑在本地服务器上，现在流行的应用都跑在云端，云包含了IaaS,、PaaS和SaaS。 原生就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如?云服务的弹性和分布式优势。 那具体要怎么利用呢，请参考下图：
微服务 微服务解决的是我们软件开发中一直追求的低耦合+高内聚，记得有一次我们系统的接口出了问题，结果影响了用户的前台操作，于是黎叔拍案而起，灵魂发问：“为啥这两个会互相影响？！” 微服务可以解决这个问题，微服务的本质是把一块大饼分成若干块低耦合的小饼，比如一块小饼专门负责接收外部的数据，一块小饼专门负责响应前台的操作，小饼可以进一步拆分，比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼，这样每个小饼出问题了，其它小饼还能正常对外提供服务。
DevOps DevOps的意思就是开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。我们现在开发和运维已经是一个团队了，但是运维方面的知识和经验还需要持续提高。
持续交付 持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，要做到这点非常非常难。我们现在两周一个版本，每次上线之后都会给不同的用户造成不同程度的影响。
容器化 容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，现在比较流行的工具是docker和k8s。
所以你也可以简单地把云原生理解为：云原生 = 微服务 + DevOps + 持续交付 + 容器化
企业在数字化转型中普遍面临IT系统架构缺乏弹性，业务交付周期长，运维效率低，高可靠性低等痛点。企业可以通过云原生的一系列技术，例如基于容器的敏捷基础设施，微服务架构等解决企业面临的这些IT痛点。
云原生的三大特征
云原生应用架构包含三个特征：容器化、微服务和 DevOps。
容器其实已有10来年的历史，2013年开源的 Docker 容器引擎，被开发者所广泛熟悉，到如今发展成为包含容器云 PaaS 等一系列商业化应用实践。
容器技术具有占用资源少、部署快、易迁移等特点，容器可以理解为隔离环境的“运行时”，这也很好诠释了 Docker 集装箱的理念 — Build, Ship and Run。容器看做是一个简易版的 Linux 环境(包括root用户权限、进程空间、用户空间和网络空间等)和运行在其中的应用程序。
云原生价值的最大体现之一在于对企业 DevOps 的支持，它将企业开发运维部门很好地结合起来，以前企业的开发、测试、运维是相互割裂的状态。我们所提倡的 DevOps 理念将打破开发、测试、运维部门之间的隔阂，让整体的应用交付变得更快速。从技术角度看，DevOps 涵盖了应用的开发、编译、构建、测试、打包、发布的自动化流程，并包含了很多 DevOps 工具链。
云原生的第三个特征是微服务，微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。以往企业应用主要是面向服务的架构（SOA），SOA 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。它的缺点是架构重，难以利用云的一些特点和优势。微服务倡导细粒度的轻量级应用架构，每一个服务相对独立的，具有轻量级、易迁移、更高效等特性。
容器PaaS的特点及优势
容器云 PaaS 平台是云原生在企业重要的落地形态之一，它包含了 PaaS 本身，以及 DevOps、微服务等。
在 IDC 的时代，用户需要管机房、物理机、包括网络、业务应用。上云之后，我们简化了这种资源的交付流程，用户获取计算、存储、网络资源变的更简单。
发展到 PaaS 的时候，用户不需要去关心底层的基础设施，只需要专注业务应用本身，容器 PaaS 以应用为中心，标准化、自动化应用的构建（Build）、交付（Ship）、部署运行（Run）流程，支撑应用的完整生命周期管理。通过容器云 PaaS 提供的丰富基础服务及之上的 SaaS 服务，提高 IT 设施自服务能力以及新业务的交付效率。
PaaS 最早其实是跟 IaaS 同步发展的，2011年时，国内出现了很多 PaaS 平台，包括 SAE、BAE等。第一代 PaaS 侧重提供支撑应用运行的应用引擎，我们现在所说的容器云 PaaS，则是基于云原生理念，融入 DevOps、微服务，解决了应用的完整生命周期管理问题。
Kubernetes 是容器云 PaaS 平台的基石，它是承载整个 PaaS 的核心。Kubernetes 是 Google 开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。Kubernetes 未来将会成为企业的云基础设施的重要组成部分，它的目标是让用户快速、简单的开发适合自己的 PaaS 或者 DevOps 平台；随着容器技术的普及，将会有越来越多的企业基于 Kubernetes 作为大规模容器的调度管理引擎，并结合自身的优势打造适合企业的 PaaS 平台。
云原生应用的趋势
关于如何实施云原生，这里简单给大家做一些参考，首先需要对企业 IT 内部有清晰的规划，结合企业自身的 IT 业务体量。很多互联网公司通过开源的 K8S 也能简单支持一些非核心业务，构建容器 PaaS 还需要考虑一些流程，包括前期的无状态服务迁移，后期有状态、重状态的服务。
最先得到商业验证的是 IaaS 和 SaaS，这符合市场客观规律。在云计算进入商业成熟期时，竞争将回归到效率和成本。PaaS 本质上是云计算模型中的能力层，让客户以更高的几率赢得竞争。PaaS 把构建上层应用场景的能力抽象化，降低重复造轮子的风险和成本。基于 K8S 的 PaaS 以应用为中心，容器技术大放异彩，将会成为未来 IT 基础设施的重要组成部分。
根据 Gartner 数据显示，在 IaaS 和 SaaS 逐步成熟的时候，企业越来越强调效率提升，而 PaaS 属于云计算的能力层，已迎来了一个非常好的发展时机。
根据 Google Trand，我们可以看到在去年7月份的时候，PaaS 和 IaaS两大代表性的开源项目的活跃度对比，Kubernetes 的活跃度已经超过了 OpenStack，目前仍处于快速发展阶段。
接下来，随着 DevOps 的深化、普及，将会形成更加标准化的应用交付流程。PaaS 会逐步弱化 IaaS 层的一些概念，在某些需求场景下甚至舍弃 IaaS，在物理资源上直接部署 PaaS。微服务、服务网格、APM 等应用侧工具逐步繁荣，用户的重心向业务架构及其治理方向转移。
随着云的类型增多及其复杂性的增加，多云管理、云管平台也会出现强烈需求，另外用户对“云原生”的更多理解，会带动新的开发模式、开发框架的产生，比如 Serverless 等。
四、虚拟化技术
过去一直在做客户端的开发工作，过程中多少了解和使用过虚拟化技术产品，但对虚拟化技术和实现原理没有一个系统性的认识。这两天抽空学习相关材料，对整体有个印象，这里做一下总结。
虚拟化技术本身很广泛，加上各大公司不同的虚拟化产品越来越受欢迎，在各技术领域影响也越来越大，虚拟化技术就更难界定了。总体来说，任何一种把资源抽象成另外一种形式的技术都是虚拟化技术，包括计算机的虚拟内存、进程，PC上使用的虚拟机软件，Android上的虚拟机，他们用到的技术都是虚拟化技术，只是抽象的粒度不同。
1、分类
? 为了对虚拟化技术有一个整体上的认识，需要先了解虚拟化技术的分类。不同的人和组织对虚拟化技术的分类不同，维基百科上对于虚拟化技术有两种分类方法，分别是按虚拟对象分类、按抽象程度分类。也有人按计算机系统的分层来分类，感觉这种分类更容易理解一些，这里梳理一下，从计算机系统分层上来看，虚拟化技术可以分成以下几类：
硬件抽象层的虚拟化
? 通过软件来模拟不同架构的处理器、内存、总线、磁盘IO等硬件设备，被模拟的机器上可以安装不同的系统。运行时，软件会将虚拟机所发出的指令，转换成物理机能够执行的指令，在物理机上执行。这种级别的虚拟化对于模拟相同架构的平台有很好的兼容性，因为相同架构的指令集是相同的，但如果模拟的是不同架构，运行时的开销会比较大。 从历史发展的角度看，虚拟化源于大型机操作系统的分页概念，之后才有论文提出怎样的系统结构是虚拟化系统结构。1979年Unix引入了chroot机制，允许进程和子进程把一个目录指定为根目录，所有的文件系统操作都只能在这个目录内执行，这样就分离了每个进程的访问权限。这样的思路为虚拟化和容器技术奠定了基础，之后开创者们更进一步，各种解决了进程隔离和网络空间隔离的技术都陆续出现。
? 早期实现的系统虚拟化技术，靠的是纯软件方法。实现复杂且开销大，后来业界逐渐意识到，更好的实现方式必须从体系结构入手。2006年之后Intel和AMD陆续推出了支持硬件虚拟化的CPU，例如Intel的vt技术，AMD的svm技术。之后为了完善虚拟化生态系统，计算机系统的各个层次都开始支持虚拟化，如Intel在芯片组中提供针对IO虚拟化功能的VT-d技术，在网卡中提供支持网络虚拟化的VMDq技术，在云游戏使用的显卡虚拟化技术GVT。
发展到今天，市面上已经有很多优秀的虚拟化应用，这里截取维基百科词条上的一部分
操作系统层的虚拟化
? 即我们常说的容器化，由操作系统提供支持，运行多个用户态的实例，每个实例有自己的运行环境，拥有自己的文件系统、CPU、内存、磁盘等，但不是一个完整的操作系统，只是一个被隔离的进程。这种技术目前最热门的应用就是Docker，比起虚拟机，Docker资源占用少、体积小、启动快，能够动态伸缩扩容，方便组建微服务架构，在持续集成上常用来提供构建环境。
函数库层面的虚拟化
? 应用软件最终都是使用系统库函数完成功能的，不同的操作系统有不同的函数接口，函数库的虚拟化就是虚拟操作系统的函数接口，从而实现让软件不需要修改就能运行在原本没有库函数的操作系统上。这一技术的典型应用就是Wine，他能够在linux上运行windows程序。
进程层面的虚拟化
? 教材上叫编程语言层面的虚拟化，本质上是系统的一个进程，是模拟出来的一台抽象计算机，被设计用来在平台无关的环境中执行程序指令，有处理器、堆栈、寄存器等，但和硬件上的计算机体系结构不同，它是另外一套体系结构。这一类的应用有Java的JVM，Andriod上的Dailvik和ART等。
2、系统虚拟机相关技术概念
虚拟机监控器
硬件抽象层虚拟化使得虚拟机提供了运行整个操作系统所需的功能，虚拟化的具体实现称为虚拟机监控器VMM(Virtual Machine Monitor)，也叫Hypervisor，它以软件的形式实现物理机资源。
1974年的一篇文章Formal requirements for virtualizable third generation architectures 将Hypervisor按实现结构分成了两种类型，这个划分方法影响至今.
第一种Hypervisor是直接跑在宿主机上面作为操作系统的，特点是需要硬件支持、程序作为操作系统运行、效率高。客户机操作系统跑在上面对底层资源的访问都会被Hypervisor拦截，由它代为操作并返回结果，从而实现对系统资源的隔离。采用这种类型的虚拟机软件有VMware ESXi、 Xen等。
第二种Hypervisor是作为应用程序跑在操作系统上的，客户端机操作系统跑在他上面所有访问也会被拦截，由于Hypervisor不直接访问硬件资源，因此运行效率通常比第一种低。采用这种类型的虚拟机软件有VMware Workstation、VirtualBox等。
以下是维基百科上的分类，第一种是”原生虚拟化“、第二种是”需要宿主操作系统“的虚拟化
KVM
从前面的分类列表里可以看到KVM属于原生虚拟化程序，起初是单独的程序，后来被合并到Linux内核2.6.20中，使得Linux在内核层面支持虚拟机，让每一个虚拟机实例能够作为不同的Linux进程运行。
KVM需要CPU支持虚拟化，例如Intel的VT和AMD-V，它以可加载内核模块的形式存在，并且只负责CPU和内存的虚拟化，其他设备如IO虚拟化需要用户空间负责。例如截图中提到的QEMU，早期是纯软件实现的虚拟机，模拟了CPU、内存、IO、网卡、声卡等全部的硬件设备，等到KVM开发时直接在QEMU的基础上进行开发，把CPU和内存的虚拟化放到了KVM中实现，而IO等模块的虚拟化依然放在了QEMU。
五、网络安全
随着互联网日益走进人们的衣食住行各个方面，网络安全也渐渐成为大众所关心重视的点。特别是依靠互联网发家的各大互联网企业，更是对网络安全十分看重。因此，网络安全防御型人才更是成为企业的抢手货，如：安全服务工程师、安全运维工程师，对于这方面的人才，公司在薪资上也是毫不吝啬，待遇极其丰厚。因此各行业将网络安全工程师纳入企业日常配置已成必然之势。
简介
网络安全是一种保护计算机、服务器、移动设备、电子系统、网络和数据免受恶意攻击的技术，这种技术也称为信息技术安全或电子信息安全。该术语适用于从业务到移动计算的各种环境，可以分为几个常见类别。
- 网络安全是一种保护计算机网络免受入侵者（无论是定向攻击还是条件恶意软件）攻击的技术。
- 应用程序安全侧重于保护软件和设备免受威胁。受到侵害的应用程序可能会对其旨在保护的数据提供访问权限。并且，早在应用程序设计阶段而非部署程序或设备之前，就决定了此应用程序能否成功保障安全。
- 信息安全设计用于在存储和传输过程中保护数据的完整和私密。
- 运营安全包括处理和保护数据资产的过程和决策。用户在访问网络时所具有的权限与确定存储/共享数据的时间和位置的步骤均包含在此保护伞下。
- 灾难恢复和业务连续性定义了组织如何应对网络安全事件或任何其它导致运营/数据损失的事件。灾难恢复策略规定了组织如何恢复其运营和信息，以恢复到事件发生之前的等同运营能力。业务连续性指组织在没有某些资源的情况下尝试运营时所依靠的计划。
- 最终用户教育解决了最不可预测的网络安全因素：人。任何人都可能因未遵循良好的安全实践而意外将病毒引入到其他安全系统中。因此，教会用户删除可疑电子邮件附件、不要插入未识别的 USB 驱动器，以及其他各种重要的课程对于所有组织的安全都至关重要。
什么是网络安全工程师
网络安全工程师前景怎么样？随着互联网发展和IT技术的普及，网络和IT已经日渐深入到日常生活和工作当中，社会信息化和信息网络化，突破了应用信息在时间和空间上的障碍，使信息的价值不断提高。但是与此同时，网页篡改、计算机病毒、系统非法入侵、数据泄密、网站欺骗、服务瘫痪、漏洞非法利用等信息安全事件时有发生。而许多企事业单位的业务依赖于信息系统安全运行，信息安全重要性日益凸显。信息已经成为各企事业单位中重要资源，也是一种重要的“无形财富”，在未来竞争中谁获取信息优势，谁就掌握了竞争的主动权。信息安全已成为影响国家安全、经济发展、社会稳定、个人利害的重大关键问题。因此，网络安全工程师应运而生。
简而言之，网络安全工程师是公司聘用来保护自己公司数据的人。他们会通过各种技术来对公司的数据进行保护，例如：寻找公司数据存放的弱点，监控公司系统或网络中的缺陷等。然后他们会处理他们发现的问题，修复和加强公司信息网络中可能会被攻击的地方。
网络安全工程师前景如何
据英国相关机构提供的信息，网络安全工程师的毕业生起薪约为2.5万英镑，随着经验增加，薪资会快速增长到3.5万左右，进入更高等级的管理或顾问职位时，预期薪资将为4.5万英镑到8万英镑之间。在美国，信息安全分析师的平均起薪约为4万美元，之后可能会高达10.5美元左右。
而在我国，网络工程师目前职业整体的平均年薪为12.744万元，其中佼佼者网络安全工程师工资最高可达36万-60万每年。
网络安全工程师的前景十分被看好，因为互联网的发展，种种网络病毒与网络犯罪也随之而来，为了减少和防止该类犯罪给企业和个人带来的隐患，网络安全工程师必不可少。社会对信息安全服务的需求很大，军队、国防、银行、税务、证券、机关、电子商务都急需大批网络安全人才，网络安全工程师已跻身IT新贵之列。在我国，根据国家信息化建设的规模保守估计，2020年国内网络安全专业人才仍存在近百万的巨大缺口，高级的战略人才和专业技术人才尤其匮乏。