平時，我們想要知道，自己的機器到目的機器之間，網絡通不通，一般會執(zhí)行ping命令。

　　一般對于狀況良好的網絡來說，你能看到它對應的loss丟包率為0%，也就是所謂的能ping通。如果看到丟包率100%，也就是ping不通。

　　那么問題來了，假設我能ping通某臺機器，那這時候如果我改用TCP協(xié)議去發(fā)數據到目的機器，也一定能通嗎？

　　或者換個問法，ping和tcp協(xié)議走的網絡路徑是一樣的嗎？

　　這時候第一反應就是不一定，因為ping完之后中間鏈路里的某個路由器可能會掛了（斷電了），再用TCP去連就會走別的路徑。

　　也沒錯。但假設，中間鏈路沒發(fā)生任何變化呢？

　　我先直接說答案。

　　不一定，走的網絡路徑還是有可能是不同的。

　　今天就來聊聊為什么。

　　我之前寫過一篇《斷網了，還能ping通 127.0.0.1 嗎？》,里面提到過ping數據包和tcp數據包的區(qū)別。

　　ping和TCP發(fā)消息的區(qū)別

　　我們知道網絡是分層的，每一層都有對應協(xié)議。

　　五層網絡協(xié)議對應的消息體變化分析

　　而這網絡層就像搭積木一樣，上層協(xié)議都是基于下層協(xié)議搭出來的。

　　不管是ping（用了ICMP協(xié)議）還是tcp本質上都是基于網絡層IP協(xié)議的數據包，而到了物理層，都是二進制01串，都走網卡發(fā)出去了。

　　如果網絡環(huán)境沒發(fā)生變化，目的地又一樣，那按道理說他們走的網絡路徑應該是一樣的，什么情況下會不同呢？

　　我們就從路由這個話題聊起吧。

　　網絡路徑

　　在我們的想象中，當我們想在兩臺機器之間傳輸數據。本機和目的機器之間會建立一條連接，像一條管道一樣，數據從這頭到那頭。這條管道其實是我們?yōu)榱朔奖憷斫舛橄蟪鰜淼母拍睢?/p>

　　實際上，我們將數據包從本地網卡發(fā)出之后，會經過各種路由器（或者交換機），才能到達目的機器。

　　這些路由器數量眾多，相互之間可以互連，連起來之后就像是一張大網，所以叫"網絡"可以說是非常的形象。

　　路由器構成的網絡

　　考慮到交換機有的功能，路由器基本上都支持，所以我們這邊只討論路由器。

　　那么現在問題來了，路由器收到數據后，怎么知道應該走哪條路徑，傳給哪個路由器？

　　路徑由什么決定？

　　在上面的那么大一張網絡中，隨便一個路由器都有可能走任何一個路徑，將數據發(fā)到另外一個路由器上，

　　但路由和路由之間距離，帶寬啥的可能都不同。

　　于是就很需要知道，兩點之間走哪條路才是最優(yōu)路徑。

　　于是問題就變成了這樣一個圖狀結構。每條邊都帶有成本或權重，算這上面任意兩點的最短距離。

　　路由器和Dijkstra

　　這時候想必大家回憶壓不住要上來了。

　　這題我熟，這就是大學時候刷的Dijkstra算法。菊花廠的OJ筆試題集里也經常出現，現在終于明白為什么他們家的筆試題里圖類題目比別的大廠貌似要多一些了吧，因為菊花廠就是搞通信的，做路由器的老玩家了。

　　路由表的生成

　　基于Dijkstra算法，封裝出了一個新的協(xié)議，OSPF協(xié)議（Open Shortest Path First, 開放最短路徑優(yōu)先）。

　　有了OSPF，路由器就得到了網絡圖里自己到其他點之間的最短距離，于是就知道了數據包要到某個點，該走哪條最優(yōu)路徑。

　　將這些信息匯成一張表，也就是我們常說的路由表。

　　路由表里記錄了到什么IP需要走什么端口，以及走這條路徑的成本（metric）。

　　可以通過 route 命令查看到。

　　route表

　　路由表決定數據包路徑

　　數據包在發(fā)送的過程中，會在網絡層加入目標地址IP。

　　路由器會根據這個IP跟路由表去做匹配。

　　然后路由表，會告訴路由器，什么樣的消息該轉發(fā)到什么端口。

　　舉個例子。

　　通過路由表轉發(fā)數據

　　假設A要發(fā)消息到D。也就是192.168.0.105/24要發(fā)消息到192.168.1.11/24。

　　那么A會把消息經發(fā)到路由器。

　　路由器已知目的地IP192.168.1.11/24 ，去跟路由表做匹配，發(fā)現192.168.1.0/24, 就在e2端口，那么就會把消息從e2端口發(fā)出，（可能還會經過交換機）最后把消息打到目的機器。

