本篇文章給大家?guī)砹岁P于docker容器間網(wǎng)絡互聯(lián)原理的相關知識，希望對大家有幫助。

一、今天我們要搞明白的實驗

如上紅字所描述：同一個宿主機上的不同容器之間的網(wǎng)絡如何互通的？？？

二、前置網(wǎng)絡知識

2.1、docker默認為我們創(chuàng)建的網(wǎng)絡

我們安裝完docker之后，docker daemon會為我們自動創(chuàng)建3個網(wǎng)絡，如下：

Copy~]# docker network ls NETWORK ID     NAME                DRIVER    SCOPE e71575e3722a   bridge              bridge    local ab8e3d45575c   host                host      local 0c9b7c1134ff   none                null      local

其實docker有4種網(wǎng)絡通信模型，分別是：bridge、host、none、container

默認的使用的網(wǎng)絡模型是bridge，也是我們生產(chǎn)上會使用到的網(wǎng)絡模型。

下文中跟大家分享docker容器互通原理到時候呢，用到的也是bridge網(wǎng)絡模型

2.2、怎么理解docker0網(wǎng)橋

另外，當我們安裝完docker之后，docker會為我們創(chuàng)建一個叫docker0的網(wǎng)絡設備

通過ifconfig命令可以查看到它，看起來它貌似和eth0網(wǎng)絡地位相當，像是一張網(wǎng)卡。然而并不是，docker0其實是一個Linux網(wǎng)橋

Copy[root@vip ~]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00     inet 127.0.0.1/8 scope host lo        valid_lft forever preferred_lft forever     inet6 ::1/128 scope host        valid_lft forever preferred_lft forever  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000     link/ether 00:0c:29:b4:97:ee brd ff:ff:ff:ff:ff:ff     inet 10.4.7.99/24 brd 10.4.7.255 scope global noprefixroute eth0        valid_lft forever preferred_lft forever     inet6 fe80::20c:29ff:feb4:97ee/64 scope link        valid_lft forever preferred_lft forever  3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default     link/ether 02:42:db:fe:ff:db brd ff:ff:ff:ff:ff:ff     inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0        valid_lft forever preferred_lft forever     inet6 fe80::42:dbff:fefe:ffdb/64 scope link        valid_lft forever preferred_lft forever

何以見得？可以通過下面的命令查看操作系統(tǒng)上的網(wǎng)橋信息

Copy ~]# yum install bridge-utils  ~]# brctl show bridge name bridge id       STP enabled interfaces docker0     8000.0242f0a8c0be   no      veth86e2ef2                                                                     vethf0a8bcb

那大家怎么理解Linux網(wǎng)橋的概念呢？

其實大家可以把docker0理解成一臺虛擬的交換機！然后像下面這樣類比著理解，就會豁然開朗

1、它好比是大學在機房上課時，老師旁邊的那個大大的交換機設備。

2、把機房里的電腦都連接在交換機上，類比成docker 容器作為一臺設備都連接著宿主機上的docker0。

3、把交換機和機房中的機器的ip在同一個網(wǎng)段，類比成docker0、和你啟動的docker容器的ip也同屬于172網(wǎng)段。

Copy# docker0 ip是：  ~]# ifconfig 3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default     link/ether 02:42:db:fe:ff:db brd ff:ff:ff:ff:ff:ff     inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0        valid_lft forever preferred_lft forever     inet6 fe80::42:dbff:fefe:ffdb/64 scope link        valid_lft forever preferred_lft forever  # 進入容器中查看ip是： /# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500         inet 172.17.0.2  netmask 255.255.0.0  broadcast 172.17.255.255         ether 02:42:ac:11:00:02  txqueuelen 0  (Ethernet)         RX packets 13  bytes 1102 (1.0 KiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 0  bytes 0 (0.0 B)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

類比成這樣：

2.3、什么是veth-pair技術(shù)？

我們剛才做類比理解docker0的時候說：把機房里的電腦都連接在交換機上，類比成docker 容器作為一臺設備都連接著宿主機上的docker0。那具體的實現(xiàn)落地實現(xiàn)用的是啥技術(shù)呢？

答案是：veth pair

veth pair的全稱是：virtual ethernet，就是虛擬的以太網(wǎng)卡。

說到以太網(wǎng)卡大家都不陌生呀，不就是我們常見的那種叫eth0或者是ens的網(wǎng)絡設備嗎？

那這個veth pair是怎么玩的呢？有啥用呢？大家可以看下面這張圖

veth-pair設備總是會成對的出現(xiàn)，用于連接兩個不同network-namespace.

就上圖來說，從network-namespace1的veth0中發(fā)送的數(shù)據(jù)會出現(xiàn)在 network-namespace2的veth1設備中。

