eth0模型

Ⅰ Docker容器间网络互联原理，讲不明白算我输

如上红字所描述：同一个宿主机上的不同容器之间的网络如何互通的？？？

我们安装完docker之后，docker daemon会为我们自动创建3个网络，如下：

其实docker有4种网络通信模型，分别是：bridge、host、none、container

默认的使用的网络模型是bridge，也是我们生产上会使用到的网络模型。

下文中跟大家分享docker容器互通原理到时候呢，用到的也是bridge网络模型

另外，当我们安装完docker之后，docker会为我们创建一个叫docker0的网络设备

通过ifconfig命令可以查看到它，看起来它貌似和eth0网络地位相当，像是一张网卡。然而并不是，docker0其实是一个Linux网桥

何以见得？可以通过下面的命令查看操作系统上的网桥信息

那大家怎么理解Linux网桥的概念呢？

其实大家可以把docker0理解成一台虚拟的交换机！然后像下面这样类比着理解，就会豁然开朗

1、它好比是大学在机房上课时，老师旁边的那个大大的交换机设备。

2、把机房里的电脑都连接在交换机上，类比成docker 容器作为一台设备都连接着宿主机上的docker0。

3、把交换机和机房中的机器的ip在同一个网段，类比成docker0、和你启动的docker容器的ip也同属于172网段。

类比成这样：

我们刚才做类比理解docker0的时候说：把机房里的电脑都连接在交换机上，类比成docker 容器作为一台设备都连接着宿主机上的docker0。那具体的实现落地实现用的是啥技术呢？

答案是：veth pair

veth pair的全称是：virtual ethernet，就是虚拟的以太网卡。

说到以太网卡大家都不陌生呀，不就是我们常见的那种叫eth0或者是ens的网络设备吗？

那这个veth pair是怎么玩的呢？有啥用呢？大家可以看下面这张图

veth-pair设备总是会成对的出现，用于连接两个不同network-namespace.

就上图来说，从network-namespace1的veth0中发送的数据会出现在 network-namespace2的veth1设备中。

虽然这种特性很好，但是如果出现有多个容器，你就会发现组织架构会越来越复杂，越来越乱

不过好在我们已经循序渐进的了解Linux网桥（docker0），以及这里的veth-pair设备，于是我们可以把整体的架构图重新绘制成下面这样

因为不同容器有自己隔离后的network-namespace所以他们都有自己的网络协议栈

那我们能不能找到容器里面的网卡和物理机上的哪张卡是一对网络vethpair设备呢？

如下：

回到宿主机

意思是就是说，容器545ed62d3abf的eth0网卡和宿主机通过ip addr命令查看的网络设备标号55的设备组成一对vethpair设备，彼此流量互通！

先看个简单的，同一个局域网中的不同主机A、B之间是如何互联交换数据的。如下图

那，既然是同一个局域网中，说明A、B的ip地址在同一个网段，如上图就假设它们都在192.168.1.0网段。

还得再看下面这张OSI 7层网络模型图。

主机A向主机B发送数据，对主机A来说数据会从最上层的应用层一路往下层传递。比如应用层使用的http协议、传输层使用的TCP协议，那数据在往下层传递的过程中，会根据该层的协议添加上不同的协议头等信息。

根据OSI7层网络模型的设定，对于接受数据的主机B来说，它会接收到很多数据包！这些数据包会从最下层的物理层依次往上层传递，依次根据每一层的网络协议进行拆包。一直到应用层取出主机A发送给他的数据。

那么问题来了，主机B怎么判断它收到的数据包是否是发送给自己的呢？万一有人发错了呢？

答案是：根据MAC地址，逻辑如下。

那对于主机A来说，它想发送给主机B数据包，还不能让主机B把这个数据包扔掉，它只能中规中矩的按以太网网络协议要求封装将要发送出去的数据包，往下传递到数据链路层（这一层传输的数据要求，必须要有目标mac地址，因为数据链路层是基于mac地址做数据传输的）。

那数据包中都需要哪些字段呢？如下：

其中的dst ip好说，我们可以直接固定写，或者通过DNS解析域名得到目标ip。

那dst mac怎么获取呢？

