网络数据包是网络层的协议数据单元（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、教育、制造业、跨国企业等行业领域。