tcp_autocork_wireguard怎样WireGuard

本文目录导读：

1. tcp_autocork 是什么？
2. WireGuard 本身不使用 TCP
3. 但 tcp_autocork 会影响 穿过 WireGuard 隧道的 TCP 连接
4. 针对 WireGuard 的建议配置
5. 更关键的 WireGuard 优化参数（非 tcp_autocork）

你提到的 tcp_autocork 和 WireGuard 结合的问题，通常想表达的是：在 WireGuard VPN 隧道中，如何利用或者调整 Linux 内核的 TCP 自动 cork（tcp_autocork）来优化性能，或者是 WireGuard 是否依赖 / 受 tcp_autocork 影响。

下面分开来解释,并给出具体的配置建议。

---

tcp_autocork 是什么？

• Corking（软木塞）：是一种推迟小包发送、积累更多数据后再一次性发送（减少小包数量、提高吞吐）的机制。
• 内核参数 net.ipv4.tcp_autocork：
  • 0：关闭，TCP 完全依赖应用层调用 setsockopt(TCP_CORK) 来控制。
  • 1（默认值）：开启，内核自动判断是否应推迟发送，无需应用层显式调用 TCP_CORK。
• 影响：对延时敏感的小包（如 SSH、游戏）可能有负面影响（增加延迟）；对批量数据传输（大文件、流媒体）有正面作用（减少 CPU 和网络开销）。

---

WireGuard 本身不使用 TCP

这是最关键的一点：

• WireGuard 是一个 Layer 3 隧道协议，它使用 UDP 端口（默认 51820）封装所有 IP 包。
• tcp_autocork 仅影响 TCP 协议栈的行为，不直接影响 UDP。
• WireGuard 的隧道控制层（握手、keepalive）不受 tcp_autocork 参数控制。

---

但 tcp_autocork 会影响 穿过 WireGuard 隧道的 TCP 连接

当你在 WireGuard 隧道内部传输 TCP 流量（远程桌面、文件下载、网页浏览）时，内部 TCP 连接的发送行为会受到 tcp_autocork 的影响。

具体关系如下：

1. 物理网络状况：如果底层物理网络（即 WireGuard 的下层网络）拥塞、丢包率高，或者 MTU 问题导致分片，tcp_autocork 可能导致内部 TCP 堆积更多数据，从而一次发送一个大 UDP 包（WireGuard 封装后），可能触发 PMTUD（路径MTU发现）问题 或 UDP 分片（不建议）。
2. 延迟敏感性：如果你的 WireGuard 用于交互式应用（SSH、VoIP），开启 tcp_autocork=1 可能会让内部 TCP 小包被延迟，造成卡顿感。

---

针对 WireGuard 的建议配置

1 如果你的 WireGuard 主要用于 文件传输 / 流媒体 等吞吐量优先的场景

• 保持默认：net.ipv4.tcp_autocork = 1
• 额外辅助：同时设置 net.ipv4.tcp_notsent_lowat = -1（默认），无需额外调整。
• 优化 MTU：确保 WireGuard 的 MTU（1420） + 50字节 头部 = 物理接口的 MTU（1500），避免分片。

# 检查物理接口 MTU
ip link show eth0 | grep mtu
# 检查 WireGuard 接口 MTU（通常为 1420）
ip link show wg0 | grep mtu

2 如果你的 WireGuard 用于 低延迟交互（SSH、远程桌面、VoIP）

• 考虑关闭：net.ipv4.tcp_autocork = 0
• 原因：关闭后，TCP 小包（如 SSH 按键、RDP 鼠标移动）会立即发送，不会因 cork 而被挂在缓冲区等待更多数据，从而降低 WireGuard 隧道内部的延迟。
• 替代方案：也可以保持 tcp_autocork=1，但为特定应用（如 SSH）使用 TCP_NODELAY（Nagle算法关闭），但 tcp_autocork 是内核级逻辑，TCP_NODELAY 不能完全绕过它，因此对于重交互场景，关闭 tcp_autocork 更彻底。

临时修改（立即生效，重启后失效）：

sysctl -w net.ipv4.tcp_autocork=0

永久修改：在 /etc/sysctl.conf 或 /etc/sysctl.d/99-wireguard.conf 中添加：

net.ipv4.tcp_autocork = 0
net.ipv4.tcp_slow_start_after_idle = 0  # 额外优化：关闭空闲后的慢启动

sysctl -p。

---

更关键的 WireGuard 优化参数（非 tcp_autocork）

tcp_autocork 对 WireGuard 间接影响有限，下面这些参数对 WireGuard 直接性能影响更大：

参数	推荐值	原因
net.core.rmem_max	2500000 (2.5MB)	增大 WireGuard 接收缓冲区，减少丢包
net.core.wmem_max	2500000	增大发送缓冲区
net.ipv4.tcp_rmem	4096 87380 2500000	允许更大的 TCP 接收窗口
net.ipv4.tcp_wmem	4096 87380 2500000	允许更大的 TCP 发送窗口
net.ipv4.tcp_congestion_control	bbr 或 bbr3	BBR 拥塞控制对高延迟、有丢包的WAN链路更好（WireGuard 通常跨公网）
WireGuard 自身参数
FwMark	设置成 0xca6c	避免 WireGuard 自身流量被路由回自己的隧道（导致环路）
PersistentKeepalive	25秒	对NAT后面的客户端，保持UDP映射有效

---

• tcp_autocork 不直接控制 WireGuard 协议本身（UDP）。
• 它会影响 WireGuard 隧道内部承载的 TCP 连接。
• 推荐策略：
  • 吞吐优先：保持默认（tcp_autocork=1），配合 BBR 拥塞控制。
  • 延迟优先：关闭（tcp_autocork=0），配合 BBR 或 CUBIC。
  • 通用优化：请优先调整内核缓冲区大小和拥塞控制算法，收益比 tcp_autocork 大得多。

如果你能告诉我你的具体使用场景（是玩游戏还是传文件？网络是移动4G/5G还是宽带？），我可以给出更精准的参数组合。

标签： TCP自动塞子 WireGuard性能