为什么WireGuard比OpenVPN延迟更低？

WireGuard运行在内核态，避免了用户态与内核态的上下文切换；使用更高效的加密算法（ChaCha20、Curve25519）；且基于UDP，无需TLS握手，减少了协议开销。

MTU设置过大会有什么影响？

MTU过大会导致IP分片，增加重传概率和延迟。VPN隧道建议MTU设为1420-1440，并配合MSS钳制，避免分片。

RPS和XPS如何帮助降低延迟？

RPS将接收中断处理分散到多个CPU核心，避免单核过载；XPS将发送队列绑定到特定CPU，提高缓存命中率，两者均能减少包处理延迟。

降低VPN延迟的工程实践：从协议选择到内核调优

6/6/2026 · 3 min

1. 协议选择：WireGuard vs OpenVPN

VPN协议对延迟的影响显著。WireGuard基于UDP，采用现代加密原语（ChaCha20、Curve25519），内核态实现消除了上下文切换开销。实测显示，WireGuard在同等网络条件下比OpenVPN（TLS模式）延迟降低30%-50%。OpenVPN虽然灵活，但用户态处理、TLS握手和加密套件协商引入额外延迟。对于延迟敏感场景，优先选择WireGuard。

2. 传输层优化：TCP BBR与MTU调整

2.1 拥塞控制算法

默认的CUBIC算法在高延迟链路中表现不佳。BBR（Bottleneck Bandwidth and Round-trip propagation time）通过建模网络路径带宽和RTT，避免缓冲区膨胀，显著降低排队延迟。在VPN隧道上启用BBR：

# 在VPN接口上设置BBR
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

2.2 MTU与MSS钳制

VPN封装增加头部开销（WireGuard约60字节，OpenVPN约80字节）。若物理链路MTU为1500，VPN隧道MTU应设为1420-1440。过大的MTU导致IP分片，增加重传和延迟。使用ip link set dev wg0 mtu 1420调整。同时，在防火墙中钳制MSS：

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

3. 内核调优：RPS、XPS与中断亲和性

3.1 接收包导向（RPS）

RPS将软中断处理分布到多个CPU核心，避免单核瓶颈。对于多队列网卡，为每个队列设置RPS CPU掩码：

echo "f" > /sys/class/net/eth0/queues/rx-0/rps_cpus  # 使用前4个核心

3.2 传输包导向（XPS）

XPS将发送队列绑定到特定CPU，提高缓存局部性。配置方式类似RPS：

echo "f" > /sys/class/net/eth0/queues/tx-0/xps_cpus

3.3 中断亲和性

将网卡中断绑定到专用CPU，减少中断处理对其他任务的干扰：

# 查看中断号
cat /proc/interrupts | grep eth0
# 绑定中断到CPU0
echo "1" > /proc/irq/<IRQ_NUM>/smp_affinity

4. 其他工程实践

启用GRO/GSO：减少小包处理开销，ethtool -K eth0 gro on gso on。
使用UDP而非TCP隧道：避免TCP-over-TCP导致的性能崩溃。WireGuard原生UDP，OpenVPN可选UDP模式。
硬件加速：支持AES-NI的CPU可加速加密操作，WireGuard的ChaCha20也受益于AVX指令集。

5. 性能验证

使用iperf3和ping测试优化前后延迟：

# 测试延迟
ping -c 100 -i 0.1 <VPN_GATEWAY>
# 测试吞吐
iperf3 -c <VPN_GATEWAY> -t 30 -P 4

对比优化前后RTT和吞吐量，确保调优有效。