最近接觸docker的網路設定方式,發現其預設會建立一個docker0的Linux Bridge,宿主機上執行的容器可以通過連線該birdge實現與外網的通訊,根據bridge這個命名很自然的認為這就是一個傳統意義上的硬體網橋的軟體實現,然而進一步探究後發現並非如此,Linux Bridge其實並不是一個虛擬網橋,而應該視為一個虛擬交換機更合適。
進一步的探究過程引發了一些纏繞在心中多年不甚清晰的網路交換裝置知識問題,這裡記錄一下自己的思考總結,如有不對歡迎勘正。
要解決上述問題,不可避免要先了解經典的TCP/IP模型與OSI七層模型這兩個概念,如下為兩個模型的圖解:
左邊的TCP/IP分層模型是現代網路協定棧的實際標準,但是討論網路相關分層時,大家一般都採用右邊的OSI參考模型分層,像是集線器、網橋、交換機、路由器都是工作在都是工作在一層(物理層)、二層(資料鏈路層)、三層(網路層)這下面三層,再比如nginx負責HTTP 協定的反向代理時我們說它是七層(應用層)負載均衡,而其作為TCP/UDP協定的反向代理時則說它是四層(傳輸層)負載均衡。
這裡以從下至上的角度梳理一下基礎網路裝置的發展與原理。
上世紀70年代乙太網被髮明出來之後,多臺計算機如果要互聯需要一個統一的黑盒子負責中轉互相之間的傳送的資料,即所有需要聯網的計算機均通過網線與這個黑盒子相連--經典的星型網路結構,這個黑盒子就是集線器,集線器只負責將任意埠收到的物理電訊號廣播到其他所有埠,完全不關心資料的具體內容與格式。
考慮下如果不採用星型結構,而是任意兩臺電腦要想通訊則用網線將其網路埠直接相連,要實現N臺電腦的相互連線需要N*(N-1)/2個連線,也就是說10臺電腦要全部45條網線,每臺計算需要9個網線介面,這明顯是不現實的同時也是絕對不划算的。
而如果採用環型結構,雖然10臺計算同樣只需要9根網線,每臺計算機也只需要一個網線介面,但是其中部分計算機之間的通訊需要經過多次不必要的中轉,且任意一臺計算機故障、關機就會導致網路故障,任意兩臺故障、關機就會導致網路直接分裂為2個獨立網路。
隨著乙太網的流行,越來越多辦公室開始接入它,網路通訊的距離和計算機的數量都急劇增長,距離過長會導致訊號衰減,這可以通過給集線器加入中繼功能保證訊號的可靠,但是每個辦公室每臺計算機傳送的資料如果每個集線器都無腦轉發,網路中會充斥大量無用資料。
比如辦公室A內部兩臺計算機只是通過乙太網互相傳輸一個內部檔案,集線器卻會最終將其廣播到全球所有接入乙太網的辦公室,這明顯是不可接受的。
於是網橋出現了,網橋看上去是隻有兩個埠的智慧版集線器,首先其只會將兩個埠收到的資訊轉發到彼此埠,但是在轉發時網橋會開始關注資料鏈路層的MAC地址,其新增了MAC地址學習功能。當網橋收到埠0的資料時,其會檢查資料目的MAC地址是否來自埠0連線的網路,如果是則過濾該資料不會轉發到埠1,目的MAC明確屬於埠1的網路或者沒有對應MAC記錄時才會轉發資料到埠1,這樣就可以避免一個辦公室內網MAC之間通訊的資料被無腦廣播到全世界了。
網橋的連線模式圖示(紅色節點為集線器):
早期的二層交換機工作原理與網橋類似,其也是通過識別資料鏈路層的MAC地址實現源埠到目的埠的資料轉發,早期的交換機不嚴格的說可以視為一個高度整合版的網橋,普通網橋只有兩個埠能連線兩臺計算機,而交換機則有多個埠可以連線多臺計算機,並且任意兩個埠之間都可以實現資料的轉發,N個埠的交換機可以簡單視為提供了N*(N-1/)/2的彼此獨立的網橋。
如下為交換機連線模式的圖示:
早期的二層交換機,純工作在資料鏈路層,因此無法隔離廣播域--當交換機不知道資料目的MAC屬於哪個埠時,會對所有其他埠廣播對應資料造成廣播風暴。要解決這個問題,也就出現了後面的三層交換機。
三層交換機在工作時會同時考慮資料鏈路層中的MAC地址與網路層中的IP地址,簡單來說如果交換機中已經記錄了資料的目的MAC對應埠,會直接走二層交換轉發資料到對應埠,而如果沒有目的MAC資訊,不像二層交換機直接廣播所有埠,而是通過識別網路層中的IP地址進行路由後選擇指定埠轉發資料,後面如果收到了目的MAC的回包,三層交換機會更新自己記錄的MAC到埠對映表,在後面到目的MAC的封包轉發時就直接走二層的交換即可--即一次路由,多次轉發。
三層交換機主要是用於大型區域網內切分多個小區域網的場景,因為對於一個大型區域網將其切分為多個小區域網能使一個大的廣播域被分割成多個小的廣播域,隔離了廣播風暴,同時其一次路由多次轉發的工作原理又能保證整個大型區域網內資料的高效交換。
路由器與三層交換機一樣都會根據網路層中的目的IP地址按照路由策略轉發資料,可以隔離所連線網路的廣播域,單從這看上去和三層交換機好像沒有區別,但是其實兩者之間存在很多差異,根據查詢資料及自我理解總結如下:
轉載請註明出處,原文地址:https://www.cnblogs.com/AcAc-t/p/hub_bridge_switch_router_summary.html
https://segmentfault.com/a/1190000009491002
https://www.cnblogs.com/AcAc-t/p/hub_bridge_switch_router_summary.html
https://www.cnblogs.com/bakari/p/10529575.html
https://www.cnblogs.com/xiaolincoding/p/12638546.html
https://zhuanlan.zhihu.com/p/158219925
https://zhuanlan.zhihu.com/p/440970417
https://zhuanlan.zhihu.com/p/158219925
https://www.zhihu.com/question/67473683/answer/254496942
https://zhuanlan.zhihu.com/p/110427712
https://sites.google.com/site/emmoblin/linux-network-1/san-ceng-jiao-huan-ji-yu-lu-you-qi-de-qu-bie
https://m.hqew.com/tech/yqj_6414
https://www.51cto.com/article/708872.html