成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

網(wǎng)絡(luò)丟包原因及解決方案

運(yùn)維 網(wǎng)絡(luò)運(yùn)維
許多時(shí)候,我們可能都會碰到網(wǎng)絡(luò)連接時(shí)斷時(shí)續(xù)的故障現(xiàn)象,那么究竟是什么因素導(dǎo)致了數(shù)據(jù)丟包現(xiàn)象比較嚴(yán)重呢?是連接線路接觸不穩(wěn)定?是網(wǎng)絡(luò)病毒?還是其他的潛在因素?

網(wǎng)絡(luò)丟包是我們在使用ping對目站進(jìn)行詢問時(shí),數(shù)據(jù)包由于各種原因在信道中丟失的現(xiàn)象。ping 使用了ICMP 回送請求與回送回答報(bào)文。ICMP 回送請求報(bào)文是主機(jī)或路由器向一個(gè)特定的目的主機(jī)發(fā)出的詢問,收到此報(bào)文的機(jī)器必須給源主機(jī)發(fā)送 ICMP 回送回答報(bào)文。這種詢問報(bào)文用來測試目的站是否可到達(dá)以及了解其狀態(tài)。

網(wǎng)絡(luò)丟包

許多時(shí)候,我們可能都會碰到網(wǎng)絡(luò)連接時(shí)斷時(shí)續(xù)的故障現(xiàn)象,面對這種網(wǎng)絡(luò)故障,不少網(wǎng)絡(luò)管理員都會使用Ping命令對網(wǎng)絡(luò)連通性進(jìn)行測試,測試結(jié)果表明此時(shí)的網(wǎng)絡(luò)傳輸線路數(shù)據(jù)丟包現(xiàn)象非常嚴(yán)重,那么究竟是什么因素導(dǎo)致了數(shù)據(jù)丟包現(xiàn)象比較嚴(yán)重呢?是連接線路接觸不穩(wěn)定?是網(wǎng)絡(luò)病毒?還是其他的潛在因素?

原因一:物理線路故障

網(wǎng)管員發(fā)現(xiàn)廣域網(wǎng)線路時(shí)通時(shí)斷, 發(fā)生這種情況時(shí), 有可能是線路出現(xiàn)故障, 也可能是用戶方面的原因。為了分清是否是線路故障,可以做如下測試。

如果廣域網(wǎng)線路是通過路由器實(shí)現(xiàn)的,可以登錄到路由器,通過擴(kuò)展 ping 向?qū)Χ寺酚善鲝V域網(wǎng)接口發(fā)送大量的數(shù)據(jù)包進(jìn)行測試。如果線路是通過三層交換機(jī)實(shí)現(xiàn),可在線路兩端分別接一臺計(jì)算機(jī),并將 IP 地址分別設(shè)為本端三層路由交換機(jī)的廣域網(wǎng)接口地址,使用 “ping 對端計(jì)算機(jī)地址 - t ”命令進(jìn)行測試。

如果上述測試沒有發(fā)生丟包現(xiàn)象, 則說明線路運(yùn)營商提供的線路是好的, 引起故障的原因在于用戶自身,需要進(jìn)一步查找。

如果上述測試發(fā)生丟包現(xiàn)象, 則說明故障是由線路供應(yīng)商提供的線路引起的, 需要與線路供應(yīng)商聯(lián)系盡快解決問題。

由物理線路引起的丟包現(xiàn)象還有很多,如光纖連接問題,跳線沒有對準(zhǔn)設(shè)備接口,雙絞線及 RJ-45 接頭有問題等。另外,通信線路受到隨機(jī)噪聲或者突發(fā)噪聲造成的數(shù)據(jù)報(bào)錯(cuò)誤,射頻信號的干擾和信號的衰減等都可能造成數(shù)據(jù)包的丟失。我們可以借助網(wǎng)絡(luò)測試儀來檢查線路的質(zhì)量。

原因二:設(shè)備故障

設(shè)備故障主要是指設(shè)備硬件方面的故障,不包含軟件配置不當(dāng)造成的丟包。如網(wǎng)卡是壞的,交換機(jī)的某個(gè)端口出現(xiàn)了物理故障,光纖收發(fā)器的電端口與網(wǎng)絡(luò)設(shè)備接口,或兩端設(shè)備接口的雙工模式不匹配。

曾看過這樣的例子,一交換機(jī)端口的光纖模塊故障造成的丟包現(xiàn)象, 該交換機(jī)在通信一段時(shí)間后死機(jī),即不能通信,重啟后恢復(fù)正常。在經(jīng)過一段時(shí)間觀察后發(fā)現(xiàn),某光纖模塊存在問題,取一塊新的模塊替換,一切正常。

