網絡數據包是網絡層的協議數據單元（PDU）。我們所有人都有這樣一個概念：通過像Internet這樣的TCP /
IP網絡傳輸數據，需要將數據分解成包含相關應用程序數據和標頭的小數據包（通常小于1500個字節）。路由器將這些數據包從源轉發到目標，并且數據封裝使數據能夠遍歷TCP
/ IP堆棧。
當此過程失敗并出現數據包丟失時，就會出現問題。丟包是某些數據包無法到達其目的地時的情況。
如果不加以檢查，未到達目的地的數據包很快就會成為企業的主要問題。當應用程序需要實時數據流時，即使丟失量相對較小也會造成重大問題。例如，Skype for
Business連接必須在任何200毫秒間隔內將丟包率保持在10％以下，在任何15秒間隔內將丟包率保持在1％以下。這沒有太大的出錯空間，并且其他關鍵任務VoIP（網際協議語音）和網真應用也存在類似的要求，這使得減輕丟包成為企業的首要任務。
讓我們更深入地研究數據包丟失，以及如何在企業WAN上減少數據包丟失。

什么是可接受的丟包？
在討論WAN優化時，“什么是可接受的丟包水平？”問題出現了很多。我不喜歡將任何級別的丟包都標記為“可以接受”，盡管這里沒有大的問題。根據經驗，超過約1％的隨機數據包丟失會明顯降低VoIP或視頻通話的質量。隨著數據包丟失的增加，呼叫變得混亂不堪，變得更加機械化，視頻切入和切出，最終連接中斷。
UCaaS（統一通信即服務）普及率的激增導致數據包丟失問題加重。在許多情況下，公共Internet太不可靠了，剩下的只有MPLS（多協議標簽交換）。除了丟包以外，UCaaS還需要考慮延遲，抖動和安全性。
檢測丟包
數據包丟失是通過測量丟失的數據包與發送的總數據包之比來計算的。例如，在下面的ping輸出中，我們看到1/5的數據包未到達catonetworks.com，造成總共20％的數據包丟失。
ping catonetworks.com -t
使用32個字節的數據對catonetworks.com [203.0.113.2]進行ping：
來自203.0.113.2的答復：字節= 32時間= 105ms TTL = 56
來自203.0.113.2的答復：字節= 32時間= 136ms TTL = 56
來自203.0.113.2的答復：字節= 32時間= 789ms TTL = 56
來自203.0.113.2的回復：字節= 32時間= 410ms TTL = 56
請求超時。
203.0.113.2的Ping統計信息：
數據包：已發送= 5，已接收= 4，丟失= 1（丟失20％），
大約往返時間（以毫秒為單位）：
最小值= 105ms，最大值= 789ms，平均值= 360ms
通常用于檢測數據包丟失的工具包括：
ping。這是檢測數據包丟失的最簡單工具，可以有效地進行臨時故障排除。但是，由于許多防火墻阻止了ICMP（Internet控制消息協議）并且它的優先級較低，因此ping并不總是足夠的。
tracert / traceroute。tracert（Windows）和traceroute（* nix）幫助確定丟包開始的特定躍點。
網絡監控軟件。SolarWinds網絡性能監視器，PRTG，Nagios和Zabbix等軟件應用程序都可以幫助大規模監視數據包丟失。
丟包的原因
檢測數據包丟失是一回事，而知道如何識別根本原因則是另一回事。丟包的常見原因包括：
CPU負載較重的路由器。路由器具有有限的計算能力，如果CPU負載過重，則會丟棄數據包。
安全漏洞。惡意軟件或拒絕服務（DoS）攻擊會消耗大量帶寬和資源，從而導致數據包丟失。
配置錯誤。通常，網絡中斷的原因是人為錯誤。丟包也是如此。錯誤配置的交換機，路由器，服務器或防火墻可能導致丟包。教科書示例使用需要全雙工的半雙工，反之亦然。
網絡擁塞。網絡上的流量越多，數據包到達目的地之前被丟棄的可能性就越大。
硬件故障。不良的電纜，路由器，服務器和交換機都可能導致數據包丟失和間歇性連接。
軟件錯誤。數據包丟失可能與給定軟件或固件中的錯誤有關，更新可能會解決此問題。
Vecloud在全球的數據中心節點30個，POP節點超過200個，服務的大客戶超過300個，涉及金融、互聯網、游戲、AI、教育、制造業、跨國企業等行業領域。

總結

以上是生活随笔為你收集整理的缓解数据包丢失对WAN的影响是当务之急—Vecloud微云的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。