arp出現2個eth0

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地址了。