　　當然，如果路由表里找不到，那就打到默認網關吧，也就是從e1口發(fā)出，發(fā)到IP192.0.2.1。這個路由器的路由表不知道該去哪，說不定其他路由器知道。

　　路由表的匹配規(guī)則

　　上面的例子里，是只匹配上了路由表里的一項，所以只能是它了。

　　但是，條條大路通羅馬。實際上能到目的地的路徑肯定有很多。

　　如果路由表里有很多項都被匹配上了，會怎么選？

　　如果多個路由項都能到目的地，那就優(yōu)先選匹配長度更長的那個。比如，還是目的地192.168.1.11，發(fā)現路由表里的192.168.1.0/24 和 192.168.0.0/16都能匹配上，但明顯前者匹配長度更長，所以最后會走 192.168.1.0/24對應的轉發(fā)端口。

　　但如果兩個表項的匹配長度都一樣呢？

　　那就會看生成這個路由表項的協(xié)議是啥，選優(yōu)先級高的，優(yōu)先級越高也就是所謂的管理距離（AD，AdministrativeDistance）越小。比如說優(yōu)先選手動配的靜態(tài)（static）路由，次優(yōu)選OSPF動態(tài)學習過來的表項。

　　如果還是相同，就看度量值metrics，其實也就是路徑成本cost，成本越小，越容易被選中。

　　路由器能選的路線有很多，但按道理，最優(yōu)的只有"一條"，所以到這里為止，我們都可以認為，對于同一個目的地，ping和TCP走的路徑是相同的。

　　但是。

　　如果連路徑成本都一樣呢？也就是說有多條最優(yōu)路徑呢。

　　那就都用。

　　這也就是所謂的等價多路徑，ECMP（Equal Cost MultiPath）。

　　我們可以通過traceroute看下鏈路是否存在等價多路徑的情況。

　　可以看到，中間某幾行，有好幾個IP，也就是說這一跳里同時可以選好幾個目的機器，說明這段路徑支持ECMP。

　　ECMP有什么用

　　利用等價多路徑，我們可以增加鏈路帶寬。

　　舉個例子。

　　沒有ECMP時只能選擇某一條路徑

　　從A點到B點，如果這兩條路徑成本不同，帶寬都是1千兆。那數據包肯定就選成本低的那條路了，如果這條路出故障了，就走下面那條路。但不管怎么樣，同一時間，只用到了一條路徑。另外一條閑置就有些浪費了，有沒有辦法可以利用起來呢？

　　有，將它們兩條路徑的成本設置成一樣，那它們就成了等價路由，然后中間的路由器開啟ECMP特性，就可以同時利用這兩條鏈路了。帶寬就從原來的1千兆變成了2千兆。數據就可以在兩條路徑中隨意選擇了。

　　利用ECMP可以同時使用兩條鏈路

　　但這也帶來了另外一個問題。加劇了數據包亂序。

　　原來我只使用一條網絡路徑，數據依次發(fā)出，如無意外，也是依次到達。

　　現在兩個數據包走兩條路徑，先發(fā)的數據包可能后到。這就亂序了。

　　那么問題又又來了。

　　亂序會有什么問題？

　　對于我們最最最常使用的TCP協(xié)議來說，它是個可靠性網絡的協(xié)議，這里提到的可靠，不僅是保證數據要能送到目的地，還要保證數據順序要跟原來發(fā)送端的一樣。

　　實現也很簡單，TCP為每個數據包（segment）做上編號。數據到了接收端后，根據數據包編號發(fā)現是亂序數據包，就會扔到亂序隊列中對數據包進行排序。如果前面的數據包還沒到，哪怕后面的數據包先到了，也得在亂序隊列中一直等，到齊后才能被上層拿到。

　　舉個例子，發(fā)送端發(fā)出三個數據包，編號1,2,3，假設在傳輸層2和3先到了，1還沒到。那此時應用層是沒辦法拿到2和3的數據包的，必須得等1來了之后，應用層才能一次性拿到這三個包。因為這三個包原來可能表示的是一個完整的消息，少了1, 那么消息就不完整，應用層拿到了也毫無意義。

　　像這種，由于前面的數據丟失導致后面的數據沒辦法及時給到應用層的現象，就是我們常說的TCP隊頭阻塞。

　　亂序隊列等待數據包的到來

　　亂序發(fā)生時2和3需要待在亂序隊列中，而亂序隊列其實用的也是接收緩沖區(qū)的內存，而接收緩沖區(qū)是有大小限制的。通過下面的命令可以看到接收緩沖區(qū)的大小。

　　# 查看接收緩沖區(qū)

　　$ sysctl net.ipv4.tcp_rmem

　　net.ipv4.tcp_rmem = 4096(min)    87380(default)  6291456(max)

　　# 緩沖區(qū)會在min和max之間動態(tài)調整

