如何用WiFi进行快速数据传输？

问题的提出

两台设备通过热点组成局域网，用 rsync 传大量文件——这是极其常见的场景：手机开热点、电脑连上来传照片；或者电脑开热点、手机连上来备份数据。

但实际速度往往远低于网卡标称速率。问题出在哪一层？

WiFi 速率从标称 1200Mbps 到实际文件传输 20MB/s（160Mbps），损耗超过 85%——这不是单一瓶颈，而是物理层→TCP层→应用层（rsync）的多层叠加效应。

本文将问题拆成三层，逐层分析并给出优化方法。

场景定义

文件传输方向可能为 AP→Client 或 Client→AP，两者在 WiFi 层不对称（AP→Client 下行和 Client→AP 上行速率可能不同）。

第一层：物理层（WiFi 链路）

1.1 四个核心参数

WiFi 物理层协商速率由四个参数决定：

给定这四个参数，查 IEEE 标准表即得 PHY 速率。例如 2×2 MIMO + 80MHz + MCS 11 + SGI = 1201 Mbps。

1.2 各协议最大 PHY 速率（消费级 2×2 设备）

1.3 快速诊断：当前连接状态

# 查看当前协商速率（最直接的诊断命令）
iw dev wlan0 link
# => tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2

这条输出告诉你当前实际协商的 MCS、带宽、GI 和流数。对照上表，如果发现：

• MCS 7（而非 9/11）→ 信号不够好，设备退而求其次
• 20MHz（而非 80/160）→ 配置或兼容性问题
• NSS 1（而非 2）→ 天线/信号问题

1.4 查看硬件能力上限

iw list    # 完整硬件能力

关键输出段落：

Band 2:   (5 GHz)
    HT20/HT40              ← 802.11n 支持 40MHz
    VHT80/VHT160           ← 802.11ac 支持 80/160MHz
VHT RX MCS set:
    1 streams: MCS 0-9     ← 单流最高 MCS 9
    2 streams: MCS 0-9     ← 双流最高 MCS 9
    3 streams: not supported  ← 最大 2 流

如果 iw list 显示支持 VHT160 但 iw dev wlan0 link 只跑在 80MHz，说明存在可优化的空间。

1.5 第一层速查：物理层常见减速原因

第二层：WiFi AP 配置（hostapd / 手机热点）

2.1 谁做 AP？选择策略

关键选择一：如果 PC 网卡是 Intel（AX200/AX210 等），5GHz AP 模式几乎不可用——Intel 的 LAR（Location-Aware Regulatory）机制要求先侦听到合法的 5G AP beacon 才允许自己发射，这在 AP 模式下形成死锁。Intel 仅支持 2.4GHz AP。

关键选择二：如果 PC 网卡是 MT7921/MT7922 或 RTL8852BE 等，推荐 PC 做 AP，性能远超手机热点。

2.2 PC 做 AP：hostapd 最小最优配置

interface=wlan0
driver=nl80211
ssid=FastTransfer
hw_mode=a                  # a=5GHz, g=2.4GHz
channel=36                 # 36-48 非DFS，兼容性最好
country_code=US
wmm_enabled=1              # 必选！否则 11n/ac/ax 全部失效

# 802.11n (HT)
ieee80211n=1
ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-7935]

# 802.11ac (VHT) — 80MHz
ieee80211ac=1
require_vht=1
vht_capab=[MAX-AMSDU-7935][SHORT-GI-80]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42     # 信道36-48 → 42

# 802.11ax (HE) — 如硬件支持
ieee80211ax=1
he_capab=[HE80]

# 安全：CCMP(AES) 最快，避免 TKIP
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
wpa_passphrase=secretpass

信道与中心频率对照（80MHz）：

2.3 手机做 AP：只能做的优化

手机热点几乎没有可调参数，但有几件事可以控制：

1. 强制 5GHz 热点：Android 设置 → 便携式热点 → 配置 → 选择 5GHz 频段
2. 关闭移动数据：避免蜂窝流量干扰（也避免误用流量）
3. 物理散热：手机放在凉爽表面甚至主动散热（风扇），延缓降频
4. 近距离：两台设备尽量靠近，减少信号衰减

2.4 第二层速查：配置常见问题

第三层：系统与 rsync 调优

这是最常见却被忽视的性能黑洞。 WiFi 链路调好后，rsync 本身的参数选择经常将实际文件吞吐拉到物理极限的 30% 以下——尤其是大量小文件的场景。

3.1 系统层基线优化

# --- WiFi 层面 ---
iw dev wlan0 set power_save off     # 关省电，WiFi 性能的首要杀手
ip link set wlan0 txqueuelen 4096   # 增大发送队列

