我在现场遇到了同样的问题，安装了 40 个 AP 并由无线控制器控制。他们在网站的任何地方拍照并自动上传到 FTP 服务器上，有些地方运行良好，而其他地方上传时间很长。我使用了一个非常有用的 Android 应用程序，称为WiFi Speed Test，它模拟您的手机和其他远程 PC 之间的上传和下载文件，并向您展示此文件传输的上传和下载速度。

关于那些AP的问题是AP输出功率，需要在控制器上自行调整

如果您想绘制数据包丢失百分比的形状，您可以使用出色的应用程序ping 绘图仪

• 测试丢包的一种方法是ping，例如，您可以向 IP 地址发送大量 ping，这样您就可以找到失败的响应并估计丢包。以下示例向您指定的地址发送一组 40 个 ping。

Ping -n 40（IP地址或域名）

• 另一个选项可以是traceroute，虽然输出不会显示丢包，但会显示路径上响应缓慢的路由器，这将帮助您找到可能发生丢包的位置。

• 或测试一些监控工具，例如：IP-SLA 或 pingplotter ( http://pingplotter.com/index.php )

正如@YLearn 指出的那样：您必须区分帧丢失（在无线 MAC 层）和数据包丢失（IP 层）。

IEEE 802.11 对无线链路有一个重传方案，以补偿与有线网络相比的高帧丢失率。只有当一个帧在无线链路上多次未能被确认时，封装在该帧中的数据包才会丢失。重传次数由供应商特定算法调整。

在 linux 系统上，您可以使用例如iwconfig获取由于无线链路上过度重试而导致的丢失数据包数：

$ /sbin/iwconfig wlan0
wlan0     IEEE 802.11abg  ESSID:"XXX"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: aa:bb:cc:dd:ee:ff
          Bit Rate=54 Mb/s   Tx-Power=15 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=62/70  Signal level=-48 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:26  Invalid misc:1830   Missed beacon:0

因此，如果您对在无线链路的上行链路（笔记本电脑→接入点）上丢失的 IP 数据包的数量感兴趣，那么您正在寻找Tx 过度重试。

由于您想测量来自客户端的数据包丢失，我建议您运行ping IP_address -i 0.001 -M do -n -s 1472并尝试尽可能地强调链接。

• 该-i选项大大缩短了间隔。
• 该-M do选项设置不要分段位，这是测试 MTU 所必需的。
• 该-n选项禁用 DNS 解析，这对于测试数据包丢失是不必要的。
• 该-s选项设置数据包大小。

如果Frag needed and DF set打印了包含的消息，则 MTU 小于 1500 字节，或者实际上存在数据包丢失。

因为ping -i 0.001打印很多行，所以使用该-q选项也很方便。因此，当 ping 停止时，您会得到一个摘要。或者，您可以使用该-c选项来限制 ping 发送的数据包数量。

通过强调链接，我的意思是您应该尝试通过使用除 ping 之外的其他工具来创建尽可能多的吞吐量。这增加了往返时间，并允许您测试网络，就好像办公室里的每个人都在工作一样。即使是最快的 ping 测试也不会显示性能问题。可能存在无法处理特定负载的交换机或路由器，因此可能导致不可接受的延迟甚至丢包。