如何测试UDP数据包的丢包率和延迟

iperf也可以用于UDP数据包吞吐量、丢包率和延迟指标，但是由于UDP协议衫斗悉是一个非面向连接的轻量级传输协议，并且不提供可靠的数据传输服务，因此对UDP应用的关注点不是传输数据有多快，而是它的丢包率和延时指标。通过iperf的“-u”参数即可测试UDP应用的传输性能，下图测试的是在iperf客户端传输100MB的UDP数据包的输出结果：

iperf传输100MB的UDP数据包的输出结果

这个输出结果过于简单，要了解更详细的UDP丢包和延时信息，可以在销升iperf服务端查看，因为在客户端执行传输测试的同时，服务端也会同时显示传输状态，如下图所示。

iperf服务端显示的UDP传输状态

在这个输出中，详细记录了在传输过程中，每个阶段的传输延时和丢包率，在UDP应用中随着传输数据的增大，丢包率和延时也或乎随之增加。对于延时和丢包可以通过改变应用程序来缓解或修复，例如视频流应用，可以通过缓存数据的方式而可以容忍更大的延时。

当电脑A向电脑B发送UDP数据的时候，电脑B可直接向电脑A回发数据。拓扑如下：

在IPV4资源紧张的大背景下诞生的NAT技术缓解了地址紧张的局面，但是也带来了大量设备不能直接访问公网的问题。

这时电脑A不能和电脑B愉快的发起TCP/UDP请求。处于不同局域网的设备不能直接互相访问，即电脑A和电脑B处于不同的局域网，所以他们互相都不能直接访问。

在这种情况下，如果电脑A主动发起UDP请求，则双方可以互相通信，其原理如下：

在链接建立的生命周期中，内网的端口和外网的端口通过路由器建立起了映射，达到地址转换/端口转换的效果。这种映射方式，对于TCP这种有链接的协议来说，很容易确定映射的生命周期。但是对于UDP来说，就很困难启宽了。还好，路由器厂家在做NAT的时候想到了这一点，在UDP从内网发送的时刻开始，为UDP数据回送保留了映射，这个时间根据路由器的厂家不同，保留映射数秒到数分钟不等。这个时间叫做Session（会话）保持时间。

我们采用以下方扒衫法验证数据回发：

如果Session会保持，则电脑A会收到电脑B返回的数据包。

为了实现以上效果，我们使用了两段Python程序来做这个实验。

局域网内电脑A的程序，会向电脑B发送“Hello”，然后静等数据返回。

具有公网IP地址的电脑B的程序（IP地址略去），接收到数据后会立刻回发“Hi”：

通常Session保持会持续一段时间，如何测试这段时间有多长呢？我们悄此亮采用以下方法验证：

电脑A的程序保持不变，电脑B的程序变化如下：

最终作者的网络环境测试的最大延迟时间为5分钟。

通过这个实验，说明网络设备在NAT/NAPT时对UDP通信已经做优化，只要延迟时间不是太长，很大概率可以将回传数据包成功送达。更有厂家对UDP Session保持时间做优化，在端口资源不紧张时长期保持端口映射。

---