# --- TCP 层面 ---
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
sysctl -w net.ipv4.tcp_congestion_control=bbr

3.2 rsync 核心参数

# 最优 LAN 传输命令
rsync -avW --no-compress --inplace --info=progress2 /source/ user@host:/dest/

3.3 SSH vs rsync Daemon：需要关心吗？

rsync 默认走 SSH 隧道。SSH 加密对 LAN 传输有两重开销：

结论：普通 WiFi LAN（PHY < 2Gbps，实际 < 1Gbps），rsync over SSH 即可。 加密开销在 AES-NI 硬件上可以忽略。

如果双方的 CPU 都很弱（老旧 ARM NAS 等），可考虑 rsync daemon 模式（免加密，端口 873）：

# 服务端
cat > /etc/rsyncd.conf << 'EOF'
[share]
    path = /srv/data
    read only = no
EOF
rsync --daemon

# 客户端
rsync -avW --no-compress /source/ rsync://host/share/

3.4 大量小文件的特殊处理

这是 rsync LAN 传输最常见的性能灾难。

rsync 对每个文件有固定开销：stat() → checksum → send metadata → transfer data。对于 KB 级别的小文件，这些开销远超数据传输本身，导致有效吞吐量暴跌 50-90%。

解决方案，按效果排序：

方案一：并行 rsync（最推荐）

将文件列表拆成 N 份，并行跑 N 个 rsync 进程：

# msrsync 方式（推荐）
msrsync -p 8 -r '-avW --no-compress' /source/ host:/dest/

# 或 GNU Parallel 手动拆分
cd /source && find . -type f | parallel -j8 --files --pipe --block 10M \
    'rsync -avW --no-compress --files-from=- /source/ host:/dest/'

效果：典型 10 万个小文件场景，单 rsync 12 分钟 → 48 秒（约 15× 提升）。

方案二：tar + netcat 全量传输

如果不是增量同步而是首次全量，rsync 的逐文件开销完全是浪费：

# 接收端
nc -l 9999 | pv | tar xv -C /dest/

# 发送端
tar cv /source/ | pv | nc <receiver_ip> 9999

无逐文件开销、无 SSH 加密、无 delta 计算——最接近裸 TCP 吞吐。缺点是无增量/断点续传能力。

方案三：优化 rsync 参数（不改变流程）

rsync -avW --no-compress --inplace --no-inc-recursive \
    --no-motd --ignore-existing --include='*/' --include='*.jpg' --exclude='*' \
    --info=progress2 /source/ host:/dest/

• --no-inc-recursive：禁用增量递归（减少内存和预扫描时间）
• --ignore-existing：跳过接收端已有文件（增量同步时）

3.5 大文件的极限优化

如果传输的是少量大文件（ISO、视频等），瓶颈不在文件数而在 TCP 流本身：

# 多并行流（多个大文件同时传）
rsync -avW --no-compress --info=progress2 \
    --rsh='ssh -c [email protected] -o Compression=no' \
    /source/ host:/dest/

如果要真正逼近物理极限，可以多实例同时传不同文件：

# 找大文件
find /source -type f -size +100M > big_files.txt
# 并行传
cat big_files.txt | parallel -j4 rsync -avW --no-compress {} host:/dest/

3.6 第三层速查：应用层减速原因

第四层：拓扑瓶颈 — 中转的性能代价

这是三层调优做完之后，可能仍然存在的硬限制。

4.1 问题现象

PC1 ──WiFi──> 手机AP ──WiFi──> PC2
     866Mbps          866Mbps

iperf3 单链路：PC1↔Phone 或 PC2↔Phone → 500-1000 Mbps ✓
PC1 → PC2 中转：                   → ~300 Mbps      ✗

单链路满速，中转直接腰斩。这不是配置问题，是 WiFi 半双工共享介质的物理规律。

4.2 为什么会减半？

WiFi 是半双工、共享信道。AP 只有一个无线电，同一时刻只能和一个客户端通信：

时间片拆分：
  t1: PC1 → AP  (数据包上行)
  t2: AP → PC2  (数据包下行)
  t3: PC1 → AP  (下一个包)
  t4: AP → PC2  (下一个包)
  ...

一个数据包从 PC1 到 PC2 要占用两倍的空口时间：入站一次、出站一次。再加上 CSMA/CA 竞争退避、ACK 帧开销，理论极限就是单链路速率的 40-50%。

300Mbps ≈ 866Mbps × 40%——数字完全对得上。

除此之外，手机 AP 在中间做 NAT 路由而非二层桥接，每个包要经过 netfilter/conntrack，CPU 负担进一步恶化：

