本文是一個理論過度到實踐的典型案例，藉助程式設計師經常遇到的一個問題——網路為什麼不通，來具體說明怎麼將書本上的死知識真正變成我們解決問題的能力。

大學學到的基本概念

我相信你腦子裡關於網路基礎知識的概念都在下面這張圖中。知識內容有點亂，感覺都認識，又都模模糊糊，更談不上將內容轉化成生產力或是用來解決實際問題了。這是因為知識沒有貫通、沒有實踐、沒有組織。

上圖中知識點的作用在RFC1180[1]中講得無比通俗易懂了。看第一遍的時候也許你就看懂了，但是一個月後又忘記了。其實這些東西我們在大學也學過，但還是忘了（能夠理解，缺少實操環境和條件），或者碰到問題才發現之前看懂了的東西其實沒懂。

所以接下來我們將示範書本知識到實踐的貫通過程，希望把網路概念之間的聯絡通過實踐來組織起來。

還是從一個問題入手

最近的環境碰到一個網路ping不通的問題，當時的網路鏈路是（大概是這樣，略有簡化）：

現象

• 從容器1 ping 物理機2 不通；

• 從物理機1上的容器2 ping物理機2 通；

• 同時發現即使是通的，有的容器 ping物理機1只需要0.1ms，有的容器需要200ms以上（都在同一個物理機上），不合理；

• 所有容器 ping 其它外網IP（比如百度）反而是通的。

這個問題扯了一週才解決是因為容器的網路是我們自己配置的，交換機我們沒有許可權接觸，由客戶配置。出問題的時候都會覺得自己沒問題對方有問題，另外就是對網路基本知識認識不夠，所以都覺得自己沒問題而不去找證據。

這個問題的答案在大家看完本文的基礎知識後會總結出來。

解決這個問題前大家先想想，假如有個面試題是：輸入 ping IP 後敲回車，然後發生了什麼？

複習一下大學課本中的知識點

要解決一個問題你首先要有基礎知識，在知識欠缺的情況下就算邏輯再好、思路再清晰、智商再高，也不一定有效。

route 路由表

假如你在這臺機器上ping 172.17.0.2 ，根據上面的route表得出 172.17.0.2這個IP符合下面這條路由：

這條路由規則，那麼ping 包會從docker0這張網絡卡發出去。

但是如果是ping 1.1.4.4 根據路由規則就應該走eth0這張網絡卡而不是docker0了。接下來就要判斷目標IP是否在同一個子網了。

ifconfig

首先來看看這臺機器的網絡卡情況：

這裡有三個網絡卡和三個IP，三個子網掩碼（netmask)。根據目標路由走哪張網絡卡，得到這個網絡卡的子網掩碼，來計算目標IP是否在這個子網內。

arp協議

網路包在物理層傳輸的時候依賴的mac 地址而不是上面的IP地址，也就是根據mac地址來決定把包發到哪裡去。

arp協議就是查詢某個IP地址的mac地址是多少，由於這種對應關係一般不太變化，所以每個os都有一份arp快取（一般15分鐘過期），也可以手工清理，下面是arp快取的內容：

進入正題，回車後發生什麼？

有了上面的基礎知識打底，我們來思考一下 ping IP 到底發生了什麼。