这就不得不说ARP协议了! ARP其实是一种地址解析协议，它的作用就是：以目标ip为线索，找到目的ip所在机器的mac地址。也就是帮我们找到dst mac地址！大概的过程如下几个step

推荐阅读：白日梦的DNS笔记

简述这个过程：主机A想给主机B发包，那需要知道主机B的mac地址。

嗯，在arp协议的帮助下，主机A顺利拿到了主机B的mac地址。于是数据包从网络层流转到数据链路层时已经被封装成了下面的样子：

根据OIS7层网络模型，我们都知道数据包经过物理层发送到机器B，机器B接收到数据包后，再将数据包向上流转，拆包。流转到主机B的数据链路层。

那主机B是如何判断这个在数据链路层的包是否是发给自己的呢？

答案前面说了，根据目的mac地址判断。

这个例子比较简单，dst ip就是主机B的本机ip 所以它自己会处理这个数据包。

那数据包处理完之后是需要给主机A一个响应包，那问题又来了，响应包该封装成什么样子呢？对主机B来说响应包也需要src ip、src mac、dst ip、dst mac

同样的道理，响应包也会按照如下的逻辑被主机A接受，处理。

这一次，让我在网络告诉你，当你请求 www..com 时都发生了什么？

有了上面那些知识储备呢？再看我们今天要探究的问题，就不难了。

如下红字部分：同一个宿主机上的不同容器是如何互通的？

那我们先分别登陆容器记录下他们的ip

先看实验效果：在9001上curl9002

实验结果是网络互通！

我们再完善一下上面的图，把docker0、以及两个容器的ip补充上去，如下图：

那两台机器之前要通信是要遵循OSI网络模型、和以太网协议的。

我们管172.17.0.2叫做容器2

我们管172.17.0.3叫做容器3

比如我们现在是从：容器2上curl 容器3，那么容器2也必须按照以太网协议将数据包封装好，如下

那现在的问题是容器3的mac地址是多少？

容器2会先查自己的本地缓存，如果之前没有访问过，那么缓存中也没有任何记录！

不过没关系，还有arp机制兜底，于是容器2会发送arp请求包，大概如下

容器2会查询自己的路由表，将这个arp请求从自己的gateway发送出去

我们发现容器2的网关对应的网络设备的ip就是docker0的ip地址，并且经由eth0发送出去！

哎？eth0不就是我们之前说的veth-pair设备吗？

并且我们通过下面的命令可以知道它的另一端对应着宿主机上的哪个网络设备：

而且我们可以下面的小实验，验证上面的观点是否正确

所以说从容器2的eth0出去的arp请求报文会同等的出现在宿主机的第53个网络设备上。

通过下面的这张图，你也知道第53个网络设备其实就是下图中的veth0-1

所以这个arp请求包会被发送到docker0上，由docker0拿到这个arp包发现，目标ip是172.17.0.3并不是自己，所以docker0会进一步将这个arp请求报文广播出去，所有在172.17.0.0网段的容器都能收到这个报文！其中就包含了容器3！

那容器3收到这个arp报文后，会判断，哦！目标ip就是自己的ip，于是它将自己的mac地址填充到arp报文中返回给docker0！

同样的我们可以通过抓包验证，在宿主机上

于是容器2就拿到了容器3的mac地址，以太网数据包需要的信息也就齐全了！如下：

再之后容器2就可以和容器3正常互联了！

容器3会收到很多数据包，那它怎么知道哪些包是发给自己的，那些不是呢？可以参考如下的判断逻辑

Ⅱ centos 双网卡绑定 mode哪种好些

