进一步测试H3C WA7000系列几个AP的速度，目前非常无语，完全不达标！全面有问题！

有线网络是全双工模式，可以同时收发数据。而Wi-Fi是半双工的，设备在同一时间要么发送数据，要么接收数据，无法同时进行；Wi-Fi实际速率远低于协商速率，是半双工共享介质、繁重的协议开销、以及现实环境中的干扰和信号衰减共同导致的必然结果。所以，当发现Wi-Fi实际吞吐量大约只有协商速率的一半时，这通常是正常的。

留作补充用。

raido下面增加个option client fast-forwarding enable level 3测试下，使用ixchariot打流pair数量保持在30条以上，多测试个几分钟试试看

用户问题复盘：H3C WA7000 系列（WA7320i/WA7232/WA7226‑C）云模式胖 AP 测速异常
现象：5G‑160MHz 信道 36，终端协商 2882Mbps，单终端 1 米无遮挡、环境干扰很小；有线打流正常；iperf3‑R 反向 TCP 打流，无线→有线实际吞吐仅 1.3‑1.5Gbps，远低于预期；三台不同型号 AP 现象一致；组网极简，无 AC、交换机、路由器，AP 直连服务器网卡。
用户排除：半双工损耗、外部设备干扰；拒绝 400 / 经销商方案，希望社区技术人员交流实测数据。
1、基础概念区分：PHY 协商速率 vs TCP 实际吞吐量
2882Mbps 是802.11be 物理层协商速率，不是应用层 TCP 吞吐上限。Wi‑Fi 协议本身有大量帧头、ACK、控制帧、保护间隔，理论上单用户 TCP 能跑到 PHY 的 50‑70%，2882Mbps 理想单用户 TCP 理论上限约1440‑2016Mbps。
用户实测 1.3‑1.5Gbps 处于这个区间的下限；第三方 Tolly 测试报告中，同系列 5G‑160MHz 单用户 TCP 可到 2.2‑2.4Gbps，说明硬件具备更高吞吐能力，问题出在云（Cloud）模式固件转发路径、配置、测试手段、终端网卡的组合问题。
2、用户当前配置中几个关键点
工作模式：Cloud Mode 云胖 AP，不是 FIT+AC 模式；Cloud 模式和 FIT 模式转发代码路径不同，部分高级转发命令行为存在差异。
执行option client fast‑forwarding enable level 3/4：
该命令是radio 视图下 FIT 模式的快速转发优化；文档明确修改 level 后需要保存 + 重启 AP 才生效；云 Web 界面下直接下发这条命令，很多版本云模式下该特性支持有限，甚至不完整生效，这是高概率疑点。
WA7320i 部分子型号对该快速转发特性存在硬件适配限制，不是全系列 WA7000 全部完整支持 level4 级别转发。
端口配置：port access vlan 4094，所有上行口划到 VLAN4094；AP 自身管理 VLAN 与业务 VLAN 分离，云模式下 VLAN4094 作为业务接口，确认 AP 的三层接口 Vlan‑if4094 是否 UP，是否存在软转发隔离。
测试命令：iperf3 -s（服务器有线）；iperf3 -c ip -R（笔记本无线）
-R代表服务器发送、无线笔记本接收（下载方向）；Wi‑Fi7 网卡（Mac M5）的驱动、TCP 栈、TCP 窗口、拥塞控制算法会直接限制 TCP 吞吐；MacOS 在高速无线下 TCP 默认参数经常跑不满带宽，这是大量实测中复现的现象。
3、可复现的对照测试建议（不需要联系 400）
测试 A：iperf 参数修正（排除终端操作系统影响）
原命令是单流，高速无线单 TCP 流很难跑满空口。
bash
# 无线笔记本（客户端），多条并行流，增大TCP窗口，跳过慢启动，测试30s
iperf3 -c 10.40.94.2 -R -P4 -w2M -O3 -t30
# 再测正向（笔记本发，服务器收），对比上下行差异
iperf3 -c 10.40.94.2 -P4 -w2M -O3 -t30
现象观察：如果开多‑P 并行流后，总吞吐抬升到 1.8‑2.1Gbps，说明不是 AP 硬件瓶颈，是单 TCP 流受终端操作系统 TCP 栈限制；Mac 笔记本尤为明显。
测试 B：快速转发参数处理
把option client fast‑forwarding恢复 disable 关闭，保存配置，完整重启 AP 再复测；
疑点：Cloud 云胖模式下，高 level 快速转发开启后，部分固件版本会引入异常，反而降低吞吐，该命令主要是 FIT 受控场景调优，云模式不一定适配。
测试 C：切换 FIT 模式 + AC/Anchor‑AP 模式对比
把 AP 切回 FIT 瘦模式，用 Anchor‑AP（WA7000 自带虚拟 AC）管理该 AP，完全相同射频参数 160M‑36 信道，完全同一套笔记本、服务器、网线复测。
如果 FIT/Anchor‑AC 模式下，同样硬件可以跑到 2G+，说明Cloud 云胖镜像版本的转发路径存在性能短板，这属于固件版本问题，需要关注新版本云镜像 Release Note。
测试 D：确认射频实际运行状态
登录 AP 命令行，查看实际射频运行状态，确认没有自动降带宽：
shell
display wlan radio verbose
display wlan client verbose
重点确认：
实际工作带宽是否真正 160MHz，没有因为雷达检测自动回退 80M；
终端实际 MCS 速率、RX/TX 速率，确认协商不是虚假显示；
Channel‑busy 信道占用率，即使外部干扰小，AP 自身内部虚拟开销也会拉高 busy 值。
测试 E：更换 Windows 平台 Wi‑Fi7 网卡笔记本对比
MacOS 无线 TCP 吞吐普遍弱于 WindowsIntel/mediatek Wi‑Fi7 网卡，相同物理环境，交叉排除终端侧瓶颈。
4、两种可能性总结
终端 + 测试方法瓶颈：单 TCP 流、MacOS 系统 TCP 栈限制，是 1.3‑1.5Gbps 最常见原因；多并行流之后吞吐可以抬升。
Cloud 云胖 AP 镜像转发性能短板：相同硬件，FIT/Anchor‑AC 模式性能明显优于 Cloud 模式，说明当前 Cloud 固件版本无线‑有线转发存在瓶颈，等待后续固件迭代修复；WA7000 系列 Cloud 模式相比 FIT 模式，软件转发路径负担更大。
补充：有线打流正常，仅无线低，说明 AP 物理网口 PHY、网线没有问题；问题收敛在：射频芯片→AP 系统转发→云模式驱动 / 固件→终端网卡驱动 / TCP 栈这条路径。
5、社区交流征集点（对应用户诉求）
欢迎其他使用者补充自己 WA7000 系列 Wi‑Fi7 AP 实测数据，标注：
AP 型号、固件版本（Cloud / FIT 模式）
测试终端（网卡型号、操作系统）
5G 带宽（160M/80M）
iperf3 测试参数（单流 / 多流、‑R 是否开启）
得到的 TCP 吞吐结果

希腊奶  可以看检测报告 不过我也没有😂