網路丟包原因及解決方案
網路丟包是我們在使用ping對目站進行詢問時，資料包由於各種原因在通道中丟失的現象。ping 使用了ICMP 回送請求與回送回答報文。ICMP 回送請求報文是主機或路由器向一個特定的目的主機發出的詢問，收到此報文的機器必須給源主機發送 ICMP 回送回答報文。這種詢問報文用來測試目的站是否可到達以及瞭解其狀態。
許多時候，我們可能都會碰到網路連線時斷時續的故障現象，面對這種網路故障，不少網路管理員都會使用Ping命令對網路連通性進行測試，測試結果表明此時的網路傳輸線路資料丟包現象非常嚴重，那麼究竟是什麼因素導致了資料丟包現象比較嚴重呢?是連線線路接觸不穩定?是網路病毒?還是其他的潛在因素?
原因一：物理線路故障
網管員發現廣域網線路時通時斷， 發生這種情況時， 有可能是線路出現故障， 也可能是使用者方面的原因。為了分清是否是線路故障，可以做如下測試。
如果廣域網線路是通過路由器實現的，可以登入到路由器，通過擴充套件 ping 向對端路由器廣域網介面傳送大量的資料包進行測試。如果線路是通過三層交換機實現，可線上路兩端分別接一臺計算機，並將 IP 地址分別設為本端三層路由交換機的廣域網介面地址，使用 “ping 對端計算機地址 - t ”命令進行測試。
如果上述測試沒有發生丟包現象， 則說明線路運營商提供的線路是好的， 引起故障的原因在於使用者自身，需要進一步查詢。
如果上述測試發生丟包現象， 則說明故障是由線路供應商提供的線路引起的， 需要與線路供應商聯絡儘快解決問題。
由物理線路引起的丟包現象還有很多，如光纖連線問題，跳線沒有對準裝置介面，雙絞線及 RJ-45 接頭有問題等。另外，通訊線路受到隨機噪聲或者突發噪聲造成的資料報錯誤，射頻訊號的干擾和訊號的衰減等都可能造成資料包的丟失。我們可以藉助網路測試儀來檢查線路的質量。
原因二：裝置故障
裝置故障主要是指裝置硬體方面的故障，不包含軟體配置不當造成的丟包。如網絡卡是壞的，交換機的某個端口出現了物理故障，光纖收發器的電埠與網路裝置介面，或兩端裝置介面的雙工模式不匹配。
曾看過這樣的例子，一交換機埠的光纖模組故障造成的丟包現象， 該交換機在通訊一段時間後宕機，即不能通訊，重啟後恢復正常。在經過一段時間觀察後發現，某光纖模組存在問題，取一塊新的模組替換，一切正常。
究其原因，交換機會對所有接收到的資料包進行 CRC 錯誤檢測和長度校驗，將檢查出有錯誤的包丟棄，正確的包轉發出去。但這個過程中有些有錯誤的包在 CRC 錯誤檢測和長度校驗中都均未檢測出錯誤，這樣的包在轉發過程中不會被髮送出去，也不會被丟棄，它們將會堆積在動態快取中，永遠無法傳送出去，等到快取中堆積滿了，就會造成交換機宕機的現象。最終結果是，資料包無法到達目的主機。
原因三：網路擁塞
網路擁塞造成丟包率上升的原因很多，主要是路由器資源被大量佔用造成的。
如果發現網速慢， 並且丟包率呈現上升的情況， 這時應該 show process cpu 和 show process mem ，一般情況下發現 IP input process 佔用過多的資源。接下來可以檢查 fast switching 在大流量外出埠是否被禁用，如果是，則需要重新使用。
再看一下 Fast switching on the same interface是否被禁用，如一個介面配有多個網段並且這些網段間流量很大時，路由器工作在 process-switches 方式，這種情況下要在介面上執行命令“enable ip route-cache same- interface 。”
接下來，用 show interfaces 和 show interfaces switching 命令識別大量包進出的埠。一旦確認進入埠後，開啟 IP accounting on the outgoing interface 看其特徵，如果是攻擊，源地址會不斷變化但是目的地址不變，可以用命令 “access list ”暫時解決此類問題(最好在接近攻擊源的裝置上配置)，最終解決辦法是停止攻擊源。
應用中遇到的造成網路擁塞的情況還有很多， 如大量的 UDP 流量， 可以用解決 spoof attack 的步驟解決此問題。大量的組播流、廣播包穿越路由器，路由器配置了 IP NAT 並且有很多 DNS 包穿越路由器等。上述情況造成網路擁塞後，通訊雙方採取流量控制，丟棄不能傳輸的包。
原因四：MTU 配置不當
在關鍵裝置上MTU設定不當，也會造成網路丟包(乙太網：1500 位元組，IEEE 802.3/802.2 1492位元組)。檢視網路中關鍵裝置的 MTU 配置。
在瞭解瞭如何定位網路丟包的位置之後，網管需要進一步分析丟包發生的原因，以排除故障。開啟網路分析軟體以後，我們配置好網路檔案，選擇分析檔案之後，就可以開始分析了。
首先我們可以在圖表中新增利用率統計，可以看到，在14:38:05 之後，網路利用率突然升高，接近40% 。推薦利用率不高於15% ，當網路利用率超過了 30% ，就會產生1%的丟包，並且呈幾何倍數的增長。這個網路中，利用率高達 40%，肯定存在著嚴重的丟包現象。
瞭解了有丟包就會有 TCP 資料包重傳之後，網管可以在診斷中，找出 TCP 資料包重傳比較嚴重的主機。
如何確定網路丟包的存在
通常我們利用 PING x.x.x.x -t 這個命令來進行測試網路中是否存在丟包。
在上圖中可以看到，在本機上向 192.168.122.2 這個不存在的地址進行長時間 PING 的時候，傳送出去的 ICMP 包都丟失了，丟失率達到 100% 。即從本機到 192.168.122.2 這個實際不可達地址的路徑上存在丟包。
定位網路丟包的分析步驟
在網路丟包發生的情況下，使用者會明顯感受到網路速度變慢，這時候網管首先需要做的就是進行 PING X.X.X.X –t 來進行大致是哪個網段的診斷。在發現確實有丟失率存在的情況下，我們可以利用科來軟體進行進一步分析。
在分析之前，我們有必要學習一下前置知識。
TCP協議的特點之一就是保障資料傳輸的可靠性，即確保資料能夠正確完整傳輸。那麼TCP究竟是如何來保障的?可以看到，TCP 在傳輸時，有著傳輸確認—重傳機制，即傳送資料一方在傳輸資料時為每一個分段編制序列號( Sequence Number )，接收方會向傳送方傳送接收到分段資料的確認(Acknowledgment)，通過這種方式確認資料是否準確傳送，在無法確認某分段資料被準確傳送或確認某分段資料沒有被準確傳送時重新進行傳輸。
所以，在網路丟包發生的情況下，必定會有 TCP 資料包重傳的出現。
1. 解決方案
- 針對網路裝置故障：通過分段捕獲的方法，在網路中關鍵裝置的兩端，使用科來網路分析系統進行抓包，確定該裝置是否丟包，從而準確定位丟包裝置。
- 針對網路擁塞：在核心交換機上配置映象，使用科來網路分析系統抓包。
分析關鍵鏈路(一般是出口鏈路) 的流量佔用情況， 檢視網路利用率是否過高，每秒資料包是否過多，資料包大小分佈是否合理、TCP會話是否正常等。
當然最根本的方法就是限制使用者流量，就是針對每個上網的使用者進行流量控制，比如禁止訪問視訊網站和其他與工作內容無關的網站，同時又能針對每個使用者做出精準的流量限制，防止其對有限網路頻寬的過度佔用。
還可以針對一些流量做出服務質量保證( QOS)，比如可以將與工作關係比較大的流量：如網頁訪問、郵件流量等的流量優先順序提高，從而可以在一定程度上緩解網路擁塞，保證高優先順序業務可以優先得到轉發。 (治標不治本的方法)
2. 另外關於 ping IP 老是丟包的問題：
通常有以下幾種原因：
- 由於伺服器的 IIS 中運行了非法或者沒有獨立程序池的原因 , 找到這個站點 , 給他一個獨立的程序池 .
- 如果伺服器上捆綁了一個主機頭為空的站點的話 , 容易造成這個問題 , 最好把這個主機為空的站點給刪除了 , 或者把這個站點的程序池給獨立起來 , 就可以解決問題。
- 由於對伺服器的頻寬和流量限制的太低問題 , 一般有一些機房的IDC服務商為了獲得更多的託管的使用者 , 十分的苛刻的限制使用者託管的伺服器 , 造成流出去的十分少 , 請求的多 , 就造成丟包問題。
- 由於交換機的交換口的問題：首先使用 Ping 命令測試，發現不定時的有資料包丟失的現象，初步認為是物理層的原因。重做網線的 RJ45頭後，故障依舊，換根網線也不行。懷疑是網絡卡介面或者交換機埠的問題。經檢視網絡卡驅動無誤，網絡卡介面也沒有任何異常。再檢視交換機埠， 發現與伺服器連線的交換 機埠工作指示燈在綠與黃之間閃爍， 這說明埠工作不正常。使用超級終端登入交換機，檢視此埠的引數，發現此埠是工作在100Mbyte/s全雙工模式，回到伺服器前檢視本地連線狀態，網絡卡是工作在 10Mbyte/s 全雙工模式。 交換機的埠與網絡卡的傳輸速率和雙工模式不一致。將網絡卡工作模式改為 100Mbyte/s 全雙工模式後測試，一切正常，故障解決。
- 由於被 DDOS或者洪水猛獸攻擊造成的大量丟包 , 這個時候沒有什麼好說的 , 趕快加上硬體防火牆吧
3. 總之一般排除故障的方法是：
- 頻寬有沒有佔滿
- 換個交換機埠試試
- 換個網線試試
- 網絡卡及主機板驅動是不是沒裝 ( 一般不會是這個問題 )
- 交換機上設定是100M的還是10M的 , 與機器設定成一樣的