雖然這種特性很好，但是如果出現(xiàn)有多個容器，你就會發(fā)現(xiàn)組織架構(gòu)會越來越復雜，越來越亂

不過好在我們已經(jīng)循序漸進的了解Linux網(wǎng)橋（docker0），以及這里的veth-pair設備，于是我們可以把整體的架構(gòu)圖重新繪制成下面這樣

因為不同容器有自己隔離后的network-namespace所以他們都有自己的網(wǎng)絡協(xié)議棧

那我們能不能找到容器里面的網(wǎng)卡和物理機上的哪張卡是一對網(wǎng)絡vethpair設備呢？

如下：

Copy# 進入容器 ~]# docker exec -ti 545ed62d3abf /bin/bash  /# apt-get install ethtool /# ethtool -S eth0 NIC statistics:      peer_ifindex: 55

回到宿主機

Copy~]# ip addr     ... 55: vethf0a8bcb@if54: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default     link/ether ae:eb:5c:2f:7d:c3 brd ff:ff:ff:ff:ff:ff link-netnsid 10     inet6 fe80::aceb:5cff:fe2f:7dc3/64 scope link        valid_lft forever preferred_lft forever

意思是就是說，容器545ed62d3abf的eth0網(wǎng)卡和宿主機通過ip addr命令查看的網(wǎng)絡設備標號55的設備組成一對vethpair設備，彼此流量互通！

三、同一個局域網(wǎng)中不同主機的互聯(lián)原理

先看個簡單的，同一個局域網(wǎng)中的不同主機A、B之間是如何互聯(lián)交換數(shù)據(jù)的。如下圖

那，既然是同一個局域網(wǎng)中，說明A、B的ip地址在同一個網(wǎng)段，如上圖就假設它們都在192.168.1.0網(wǎng)段。

還得再看下面這張OSI 7層網(wǎng)絡模型圖。

主機A向主機B發(fā)送數(shù)據(jù)，對主機A來說數(shù)據(jù)會從最上層的應用層一路往下層傳遞。比如應用層使用的http協(xié)議、傳輸層使用的TCP協(xié)議，那數(shù)據(jù)在往下層傳遞的過程中，會根據(jù)該層的協(xié)議添加上不同的協(xié)議頭等信息。

根據(jù)OSI7層網(wǎng)絡模型的設定，對于接受數(shù)據(jù)的主機B來說，它會接收到很多數(shù)據(jù)包！這些數(shù)據(jù)包會從最下層的物理層依次往上層傳遞，依次根據(jù)每一層的網(wǎng)絡協(xié)議進行拆包。一直到應用層取出主機A發(fā)送給他的數(shù)據(jù)。

那么問題來了，主機B怎么判斷它收到的數(shù)據(jù)包是否是發(fā)送給自己的呢？萬一有人發(fā)錯了呢？

答案是：根據(jù)MAC地址，邏輯如下。

Copyif 收到的數(shù)據(jù)包.MAC地址 == 自己的MAC地址{   // 接收數(shù)據(jù)   // 處理數(shù)據(jù)包 }else{  // 丟棄 }

那對于主機A來說，它想發(fā)送給主機B數(shù)據(jù)包，還不能讓主機B把這個數(shù)據(jù)包扔掉，它只能中規(guī)中矩的按以太網(wǎng)網(wǎng)絡協(xié)議要求封裝將要發(fā)送出去的數(shù)據(jù)包，往下傳遞到數(shù)據(jù)鏈路層（這一層傳輸?shù)臄?shù)據(jù)要求，必須要有目標mac地址，因為數(shù)據(jù)鏈路層是基于mac地址做數(shù)據(jù)傳輸?shù)模?/p>

那數(shù)據(jù)包中都需要哪些字段呢？如下：

Copysrc ip = 192.168.1.2  //源ip地址，交換機 dst ip = 192.168.1.3  //目標ip地址 //本機的mac地址（保證從主機B回來的包正常送達主機A，且主機A能正常處理它） src mac = 主機A的mac地址 dst mac = 主機B的mac地址//目標mac地址

其中的dst ip好說，我們可以直接固定寫，或者通過DNS解析域名得到目標ip。

那dst mac怎么獲取呢？

這就不得不說ARP協(xié)議了! ARP其實是一種地址解析協(xié)議，它的作用就是：以目標ip為線索，找到目的ip所在機器的mac地址。也就是幫我們找到dst mac地址！大概的過程如下幾個step

推薦閱讀：白日夢的DNS筆記

簡述這個過程：主機A想給主機B發(fā)包，那需要知道主機B的mac地址。

