RM新时代网站-首页

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

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

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

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

大家好,我是小林。

昨天分享了一篇騰訊后端面經(jīng):「好難!騰訊面試體驗(yàn)已結(jié)束」,里面就有個(gè)問題:

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

那么,今天就詳細(xì)聊聊這個(gè)問題。

正文

平時(shí),我們想要知道,自己的機(jī)器到目的機(jī)器之間,網(wǎng)絡(luò)通不通,一般會執(zhí)行ping命令。

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

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

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

或者換個(gè)問法,ping和tcp協(xié)議走的網(wǎng)絡(luò)路徑是一樣的嗎?

這時(shí)候第一反應(yīng)就是不一定,因?yàn)閜ing完之后中間鏈路里的某個(gè)路由器可能會掛了(斷電了),再用TCP去連就會走別的路徑。

也沒錯(cuò)。但假設(shè),中間鏈路沒發(fā)生任何變化呢?

我先直接說答案。

不一定,走的網(wǎng)絡(luò)路徑還是有可能是不同的。

今天就來聊聊為什么。

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

4c9ad352-9030-11ef-a511-92fbcf53809c.pngping和TCP發(fā)消息的區(qū)別

我們知道網(wǎng)絡(luò)是分層的,每一層都有對應(yīng)協(xié)議。

4cb2d100-9030-11ef-a511-92fbcf53809c.png五層網(wǎng)絡(luò)協(xié)議對應(yīng)的消息體變化分析

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

不管是ping(用了ICMP協(xié)議)還是tcp本質(zhì)上都是基于網(wǎng)絡(luò)層IP協(xié)議的數(shù)據(jù)包,而到了物理層,都是二進(jìn)制01串,都走網(wǎng)卡發(fā)出去了。

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

我們就從路由這個(gè)話題聊起吧。

網(wǎng)絡(luò)路徑

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

實(shí)際上,我們將數(shù)據(jù)包從本地網(wǎng)卡發(fā)出之后,會經(jīng)過各種路由器(或者交換機(jī),才能到達(dá)目的機(jī)器。

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

4ccab46e-9030-11ef-a511-92fbcf53809c.png路由器構(gòu)成的網(wǎng)絡(luò)

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

那么現(xiàn)在問題來了,路由器收到數(shù)據(jù)后,怎么知道應(yīng)該走哪條路徑,傳給哪個(gè)路由器?

路徑由什么決定?

在上面的那么大一張網(wǎng)絡(luò)中,隨便一個(gè)路由器都有可能走任何一個(gè)路徑,將數(shù)據(jù)發(fā)到另外一個(gè)路由器上,

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

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

于是問題就變成了這樣一個(gè)圖狀結(jié)構(gòu)。每條邊都帶有成本或權(quán)重,算這上面任意兩點(diǎn)的最短距離。

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

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

這題我熟,這就是大學(xué)時(shí)候刷的Dijkstra算法。菊花廠的OJ筆試題集里也經(jīng)常出現(xiàn),現(xiàn)在終于明白為什么他們家的筆試題里圖類題目比別的大廠貌似要多一些了吧,因?yàn)榫栈◤S就是搞通信的,做路由器的老玩家了。

路由表的生成

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

有了OSPF,路由器就得到了網(wǎng)絡(luò)圖里自己到其他點(diǎn)之間的最短距離,于是就知道了數(shù)據(jù)包要到某個(gè)點(diǎn),該走哪條最優(yōu)路徑。

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

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

可以通過 route 命令查看到。

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

路由表決定數(shù)據(jù)包路徑

數(shù)據(jù)包在發(fā)送的過程中,會在網(wǎng)絡(luò)層加入目標(biāo)地址IP。

路由器會根據(jù)這個(gè)IP路由表去做匹配。

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

舉個(gè)例子。

4d233b3e-9030-11ef-a511-92fbcf53809c.png通過路由表轉(zhuǎn)發(fā)數(shù)據(jù)

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

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

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

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

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

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

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

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

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

但如果兩個(gè)表項(xiàng)的匹配長度都一樣呢?

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

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

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

但是。

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

那就都用。

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

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

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

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

ECMP有什么用

利用等價(jià)多路徑,我們可以增加鏈路帶寬。

舉個(gè)例子。

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

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

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

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

但這也帶來了另外一個(gè)問題。加劇了數(shù)據(jù)包亂序。

原來我只使用一條網(wǎng)絡(luò)路徑,數(shù)據(jù)依次發(fā)出,如無意外,也是依次到達(dá)。

現(xiàn)在兩個(gè)數(shù)據(jù)包走兩條路徑,先發(fā)的數(shù)據(jù)包可能后到。這就亂序了。

那么問題又又來了。

亂序會有什么問題?

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

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

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

像這種,由于前面的數(shù)據(jù)丟失導(dǎo)致后面的數(shù)據(jù)沒辦法及時(shí)給到應(yīng)用層的現(xiàn)象,就是我們常說的TCP隊(duì)頭阻塞。

4dac7c5a-9030-11ef-a511-92fbcf53809c.png亂序隊(duì)列等待數(shù)據(jù)包的到來

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

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

亂序的情況越多,接收緩沖區(qū)的內(nèi)存就被占用的越多,對應(yīng)的接收窗口就會變小,那正常能收的數(shù)據(jù)就變少了,網(wǎng)絡(luò)吞吐就變差了,也就是性能變差了。

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

ECMP的路徑選擇策略

當(dāng)初開啟ECMP就是為了提升性能,現(xiàn)在反而加重了亂序,降低了TCP傳輸性能。

