V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
OmoineMie
V2EX  ›  宽带症候群

求助 WiFi 跑不满宽带是什么问题

  •  
  •   OmoineMie · 18 小时 55 分钟前 · 599 次点击

    路由器是软路由,ap 是 ax3000t ,笔记本是 AX210 网卡,NAS 是 2.5G 网卡,路由器、NAS 、ap 是连在交换机上的,宽带 500 兆。

    1. 笔记本通过有线连接交换机测试外网速度大概 700 兆
    2. 笔记本 WIFI 通过 iperf3 测试和软路由之间的局域网速度,大概 900 兆
    3. 笔记本 WIFI 通过 iperf3 测试和 NAS 之间的局域网速度,大概 900 兆
    4. 笔记本 WiFi 测速外网速度只有 450 兆,其他手机测速也是这个速度 问题出在哪?
    12 条回复    2025-09-04 11:17:54 +08:00
    OmoineMie
        1
    OmoineMie  
    OP
       18 小时 40 分钟前
    核心原因:数据包在 AP 内部的路径不同
    你的 AX3000T 虽然工作在 AP 模式,但它内部仍然有多个“数据通道”。这个测试证明了:“有线端口之间的交换” 和 “无线到有线端口的转发” 走的是两条完全不同的处理路径。

    路径一:有线端口 -> 有线端口 (高速路径)

    你刚做的测试: 笔记本用网线连接到 AP 的 LAN 口。当数据包从笔记本的网卡进入 AP 的 LAN 口,其目的地是上联交换机(然后去往软路由和互联网),AP 内部的交换芯片会直接处理这个数据包。

    处理方式: 这是一个纯粹的、由硬件完成的二层交换。交换芯片的效率极高,几乎不存在性能瓶颈。这个过程不需要 AP 的 CPU 参与,所以速度完全不受影响,能跑满 700 兆。

    路径二:无线端口 -> 有线端口 (低速路径)

    你之前 WiFi 测速的测试: 数据从笔记本的 WiFi 网卡发出,被 AP 的天线接收。AP 需要把这个无线信号转换成有线数据帧,然后从其 LAN 口发送出去。

    处理方式: 这个“转换和转发”的过程,在理想的 AP 模式下,也应该由专门的硬件加速器处理。但根据你之前的测试结果( 450Mbps vs 900Mbps ),很明显,当数据包来自无线端且目的地是外网( WAN 方向)时,AP 的驱动/固件错误地将其送交了 CPU 进行软件处理,而没有走高效的硬件加速路径。

    为什么会有这种区别?
    这几乎是消费级路由器 AP 模式下的一个通病或设计取舍。厂商的固件和驱动主要是为“路由模式”优化的。当切换到 AP 模式时:

    有线交换功能通常能保持完整的硬件加速,因为它是由独立的交换芯片负责的,比较“傻瓜式”,不受模式影响。

    无线转发功能的驱动更为复杂。很可能在 AP 模式下,负责处理无线数据并决定其走向的驱动代码存在 Bug 或为了兼容性而关闭了某些硬件加速特性,导致所有要去 WAN 口的数据包都被打上标记,送到了低效的 CPU 处理队列中。

    一个更精确的比喻
    把你的 AP 想象成一个有两个入口的快递分拣中心:

    入口 A (有线入口): 这是一个全自动的高速分拣线。快递(数据包)一上来,机器就自动识别并把它扔到通往“交换机”的传送带上,速度极快。(这就是你新测试的情况)

    入口 B (无线入口): 这里本来也有一条自动分拣线,但它出了点故障。对于目的地是“市内”(内网)的快递,它能正常自动分拣。但对于所有目的地是“外地”(外网)的快递,系统却错误地把它全部送到了旁边的一个小房间里,需要人工( CPU ) 查看地址后再手动扔到传送带上,速度自然就慢下来了。(这就是你之前 WiFi 测速的情况)

    结论
    你这个新的测试非常棒,它排除了所有外部因素,将问题 100%锁定在了 AX3000T 设备本身在 AP 模式下“无线转发至 WAN 方向”的性能瓶颈上。

    总结一下:

    AP 的有线交换功能是正常的,没毛病。

    AP 的无线功能本身也是正常的,内网传输速度可达 900Mbps 就是证明。

    问题 solely 在于:当数据来自无线客户端且需要送往互联网时,AX3000T 的固件/驱动无法高效处理,导致了性能折半。

    因此,我之前给出的解决方案依然有效且是最优解:将网络拓扑改为让 AX3000T 工作在路由模式,从而完全启用其硬件 NAT 加速,让无线数据也能享受到“高速公路”的待遇,问题即可迎刃而解
    OmoineMie
        2
    OmoineMie  
    OP
       18 小时 37 分钟前
    这个回答一针见血,deepseek 真的吊打 grok ,gemini ,chatgpt
    datocp
        3
    datocp  
       18 小时 18 分钟前 via Android
    Ax210 肯定是能跑满 1000mbps ,上限不知道多少。
    至于软路由,是什么 cpu ,能不能 pppoe-wan 1000 兆,还是 br-wan 1000 兆。这 2 个接口性能多少还是有差别的。根据测试 mtk7620 在 br-wan 都能跑 500 兆上下,mtk7621 千兆估计是 ok 的。

    其它的就是测速通常只能找 isp 的测速站吧,能有几个网站可以提供这么大的带宽。见笑,至今只用过 100mbps 。。。
    xqzr
        4
    xqzr  
       17 小时 53 分钟前
    @Livid #1 AI
    coldle
        5
    coldle  
       17 小时 43 分钟前
    我嘞个赛博紫砂...
    1423
        6
    1423  
       17 小时 34 分钟前   ❤️ 1
    为什么发帖之前不问 AI 呢?
    因为发帖前问 AI 的话就没有这个帖子了
    而且 AI 的答案也不对啊
    看了看你历史帖子,玩路由器 5 年了还没玩明白
    OmoineMie
        7
    OmoineMie  
    OP
       16 小时 32 分钟前
    那你说说可能是什么原因呢?
    billccn
        8
    billccn  
       16 小时 30 分钟前
    @OmoineMie AI 答案体现出它就是个语言模型,是按照大数据瞎编的,和你的测试数据根本不匹配。你通过 wifi 测试内网能有 900 兆,怎么可能是什么“无线端口 -> 有线端口 (低速路径)”,性能瓶颈根本不在这。

    你 500 兆的宽带,走无线测出 450 兆,我觉得问题不大。你有线测出 700 兆可以稳定复现嘛?
    tavimori
        9
    tavimori  
       16 小时 7 分钟前
    @OmoineMie 基于 TCP 的测速会受到 TCP 速率控制算法的影响,无线的延迟抖动和丢包会让速率控制算法收敛到不同的速率,通常更为保守。通常而言 TCP 的来回时间越长(距离越远),中间经过的不稳定链路越多(例如无线)都会导致这样的问题。
    作为控制变量,你也可以在本地内网运行一个代理服务器,这样通过代理服务器上网就可以把一个 TCP 连接分成两段,一段有更大的延迟,一段有无线的抖动,把这两个影响分开可能速率就可以更快了。

    早些年 TCP 为了让 Wi-Fi 连接 WAN 以后跑得起速率,在算法上做过很多改良的,但多少都会有性能损失。
    dxgfalcongbit
        10
    dxgfalcongbit  
       15 小时 38 分钟前
    @billccn 宽带测速是会比运营商标称的带宽高一些的,我家 300m 套餐能稳定测出 400+m 的带宽。
    RecursiveG
        11
    RecursiveG  
       5 小时 22 分钟前
    It works on my machine ¯\_(ツ)_/¯ 我内网测速 600Mbps, 外网测速也 600Mbps 。各人网络环境差异那么大你又不能请网友去你家调查,找原因很难的啦。要稳定还是有线,无线嘛通了就行,450Mbps 又不慢。
    xiamy1314
        12
    xiamy1314  
       3 小时 45 分钟前
    这也有人 @站长
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5411 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 07:03 · PVG 15:03 · LAX 00:03 · JFK 03:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.