1. 主機A查詢本地的arp 高速緩存中是否已經(jīng)存在dst ip和dst mac地址的映射關系了，如果已存在，那就直接用。
2. 本地arp高速緩存中不存在dst ip和dst mac地址的映射關系的話那就只能廣播arp請求包，同一網(wǎng)段的所有機器都能收到arp請求包。
3. 收到arp請求包的機器會對比arp包中的src ip是否是自己的ip，如果不是則直接丟棄該arp包。如果是的話就將自己的mac地址寫到arp響應包中。并且它會把請求包中src ip和src mac的映射關系存儲在自己的本地。

補充：

交換機本身也有學習能力，他會記錄mac地址和交換機端口的映射關系。比如：mac=a，端口為1。

那當它接收到數(shù)據(jù)包，并發(fā)現(xiàn)mac=a時，它會直接將數(shù)據(jù)扔向端口1。

嗯，在arp協(xié)議的幫助下，主機A順利拿到了主機B的mac地址。于是數(shù)據(jù)包從網(wǎng)絡層流轉(zhuǎn)到數(shù)據(jù)鏈路層時已經(jīng)被封裝成了下面的樣子：

Copysrc ip = 192.168.1.2 src mac = 主機A的mac地址 dst ip = 192.168.1.3 dst mac = 主機B的mac地址

網(wǎng)絡層基于ip地址做數(shù)據(jù)做轉(zhuǎn)發(fā)

數(shù)據(jù)鏈路基于mac地址做數(shù)據(jù)轉(zhuǎn)發(fā)

根據(jù)OIS7層網(wǎng)絡模型，我們都知道數(shù)據(jù)包經(jīng)過物理層發(fā)送到機器B，機器B接收到數(shù)據(jù)包后，再將數(shù)據(jù)包向上流轉(zhuǎn)，拆包。流轉(zhuǎn)到主機B的數(shù)據(jù)鏈路層。

那主機B是如何判斷這個在數(shù)據(jù)鏈路層的包是否是發(fā)給自己的呢？

答案前面說了，根據(jù)目的mac地址判斷。

Copy// 主機B if 收到的數(shù)據(jù)包.MAC地址 == 自己的MAC地址{   if dst ip == 本機ip{     // 本地處理數(shù)據(jù)包   }else{     // 查詢路由表，根據(jù)路由表的規(guī)則，將數(shù)據(jù)包轉(zhuǎn)某個某卡、或者默認網(wǎng)關   } }else{  // 直接丟棄 }

這個例子比較簡單，dst ip就是主機B的本機ip 所以它自己會處理這個數(shù)據(jù)包。

那數(shù)據(jù)包處理完之后是需要給主機A一個響應包，那問題又來了，響應包該封裝成什么樣子呢？對主機B來說響應包也需要src ip、src mac、dst ip、dst mac

Copysrc ip = 192.168.1.3 src mac = 主機B的mac地址 dst ip = 192.168.1.2 src mac = 主機A的mac地址 （之前通過arp記錄在自己的arp高速緩存中了，所以，這次直接用）

同樣的道理，響應包也會按照如下的邏輯被主機A接受，處理。

Copy// 主機A if 收到的數(shù)據(jù)包.MAC地址 == 自己的MAC地址{   if dst ip == 本機ip{     // 本地處理數(shù)據(jù)包   }else{     // 查詢路由表，根據(jù)路由表的規(guī)則，將數(shù)據(jù)包轉(zhuǎn)某個某卡、或者默認網(wǎng)關   } }else{  // 直接丟棄 }

這一次，讓我在百度告訴你，當你請求www.baidu.com時都發(fā)生了什么？

四、容器網(wǎng)絡互通原理

有了上面那些知識儲備呢？再看我們今天要探究的問題，就不難了。

如下紅字部分：同一個宿主機上的不同容器是如何互通的？

那我們先分別登陸容器記錄下他們的ip

Copy9001的ip是：172.17.0.2 9002的ip是：172.17.0.3

先看實驗效果：在9001上curl9002

Copy/# curl 172.7.88.3 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } ...

實驗結(jié)果是網(wǎng)絡互通！

我們再完善一下上面的圖，把docker0、以及兩個容器的ip補充上去，如下圖：

Docker容器間網(wǎng)絡互聯(lián)原理，講不明白算我輸

那兩臺機器之前要通信是要遵循OSI網(wǎng)絡模型、和以太網(wǎng)協(xié)議的。

我們管172.17.0.2叫做容器2

我們管172.17.0.3叫做容器3

比如我們現(xiàn)在是從：容器2上curl 容器3，那么容器2也必須按照以太網(wǎng)協(xié)議將數(shù)據(jù)包封裝好，如下

Copysrc ip = 172.17.0.2 src mac = 容器2的mac地址 dst ip = 172.17.0.3 dst mac = 容器3的mac地址 ？？？