首先 OS 的協議棧需要把ping命令封成一個icmp包，要填上包頭（包括src-IP、mac地址），那麼OS先根據目標IP和本機的route規則計算使用哪個interface(網絡卡），確定了路由也就基本上知道傳送包的src-ip和src-mac了。每條路由規則基本都包含目標IP範圍、閘道器、MAC地址、網絡卡這樣幾個基本元素。

如果目標IP和本機使用的IP在同一子網

如果目標IP和本機IP是同一個子網（根據本機ifconfig上的每個網絡卡的netmask來判斷是否是同一個子網——知識點：子網掩碼的作用），並且本機arp快取沒有這條IP對應的mac記錄，那麼給整個子網的所有機器廣播發送一個 arp查詢，比如我ping 1.1.3.42，然後tcpdump抓包首先看到的是一個arp請求：

上面就是本機發送廣播訊息，1.1.3.42的mac地址是多少？很快1.1.3.42回覆了自己的mac地址。 收到這個回覆後，先快取起來，下個ping包就不需要再次發arp廣播了。 然後將這個mac地址填寫到ping包的包頭的目標Mac（icmp包），然後發出這個icmp request包，按照mac地址，正確到達目標機器，然後對方正確回覆icmp reply（對方回覆也要查路由規則，arp查傳送方的mac，這樣回包才能正確路由回來，略過）。

來看一次完整的ping 1.1.3.43，tcpdump抓包結果：

我換了個IP地址，接著再ping同一個IP地址，arp有快取了就看不到arp廣播查詢過程了。

如果目標IP不是同一個子網

arp只是同一子網廣播查詢，如果目標IP不是同一子網的話就要經過本IP閘道器進行轉發(知識點：閘道器的作用)。如果本機沒有快取閘道器mac（一般肯定快取了），那麼先發送一次arp查詢閘道器的mac，然後流程跟上面一樣，只是這個icmp包發到閘道器上去了（mac地址填寫的是閘道器的mac）。

從本機1.1.3.33 ping 11.239.161.60的過程，因為不是同一子網按照路由規則匹配，根據route表應該走1.1.15.254這個閘道器，如下截圖：

首先是目標IP 11.239.161.60 符合最上面紅框中的路由規則，又不是同一子網，所以查詢路由規則中的閘道器1.1.15.254的Mac地址，arp cache中有，於是將 0c:da:41:6e:23:00 填入包頭，那麼這個icmp request包就發到1.1.15.254上了，雖然包頭的mac是 0c:da:41:6e:23:00，但是IP還是 11.239.161.60。

看看目標IP 11.239.161.60 真正的mac資訊（跟ping包包頭的Mac是不同的）：

這個包根據Mac地址路由到了閘道器上。

閘道器接下來怎麼辦？

為了簡化問題，假設兩個閘道器直連

閘道器收到這個包後（因為mac地址是它的），開啟一看IP地址是 11.239.161.60，不是自己的，於是繼續查自己的route和arp快取，發現11.239.161.60這個IP的閘道器是11.239.163.247，於是把包的目的mac地址改成11.239.163.247的mac繼續發出去。

11.239.163.247這個閘道器收到包後，一看 11.239.161.60是自己同一子網的IP，於是該arp廣播找mac就廣播，cache有就拿cache的，然後這個包才最終到達目的11.239.161.60上。

整個過程中目標mac地址每一跳都在變，IP地址不變，每經過一次MAC變化可以簡單理解成一跳。

實際上可能要經過多個閘道器多次跳躍才能真正到達目標機器。

目標機器收到這個icmp包後的回覆過程一樣，略過。

arp廣播風暴和arp欺騙

廣播風暴：如果一個子網非常大，機器非常多，每次arp查詢都是廣播的話，也容易因為N*N的問題導致廣播風暴。

arp欺騙：同樣如果一個子網中的某臺機器冒充閘道器或者其他機器，當收到arp廣播查詢的時候總是把自己的mac冒充目標機器的mac發給你，然後你的包先走到他，再轉發給真正的閘道器或者目標機器，所以在裡面動點什麼手腳，看看你傳送的內容都還是很容易的。

講完基礎知識再來看開篇問題的答案

讀完上面的基礎知識相信現在我們已經能夠回答 ping IP 後發生了什麼。這些已經足夠解決99%的程式設計師日常網路中網路為什麼不通的問題了。但是前面的問題比這個要稍微複雜一點，還是依靠這些基礎知識就能解決——這是基礎知識的威力。

現場網路同學所做的一些其它測試：

1. 懷疑不通的IP所使用的mac地址衝突，在交換機上清理了交換機的arp快取，沒有幫助，還是不通；

2. 新拿出一臺物理機配置上不通的容器的IP，這是通的，所以負責網路的同學堅持是容器網路的配置導致了問題。

對於1能通，我認為這個測試不嚴格，新物理機所用的mac不一樣，並且所接的交換機口也不一樣，影響了測試結果。

祭出萬能手段——抓包

抓包在網路問題中是萬能的，但是第一次容易被tcpdump抓包命令的眾多引數嚇暈，不去操作你永遠上不了手，差距也就拉開了，你看差距有時候只是你對一條命令的執行。

在物理機2上抓包：

這個抓包能看到核心證據，ping包有到達物理機2，同時物理機2也正確回覆了（mac、ip都對）。

同時在物理機1上抓包（抓包截圖略掉）只能看到ping包出去，回包沒有到物理機1（所以回包肯定不會回到容器裡了）。

到這裡問題的核心在交換機沒有正確地把物理機2的回包送到物理機1上面，同時觀察到的不正常延時都在閘道器那一跳：

最終的原因

最後在交換機上分析包沒正確發到物理機1上的原因跟客戶交換機使用了HSRP（熱備份路由器協議，就是多個交換機HA高可用，也就是同一子網可以有多個閘道器的IP），停掉HSRP後所有IP容器都能通了，並且前面的某些容器延時也恢復正常了。

通俗點說就是HSRP把回包拐跑了，有些回包拐跑了又送回來了（延時200ms那些）

至於HSRP為什麼會這麼做，要廠家出來解釋了。這裡關鍵在於能讓客戶認同問題出現在交換機上還是前面的抓包證據充分，無可辯駁。實際中我們都習慣不給證據就說：我的程式沒問題，就是你的問題。這樣表述沒有一點意義，我們是要拿著證據這麼說，對方也好就著證據來反駁，這叫優雅地甩鍋。

網路到底通不通是個複雜的問題嗎？

講這個過程的核心目的是除了真正的網路不通，有些是服務不可用了也怪網路。很多現場的同學根本講不清自己的服務（比如80埠上的tomcat服務）還在不在，網路通不通，是網路不通呢還是服務出了問題。一看到SocketTimeoutException 就想把網路同學抓過來羞辱兩句：網路不通了，網路抖動導致我的程式異常了（網路抖動是個萬能的扛包俠）。

實際這裡涉及到四個節點（以兩個閘道器直連為例），srcIP -> src閘道器 -> dest閘道器 -> destIP。如果ping不通(也有特殊的防火牆限制ping包不讓過的），那麼在這四段中分段ping（二分查詢程式設計師應該最熟悉了）。 比如前面的例子就是閘道器沒有把包轉發回來。

抓包看ping包有沒有出去，對方抓包看有沒有收到，收到後有沒有回覆。

ping自己閘道器能不能通，ping對方閘道器能不能通。

接下來說點跟程式設計師日常相關的

如果網路能ping通，服務無法訪問

那麼嘗試telnet IP port 看看你的服務是否還在監聽埠，在的話再看看服務程序是否能正常響應新的請求。有時候是程序死掉了，埠也沒人監聽了；有時候是程序還在但是假死了，所以埠也不響應新的請求了，還有的是TCP連線佇列滿了不能響應新的連線。

如果埠還在也是正常的話，telnet應該是好的：

假如我故意換成一個不存在的埠，目標機器上的OS直接就拒絕了這個 連線（抓包的話一般是看到reset標識）：

一個SocketTimeoutException，程式設計師首先懷疑網路丟包的Case

當時的反饋應用程式碼拋SocketTimeoutException，懷疑網路問題：

1. 業務應用連線Server 偶爾會出現超時異常；

2. 業務很多這樣的異常日誌：[Server  SocketTimeoutException]

檢查一下當時的網路狀態非常好，出問題時間段的網絡卡的量資訊也非常正常：

上圖是通過sar監控到的9號 v24d9e0f23d40 這個網絡卡的流量，看起來也是正常，流量沒有出現明顯的波動。

為了監控網路到底有沒有問題，接著在出問題的兩個容器上各啟動一個http server，然後在對方每1秒鐘互相發一次發http get請求訪問這個http server，基本認識告訴我們如果網路丟包、卡頓嚴重，那麼我這個http server的監控日誌時間戳也會跳躍，如果應用是因為網路出現異常那麼我啟動的http服務也會出現異常——寧願寫個工具都不背鍋（主要是背了鍋也不一定能解決掉問題）。

從實際監控來看，應用出現異常的時候我的http服務是正常的（寫了指令碼判斷日誌的連續性）：

這也強有力地證明了網路沒問題，所以寫業務程式碼的同學一門心思集中火力檢視應用的問題。後來的實際調查發現是應用假死掉了（內部執行緒太多，卡死了），服務埠不響應請求了。

如果基礎知識缺乏一點那麼甩過來的這個鍋網路是扛不動的，同時也阻礙了問題的真正發現。

TCP協議通訊過程跟前面ping一樣，只是把ping的icmp協議換成TCP協議，也是要先根據route，然後arp。

總結

網路丟包、卡頓、抖動很容易做扛包俠，只有找到真正的原因解決問題才會更快，否則在錯誤的方向上怎麼發力都不對。準確的方向要靠好的基礎知識和正確的邏輯以及證據來支撐，而不是猜測。

• 基礎知識是決定你能否幹到退休的關鍵因素；

• 有了基礎知識不代表你能真正轉化成生產力；

• 越是基礎，越是幾十年不變的基礎越是重要；

• 知識到靈活運用要靠實踐，同時才能把知識之間的聯絡建立起來；

• 簡而言之缺的是融會貫通和運用；

• 做一個有禮有節的甩包俠；

• 在別人不給證據愚昧甩包的情況下你的機會就來了。

留幾個小問題：

1. server回覆client的時候是如何確定回覆包中的src-ip和dest-mac的？一定是請求包中的dest-ip當成src-ip嗎？

2. 上面問題中如果是TCP或者UDP協議，他們回覆包中的src-ip和dest-mac獲取會不一樣嗎？

3. 既然區域網中都是依賴Mac地址來定位，那麼IP的作用又是什麼呢？