從計(jì)算機(jī)知識(shí)到落地能力，你欠缺了什么？
大學(xué)學(xué)到的基本概念
我相信你腦子里關(guān)于網(wǎng)絡(luò)基礎(chǔ)知識(shí)的概念都在下面這張圖中。知識(shí)內(nèi)容有點(diǎn)亂，感覺(jué)都認(rèn)識(shí)，又都模模糊糊，更談不上將內(nèi)容轉(zhuǎn)化成生產(chǎn)力或是用來(lái)解決實(shí)際問(wèn)題了。這是因?yàn)橹R(shí)沒(méi)有貫通、沒(méi)有實(shí)踐、沒(méi)有組織。
上圖中知識(shí)點(diǎn)的作用在RFC1180[1]中講得無(wú)比通俗易懂了?？?**遍的時(shí)候也許你就看懂了，但是一個(gè)月后又忘記了。其實(shí)這些東西我們?cè)诖髮W(xué)也學(xué)過(guò)，但還是忘了（能夠理解，缺少實(shí)操環(huán)境和條件），或者碰到問(wèn)題才發(fā)現(xiàn)之前看懂了的東西其實(shí)沒(méi)懂。
所以接下來(lái)我們將示范書(shū)本知識(shí)到實(shí)踐的貫通過(guò)程，希望把網(wǎng)絡(luò)概念之間的聯(lián)系通過(guò)實(shí)踐來(lái)組織起來(lái)。
還是從一個(gè)問(wèn)題入手
最近的環(huán)境碰到一個(gè)網(wǎng)絡(luò)ping不通的問(wèn)題，當(dāng)時(shí)的網(wǎng)絡(luò)鏈路是（大概是這樣，略有簡(jiǎn)化）：
現(xiàn)象
- 從容器1 ping 物理機(jī)2 不通；
- 從物理機(jī)1上的容器2 ping物理機(jī)2 通；
- 同時(shí)發(fā)現(xiàn)即使是通的，有的容器 ping物理機(jī)1只需要0.1ms，有的容器需要200ms以上（都在同一個(gè)物理機(jī)上），不合理；
- 所有容器 ping 其它外網(wǎng)IP（比如百度）反而是通的。
這個(gè)問(wèn)題扯了一周才解決是因?yàn)槿萜鞯木W(wǎng)絡(luò)是我們自己配置的，交換機(jī)我們沒(méi)有權(quán)限接觸，由客戶配置。出問(wèn)題的時(shí)候都會(huì)覺(jué)得自己沒(méi)問(wèn)題對(duì)方有問(wèn)題，另外就是對(duì)網(wǎng)絡(luò)基本知識(shí)認(rèn)識(shí)不夠，所以都覺(jué)得自己沒(méi)問(wèn)題而不去找證據(jù)。
這個(gè)問(wèn)題的答案在大家看完本文的基礎(chǔ)知識(shí)后會(huì)總結(jié)出來(lái)。
解決這個(gè)問(wèn)題前大家先想想，假如有個(gè)面試題是：輸入 ping IP 后敲回車(chē)，然后發(fā)生了什么？
復(fù)習(xí)一下大學(xué)課本中的知識(shí)點(diǎn)
要解決一個(gè)問(wèn)題你首先要有基礎(chǔ)知識(shí)，在知識(shí)欠缺的情況下就算邏輯再好、思路再清晰、智商再高，也不一定有效。
route 路由表
假如你在這臺(tái)機(jī)器上ping 172.17.0.2 ，根據(jù)上面的route表得出 172.17.0.2這個(gè)IP符合下面這條路由：
這條路由規(guī)則，那么ping 包會(huì)從docker0這張網(wǎng)卡發(fā)出去。
但是如果是ping 1.1.4.4 根據(jù)路由規(guī)則就應(yīng)該走eth0這張網(wǎng)卡而不是docker0了。接下來(lái)就要判斷目標(biāo)IP是否在同一個(gè)子網(wǎng)了。
ifconfig
首先來(lái)看看這臺(tái)機(jī)器的網(wǎng)卡情況：
這里有三個(gè)網(wǎng)卡和三個(gè)IP，三個(gè)子網(wǎng)掩碼（netmask)。根據(jù)目標(biāo)路由走哪張網(wǎng)卡，得到這個(gè)網(wǎng)卡的子網(wǎng)掩碼，來(lái)計(jì)算目標(biāo)IP是否在這個(gè)子網(wǎng)內(nèi)。
arp協(xié)議
網(wǎng)絡(luò)包在物理層傳輸?shù)臅r(shí)候依賴的mac 地址而不是上面的IP地址，也就是根據(jù)mac地址來(lái)決定把包發(fā)到哪里去。
arp協(xié)議就是查詢某個(gè)IP地址的mac地址是多少，由于這種對(duì)應(yīng)關(guān)系一般不太變化，所以每個(gè)os都有一份arp緩存（一般15分鐘過(guò)期），也可以手工清理，下面是arp緩存的內(nèi)容：
進(jìn)入正題，回車(chē)后發(fā)生什么？
有了上面的基礎(chǔ)知識(shí)打底，我們來(lái)思考一下 ping IP 到底發(fā)生了什么。
首先 OS 的協(xié)議棧需要把ping命令封成一個(gè)icmp包，要填上包頭（包括src-IP、mac地址），那么OS先根據(jù)目標(biāo)IP和本機(jī)的route規(guī)則計(jì)算使用哪個(gè)interface(網(wǎng)卡），確定了路由也就基本上知道發(fā)送包的src-ip和src-mac了。每條路由規(guī)則基本都包含目標(biāo)IP范圍、網(wǎng)關(guān)、MAC地址、網(wǎng)卡這樣幾個(gè)基本元素。
如果目標(biāo)IP和本機(jī)使用的IP在同一子網(wǎng)
如果目標(biāo)IP和本機(jī)IP是同一個(gè)子網(wǎng)（根據(jù)本機(jī)ifconfig上的每個(gè)網(wǎng)卡的netmask來(lái)判斷是否是同一個(gè)子網(wǎng)——知識(shí)點(diǎn)：子網(wǎng)掩碼的作用），并且本機(jī)arp緩存沒(méi)有這條IP對(duì)應(yīng)的mac記錄，那么給整個(gè)子網(wǎng)的所有機(jī)器廣播發(fā)送一個(gè) arp查詢，比如我ping 1.1.3.42，然后tcpdump抓包首先看到的是一個(gè)arp請(qǐng)求：
上面就是本機(jī)發(fā)送廣播消息，1.1.3.42的mac地址是多少？很快1.1.3.42回復(fù)了自己的mac地址。 收到這個(gè)回復(fù)后，先緩存起來(lái)，下個(gè)ping包就不需要再次發(fā)arp廣播了。 然后將這個(gè)mac地址填寫(xiě)到ping包的包頭的目標(biāo)Mac（icmp包），然后發(fā)出這個(gè)icmp request包，按照mac地址，正確到達(dá)目標(biāo)機(jī)器，然后對(duì)方正確回復(fù)icmp reply（對(duì)方回復(fù)也要查路由規(guī)則，arp查發(fā)送方的mac，這樣回包才能正確路由回來(lái)，略過(guò)）。
來(lái)看一次完整的ping 1.1.3.43，tcpdump抓包結(jié)果：
我換了個(gè)IP地址，接著再ping同一個(gè)IP地址，arp有緩存了就看不到arp廣播查詢過(guò)程了。
如果目標(biāo)IP不是同一個(gè)子網(wǎng)
arp只是同一子網(wǎng)廣播查詢，如果目標(biāo)IP不是同一子網(wǎng)的話就要經(jīng)過(guò)本IP網(wǎng)關(guān)進(jìn)行轉(zhuǎn)發(fā)(知識(shí)點(diǎn)：網(wǎng)關(guān)的作用)。如果本機(jī)沒(méi)有緩存網(wǎng)關(guān)mac（一般肯定緩存了），那么先發(fā)送一次arp查詢網(wǎng)關(guān)的mac，然后流程跟上面一樣，只是這個(gè)icmp包發(fā)到網(wǎng)關(guān)上去了（mac地址填寫(xiě)的是網(wǎng)關(guān)的mac）。
從本機(jī)1.1.3.33 ping 11.239.161.60的過(guò)程，因?yàn)椴皇峭蛔泳W(wǎng)按照路由規(guī)則匹配，根據(jù)route表應(yīng)該走1.1.15.254這個(gè)網(wǎng)關(guān)，如下截圖：
首先是目標(biāo)IP 11.239.161.60 符合最上面紅框中的路由規(guī)則，又不是同一子網(wǎng)，所以查找路由規(guī)則中的網(wǎng)關(guān)1.1.15.254的Mac地址，arp cache中有，于是將 0c:da:41:6e:23:00 填入包頭，那么這個(gè)icmp request包就發(fā)到1.1.15.254上了，雖然包頭的mac是 0c:da:41:6e:23:00，但是IP還是 11.239.161.60。
看看目標(biāo)IP 11.239.161.60 真正的mac信息（跟ping包包頭的Mac是不同的）：
這個(gè)包根據(jù)Mac地址路由到了網(wǎng)關(guān)上。
網(wǎng)關(guān)接下來(lái)怎么辦？
為了簡(jiǎn)化問(wèn)題，假設(shè)兩個(gè)網(wǎng)關(guān)直連
網(wǎng)關(guān)收到這個(gè)包后（因?yàn)閙ac地址是它的），打開(kāi)一看IP地址是 11.239.161.60，不是自己的，于是繼續(xù)查自己的route和arp緩存，發(fā)現(xiàn)11.239.161.60這個(gè)IP的網(wǎng)關(guān)是11.239.163.247，于是把包的目的mac地址改成11.239.163.247的mac繼續(xù)發(fā)出去。
11.239.163.247這個(gè)網(wǎng)關(guān)收到包后，一看 11.239.161.60是自己同一子網(wǎng)的IP，于是該arp廣播找mac就廣播，cache有就拿cache的，然后這個(gè)包才最終到達(dá)目的11.239.161.60上。
整個(gè)過(guò)程中目標(biāo)mac地址每一跳都在變，IP地址不變，每經(jīng)過(guò)一次MAC變化可以簡(jiǎn)單理解成一跳。
實(shí)際上可能要經(jīng)過(guò)多個(gè)網(wǎng)關(guān)多次跳躍才能真正到達(dá)目標(biāo)機(jī)器。
目標(biāo)機(jī)器收到這個(gè)icmp包后的回復(fù)過(guò)程一樣，略過(guò)。
arp廣播風(fēng)暴和arp欺騙
廣播風(fēng)暴：如果一個(gè)子網(wǎng)非常大，機(jī)器非常多，每次arp查詢都是廣播的話，也容易因?yàn)镹*N的問(wèn)題導(dǎo)致廣播風(fēng)暴。
arp欺騙：同樣如果一個(gè)子網(wǎng)中的某臺(tái)機(jī)器冒充網(wǎng)關(guān)或者其他機(jī)器，當(dāng)收到arp廣播查詢的時(shí)候總是把自己的mac冒充目標(biāo)機(jī)器的mac發(fā)給你，然后你的包先走到他，再轉(zhuǎn)發(fā)給真正的網(wǎng)關(guān)或者目標(biāo)機(jī)器，所以在里面動(dòng)點(diǎn)什么手腳，看看你發(fā)送的內(nèi)容都還是很容易的。
講完基礎(chǔ)知識(shí)再來(lái)看開(kāi)篇問(wèn)題的答案
讀完上面的基礎(chǔ)知識(shí)相信現(xiàn)在我們已經(jīng)能夠回答 ping IP 后發(fā)生了什么。這些已經(jīng)足夠解決99%的程序員日常網(wǎng)絡(luò)中網(wǎng)絡(luò)為什么不通的問(wèn)題了。但是前面的問(wèn)題比這個(gè)要稍微復(fù)雜一點(diǎn)，還是依靠這些基礎(chǔ)知識(shí)就能解決——這是基礎(chǔ)知識(shí)的威力。
現(xiàn)場(chǎng)網(wǎng)絡(luò)同學(xué)所做的一些其它測(cè)試：
- 懷疑不通的IP所使用的mac地址沖突，在交換機(jī)上清理了交換機(jī)的arp緩存，沒(méi)有幫助，還是不通；
- 新拿出一臺(tái)物理機(jī)配置上不通的容器的IP，這是通的，所以負(fù)責(zé)網(wǎng)絡(luò)的同學(xué)堅(jiān)持是容器網(wǎng)絡(luò)的配置導(dǎo)致了問(wèn)題。
對(duì)于1能通，我認(rèn)為這個(gè)測(cè)試不嚴(yán)格，新物理機(jī)所用的mac不一樣，并且所接的交換機(jī)口也不一樣，影響了測(cè)試結(jié)果。
祭出***手段——抓包
抓包在網(wǎng)絡(luò)問(wèn)題中是***的，但是***次容易被tcpdump抓包命令的眾多參數(shù)嚇暈，不去操作你永遠(yuǎn)上不了手，差距也就拉開(kāi)了，你看差距有時(shí)候只是你對(duì)一條命令的執(zhí)行。
在物理機(jī)2上抓包：
這個(gè)抓包能看到核心證據(jù)，ping包有到達(dá)物理機(jī)2，同時(shí)物理機(jī)2也正確回復(fù)了（mac、ip都對(duì)）。
同時(shí)在物理機(jī)1上抓包（抓包截圖略掉）只能看到ping包出去，回包沒(méi)有到物理機(jī)1（所以回包肯定不會(huì)回到容器里了）。
到這里問(wèn)題的核心在交換機(jī)沒(méi)有正確地把物理機(jī)2的回包送到物理機(jī)1上面，同時(shí)觀察到的不正常延時(shí)都在網(wǎng)關(guān)那一跳：
最終的原因
***在交換機(jī)上分析包沒(méi)正確發(fā)到物理機(jī)1上的原因跟客戶交換機(jī)使用了HSRP（熱備份路由器協(xié)議，就是多個(gè)交換機(jī)HA高可用，也就是同一子網(wǎng)可以有多個(gè)網(wǎng)關(guān)的IP），停掉HSRP后所有IP容器都能通了，并且前面的某些容器延時(shí)也恢復(fù)正常了。
通俗點(diǎn)說(shuō)就是HSRP把回包拐跑了，有些回包拐跑了又送回來(lái)了（延時(shí)200ms那些）
至于HSRP為什么會(huì)這么做，要廠家出來(lái)解釋了。這里關(guān)鍵在于能讓客戶認(rèn)同問(wèn)題出現(xiàn)在交換機(jī)上還是前面的抓包證據(jù)充分，無(wú)可辯駁。實(shí)際中我們都習(xí)慣不給證據(jù)就說(shuō)：我的程序沒(méi)問(wèn)題，就是你的問(wèn)題。這樣表述沒(méi)有一點(diǎn)意義，我們是要拿著證據(jù)這么說(shuō)，對(duì)方也好就著證據(jù)來(lái)反駁，這叫優(yōu)雅地甩鍋。
網(wǎng)絡(luò)到底通不通是個(gè)復(fù)雜的問(wèn)題嗎？
講這個(gè)過(guò)程的核心目的是除了真正的網(wǎng)絡(luò)不通，有些是服務(wù)不可用了也怪網(wǎng)絡(luò)。很多現(xiàn)場(chǎng)的同學(xué)根本講不清自己的服務(wù)（比如80端口上的tomcat服務(wù)）還在不在，網(wǎng)絡(luò)通不通，是網(wǎng)絡(luò)不通呢還是服務(wù)出了問(wèn)題。一看到SocketTimeoutException 就想把網(wǎng)絡(luò)同學(xué)抓過(guò)來(lái)羞辱兩句：網(wǎng)絡(luò)不通了，網(wǎng)絡(luò)抖動(dòng)導(dǎo)致我的程序異常了（網(wǎng)絡(luò)抖動(dòng)是個(gè)***的扛包俠）。
實(shí)際這里涉及到四個(gè)節(jié)點(diǎn)（以兩個(gè)網(wǎng)關(guān)直連為例），srcIP -> src網(wǎng)關(guān) -> dest網(wǎng)關(guān) -> destIP。如果ping不通(也有特殊的防火墻限制ping包不讓過(guò)的），那么在這四段中分段ping（二分查找程序員應(yīng)該最熟悉了）。 比如前面的例子就是網(wǎng)關(guān)沒(méi)有把包轉(zhuǎn)發(fā)回來(lái)。
抓包看ping包有沒(méi)有出去，對(duì)方抓包看有沒(méi)有收到，收到后有沒(méi)有回復(fù)。
ping自己網(wǎng)關(guān)能不能通，ping對(duì)方網(wǎng)關(guān)能不能通。
接下來(lái)說(shuō)點(diǎn)跟程序員日常相關(guān)的
如果網(wǎng)絡(luò)能ping通，服務(wù)無(wú)法訪問(wèn)
那么嘗試telnet IP port 看看你的服務(wù)是否還在監(jiān)聽(tīng)端口，在的話再看看服務(wù)進(jìn)程是否能正常響應(yīng)新的請(qǐng)求。有時(shí)候是進(jìn)程死掉了，端口也沒(méi)人監(jiān)聽(tīng)了；有時(shí)候是進(jìn)程還在但是假死了，所以端口也不響應(yīng)新的請(qǐng)求了，還有的是TCP連接隊(duì)列滿了不能響應(yīng)新的連接。
如果端口還在也是正常的話，telnet應(yīng)該是好的：
假如我故意換成一個(gè)不存在的端口，目標(biāo)機(jī)器上的OS直接就拒絕了這個(gè)
連接（抓包的話一般是看到reset標(biāo)識(shí)）：
一個(gè)SocketTimeoutException，程序員首先懷疑網(wǎng)絡(luò)丟包的Case
當(dāng)時(shí)的反饋應(yīng)用代碼拋SocketTimeoutException，懷疑網(wǎng)絡(luò)問(wèn)題：
業(yè)務(wù)應(yīng)用連接Server 偶爾會(huì)出現(xiàn)超時(shí)異常；
業(yè)務(wù)很多這樣的異常日志：[Server SocketTimeoutException]
檢查一下當(dāng)時(shí)的網(wǎng)絡(luò)狀態(tài)非常好，出問(wèn)題時(shí)間段的網(wǎng)卡的量信息也非常正常：
上圖是通過(guò)sar監(jiān)控到的9號(hào) v24d9e0f23d40 這個(gè)網(wǎng)卡的流量，看起來(lái)也是正常，流量沒(méi)有出現(xiàn)明顯的波動(dòng)。
為了監(jiān)控網(wǎng)絡(luò)到底有沒(méi)有問(wèn)題，接著在出問(wèn)題的兩個(gè)容器上各啟動(dòng)一個(gè)http server，然后在對(duì)方每1秒鐘互相發(fā)一次發(fā)http get請(qǐng)求訪問(wèn)這個(gè)http server，基本認(rèn)識(shí)告訴我們?nèi)绻W(wǎng)絡(luò)丟包、卡頓嚴(yán)重，那么我這個(gè)http server的監(jiān)控日志時(shí)間戳也會(huì)跳躍，如果應(yīng)用是因?yàn)榫W(wǎng)絡(luò)出現(xiàn)異常那么我啟動(dòng)的http服務(wù)也會(huì)出現(xiàn)異常——寧愿寫(xiě)個(gè)工具都不背鍋（主要是背了鍋也不一定能解決掉問(wèn)題）。
從實(shí)際監(jiān)控來(lái)看，應(yīng)用出現(xiàn)異常的時(shí)候我的http服務(wù)是正常的（寫(xiě)了腳本判斷日志的連續(xù)性）：
這也強(qiáng)有力地證明了網(wǎng)絡(luò)沒(méi)問(wèn)題，所以寫(xiě)業(yè)務(wù)代碼的同學(xué)一門(mén)心思集中火力查看應(yīng)用的問(wèn)題。后來(lái)的實(shí)際調(diào)查發(fā)現(xiàn)是應(yīng)用假死掉了（內(nèi)部線程太多，卡死了），服務(wù)端口不響應(yīng)請(qǐng)求了。
如果基礎(chǔ)知識(shí)缺乏一點(diǎn)那么甩過(guò)來(lái)的這個(gè)鍋網(wǎng)絡(luò)是扛不動(dòng)的，同時(shí)也阻礙了問(wèn)題的真正發(fā)現(xiàn)。
TCP協(xié)議通訊過(guò)程跟前面ping一樣，只是把ping的icmp協(xié)議換成TCP協(xié)議，也是要先根據(jù)route，然后arp。
總結(jié)
網(wǎng)絡(luò)丟包、卡頓、抖動(dòng)很容易做扛包俠，只有找到真正的原因解決問(wèn)題才會(huì)更快，否則在錯(cuò)誤的方向上怎么發(fā)力都不對(duì)。準(zhǔn)確的方向要靠好的基礎(chǔ)知識(shí)和正確的邏輯以及證據(jù)來(lái)支撐，而不是猜測(cè)。
- 基礎(chǔ)知識(shí)是決定你能否干到退休的關(guān)鍵因素；
- 有了基礎(chǔ)知識(shí)不代表你能真正轉(zhuǎn)化成生產(chǎn)力；
- 越是基礎(chǔ)，越是幾十年不變的基礎(chǔ)越是重要；
- 知識(shí)到靈活運(yùn)用要靠實(shí)踐，同時(shí)才能把知識(shí)之間的聯(lián)系建立起來(lái)；
- 簡(jiǎn)而言之缺的是融會(huì)貫通和運(yùn)用；
- 做一個(gè)有禮有節(jié)的甩包俠；
- 在別人不給證據(jù)愚昧甩包的情況下你的機(jī)會(huì)就來(lái)了。
留幾個(gè)小問(wèn)題：
- server回復(fù)client的時(shí)候是如何確定回復(fù)包中的src-ip和dest-mac的？一定是請(qǐng)求包中的dest-ip當(dāng)成src-ip嗎？
- 上面問(wèn)題中如果是TCP或者UDP協(xié)議，他們回復(fù)包中的src-ip和dest-mac獲取會(huì)不一樣嗎？
- 既然局域網(wǎng)中都是依賴Mac地址來(lái)定位，那么IP的作用又是什么呢？
【本文為51CTO專(zhuān)欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