這怎么能忍。

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

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

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

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

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

TCP和Ping走的網(wǎng)絡(luò)路徑一樣嗎

現(xiàn)在我們回到文章開頭的問題。

對于同樣的發(fā)送端和接收端,TCP和Ping走的網(wǎng)絡(luò)路徑一樣嗎?

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

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

同樣都用TCP協(xié)議,數(shù)據(jù)包走的網(wǎng)絡(luò)路徑一樣嗎

還是同樣的發(fā)送端和接收端,同樣是TCP協(xié)議,不同TCP連接走的網(wǎng)絡(luò)路徑是一樣的嗎?

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

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

但問題又來了。

我知道這個(gè)有什么用呢?我做業(yè)務(wù)開發(fā),又沒有設(shè)置網(wǎng)絡(luò)路由的權(quán)限。

利用這個(gè)知識點(diǎn)排查問題

對于業(yè)務(wù)開發(fā),這絕對不是個(gè)沒用的知識點(diǎn)。

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

你就可以想想,會不會是網(wǎng)絡(luò)中用到了ECMP,其中一條鏈路有問題導(dǎo)致的。

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

排查方法也很簡單。

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

只要你在報(bào)錯(cuò)的時(shí)候打印下錯(cuò)誤信息,你就知道了發(fā)送端的端口號了。

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

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

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

nc-p6666baidu.com80

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

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

假設(shè)用了6666端口的五元組去連接總是失敗,改用6667或其他端口卻能成功,你可以帶著這個(gè)信息去找找負(fù)責(zé)網(wǎng)絡(luò)的同事。

總結(jié)

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

當(dāng)路由表一個(gè)都匹配不上時(shí)會走默認(rèn)網(wǎng)關(guān)。當(dāng)匹配上多個(gè)的時(shí)候,會先看匹配長度,如果一樣就看管理距離,還一樣就看路徑成本。如果連路徑成本都一樣,那等價(jià)路徑。如果路由開啟了ECMP,那就可以同時(shí)利用這幾條路徑做傳輸。

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

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

開啟了ECMP的網(wǎng)絡(luò)鏈路中,TCP和ping命令可能走的路徑不同,甚至同樣是TCP,不同連接之間,走的路徑也不同,因此出現(xiàn)了連接時(shí)好時(shí)壞的問題,實(shí)在是走投無路了,可以考慮下是不是跟ECMP有關(guān)。

當(dāng)然,遇到問題多懷疑自己,要相信絕大部分時(shí)候真的跟ECMP無關(guān)。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • TCP
    TCP
    +關(guān)注

    關(guān)注

    8

    文章

    1353

    瀏覽量

    79055
  • Ping
    +關(guān)注

    關(guān)注

    0

    文章

    69

    瀏覽量

    15974
  • 命令
    +關(guān)注

    關(guān)注

    5

    文章

    683

    瀏覽量

    22011
  • TCP協(xié)議
    +關(guān)注

    關(guān)注

    1

    文章

    91

    瀏覽量

    12070

原文標(biāo)題:騰訊一面:能ping通,TCP就一定能連通嗎?

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

收藏 人收藏

    評論

    相關(guān)推薦

    dhcp服務(wù)器

    服務(wù)設(shè)置完了后,客戶電腦上得到服務(wù)器分配的ip地址但是網(wǎng)不通什么原因??!請高手指點(diǎn),聯(lián)系QQ279282417
    發(fā)表于 02-14 00:39

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

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

    dm8148網(wǎng)絡(luò)uboot環(huán)境下ping同,進(jìn)入系統(tǒng)卻ping不通??

    不知道什么原因造成的),在文件系統(tǒng)內(nèi)配置與主機(jī)在同一網(wǎng)斷,但是不能ping通主機(jī); 我的疑問是uboot下使用ping 的時(shí)候顯示active;并且tftp也
    發(fā)表于 06-23 05:33

    LPC1788TCP服務(wù)器ping成功

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

    為什么ping不通還能燒寫程序?

    大家好,我是一個(gè)菜鳥,剛學(xué)2440,我用CRT ping不通PC機(jī),卻能順利燒寫到nanflash,這是什么原因,怎樣解決ping不通
    發(fā)表于 06-17 22:59

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

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

    使用CH32V307+WCHNET實(shí)現(xiàn)webserver服務(wù)http請求無法訪問怎么解決?

    使用CH32V307+ WCHNET 實(shí)現(xiàn) webserver 服務(wù),加電后HTTP請求可以正常訪問,ping平通,
    發(fā)表于 09-14 07:06

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

    請問 CH32V307ping正常 但是 http請求少部分正常大部分請求超時(shí) ,用的是netlib,這個(gè)會是
    發(fā)表于 09-15 07:32

    ESP32 Web服務(wù)器可以向外部Rest API發(fā)起HTTP請求嗎?

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

    Java編程:發(fā)送HTTP請求服務(wù)器

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

    MCU沒有響應(yīng)服務(wù)器請求,NodeMCU HTTP服務(wù)器停止響應(yīng)

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

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

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

    使用NS1串口服務(wù)器HTTP模式上傳服務(wù)器數(shù)據(jù)

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

    服務(wù)器之間ping不通原因

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

    局域網(wǎng)ping不通原因有哪些

    使用 ping 命令測試兩臺計(jì)算機(jī)之間的連接時(shí),如果 ping 不通,可能存在多種原因。以下是一些可能導(dǎo)致局域網(wǎng) ping
    的頭像 發(fā)表于 10-14 15:03 ?3796次閱讀
    RM新时代网站-首页