那現(xiàn)在的問題是容器3的mac地址是多少？

刪掉所有容器，重新啟動，方便實驗抓包

容器2會先查自己的本地緩存，如果之前沒有訪問過，那么緩存中也沒有任何記錄！

Copy:/# arp -n

不過沒關系，還有arp機制兜底，于是容器2會發(fā)送arp請求包，大概如下

Copy1、這是一個arp請求包 2、我的ip地址是：172.17.0.2 3、我的mac地址是：容器2的mac地址 4、請問：ip地址為：172.17.0.3的機器，你的mac地址是多少？

容器2會查詢自己的路由表，將這個arp請求從自己的gateway發(fā)送出去

Copy/# route -n Kernel IP routing table Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 0.0.0.0         172.7.88.1      0.0.0.0         UG    0      0        0 eth0 172.7.88.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0

我們發(fā)現(xiàn)容器2的網(wǎng)關對應的網(wǎng)絡設備的ip就是docker0的ip地址，并且經(jīng)由eth0發(fā)送出去！

哎？eth0不就是我們之前說的veth-pair設備嗎？

并且我們通過下面的命令可以知道它的另一端對應著宿主機上的哪個網(wǎng)絡設備：

Copy/# ethtool -S eth0 NIC statistics:      peer_ifindex: 53

而且我們可以下面的小實驗，驗證上面的觀點是否正確

Copy# 在容器中ping百度 ~]# ping 220.181.38.148  # 在宿主機上抓包 ~]# yum install tcpdump -y ~]# tcpdump -i ${vethpair宿主機側(cè)的接口名} host 220.181.38.148  ...

所以說從容器2的eth0出去的arp請求報文會同等的出現(xiàn)在宿主機的第53個網(wǎng)絡設備上。

通過下面的這張圖，你也知道第53個網(wǎng)絡設備其實就是下圖中的veth0-1

所以這個arp請求包會被發(fā)送到docker0上，由docker0拿到這個arp包發(fā)現(xiàn)，目標ip是172.17.0.3并不是自己，所以docker0會進一步將這個arp請求報文廣播出去，所有在172.17.0.0網(wǎng)段的容器都能收到這個報文！其中就包含了容器3！

那容器3收到這個arp報文后，會判斷，哦！目標ip就是自己的ip，于是它將自己的mac地址填充到arp報文中返回給docker0！

同樣的我們可以通過抓包驗證，在宿主機上

Copy# 在172.17.0.2容器上ping172.17.0.3 /# ping 172.17.0.3  ~]# tcpdump -i vethdb0d222 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vethdb0d222, link-type EN10MB (Ethernet), capture size 262144 bytes  17:25:30.218640 ARP, Request who-has 172.17.0.3 tell 172.17.0.2, length 28 17:25:30.218683 ARP, Reply 172.17.0.3 is-at 02:42:ac:11:00:03 (oui Unknown), length 28 17:25:30.218686 IP 172.17.0.2.54014 > 172.17.0.3.http: Flags [S], seq 3496600258, win 29200, options [mss 1460,sackOK,TS val 4503202 ecr 0,nop,wscale 7], length 0

于是容器2就拿到了容器3的mac地址，以太網(wǎng)數(shù)據(jù)包需要的信息也就齊全了！如下：

Copysrc ip = 172.17.0.2 src mac = 容器2的mac地址 dst ip = 172.17.0.3 dst mac = 容器3的mac地址

再之后容器2就可以和容器3正常互聯(lián)了！

容器3會收到很多數(shù)據(jù)包，那它怎么知道哪些包是發(fā)給自己的，那些不是呢？可以參考如下的判斷邏輯

Copyif 響應包.mac == 自己的mac{  // 說明這是發(fā)給自己包，所以不能丟棄   if 響應包.ip == 自己的ip{     // 向上轉(zhuǎn)發(fā)到osi7層網(wǎng)絡模型的上層   }else{     // 查自己的route表，找下一跳   } }else{  // 直接丟棄 }

五、實驗環(huán)境

Copy# 下載  ~]# docker pull registry.cn-hangzhou.aliyuncs.com/changwu/nginx:1.7.9-nettools  # 先啟動1個容器  ~]# docker run --name mynginx1 -i -t -d -p 9001:80 nginx-1.7.9-nettools:latest eb569b938c07e95ccccbfc654c1fee6364eea55b20f5394382ff42b4ccf96312  ~]# docker run --name mynginx2 -i -t -d -p 9002:80 nginx-1.7.9-nettools:latest 545ed62d3abfd63aa9c3ae196e9d7fe6f59bbd2e9ae4e6f2bd378f23587496b7  # 驗證 ~]# curl 127.0.0.1:9001

推薦學習：《docker視頻教程》