虚拟化网络：以VMware Workstation为例，其网络有以下类型
桥接（Bridge）：网卡变身为交换机，虚拟出一个桥设备，作为主机的网卡，与虚拟机的网卡同样连接到交换机上；
仅主机（Host-only）：在宿主机上纯软件模拟出一个交换机，宿主机虚拟出一个网卡vnet1，虚拟机网卡和宿主机虚拟网卡连接到交换机，宿主机的虚拟网卡没有路由转发功能，不能与物理网卡通信；
NAT：宿主机虚拟一张网卡（vnet8），并模拟一个nat服务器，将vnet8的源地址nat为物理网卡的地址，实现各虚拟机与外部主机的通信。
Centos上使用桥设备，需要安装bridge-utils软件包，安装后，提供了brctl工具
使用brctl的配置桥设备的步骤：
brctl add br0 #添加桥设备
brctl stp br0 on #桥设备启动STP协议，自动生成树协议，避免环路
ifconfig eth0 0 up #取消物理网卡的IP地址配置
brctl addif br0 eth0 #为桥设备添加物理网卡接口
ifconfig br0 IP/NETMASK up # 为桥设备配置IP地址
route add default gw GW #配置默认路由
好像是在CentOS7上使用网桥时，不能使用NetworkManager网络管理器，要使用networknetw
也可以直接添加、修改配置文件：
/etc/sysconfig/network-scripts/目录下
复制ifcfg-ens33为ifcfg-br0，编辑ifcfg-br0
原来的ifcfg-ens33：地址、网关、DNS全部去掉，增加BRIDGE=br0，指定网卡桥接到哪个桥设备；
网络的虚拟化是虚拟技术中的重要一环，是理解各种虚拟实现方案的重要基础。
网络的虚拟化，涉及的一些技术，如桥接/网桥（Bridge）和桥接/网桥设备，TUN（Network TUNnel）/TAP（Network TAP）虚拟网络设备，是隧道设备，虚拟网卡，veth（虚拟以太网设备）和veth-pair，虚拟交换机vSwitch和OVS（Open Vitual Switch），socket，网络协议栈（Network Protocol Stack），网络设备驱动，网络设备管理子系统，三层路由和二层转发，交换机的主要功能，网络数据包的接收过程等。
Bridge（桥接设备） ：bridge是一个虚拟网络设备，具有网络设备的特征，可以配置IP、MAC地址等；其次，bridge是一个类虚拟交换机，和物理交换机有类似的功能。
对于普通的网络设备来说，只有两端，从一端进来的数据会从另一端出去，如物理网卡从外面网络中收到的数据会转发给内核协议栈，而从协议栈过来的数据会转发到外面的物理网络中。
而bridge不同，bridge有多个端口，数据可以从任何端口进来，进来之后从哪个口出去和物理交换机的原理差不多，要看mac地址，即是二层转发。
常见的物理交换机中，有可以配置IP和不能配置IP两种，不能配置IP的交换机一般通过com口连上去做配置（更简单的交换机连com口的没有，不支持任何配置），而能配置IP的交换机可以在配置好IP之后，通过该IP远程连接上去做配置，即配置的IP用来与交换机自身交互。
bridge就属于后一种交换机，自带虚拟网卡，可以配置IP，该虚拟网卡一端连在bridge上，另一端跟协议栈相连。和物理交换机一样，bridge的工作不依赖于该虚拟网卡。Bridge设备主要用于实现虚拟机之间的通信，或者将虚拟机连接到物理网络。通过Bridge，虚拟机可以像物理机一样，在网络中发送和接收数据包。
工作原理：当一个从设备（如Tap设备或物理网卡）被attach到Bridge上时，Bridge会学习该设备的MAC地址，并将其存储在内部的MAC地址-端口映射表（CAM表）中。当Bridge接收到数据包时，它会检查数据包的目标MAC地址，并在CAM表中查找对应的端口。如果找到匹配的端口，Bridge会将数据包转发到该端口；如果没有找到匹配的端口，Bridge可能会将数据包广播到所有端口，或者根据网络配置进行其他处理。
CAM（ Content Addressed Memory），内容可寻址存储器表，用于存储MAC地址与交换机端口的映射关系，实现以太网数据帧的快速转发和广播控制。
通过上面的叙述可以看出，网桥与交换机是非常相似的，交换机可以看成是网桥的功能升级设备，从其应用场景看，网桥的最初作用是实现网段的互联，是将两个或多个局域网连接起来的设备，而交换机的应用场景只要是实现一个局域网内单个设备之间的通信，本质是局域网（LAN）内部的 "数据交换中心"。它的核心功能是通过物理端口连接多个有线设备（如电脑、服务器、打印机、摄像头等），并根据设备的 MAC 地址高效转发数据帧，实现局域网内设备之间的高速通信。简单说，交换机是 "让同一局域网内的多个有线设备能互相通信" 的设备。
在虚拟化环境中，宿主机的物理网卡被桥接到虚拟网桥后，物理网卡通常不再拥有独立的IP地址。此时，IP 地址会被配置在虚拟网桥接口上，而非原来的物理网卡。
原因与机制：
▪ 在桥接模式下，虚拟网桥（如 br0、virbr0 或 VMware 的 VMnet0）充当一个虚拟交换机，将物理网卡和虚拟机的虚拟网卡连接在一起。
▪ 为了维持宿主机自身的网络通信能力，IP 地址会从物理网卡"迁移"到网桥接口，由网桥代表宿主机参与网络通信。
▪ 物理网卡此时工作在二层（数据链路层），仅负责转发帧，不再需要三层（网络层）的 IP 配置。
个人的理解如下（不一定正确）：
桥接模式下，宿主机创建虚拟网桥/虚拟交换机，vBridge/vSwitch，在vmware中，看到的是虚拟交换机VMnet0，实际上是虚拟网桥，宿主机的物理网卡PNIC桥接到网桥上，PNIC就变成了一条网线，此时宿主机就相当于没有网卡了，无法与外界通信，所以虚拟出VPNIC，用于宿主机的虚拟网卡，宿主机通过VPNIC一端与宿主机内核HOS中的网络协议栈NPS连接，一端连接到vBridge/vSwtich，实现与外部网络和内部虚拟机的通信，实际上，VPNIC是与vBridge一体的，这是虚拟网桥的功能，也就是前面说的虚拟网桥自带虚拟网卡，所以物理网卡PNIC上无需配置IP，VPNIC的IP与MAC与PNIC相同，完全取代PNIC。所以说配置虚拟网桥的地址就是配置宿主机的地址。虚拟机VM通过各自的虚拟网卡VNIC，一端连接到虚拟机内核VOS中的虚拟网络协议栈VNPS，一端链接到虚拟网桥/虚拟交换机上，实现与宿主机和外部网络的通信，通过示意图，宿主机Host和虚拟机VM是处于同一个局域网中，地位平等。
上图中虚拟网卡VNIC和VPNIC与虚拟网桥的链接，用了一条红色双向虚线表示，浅层面上，就可以认为是一条网线，但实际我们知道这里根本没有网线的，这条链接还涉及更多虚拟网络设备，稍后再说。
主机网络通信理解 ：了解一下一台主机通信，即收发网络报文的过程（个人理解，可能有误）
网络数据的收发，要经过网卡、网络设备驱动程序、网络设备管理子系统、网络协议栈、用户APP等部件。接收过程：网络数据包，我们接触到的大多数是以太网帧，进入物理网卡，被物理网卡接收后，物理网卡发送中断请求，中断响应会调用网络设备管理子系统，判断设备类型，然后调用对应的网络设备驱动程序，将物理网卡接收的数据保存到内核中的缓存，然后由网络设备管理子程序将数据送入网络协议栈，在网络协议栈中，数据包依次经过MAC层、IP层、TCP层，最后经过SOCKET送到用户APP进程中，MAC层拆掉MAC帧头，将IP报文送到IP层，IP层拆掉IP报头，将TCP报文送到TCP层，TCP层根据端口号，找到对应SOCKET，然后送到用户APP中，完成数据接收。发送过程：用户APP的原始数据，进入网络协议栈，经过SOCKET进入TCP层，TCP层添加TCP报头，下送到IP层，IP层添加IP报头，同时要查询路由表，确定转发的网络接口，下送到MAC层，MAC层根据转发的网络接口，添加MAC帧头，然后在网络设备管理子系统的协助下，将MAC帧数据从网络协议栈保存到内核缓存中，然后网络设备管理子系统调用对应的网络设备驱动程序，将缓存中的帧从对应接口中发送出去。
这个过程中，我的一点疑惑是，IP的源地址是如何确定的，正常是建立SOCKET时就确定了，一般是本地网卡配置的IP，但是这个封装是否强制保证呢？如果不强制，将源IP改了，数据包发送后，假设是A机器发送的请求报文给服务器S，其源IP写的是B机器的IP，服务器S收到报文后，会将应答报文响应给B，这实际上形成了一种网络攻击，A借助S攻击B；同样道理，在MAC层添加MAC帧头时，源MAC如何确定，是否必须与对应网卡的MAC一致，如果不一致，在报文接收端就无法正确判断是哪一台机器发送的报文，如果结合IP层，这种攻击报文朔源都很难。这是题外话。
再回到话题，了解报文收发过程，主要是了解各个部件在其中的作用。
网络报文添加IP报头和MAC帧头的过程，分别由网络协议栈和网络设备驱动程序协同完成，具体分工如下：
• IP报头的添加：由 操作系统内核中的网络协议栈（网络层） 完成。
当应用层数据向下传递至网络层时，协议栈会根据目标IP地址、协议类型（如TCP/UDP）等信息，自动生成并封装IP头部，形成IP数据报 。
• MAC帧头的添加：由 网卡驱动程序（属于数据链路层） 完成。
网络层将封装好的IP数据报传递给数据链路层后，网卡驱动程序会进一步添加MAC帧头（包含源和目的MAC地址）、帧尾（如CRC校验），最终形成可在物理链路上传输的以太网帧 。
TUN与TAP ：
在计算机网络中，TUN与TAP是操作系统内核中的虚拟网络设备。不同于普通靠硬件网路板卡实现的设备，这些虚拟的网络设备全部用软件实现，并向运行于操作系统上的软件提供与硬件的网络设备完全相同的功能。
TAP等同于一个以太网设备，它操作第二层数据包如以太网数据帧，一般可称为虚拟网卡。TUN模拟了网络层设备，操作第三层数据包比如IP数据封包，一般称为隧道设备。
操作系统通过TUN/TAP设备向绑定该设备的用户空间的程序发送数据，反之，用户空间的程序也可以像操作硬件网络设备那样，通过TUN/TAP设备发送数据。在后种情况下，TUN/TAP设备向操作系统的网络栈投递（或"注入"）数据包，从而模拟从外部接受数据的过程。
TUN/TAP 设备是操作系统内核中的虚拟网络设备，是用软件模拟的网络设备，提供与硬件网络设备完全相同的功能。主要用于用户空间和内核空间传递报文。
双重身份：从不同视角看，TUN/TAP设备有着不同的身份：
• 从Linux文件系统视角：TUN/TAP是用户可以用文件句柄操作的字符设备。这种设计使得用户态程序可以像操作普通文件一样操作网络数据包。
• 从网络虚拟化视角：它是虚拟网卡，一端连接着内核网络协议栈，另一端连接着用户态程序。这种特殊的"桥梁"设计，为网络数据包的处理提供了极大的灵活性。
tun与tap：表兄弟而非亲兄弟 ，虽然经常被并列提及，但tun和tap有着明显的区别：
• tun设备：虚拟的是点对点设备，工作在网络层（第三层），处理的是IP数据包。它没有 MAC 地址，因此不能处理 ARP 请求或以太网广播。
• tap设备：虚拟的是以太网设备，工作在数据链路层（第二层），处理的是完整的以太网帧。拥有 MAC 地址，可以参与桥接网络，就像一块虚拟的以太网卡。
TUN/TAP设备的作用：TUN/TAP设备可以将TCP/IP协议栈处理好的网络包发送给任何一个使用TUN/TAP驱动的进程，由进程重新处理后发到物理链路中。TUN/TAP设备就像是埋在用户程序空间的一个钩子，我们可以很方便地将对网络包的处理程序挂在这个钩子上。
核心工作原理：连接用户空间与内核空间
• 物理网卡：一端连接的是物理网络，一端连接的是网络协议栈。
• TUN/TAP 设备：在操作系统内部连接了内核网络协议栈和用户空间的应用程序。一端连接的是应用程序，一端连接的是网络协议栈。
从网络协议栈的角度看，TUN/TAP设备这类虚拟网卡与物理网卡并无区别。只是对TUN/TAP设备而言，它与物理网卡的不同表现在它的数据源不是物理链路，而是来自用户态！这也是TUN/TAP设备的最大价值所在。TUN/TAP设备其实就是利用Linux的设备文件实现内核态和用户态的数据交互，而访问设备文件则会调用设备驱动相应的例程，要知道设备驱动也是内核态和用户态的一个接口。tun设备的工作模式如下图所示。
从上图可以更直观的看出 tun/tap 设备和物理设备的区别：虽然它们的一端都是连着网络协议栈，但是物理网卡另一端连接的是物理网络，而 tun/tap 设备另一端连接的是一个应用层程序，这样协议栈发送给 tun/tap 的数据包就可以被这个应用程序读取到，此时这个应用程序可以对数据包进行一些自定义的修改。
个人的理解，对于上图的虚拟网卡tun/tap，是对于B、C进程而言的，也就是B、C进程网络通信时看到有虚拟网卡，以B为例，B在应用层准备发送的内容，然后通过Socket和网络协议栈，最后通过虚拟网卡驱动程序，将数据包发送到/dev/net/tun文件中，这里的虚拟网卡驱动，其实就是一个字符设备驱动，用来写/dev/net/tun文件，写完后，就相当物理网卡把数据包从网线上发送出去。进程A读取/dev/net/tun，只是一个单纯的文件读操作，不涉及网络协议栈，使用的是字符设备驱动。而对于进程A写/dev/net/tun文件，也是单纯的文件写操作，不涉及网络协议栈，写完后，相当于物理网卡从网线上接收到数据包，然后虚拟网卡驱动程序会从/dev/net/tun文件中读数据，此时驱动是字符设备驱动，读取完毕，转换为网络设备驱动的角色，完成数据包送网络协议栈的功能。
Tun/tap 设备提供的虚拟网卡驱动，从tcp/ip协议栈的角度而言，它与真实网卡驱动并没有区别。
tun/tap 有两种模式，tun模式与tap模式。tun设备与tap设备工作方式完全相同，区别在于：
-
Tun 设备是一个三层设备，从 /dev/net/tun 字符设备上读取的是 IP 数据包，写入的也只能是 IP 数据包，因此不能进行二层操作，如发送 ARP 请求和以太网广播。
-
Tap 设备是二层设备，处理的是二层 MAC 层数据帧，从 /dev/net/tun 字符设备上读取的是 MAC 层数据帧，写入的也只能是 MAC 层数据帧。从这点来看， Tap 虚拟设备和真实的物理网卡的能力更接近，可以与物理网卡做 bridge。
tun虚拟设备用于VPN的场景：
发送过程，红线是内网IP，黑色线是加密过后的公网IP包。应用程序发送目的IP为内网IP的数据包，会先通过虚拟网卡，转到字符设备文件，被 VPN 进程读取到。在VPN进程经过封包加密后，通过网络协议栈路由到物理网卡，最终通过公网网卡发送出去。接收过程，黑线是公网IP，红线是解密后的内网IP包。VPN 进程监听的是公网IP+端口，数据包经过网卡到达协议栈，到达 VPN 进程，VPN 进程解密解包后，将数据通过字符设备文件发送给虚拟网卡设备，再次经过协议栈的路由，最终将数据发到用户程序。
VMware虚拟机的虚拟网卡在Linux宿主机上通常使用的是TAP设备，对前图做一个延伸（个人理解，可能有误）：
将应用进程延伸为虚拟机，进入到虚拟机内部，在内部又经过了一个网络协议栈的过程，如果从Host角度观看，虚拟机只是一个用户态的应用进程。虚拟机到/dev/net/tap之间的过程不是网络通信过程，只是文件读写过程，模拟了网线；虚拟交换机将/dev/net/tap作为输入和输出，或者作为端口，按照二层交换进行处理，是网络通信，不经过宿主机的网络协议栈，只有与宿主机的通信，才会经过宿主机的网络协议栈。
veth虚拟网络设备 ：Veth虚拟网络设备(Virtual Ethernet Device)是成对出现的网络设备，也叫做veth-pair，可以理解为软件模拟的一对 "虚拟网卡"，也就是，当你创建一个veth时候，此时会自动创建对端的veth设备，并且这两个veth设备是相连的，可以理解为2个接口中间连着根线，一端连着协议栈，一端彼此相连着。如下图：
正因为有这个特性，它常常充当着一个桥梁，连接着各种虚拟网络设备，典型的例子像两个 "namespace"之间的连接，"Bridge、OVS 之间的连接"，"Docker 容器之间的连接"等。
veth设备的特点：
• veth和其它的网络设备都一样，一端连接的是内核协议栈。
• veth设备是成对出现的，另一端两个设备彼此相连
• 一个设备收到协议栈的数据发送请求后，会将数据发送到另一个设备上去。
veth pair 就是软件实现的这种 "直连网线"，一端叫 veth0，另一端叫 veth1，数据从 veth0 发出，必然从 veth1 收到，反之亦然。所以它的主要作用之一是反转数据流方向。它和本机的 lo （回环设备）不同，lo 是 "自己发给自己"，而 veth 是 "一端发给另一端"，是跨命名空间或跨容器通信的基础。
veth pair 是 Docker 、Kubernetes 等容器技术实现网络隔离和通信的核心机制：
• 容器网络：每个容器都有自己的网络命名空间，容器内的 eth0 实际上就是 veth pair 的一端，另一端在宿主机上，连接到网桥（bridge）或路由表，从而实现容器与宿主机、容器与外部网络的通信。
• 网络命名空间通信：不同 network namespace 之间无法直接通信，veth pair 就是连接它们的 "桥梁"。
网络命名空间 ------ 隔离的基石：
默认情况下，所有的进程（包括 Docker 容器里的进程）都在一个叫 host net 的默认命名空间里。大家共用一张路由表、共用所有的网卡（eth0, lo 等）、共用 iptables。
当你创建一个新的网络命名空间（比如叫 net1），你就相当于凭空变出了一套全新的、独立的网络协议栈：
• 独立的网卡：在这个空间里，你看不到宿主机的 eth0，除非特意把它放进去。
• 独立的 IP：你可以给这个空间配一个和宿主机完全不同的 IP 段。
• 独立的规则：这个空间里的 iptables 规则和宿主机互不干扰。
再看虚拟网桥、veth及虚拟机网络 ：
宿主机新建一个Bridge时，它是一个独立的网络设备，只有一个端口连接协议栈，其他端口什么也没有连接；加入veth-pair并配置IP；将veth0加入Bridge；将物理网卡加入Bridge；虚拟机的虚拟网络示意图。Bridge作为虚拟交换机，加入的Bridge的网络设备变为线路（端口）。
br0和veth0相连之后，发生了几个变化：
• br0和veth0之间连接起来了，并且是双向的通道
• 协议栈和veth0之间变成了单通道，协议栈能发数据给veth0，但veth0从外面收到的数据不会转发给协议栈
• br0的mac地址变成了veth0的mac地址
• veth0与协议栈的连接失去作用，变成一根单纯的网线，bridge配置veth0的IP，代替veth0
bridge配置为物理网卡MAC和IP，取代物理网卡。
网络通信中核心关系：网卡、网卡驱动、网络协议栈（内核）
• 网卡（Network Interface Card, NIC）：是物理硬件设备，负责将数字信号转换为电信号或光信号，在网络介质（如网线、光纤）上传输。
• 网卡驱动：是操作系统内核中的软件模块，用于控制和管理网卡硬件，提供内核协议栈与网卡之间的接口。
• 网络协议栈：是操作系统内核中的软件层（如 TCP/IP 协议栈），负责处理网络通信的逻辑，包括封装/解封装数据包、路由、错误检测等。
三者构成一个分层协作体系：
应用层 → 协议栈 → 驱动 → 网卡硬件
• 网络协议栈（如 TCP/IP）：
-
负责数据包的封装与解封装（添加 IP、TCP/UDP、MAC 头部等）。
-
执行路由决策，确定数据包应从哪个网卡发出。
-
通过 ARP 协议获取下一跳设备的 MAC 地址。
-
将组装好的以太网帧交给网卡驱动发送 。
• 网卡驱动：
-
初始化网卡硬件（如读取 EEPROM 中的 MAC 地址、配置 DMA 缓冲区）。
-
提供标准接口供协议栈调用。
-
使用 DMA 将协议栈生成的数据包从内存传输到网卡硬件，避免 CPU 频繁参与 。
-
通过中断或 NAPI 机制通知协议栈有新数据到达 。
• 网卡硬件：
-
永久存储全球唯一 MAC 地址（通常在 EEPROM 中）。
-
将数字帧转换为物理信号（电信号/光信号）发送 。
-
接收物理信号并转换为数字数据，通过 DMA 传入主机内存 。