本文由小白debug分享，原題“能 ping 通，TCP 就一定能連通嗎？”，下文進行了排版和內容優化。

1、引言

平時，我們想要知道，自己的機器到目的機器之間，網絡通不通，一般會執行ping命令。一般對于狀況良好的網絡來說，你能看到它對應的loss丟包率為0%，也就是所謂的能ping通。如果看到丟包率100%，也就是ping不通。

▲ ping正常

▲ ping不通

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

或者換個問法：ping和tcp協議走的網絡路徑是一樣的嗎？

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

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

我先直接說答案：不一定，走的網絡路徑還是有可能是不同的。

今天就來聊聊為什么。

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

▲ ping和TCP發消息的區別

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

▲ 五層網絡協議對應的消息體變化分析

而這網絡層就像搭積木一樣，上層協議都是基于下層協議搭出來的。不管是ping（用了ICMP協議）還是tcp本質上都是基于網絡層IP協議的數據包，而到了物理層，都是二進制01串，都走網卡發出去了。

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

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

技術交流：

2、網絡路徑

在我們的想象中，當我們想在兩臺機器之間傳輸數據。本機和目的機器之間會建立一條連接，像一條管道一樣，數據從這頭到那頭。這條管道其實是我們為了方便理解而抽象出來的概念。

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

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

▲ 路由器構成的網絡

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

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

3、網絡路徑由什么決定？

在上面的那么大一張網絡中，隨便一個路由器都有可能走任何一個路徑，將數據發到另外一個路由器上，但路由和路由之間距離，帶寬啥的可能都不同。

于是就很需要知道，兩點之間走哪條路才是最優路徑。于是問題就變成了這樣一個圖狀結構。每條邊都帶有成本或權重，算這上面任意兩點的最短距離。

▲ 路由器和Dijkstra

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

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

4、路由表的生成

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

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

將這些信息匯成一張表，也就是我們常說的路由表。路由表里記錄了到什么IP需要走什么端口，以及走這條路徑的成本（metric）。

可以通過 route 命令查看到：

▲ route表

5、路由表決定數據包路徑

數據包在發送的過程中，會在網絡層加入目標地址IP。路由器會根據這個IP跟路由表去做匹配。然后路由表，會告訴路由器，什么樣的消息該轉發到什么端口。

舉個例子：

▲ 通過路由表轉發數據

假設A要發消息到D。也就是192.168.0.105/24要發消息到192.168.1.11/24。那么A會把消息經發到路由器。

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

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

6、路由表的匹配規則

上面的例子里，是只匹配上了路由表里的一項，所以只能是它了。但是，條條大路通羅馬。實際上能到目的地的路徑肯定有很多。

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

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

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

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

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

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

但是：如果連路徑成本都一樣呢？也就是說有多條最優路徑呢。

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

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

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

7、ECMP有什么用

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

舉個例子：

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

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

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

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

但這也帶來了另外一個問題：加劇了數據包亂序。原來我只使用一條網絡路徑，數據依次發出，如無意外，也是依次到達?，F在兩個數據包走兩條路徑，先發的數據包可能后到。這就亂序了。

那么問題又又來了。。。

8、數據包亂序會有什么問題？

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

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

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

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

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

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

# 查看接收緩沖區

$ sysctl net.ipv4.tcp_rmem

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

# 緩沖區會在min和max之間動態調整

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

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

9、ECMP的路徑選擇策略

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

這怎么能忍！

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

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

▲ 五元組

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

▲ 五元組映射成hash鍵

根據五元組選擇ECMP路徑

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

現在我們回到文章開頭的問題：對于同樣的發送端和接收端，TCP和Ping走的網絡路徑一樣嗎？

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

▲ TCP和ping的五元組差異

11、同樣都用TCP協議，數據包走的網絡路徑一樣嗎

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

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

▲ 不同TCP連接的五元組差異

但問題又來了：我知道這個有什么用呢？我做業務開發，又沒有設置網絡路由的權限。

12、學這些知識到底還有啥用？

對于業務開發，這絕對不是個沒用的知識點。

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

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

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

排查方法也很簡單。

你是知道本機的IP以及目的機器的IP和端口號的，也知道自己用的是TCP連接。只要你在報錯的時候打印下錯誤信息，你就知道了發送端的端口號了。這樣五元組是啥你就知道了。

下一步就是指定發送端的端口號重新發起TCP請求，同樣的五元組，走同樣的路徑，按理說如果鏈路有問題，就肯定會復現。如果不想改自己的代碼，你可以用nc命令指定客戶端端口看下能不能正常建立TCP連接。

nc -p 6666 baidu.com 80

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

▲ 通過nc成功建立tcp連接

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

13、本文小結

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

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

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

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

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

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

14、系列文章

本文是系列文章中的第 19篇，本系列文章的大綱如下：

《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》

《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》

《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》

《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》

《不為人知的網絡編程(五)：UDP的連接性和負載均衡》

《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》

《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》

《不為人知的網絡編程(八)：從數據傳輸層深度解密HTTP》

《不為人知的網絡編程(九)：理論聯系實際，全方位深入理解DNS》

《不為人知的網絡編程(十)：深入操作系統，從內核理解網絡包的接收過程(Linux篇)》

《不為人知的網絡編程(十一)：從底層入手，深度分析TCP連接耗時的秘密》

《不為人知的網絡編程(十二)：徹底搞懂TCP協議層的KeepAlive?；顧C制》

《不為人知的網絡編程(十三)：深入操作系統，徹底搞懂127.0.0.1本機網絡通信》

《不為人知的網絡編程(十四)：拔掉網線再插上，TCP連接還在嗎？一文即懂！》

《不為人知的網絡編程(十五)：深入操作系統，一文搞懂Socket到底是什么》

《不為人知的網絡編程(十六)：深入分析與解決TCP的RST經典異常問題》

《不為人知的網絡編程(十七)：冰山之下，一次網絡請求背后的技術秘密》

《不為人知的網絡編程(十八)：UDP比TCP高效？還真不一定！》

《不為人知的網絡編程(十九)：能Ping通，TCP就一定能連接和通信嗎？》（* 本文）

15、參考資料

[1] TCP/IP詳解 - 第11章·UDP：用戶數據報協議

[2] 網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）

[3] 網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）

[4] 網絡編程懶人入門(三)：快速理解TCP協議一篇就夠

[5] 網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門

[6] 腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？

[7] 腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？

[8] 腦殘式網絡編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區別？

[9] 網絡編程入門如此簡單(四)：一文搞懂localhost和127.0.0.1

[10] 不為人知的網絡編程(十三)：深入操作系統，徹底搞懂127.0.0.1本機網絡通信

[11] 腦殘式網絡編程入門(七)：面視必備，史上最通俗計算機網絡分層詳解

[12] 技術大牛陳碩的分享：由淺入深，網絡編程學習經驗干貨總結

[13] 網絡編程入門如此簡單(一)：假如你來設計網絡，會怎么做？

[14] 網絡編程入門如此簡單(二)：假如你來設計TCP協議，會怎么做？

[15] 不為人知的網絡編程(十四)：拔掉網線再插上，TCP連接還在嗎？一文即懂！

[16] 不為人知的網絡編程(十五)：深入操作系統，一文搞懂Socket到底是什么

[17] 移動端弱網優化專題(五)：百度APP網絡深度優化實踐（網絡連接優化篇）

（本文已同步發布于：http://www.52im.net/thread-4756-1-1.html）