A. 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会收到很多数据包，那它怎么知道哪些包是发给自己的，那些不是呢？可以参考如下的判断逻辑

B. 什么是ARP

地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址；收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。

地址解析协议是建立在网络中各个主机互相信任的基础上的，局域网络上的主机可以自主发送ARP应答消息，其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存；由此攻击者就可以向某一主机发送伪ARP应答报文，使其发送的信息无法到达预期的主机或到达错误的主机，这就构成了一个ARP欺骗。

(2)arp出现2个eth0扩展阅读：

RARP和ARP不同，地址解析协议是根据IP地址获取物理地址的协议，而反向地址转换协议（RARP）是局域网的物理机器从网关服务器的ARP表或者缓存上根据MAC地址请求IP地址的协议，其功能与地址解析协议相反。与ARP相比，RARP的工作流程也相反。首先是查询主机向网路送出一个RARP Request广播封包，向别的主机查询自己的IP地址。这时候网络上的RARP服务器就会将发送端的IP地址用RARP Reply封包回应给查询者，这样查询主机就获得自己的IP地址了。

A. The principle of network interconnection between Docker containers, if you can’t explain it clearly, I lose

As described in the red text above: How do the networks between different containers on the same host communicate with each other? ? ?

After we install docker, the docker daemon will automatically create 3 networks for us, as follows:

In fact, docker has 4 network communication models, namely: bridge, host, none , container

The default network model used is bridge, which is also the network model we will use in production.

Next, I will share with you the principles of docker container interoperability. The bridge network model will also be used.

In addition, after we install docker, docker will create a network called The network device of docker0

You can view it through the ifconfig command. It seems that it has the same status as the eth0 network, like a network card. But no, docker0 is actually a Linux bridge

How can you tell? You can use the following command to view the bridge information on the operating system

So how do you understand the concept of Linux bridges?

In fact, you can understand docker0 as a virtual switch! Then understand it through the analogy below, and it will suddenly become clear

1. It is like the big switching device next to the teacher in the computer room of the university.

2. Connect all the computers in the computer room to the switch. It is analogous to the docker container as a device connected to docker0 on the host machine.

3. The IP of the switch and the machine in the computer room are in the same network segment, analogously to docker0, and the IP of the docker container you started also belongs to the same network segment 172.

The analogy is like this:

When we just made an analogy to understand docker0, we said: connect all the computers in the computer room to the switch, and the docker container is connected as a device. docker0 on the host machine. So what specific technology is used to implement it?

The answer is: veth pair

The full name of veth pair is: virtual ethernet, which is a virtual Ethernet card.

Everyone is familiar with Ethernet cards., isn’t it our common network device called eth0 or ens?

So how does this veth pair work? What's the use? You can look at the picture below

Veth-pair devices always appear in pairs and are used to connect two different network-namespaces.

As far as the picture above is concerned, from The data sent in veth0 of network-namespace1 will appear in the veth1 device of network-namespace2.

Although this feature is very good, if there are multiple containers, you will find that the organizational structure will become more and more complex and chaotic

But fortunately we have Step by step, we will understand the Linux network bridge (docker0) and the veth-pair device here, so we can redraw the overall architecture diagram as follows

Because different containers have their own isolated network-namespace, They all have their own network protocol stack

So can we find out which card in the container and physical machine is a pair of network vethpair devices?

As follows:

Return to the host

This means that the eth0 network card of the container 545ed62d3abf and the network device label 55 viewed by the host through the ip addr command The devices form a pair of vethpair devices and communicate with each other!

Let’s first look at a simple example of how different hosts A and B in the same LAN interconnect and exchange data. As shown in the picture below

Well, since they are in the same LAN, it means that the IP addresses of A and B are in the same network segment. As shown in the picture above, assume that they are both in the 192.168.1.0 network segment.

You have to look at the following OSI 7-layer network model diagram again.

Host A sends data to host B. For host A, the data will be passed from the uppermost application layer all the way to the lower layer. For example, if the http protocol used by the application layer and the TCP protocol used by the transport layer are transmitted to the lower layer, different protocol header information will be added according to the protocol of that layer.

According to the settings of the OSI7 layer network model, for host B that receives data, it will receive a lot of data packets! These data packets will be passed from the lowest physical layer to the upper layer in sequence, and will be unpacked according to the network protocol of each layer. Until the application layer takes out the data sent to him by host A.

So the question is, how does host B determine whether the data packet it receives is sent to itself? What if someone sent it by mistake?

The answer is: According to the MAC address, the logic is as follows.

For host A, if it wants to send a data packet to host B, it cannot let host B throw away the data packet. It can only encapsulate it according to the requirements of the Ethernet network protocol and send it out. The data packet is passed down to the data link layer (the data transmitted at this layer must have a target mac address, because the data link layer transmits data based on the mac address).

What fields are required in the data packet? As follows:

The dst ip is easy to say, we can directly write it fixedly, or resolve the domain name through DNS to get the target ip.