究其原因,交換機(jī)會對所有接收到的數(shù)據(jù)包進(jìn)行 CRC 錯(cuò)誤檢測和長度校驗(yàn),將檢查出有錯(cuò)誤的包丟棄,正確的包轉(zhuǎn)發(fā)出去。但這個(gè)過程中有些有錯(cuò)誤的包在 CRC 錯(cuò)誤檢測和長度校驗(yàn)中都均未檢測出錯(cuò)誤,這樣的包在轉(zhuǎn)發(fā)過程中不會被發(fā)送出去,也不會被丟棄,它們將會堆積在動態(tài)緩存中,永遠(yuǎn)無法發(fā)送出去,等到緩存中堆積滿了,就會造成交換機(jī)死機(jī)的現(xiàn)象。最終結(jié)果是,數(shù)據(jù)包無法到達(dá)目的主機(jī)。

原因三:網(wǎng)絡(luò)擁塞

網(wǎng)絡(luò)擁塞造成丟包率上升的原因很多,主要是路由器資源被大量占用造成的。

如果發(fā)現(xiàn)網(wǎng)速慢, 并且丟包率呈現(xiàn)上升的情況, 這時(shí)應(yīng)該 show process cpu 和 show process mem ,一般情況下發(fā)現(xiàn) IP input process 占用過多的資源。接下來可以檢查 fast switching 在大流量外出端口是否被禁用,如果是,則需要重新使用。

再看一下 Fast switching on the same interface是否被禁用,如一個(gè)接口配有多個(gè)網(wǎng)段并且這些網(wǎng)段間流量很大時(shí),路由器工作在 process-switches 方式,這種情況下要在接口上執(zhí)行命令“enable ip route-cache same- interface 。”

接下來,用 show interfaces 和 show interfaces switching 命令識別大量包進(jìn)出的端口。一旦確認(rèn)進(jìn)入端口后,打開 IP accounting on the outgoing interface 看其特征,如果是攻擊,源地址會不斷變化但是目的地址不變,可以用命令 “access list ”暫時(shí)解決此類問題(最好在接近攻擊源的設(shè)備上配置),最終解決辦法是停止攻擊源。

應(yīng)用中遇到的造成網(wǎng)絡(luò)擁塞的情況還有很多, 如大量的 UDP 流量, 可以用解決 spoof attack 的步驟解決此問題。大量的組播流、廣播包穿越路由器,路由器配置了 IP NAT 并且有很多 DNS 包穿越路由器等。上述情況造成網(wǎng)絡(luò)擁塞后,通信雙方采取流量控制,丟棄不能傳輸?shù)陌?/p>

原因四:MTU 配置不當(dāng)

在關(guān)鍵設(shè)備上MTU設(shè)置不當(dāng),也會造成網(wǎng)絡(luò)丟包(以太網(wǎng):1500 字節(jié),IEEE 802.3/802.2 1492字節(jié))。查看網(wǎng)絡(luò)中關(guān)鍵設(shè)備的 MTU 配置。

在了解了如何定位網(wǎng)絡(luò)丟包的位置之后,網(wǎng)管需要進(jìn)一步分析丟包發(fā)生的原因,以排除故障。打開網(wǎng)絡(luò)分析軟件以后,我們配置好網(wǎng)絡(luò)檔案,選擇分析檔案之后,就可以開始分析了。

首先我們可以在圖表中添加利用率統(tǒng)計(jì),可以看到,在14:38:05 之后,網(wǎng)絡(luò)利用率突然升高,接近40% 。推薦利用率不高于15% ,當(dāng)網(wǎng)絡(luò)利用率超過了 30% ,就會產(chǎn)生1%的丟包,并且呈幾何倍數(shù)的增長。這個(gè)網(wǎng)絡(luò)中,利用率高達(dá) 40%,肯定存在著嚴(yán)重的丟包現(xiàn)象。

了解了有丟包就會有 TCP 數(shù)據(jù)包重傳之后,網(wǎng)管可以在診斷中,找出 TCP 數(shù)據(jù)包重傳比較嚴(yán)重的主機(jī)。

如何確定網(wǎng)絡(luò)丟包的存在

通常我們利用 PING x.x.x.x -t 這個(gè)命令來進(jìn)行測試網(wǎng)絡(luò)中是否存在丟包。

在上圖中可以看到,在本機(jī)上向 192.168.122.2 這個(gè)不存在的地址進(jìn)行長時(shí)間 PING 的時(shí)候,發(fā)送出去的 ICMP 包都丟失了,丟失率達(dá)到 100% 。即從本機(jī)到 192.168.122.2 這個(gè)實(shí)際不可達(dá)地址的路徑上存在丟包。

