衡阳派盒市场营销有限公司

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

服務器ping不通但是http能請求成功是什么原因

小林coding ? 來源:小白debug ? 2024-10-23 09:23 ? 次閱讀

以下文章來源于小白debug,作者小白

大家好,我是小林。

昨天分享了一篇騰訊后端面經:「好難!騰訊面試體驗已結束」,里面就有個問題:

服務器ping不通但是http能請求成功,會出現這種情況嗎?什么原因造成的?

那么,今天就詳細聊聊這個問題。

正文

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

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

4c52a26c-9030-11ef-a511-92fbcf53809c.pngping正常 4c803d8a-9030-11ef-a511-92fbcf53809c.pngping不通

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

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

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

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

我先直接說答案。

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

今天就來聊聊為什么。

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

4c9ad352-9030-11ef-a511-92fbcf53809c.pngping和TCP發消息的區別

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

4cb2d100-9030-11ef-a511-92fbcf53809c.png五層網絡協議對應的消息體變化分析

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

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

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

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

網絡路徑

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

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

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

4ccab46e-9030-11ef-a511-92fbcf53809c.png路由器構成的網絡

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

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

路徑由什么決定?

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

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

于是就很需要知道,兩點之間走哪條路才是最優路徑

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

4ce39b8c-9030-11ef-a511-92fbcf53809c.png路由器和Dijkstra

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

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

路由表的生成

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

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

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

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

可以通過 route 命令查看到。

4d06ff8c-9030-11ef-a511-92fbcf53809c.pngroute表

路由表決定數據包路徑

數據包在發送的過程中,會在網絡層加入目標地址IP

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

然后路由表,會告訴路由器,什么樣的消息該轉發到什么端口。

舉個例子。

4d233b3e-9030-11ef-a511-92fbcf53809c.png通過路由表轉發數據

假設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。這個路由器的路由表不知道該去哪,說不定其他路由器知道

路由表的匹配規則

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

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

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

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

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

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

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

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

但是。

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

那就都用

這也就是所謂的等價多路徑,ECMPEqual Cost MultiPath)。

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

4d45e274-9030-11ef-a511-92fbcf53809c.png圖片

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

ECMP有什么用

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

舉個例子。

4d628b2c-9030-11ef-a511-92fbcf53809c.png沒有ECMP時只能選擇某一條路徑

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

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

4d8c7d6a-9030-11ef-a511-92fbcf53809c.png利用ECMP可以同時使用兩條鏈路

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

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

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

那么問題又又來了。

亂序會有什么問題?

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

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

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

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

4dac7c5a-9030-11ef-a511-92fbcf53809c.png亂序隊列等待數據包的到來

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

#查看接收緩沖區
$sysctlnet.ipv4.tcp_rmem
net.ipv4.tcp_rmem=4096(min)87380(default)6291456(max)
#緩沖區會在min和max之間動態調整

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

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

ECMP的路徑選擇策略

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

這怎么能忍。

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

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

4dc52e6c-9030-11ef-a511-92fbcf53809c.png五元組

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

4def8162-9030-11ef-a511-92fbcf53809c.png五元組映射成hash鍵 4e04642e-9030-11ef-a511-92fbcf53809c.png根據五元組選擇ECMP路徑

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

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

對于同樣的發送端和接收端,TCP和Ping走的網絡路徑一樣嗎?

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

4e64e27c-9030-11ef-a511-92fbcf53809c.pngTCP和ping的五元組差異

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

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

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

4e89b26e-9030-11ef-a511-92fbcf53809c.png不同TCP連接的五元組差異

但問題又來了。

我知道這個有什么用呢?我做業務開發,又沒有設置網絡路由的權限。

利用這個知識點排查問題

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

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

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

4ea1bcf6-9030-11ef-a511-92fbcf53809c.pngping能成功但部分TCP連接失敗

排查方法也很簡單。

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

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

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

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

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

nc-p6666baidu.com80

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

4ebc39aa-9030-11ef-a511-92fbcf53809c.png通過nc成功建立tcp連接

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

總結

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

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

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

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

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

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

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • TCP
    TCP
    +關注

    關注

    8

    文章

    1378

    瀏覽量

    79305
  • Ping
    +關注

    關注

    0

    文章

    69

    瀏覽量

    16053
  • 命令
    +關注

    關注

    5

    文章

    696

    瀏覽量

    22113
  • TCP協議
    +關注

    關注

    1

    文章

    101

    瀏覽量

    12124

原文標題:騰訊一面:能ping通,TCP就一定能連通嗎?