CentOS双网卡绑定的模式一共有7种（即mode=0、1、2、3、4、5、6）：
0 （balance-rr模式）网卡的负载均衡模式。特点：（1）所有链 路处于负载均衡状态，轮询方式往每条链路发送报文，基于per packet方式发送。服务上ping 一个相同地址：1.1.1.1 双网卡的两个网卡都有流量发出。负载到两条链路上，说明是基于per packet方式 ，进行轮询发送。（2）这模式的特点增加了带宽，同时支持容错能力，当有链路出问题，会把流量切换到正常的链路上。
1 （active-backup模式）网卡的容错模式。 特点：一个端口处于主状态 ，一个处于从状态，所有流量都在主链路上处理，从不会有任何流量。当主端口down掉时，从端口接手主状态。
2 （balance-xor模式）需要交换机支持。特点：该模式将限定 流量，以保证到达特定对端的流量总是从同一个接口上发出。既然目的地是通过MAC地址来决定的，因此该模式在“本地”网络配置下可以工作得很好。如果所有 流量是通过单个路由器（比如 “网关”型网络配置，只有一个网关时，源和目标mac都固定了，那么这个算法算出的线路就一直是同一条，那么这种模式就没有多少意义了。），那该模式就不 是最好的选择。和balance-rr一样，交换机端口需要能配置为“port channel”。这模式是通过源和目标mac做hash因子来做xor算法来选路的。
3 （broadcast模式）。特点:这种模式的特点是一个报文会复制两份往bond下的两个接口分别发送出去,当有对端交换机失效，我们感觉不到任何downtime,但此法过于浪费资源;不过这种模式有很好的容错机制。此模式适用于金融行业，因为他们需要高可靠性的网络，不允许出现任何问题。
4 （IEEE 802.3ad动态链路聚合模式）需要交换机支持。特 点：802.3ad模式是IEEE标准，因此所有实现了802.3ad的对端都可以很好的互操作。802.3ad 协议包括聚合的自动配置，因此只需要很少的对交换机的手动配置（要指出的是，只有某些设备才能使用802.3ad）。802.3ad标准也要求帧按顺序 （一定程度上）传递，因此通常单个连接不会看到包的乱序。802.3ad也有些缺点：标准要求所有设备在聚合操作时，要在同样的速率和双工模式，而且，和 除了balance-rr模式外的其它bonding负载均衡模式一样，任何连接都不能使用多于一个接口的带宽。此外，linux bonding的802.3ad实现通过对端来分发流量（通过MAC地址的XOR值），因此在“网关”型配置下，所有外出（Outgoing）流量将使用 同一个设备。进入（Incoming）的流量也可能在同一个设备上终止，这依赖于对端802.3ad实现里的均衡策略。在“本地”型配置下，路两将通过 bond里的设备进行分发。
5 自适应传输负载均衡模式。特 点：balance-tlb模式通过对端均衡外出（outgoing）流量。既然它是根据MAC地址进行均衡，在“网关”型配置（如上文所述）下，该模式 会通过单个设备来发送所有流量，然而，在“本地”型网络配置下，该模式以相对智能的方式（不是balance-xor或802.3ad模式里提及的XOR 方式）来均衡多个本地网络对端，因此那些数字不幸的MAC地址（比如XOR得到同样值）不会聚集到同一个接口上。
不像802.3ad，该模式的接口可以有不同的速率，而且不需要特别的交换机配置。不利的一面在于，该模式下所有进入的（incoming）流量会到达同一个接口；该模式要求slave接口的网络设备驱动有某种ethtool支持；而且ARP监控不可用。
6 网卡虚拟化方式。特点：该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件 地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。所有端口都会收到对端的arp请求报文，回复arp 回时，bond驱动模块会截获所发的arp回复报文，根据算法算到相应端口，这时会把arp回复报文的源mac，send源mac都改成相应端口mac。 从抓包情况分析回复报文是第一个从端口1发，第二个从端口2发。以此类推。

具体选择哪种要根据自己需要和交换机情况定，一般Mode=0和Mode=1比较常见；Mode=6负载均衡方式，两块网卡都工作，不需要交换机支持，也常用

Ⅲ 网卡配置文件路径

网卡配置文件通常存放在/etc/sysconfig/network-scripts/ifcfg-interface-name目录中。其中interface-name是网络接口的名字，例如eth0、eth1、eno等，这个名称会根据网卡的类型和排序而有所不同。在配置文件中，可以定义诸如IP地址、子网掩码、网关、DNS服务器等网络参数，这些参数的设置取决于网络接口的类型和配置方式。网卡：一块被设计用来允许计算机在计算机网络上进行通讯的计算机硬件。由于其拥有MAC地址，因此属于OSI模型的第1层和2层之间。它使得用户可以通过电缆或无线相互连接。