定位網(wǎng)絡(luò)丟包的分析步驟

在網(wǎng)絡(luò)丟包發(fā)生的情況下,用戶會明顯感受到網(wǎng)絡(luò)速度變慢,這時(shí)候網(wǎng)管首先需要做的就是進(jìn)行 PING X.X.X.X –t 來進(jìn)行大致是哪個(gè)網(wǎng)段的診斷。在發(fā)現(xiàn)確實(shí)有丟失率存在的情況下,我們可以利用科來軟件進(jìn)行進(jìn)一步分析。

在分析之前,我們有必要學(xué)習(xí)一下前置知識。

TCP協(xié)議的特點(diǎn)之一就是保障數(shù)據(jù)傳輸?shù)目煽啃裕创_保數(shù)據(jù)能夠正確完整傳輸。那么TCP究竟是如何來保障的?可以看到,TCP 在傳輸時(shí),有著傳輸確認(rèn)—重傳機(jī)制,即發(fā)送數(shù)據(jù)一方在傳輸數(shù)據(jù)時(shí)為每一個(gè)分段編制序列號( Sequence Number ),接收方會向發(fā)送方發(fā)送接收到分段數(shù)據(jù)的確認(rèn)(Acknowledgment),通過這種方式確認(rèn)數(shù)據(jù)是否準(zhǔn)確傳送,在無法確認(rèn)某分段數(shù)據(jù)被準(zhǔn)確傳送或確認(rèn)某分段數(shù)據(jù)沒有被準(zhǔn)確傳送時(shí)重新進(jìn)行傳輸。

所以,在網(wǎng)絡(luò)丟包發(fā)生的情況下,必定會有 TCP 數(shù)據(jù)包重傳的出現(xiàn)。

1. 解決方案

  • 針對網(wǎng)絡(luò)設(shè)備故障:通過分段捕獲的方法,在網(wǎng)絡(luò)中關(guān)鍵設(shè)備的兩端,使用科來網(wǎng)絡(luò)分析系統(tǒng)進(jìn)行抓包,確定該設(shè)備是否丟包,從而準(zhǔn)確定位丟包設(shè)備。
  • 針對網(wǎng)絡(luò)擁塞:在核心交換機(jī)上配置鏡像,使用科來網(wǎng)絡(luò)分析系統(tǒng)抓包。

分析關(guān)鍵鏈路(一般是出口鏈路) 的流量占用情況, 查看網(wǎng)絡(luò)利用率是否過高,每秒數(shù)據(jù)包是否過多,數(shù)據(jù)包大小分布是否合理、TCP會話是否正常等。

當(dāng)然最根本的方法就是限制用戶流量,就是針對每個(gè)上網(wǎng)的用戶進(jìn)行流量控制,比如禁止訪問視頻網(wǎng)站和其他與工作內(nèi)容無關(guān)的網(wǎng)站,同時(shí)又能針對每個(gè)用戶做出精準(zhǔn)的流量限制,防止其對有限網(wǎng)絡(luò)帶寬的過度占用。

還可以針對一些流量做出服務(wù)質(zhì)量保證( QOS),比如可以將與工作關(guān)系比較大的流量:如網(wǎng)頁訪問、郵件流量等的流量優(yōu)先級提高,從而可以在一定程度上緩解網(wǎng)絡(luò)擁塞,保證高優(yōu)先級業(yè)務(wù)可以優(yōu)先得到轉(zhuǎn)發(fā)。 (治標(biāo)不治本的方法)

2. 另外關(guān)于 ping IP 老是丟包的問題:

通常有以下幾種原因:

  • 由于服務(wù)器的 IIS 中運(yùn)行了非法或者沒有獨(dú)立進(jìn)程池的原因 , 找到這個(gè)站點(diǎn) , 給他一個(gè)獨(dú)立的進(jìn)程池 .
  • 如果服務(wù)器上捆綁了一個(gè)主機(jī)頭為空的站點(diǎn)的話 , 容易造成這個(gè)問題 , 最好把這個(gè)主機(jī)為空的站點(diǎn)給刪除了 , 或者把這個(gè)站點(diǎn)的進(jìn)程池給獨(dú)立起來 , 就可以解決問題。
  • 由于對服務(wù)器的帶寬和流量限制的太低問題 , 一般有一些機(jī)房的IDC服務(wù)商為了獲得更多的托管的用戶 , 十分的苛刻的限制用戶托管的服務(wù)器 , 造成流出去的十分少 , 請求的多 , 就造成丟包問題。
  • 由于交換機(jī)的交換口的問題:首先使用 Ping 命令測試,發(fā)現(xiàn)不定時(shí)的有數(shù)據(jù)包丟失的現(xiàn)象,初步認(rèn)為是物理層的原因。重做網(wǎng)線的 RJ45頭后,故障依舊,換根網(wǎng)線也不行。懷疑是網(wǎng)卡接口或者交換機(jī)端口的問題。經(jīng)查看網(wǎng)卡驅(qū)動無誤,網(wǎng)卡接口也沒有任何異常。再查看交換機(jī)端口, 發(fā)現(xiàn)與服務(wù)器連接的交換 機(jī)端口工作指示燈在綠與黃之間閃爍, 這說明端口工作不正常。使用超級終端登錄交換機(jī),查看此端口的參數(shù),發(fā)現(xiàn)此端口是工作在100Mbyte/s全雙工模式,回到服務(wù)器前查看本地連接狀態(tài),網(wǎng)卡是工作在 10Mbyte/s 全雙工模式。 交換機(jī)的端口與網(wǎng)卡的傳輸速率和雙工模式不一致。將網(wǎng)卡工作模式改為 100Mbyte/s 全雙工模式后測試,一切正常,故障解決。
  • 由于被 DDOS或者洪水猛獸攻擊造成的大量丟包 , 這個(gè)時(shí)候沒有什么好說的 , 趕快加上硬件防火墻吧

3. 總之一般排除故障的方法是:

  • 帶寬有沒有占滿
  • 換個(gè)交換機(jī)端口試試
  • 換個(gè)網(wǎng)線試試
  • 網(wǎng)卡及主板驅(qū)動是不是沒裝 ( 一般不會是這個(gè)問題 )
  • 交換機(jī)上設(shè)置是100M的還是10M的 , 與機(jī)器設(shè)置成一樣的
責(zé)任編輯:趙寧寧 來源: 廈門微思網(wǎng)絡(luò)
相關(guān)推薦

2019-05-22 09:51:28

網(wǎng)絡(luò)故障

2022-05-26 16:51:07

網(wǎng)絡(luò)丟包網(wǎng)絡(luò)故障網(wǎng)絡(luò)

2011-05-24 11:26:11

2009-07-22 17:37:06

ASP.NET Ses

2024-11-08 13:47:35

中文亂碼配置

2010-08-27 14:35:37

IEFirefox兼容

2011-08-22 15:31:51

SQL Servermssqlserver數(shù)據(jù)庫復(fù)制

2022-08-12 13:26:14

內(nèi)聯(lián)崩潰TV 端插件化

2010-12-24 12:49:39

2020-03-05 09:09:18

緩存原因方案

2023-12-01 15:58:00

Kubernetes集群DevOps

2024-08-05 10:40:58

2013-02-27 10:39:41

網(wǎng)絡(luò)丟包故障

2009-10-27 15:35:08

2009-07-31 16:47:53

網(wǎng)絡(luò)線纜定位

2010-07-29 15:56:04

FlexSocket

2019-10-08 16:05:19

Redis數(shù)據(jù)庫系統(tǒng)

2025-03-25 01:00:00

2010-04-26 16:31:09

Oracle SQL

2025-03-25 08:20:00

Linux虛擬內(nèi)存系統(tǒng)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號

主站蜘蛛池模板: 在线国产一区二区 | 99国产视频| 亚洲成人动漫在线观看 | 日韩在线免费视频 | 久久一区二区三区四区 | 91在线中文字幕 | 精品一区二区三区四区五区 | 精品久久久久一区二区国产 | 亚洲一区av在线 | 91精品国产91久久久久久最新 | 香蕉一区 | 亚洲男女激情 | 久久国产亚洲 | www.久久99 | 91在线视频观看 | 国产91av视频在线观看 | 香蕉久久网 | 在线观看免费毛片 | 久久久女女女女999久久 | 亚洲欧美在线观看视频 | 噜噜噜噜狠狠狠7777视频 | 爱高潮www亚洲精品 中文字幕免费视频 | 91免费在线 | 综合中文字幕 | 黄色国产大片 | 国产精品久久久久久久久久久久午夜片 | 99re6在线视频精品免费 | 久久精品日产第一区二区三区 | 国产99久久精品一区二区永久免费 | av国产在线观看 | 无码日韩精品一区二区免费 | 日韩中文字幕免费在线 | 亚洲一区视频在线 | 久久99精品久久久久久秒播九色 | 一区二区三区免费在线观看 | 中文字幕精品一区二区三区精品 | 国产乱肥老妇国产一区二 | 国产高清视频一区二区 | 久久久久综合 | 成人免费观看男女羞羞视频 | 国产成人在线视频 |