　　亂序的情況越多，接收緩沖區(qū)的內存就被占用的越多，對應的接收窗口就會變小，那正常能收的數據就變少了，網絡吞吐就變差了，也就是性能變差了。

　　因此，我們需要盡量保證所有同一個TCP連接下的所有TCP包都走相同路徑，這樣才能最大程度避免丟包。

　　ECMP的路徑選擇策略

　　當初開啟ECMP就是為了提升性能，現在反而加重了亂序，降低了TCP傳輸性能。

　　這怎么能忍。

　　為了解決這個問題，我們需要有一個合理的路徑選擇策略。為了避免同一個連接里的數據包亂序，我們需要保證同一個連接里的數據包，都走同樣的路徑。

　　這好辦。我們可以通過連接的五元組（發(fā)送方的IP和端口，接收方的IP和端口，以及通信協(xié)議）信息定位到唯一一條連接。

　　五元組

　　然后對五元組信息生成哈希鍵，讓同一個哈希鍵的數據走同一條路徑，問題就完美解決了。

　　TCP和Ping走的網絡路徑一樣嗎

　　現在我們回到文章開頭的問題。

　　對于同樣的發(fā)送端和接收端，TCP和Ping走的網絡路徑一樣嗎？

　　不一定一樣，因為五元組里的信息里有一項是通信協(xié)議。ping用的是ICMP協(xié)議，跟TCP協(xié)議不同，并且ping不需要用到端口，所以五元組不同，生成的哈希鍵不同，通過ECMP選擇到的路徑也可能不同。

　　TCP和ping的五元組差異

　　同樣都用TCP協(xié)議，數據包走的網絡路徑一樣嗎

　　還是同樣的發(fā)送端和接收端，同樣是TCP協(xié)議，不同TCP連接走的網絡路徑是一樣的嗎？

　　跟上面的問題一樣，其實還是五元組的問題，同樣都是TCP協(xié)議，對于同樣的發(fā)送端和接收端，他們的IP和接收端的端口肯定是一樣的，但發(fā)送方的端口是可以隨時變化的，因此通過ECMP走的路徑也可能不同。

　　不同TCP連接的五元組差異

　　但問題又來了。

　　我知道這個有什么用呢？我做業(yè)務開發(fā)，又沒有設置網絡路由的權限。

　　利用這個知識點排查問題

　　對于業(yè)務開發(fā)，這絕對不是個沒用的知識點。

　　如果某天，你發(fā)現，你能ping通目的機器，但用TCP去連，卻偶爾連不上目的機器。而且兩端機器都挺空閑，沒什么性能上的瓶頸。實在走投無路了。

　　你就可以想想，會不會是網絡中用到了ECMP，其中一條鏈路有問題導致的。

　　ping能成功但部分TCP連接失敗

　　排查方法也很簡單。

　　你是知道本機的IP以及目的機器的IP和端口號的，也知道自己用的是TCP連接。

　　只要你在報錯的時候打印下錯誤信息，你就知道了發(fā)送端的端口號了。

　　這樣五元組是啥你就知道了。

　　下一步就是指定發(fā)送端的端口號重新發(fā)起TCP請求，同樣的五元組，走同樣的路徑，按理說如果鏈路有問題，就肯定會復現。

　　如果不想改自己的代碼，你可以用nc命令指定客戶端端口看下能不能正常建立TCP連接。

　　nc -p 6666 baidu.com 80

　　-p 6666是指定發(fā)出請求的客戶端端口是6666，后面跟著的是連接的域名和80端口。

　　通過nc成功建立tcp連接

　　假設用了6666端口的五元組去連接總是失敗，改用6667或其他端口卻能成功，你可以帶著這個信息去找找負責網絡的同事。

　　總結

　　路由器可以通過OSPF協(xié)議生成路由表，利用數據包里的IP地址去跟路由表做匹配，選擇最優(yōu)路徑后進行轉發(fā)。

　　當路由表一個都匹配不上時會走默認網關。當匹配上多個的時候，會先看匹配長度，如果一樣就看管理距離，還一樣就看路徑成本。如果連路徑成本都一樣，那等價路徑。如果路由開啟了ECMP，那就可以同時利用這幾條路徑做傳輸。

　　ECMP可以提高鏈路帶寬，同時利用五元組做哈希鍵進行路徑選擇，保證了同一條連接的數據包走同一條路徑，減少了亂序的情況。

　　可以通過traceroute命令查看到鏈路上是否有用到ECMP的情況。

　　開啟了ECMP的網絡鏈路中，TCP和ping命令可能走的路徑不同，甚至同樣是TCP，不同連接之間，走的路徑也不同，因此出現了連接時好時壞的問題，實在是走投無路了，可以考慮下是不是跟ECMP有關。

　　當然，遇到問題多懷疑自己，要相信絕大部分時候真的跟ECMP無關。

　　更多信息可以來這里獲取==>>電子技術應用-AET<<