How to get dst mac?

This has to be said about the ARP protocol! ARP is actually an address resolution protocol. Its function is to use the target IP as a clue to find the mac address of the machine where the target IP is located. That is to help us find the dst mac address! The general process is as follows

Recommended reading: Daydream's DNS Notes

Briefly describe this process: Host A wants to send a packet to Host B, so it needs to know the mac of Host B address.

Well, with the help of the arp protocol, host A successfully obtained the mac address of host B. So when the data packet flows from the network layer to the data link layer, it has been encapsulated as follows:

According to the OIS7 layer network model, we all know that the data packet is sent to machine B through the physical layer, and machine B After receiving the data packet, the data packet is forwarded upward and unpacked. Flows to the data link layer of host B.

How does host B determine whether the packet at the data link layer is sent to itself?

As mentioned before, the answer is based on the destination mac address.

This example is relatively simple. dst ip is the local ip of host B, so it will process this data packet by itself.

After the data packet is processed, a response packet needs to be sent to host A. Then the question arises again. What should the response packet be encapsulated in? For host B, the response packet also requires src ip, src mac, dst ip,dst mac

In the same way, the response packet will be accepted and processed by host A according to the following logic.

This time, let me tell you on the Internet, what happens when you request www..com?

With the above knowledge reserves? Looking at the question we are going to explore today, it is not difficult.

The following red text: How do different containers on the same host communicate with each other?

Then we first log in to the containers and record their IPs

Let’s look at the experimental results first: curl9002 on 9001

The experimental result is network interoperability!

Let’s improve the above picture and add docker0 and the IPs of the two containers, as shown below:

The two machines must follow the OSI network model before communicating. , and Ethernet protocol.

We call 172.17.0.2 container 2

We call 172.17.0.3 container 3

For example, we are now curling container 3 from: container 2, Then container 2 must also encapsulate the data packet according to the Ethernet protocol, as follows

The question now is what is the mac address of container 3?

Container 2 will first check its own local cache. If it has not been accessed before, there will be no record in the cache!

But it doesn’t matter, there is still an arp mechanism to cover it up, so container 2 will send an arp request packet, which is roughly as follows

Container 2 will query its own routing table and transfer this arp request from its own gateway is sent out

We found that the ip of the network device corresponding to the gateway of container 2 is the ip address of docker0, and it is sent out via eth0!

Huh? Isn't eth0 the veth-pair device we mentioned before?

And we can know which network device on the host the other end corresponds to by running the following command:

And we can conduct the following small experiment to verify whether the above point of view is correct.

Therefore, the arp request message sent from eth0 of container 2 will equally appear on the 53rd network device of the host.

From the picture below, you also know that the 53rd network device is actually veth0-1 in the picture below

So this arp request packet will be sent to docker0. When docker0 gets the arp packet, it is found that the target IP is 172.17.0.3 and not its own, so docker0 will further broadcast the arp request packet, all at 172.17 Containers in the .0.0 network segment can all receive this message! Container 3 is included!

After receiving this arp message, container 3 will judge, oh! The target IP is its own IP, so it fills its own mac address into the arp message and returns it to docker0!

Similarly, we can verify it by capturing packets on the host machine

So container 2 gets the mac address of container 3, and the information required for the Ethernet packet is complete. ! As follows:

After that, container 2 can be connected to container 3 normally!

Container 3 will receive a lot of data packets, so how does it know which packets are sent to itself and which ones are not? You can refer to the following judgment logic

B. What is ARP

Address Resolution Protocol, or ARP (Address Resolution Protocol), is a TCP/IP protocol that obtains physical addresses based on IP addresses. . When the host sends information, it broadcasts the ARP request containing the target IP address to all hosts on the local area network and receives the return message to determine the target's physical address; after receiving the return message, the IP address and physical address are stored in the local machine. The ARP cache is kept for a certain period of time, and the ARP cache is directly queried on the next request to save resources.

The address resolution protocol is based on mutual trust between hosts in the network. Hosts on the local area network can send ARP response messages independently, and other hosts will not detect the message when they receive the response message. The authenticity will be recorded in the local ARP cache; thus the attacker can send a fake ARP reply message to a certain host, so that the information sent cannot reach the expected host or reaches the wrong host, which constitutes Got an ARP spoofed.

(2) 2 eth0 appear in arp Extended reading:

RARP is different from ARP. Address Resolution Protocol is a protocol that obtains a physical address based on an IP address, while Reverse Address Translation Protocol (RARP) is a physical machine on a LAN that requests an IP based on a MAC address from the gateway server's ARP table or cache. A protocol for addresses that functions inversely to the Address Resolution Protocol. Compared with ARP, the workflow of RARP is also opposite. First, the query host sends a RARP Request broadcast packet to the network to query other hosts for its IP address. At this time, the RARP server on the network will send the IThe P address responds to the queryer with a RARP Reply packet, so that the querying host obtains its own IP address.