PC1 → AP: WiFi 上行 (空口时间 50%)
AP 内部: NAT/conntrack (CPU)
AP → PC2: WiFi 下行 (空口时间 50%)

4.3 有没有办法绕过？

4.4 最佳实践：根据硬件选择拓扑

方案 A：PC 网卡能做 AP（MT792x / RTL8852）→ PC 开热点

PC1 (AP) ──WiFi──> PC2 (Client)
        单跳，无中转

数据直接从 PC1 的 WiFi 接口发到 PC2，只经过一次空口传输，速率接近单链路上限。

方案 B：PC 网卡是 Intel（不能做 5G AP）→ USB tethering + WiFi 混合

PC1 ──USB──> 手机AP ──WiFi──> PC2
    有线侧     无线侧

USB tethering 不占 WiFi 空口。PC1 通过 USB 把数据发给手机，手机用全部 WiFi 带宽传给 PC2——单链路速率基本不损耗。这是绕过 Intel 网卡限制和 WiFi 中转损耗的最简单方法：

# 手机 USB 连接 PC1，开启 "USB 网络共享"
# PC1 上会出现 usb0 接口
# 然后在 PC1 上启动 rsync 服务端，PC2 通过手机热点的 WiFi IP 连接 PC1

# PC1 (USB 连接手机)：
rsync -avW --no-compress /source/ user@<PC2_WiFi_IP>:/dest/

方案 C：只能手机做 AP，两台 PC 都 WiFi 连接 → 接受物理限制

中转损耗是硬性的，此时能做的只是确保链路本身是最优的： - 两台 PC 都连 5GHz - 手机和两台 PC 保持近距离等距 - 关省电模式 - iperf3 验证单链路能跑满，然后接受中转 ≈ 40% 的现实

如果手机支持双频同时热点（Android 16+ 的 2.4+6G 模式），可以让一台 PC 连 2.4GHz、另一台连 5GHz——两个频段不共享空口，中转损耗可大幅降低。

完整优化流程

graph TD
    A[iw dev wlan0 link<br/>查看当前 PHY 速率] --> B{达到硬件上限的<br/>60-70%?}
    B -->|否| C[第一层：检查 MCS/NSS/<br/>带宽/GI/频段]
    B -->|是| D[iperf3 测试 TCP 吞吐]
    D --> E{达到 PHY × 0.65?}
    E -->|否| F[第二层：hostapd 配置<br/>/系统 TCP 参数]
    E -->|是| G{数据经过 WiFi 中转?<br/>PC→AP→PC?}
    G -->|是| H[第四层：消除中转<br/>换 PC 做 AP / USB 有线 / WiFi Direct]
    G -->|否| I[rsync 传输基准测试]
    I --> J{是否是大量小文件?}
    J -->|是| K[第三层：-W + 并行 rsync<br/>或 tar+nc]
    J -->|否| L[第三层：-W --no-compress<br/>基本够用]

速查表：按场景选方案

总结

四层优化，按优先级排：

1. 物理层：5GHz + 80/160MHz + 2×2 MIMO = 先确保 PHY 协商到硬件上限
2. WiFi 配置层：wmm_enabled=1、正确 country_code、AP 角色选择（Intel 别做 5G AP）
3. 拓扑层：避免 WiFi 中转！让数据源/目的地之一充当 AP，或用 USB 有线替代一侧 WiFi 连接
4. 应用层：rsync -W（跳过 delta）、--no-compress、大量小文件用并行 rsync 或 tar+nc

针对你的现象：手机热点中转跑 300Mbps，单链路能跑 500-1000Mbps——这不是配置问题，是 WiFi 半双工共享介质在中转场景下的硬限制（~40-50%）。 解决方案：让一台 PC 做 AP，或 USB tethering + WiFi 混合连接。

附录：两台 Linux 间的硬件直连策略

如果 WiFi 热点不够快，两台 Linux 电脑间建立直连链路有哪些硬件方案？以下是三种主流选择的实测数据对比。

方案对比总览

方案一：10GbE 直连（最推荐）

两条网线对插，配个 IP 就能跑满万兆。不需要交换机——现代网卡都支持 Auto MDI-X，普通 Cat6a 线直连即可。

推荐硬件： - 二手企业卡（$25-40/张）：Mellanox ConnectX-3/4、Intel X520/X540，PCIe 插上即用 - 全新消费卡（$100-150/张）：TP-Link TX401、ASUS XG-C100C - 线缆：Cat6a/Cat7 ~$15-30（短距离），或 SFP+ DAC 线 ~$20-40

配置：