文章出處:【微信號:小林coding,微信公眾號:小林coding】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    dhcp服務器

    服務設置完了后,客戶電腦上得到服務器分配的ip地址但是不通什么原因啊!請高手指點,聯系QQ279282417
    發表于 02-14 00:39

    在部署共享變量時 可以找到服務器但是找不到服務器中的共享變量,這是什么原因呢?

    請教一下在部署共享變量時 可以找到服務器但是找不到服務器中的共享變量,這是什么原因呢?可以指導一下嗎共享變量的部署問題:
    發表于 05-21 15:40

    dm8148網絡uboot環境下ping同,進入系統卻ping不通??

    不知道什么原因造成的),在文件系統內配置與主機在同一網斷,但是不能ping通主機; 我的疑問是uboot下使用ping 的時候顯示active;并且tftp也
    發表于 06-23 05:33

    LPC1788TCP服務器ping成功

    LPC1788的UDP通信沒有問題,可以ping成功,正常收發數據,但是下載了咱們論壇里的悍馬版LPC1788的TCP服務器程序,就是ping
    發表于 07-20 17:31

    請求信號量能請求成功嗎?

    OS_EVENT * RandomSem; OSSemPend(RandomSem, 0, &err);LED1_ON(RED);//點燈這樣寫有個地方不明白,這是請求信號量,能不能請求成功,沒有判斷,為什么可以這樣寫LED1_ON(RED).
    發表于 08-20 04:35

    使用CH32V307+WCHNET實現webserver服務http請求無法訪問怎么解決?

    使用CH32V307+ WCHNET 實現 webserver 服務,加電后HTTP請求可以正常訪問,ping平通,
    發表于 09-14 07:06

    請問CH32V307 ping正常但是http請求少部分正常大部分請求超時是為什么?

    請問 CH32V307ping正常 但是 http請求少部分正常大部分請求超時 ,用的是netlib,這個會是
    發表于 09-15 07:32

    ESP32 Web服務器可以向外部Rest API發起HTTP請求嗎?

    服務器 API 也可以發起/發出請求?3)傳入和傳出請求的流量是否由同一個端口處理(出于端口轉發的原因)?舉個例子,考慮一下自動化中使用的 ESP32,它有自己的 WEB UI,可以
    發表于 03-01 06:22

    Java編程:發送HTTP請求服務器

    當Java程序需要向服務器發送請求或讀取服務器數據時,使用URLConnection類是比較好的選擇。URLConnection類封裝了與服務器互動操作的方法,通過它可以建立與
    的頭像 發表于 07-01 09:59 ?3134次閱讀
    Java編程:發送<b class='flag-5'>HTTP</b><b class='flag-5'>請求</b>到<b class='flag-5'>服務器</b>

    MCU沒有響應服務器請求,NodeMCU HTTP服務器停止響應

    我正在嘗試使用NodeMCU創建一個簡單的HTTP服務器 . 我啟動nodeMCU然后將其連接到wifi,然后運行下面的程序 . 我可以從瀏覽連接到服務器 . 如果我繼續重新加載頁面
    發表于 10-25 18:21 ?11次下載
    MCU沒有響應<b class='flag-5'>服務器</b><b class='flag-5'>請求</b>,NodeMCU <b class='flag-5'>HTTP</b><b class='flag-5'>服務器</b>停止響應

    【筆記】ping不通原因有那些?

    Ping命令無法成功訪問目標主機時,可能存在多種原因。以下是一些常見的導致Ping不通的問題,并對每個問題進行了分析和解釋:1.
    的頭像 發表于 05-30 17:24 ?2.2w次閱讀
    【筆記】<b class='flag-5'>ping</b><b class='flag-5'>不通</b>的<b class='flag-5'>原因</b>有那些?

    使用NS1串口服務器HTTP模式上傳服務器數據

    HTTP協議工作于客戶端-服務端架構之上。瀏覽作為HTTP客戶端通過URL向HTTP服務端即W
    的頭像 發表于 08-30 12:36 ?479次閱讀
    使用NS1串口<b class='flag-5'>服務器</b><b class='flag-5'>HTTP</b>模式上傳<b class='flag-5'>服務器</b>數據

    服務器之間ping不通原因

    服務器之間ping不通可能由多種原因造成,以下是一些常見的原因及其解決方法: 一、物理連接問題 網線問題 : 網線未插好或松動,導致
    的頭像 發表于 10-14 15:02 ?3136次閱讀

    局域網ping不通原因有哪些

    使用 ping 命令測試兩臺計算機之間的連接時,如果 ping 不通,可能存在多種原因。以下是一些可能導致局域網 ping
    的頭像 發表于 10-14 15:03 ?5321次閱讀

    服務器如何處理 HTTP 請求

    服務器處理HTTP請求的過程是一個有序且復雜的流程,通常涉及多個步驟。以下是服務器處理HTTP請求
    的頭像 發表于 12-30 09:37 ?155次閱讀
    百家乐真人游戏开户| 百家乐能赢到钱吗| 娱网棋牌官方下载| 澳门百家乐一把决战输赢| 网上百家乐官网有没有假| 大发888 casino组件下载| 做生意讲究风水吗| 玩百家乐官网保时捷娱乐城| 博彩策略| 百家乐光纤冼牌机| 网上百家乐网站导航| 神人百家乐官网赌场| 故城县| 棋牌游戏赚钱| 百家乐策略网络游戏信誉怎么样 | 线上老虎机| 大发888投注鸿博博彩| 百家乐笑话| 百家乐娱乐城网址| 百家乐官网群b28博你| 至尊百家乐官网奇热| 网上尊龙国际娱乐| 大发888娱乐城官方网站| 粤港澳百家乐娱乐| 百家乐5式直缆投注法| 天天百家乐游戏| 传奇百家乐官网的玩法技巧和规则| 百家乐官网美食坊| 百家乐官网路单破解方法| 崇州市| 足球博彩| 蒙特卡罗娱乐网| 新盈国际| 大发888娱乐场官方| 太阳城直属现金网| 百家乐技巧| 百家乐桌子定制| 全讯网新2| 新花园百家乐的玩法技巧和规则| 钱隆百家乐智能| 百家乐园有限公司|