# 两台机器各配一个 IP，搞定
# PC1
ip addr add 10.0.0.1/24 dev eth1
# PC2
ip addr add 10.0.0.2/24 dev eth1

# 实测
iperf3 -c 10.0.0.2    # 预期 ~9.4-9.9 Gbps

优点：全双工、最稳定、CPU 开销最低（硬件卸载）、线长可达 100m。需要更高带宽时可以 bond 多张卡。

缺点：需要 PCIe 插槽（笔记本通常没有），除非用 Thunderbolt 转 10GbE 适配器。

方案二：Thunderbolt/USB4 网络

如果两台电脑都有 TB3/TB4 或 USB4 接口，只需一根线就能获得比万兆更快的连接。

关键认知：TB4 标称 40Gbps 是物理层速率。IP 网络跑在其上是半双工的，实际单向吞吐约 11-18 Gbps——差不多是 10GbE 的 1.2-1.8 倍，但远不是 40Gbps。

驱动：Linux 内核自带 thunderbolt-net 模块。插上线后会自动出现 thunderbolt0 网络接口。

# 加载驱动（一端执行即可，对端自动触发）
modprobe thunderbolt-net

# 配置 IP
# PC1
ip link set thunderbolt0 up
ip addr add 10.0.0.1/24 dev thunderbolt0

# PC2
ip link set thunderbolt0 up
ip addr add 10.0.0.2/24 dev thunderbolt0

# 设置巨帧 MTU 提升吞吐
ip link set thunderbolt0 mtu 65520

# 实测
iperf3 -c 10.0.0.2    # 预期 ~11-18 Gbps

实测数据（iperf3 TCP）： - TB3 直连 (kernel 6.14)：~9.4-10 Gbps - TB4/USB4 直连 (AMD)：~13.7 Gbps（大数据包）、~11.7 Gbps（4K 小包） - Strix Halo USB4：~11 Gbps/方向

优点：单线缆即插即用（USB4）；延迟最低（~15-20 µs）；零额外成本（如果已有端口）。

缺点：半双工，总带宽有限；线缆极短（<2m）；AMD USB4 和 Intel TB4 实现有差异；桥接模式下有已知性能 bug（TB→以太网方向可能掉到 ~5Mbps，kernel 6.14 中仍在修复）。

方案三：USB 2.5GbE 网卡

笔记本没有 PCIe 插槽也没有 Thunderbolt 时的折中选择。

芯片：Realtek RTL8156/B，USB 3.0 接口，支持 2.5GBASE-T。

实测吞吐：~2.3 Gbps（280 MB/s），接近线速。但有几个坑：

# 1. 检查驱动是否正确（必须 r8152，不是 cdc_ncm）
ethtool -i eth1    # driver: r8152 ✓

# 2. 检查协商速率和双工
ethtool eth1       # Speed: 2500Mb/s, Duplex: Full ✓

# 3. 如果驱动错误，手动修复
modprobe -r cdc_ncm
modprobe r8152

驱动陷阱：内核有时错误加载 cdc_ncm 而非 r8152，导致速度下降 2-4 倍（~500-750 Mbps）且频繁断连。内核 5.13+ 自带正确的 r8152 驱动。

成本：单个适配器 ~$15-30，配 Cat5e/Cat6 线即可。

方案四：WiFi Direct（P2P）——不推荐用于高速传输

两台电脑不经过 AP 直接通过 WiFi P2P 连接。理论可跑到 867Mbps (11ac 2×2)，但 Linux 上的实际体验极差：

• 配置极其繁琐：需要 wpa_supplicant + p2p_find + p2p_connect + PIN 交换
• 需要关闭 NetworkManager
• Intel 网卡兼容性差（Atheros/Mediatek 略好）
• 实际吞吐远低于理论值
• 延迟高且不稳定（2-10ms）

结论：除非绝无可能拉线，否则不要用 WiFi Direct。

决策树：选哪个方案？

两台电脑都有 Thunderbolt/USB4 接口？
├── 是 → 方案二（Thunderbolt），$15 买根线就行，~11-18 Gbps
└── 否 → 是否有 PCIe 插槽？
    ├── 是 → 方案一（10GbE），网卡 $25-40/张，~9.5 Gbps 全双工
    └── 否（笔记本无 PCIe）→ 方案三（USB 2.5GbE），$15-30/个，~2.3 Gbps

我个人的推荐排序：10GbE > Thunderbolt/USB4 > USB 2.5GbE >>> WiFi Direct

10GbE 用二手 Mellanox 卡性价比极高，全双工 9.5Gbps 极其稳定，几乎零维护。Thunderbolt 在有口的设备上很便利，但短线和半双工是其软肋。