NAS 慢上传的发送端拥塞控制排查

10 月 11 日，我在 CachyOS 工作站上排查了一次共享盘慢上传。访问经过 WireGuard，桌面文件操作使用 GVFS 的 SMB 客户端。一个 128 MiB 随机文件写入共享盘用了 178.56 秒，只有 0.752 MB/s；同一轮完整读回却有 6.909 MB/s。

上传和下载的差距很大，但这还不足以把问题归给 NAS 磁盘、SMB 或 VPN。我先把这几个环节拆开测，再对客户端发送端做局部调整。文中的 MB/s 使用十进制单位，文件大小使用 MiB；随机数据生成和哈希计算不计入 SMB 复制时间。

第一组对照绕开了 NAS：用单条 SSH TCP 流向中继节点上传随机数据，关闭压缩，接收端计算 SHA-256 后丢弃数据。公网直连上传只有 0.675 MB/s，经过隧道上传只有 0.365 MB/s，而两个方向的下载都在 10 MB/s 以上。慢上行同样出现在不经过 SMB 的传输中，排查范围因此扩展到了客户端到中继的路径。

随后从中继节点直接访问 NAS，使用 CIFS、O_DIRECT 和包含 fsync 的写入测试。同样 128 MiB，写入达到 101.284 MB/s，完整回读校验通过。这个结果说明 NAS 的这条局域网接收路径具有高速处理能力，不能据此推断整台 NAS 没有其他问题。O_DIRECT 绕过的是中继节点的页缓存，NAS 自身仍可能缓存；fsync 返回也不等于我独立观测到了物理介质落盘。

实际上传期间，我还采样了中继的 CPU、接口错误、UDP 接收缓冲、分片与重组统计以及出口队列。没有取得 CPU 饱和、UDP 缓冲溢出或队列持续堆积的证据。到中继的指定大小禁止分片探测也能通过，所以当时没有直接降低 MTU、扩大缓冲或修改全局队列参数。

接下来只调整 Linux 客户端发往测试目标的拥塞控制，其他路径保持原状。SSH 对照得到下面的结果：

恢复对照的文件较小，不能把三轮写成完全相同的测试。它仍提供了一个有用的方向：更换发送端算法后上行明显改善，恢复原算法后又回到较低速度。不过 SSH 测试包含加密、流控和握手时间，也没有随机交错运行，不能把它当作裸 TCP 极限或严格的实验室基准。

再回到实际 SMB 路径，只给 NAS 主机的 /32 路由设置 congctl bbr。Linux 的路由选项允许按目标指定拥塞控制，不必为这次验证更改全局默认值；未加 lock 时，应用仍可能覆盖该选择。这些语义可在 ip-route 手册中核对。

三次 128 MiB SMB 复测如下：

三次都完成了完整回读，SHA-256 与各自的源文件一致；隧道字节增长也确认数据确实经过 VPN。收益大约是基线的 5.1–6.5 倍。这个结论限于本机、当时的路径和 SMB 客户端。

这里容易改错位置。上传时 TCP 发送端是工作站，NAS 是接收端；中继解密 WireGuard 流量后继续转发原来的 TCP 连接。给中继自己的 TCP 连接启用 BBR，不会替换工作站的发送算法。Linux 对新连接默认拥塞控制的定义见内核 IP sysctl 文档，普通 IP 转发走的是另一条内核处理路径。这也是我把调整留在客户端的原因。

最终持久化的范围也只有 NAS 主机路由：隧道建立后，辅助程序先确认该目标确实走预期接口，再设置路由算法；执行失败记录日志，不阻断 VPN 启动。全局 TCP 默认仍是 CUBIC，原有身份和业务路由保留。临时用于 SSH 对照的路由设置已撤掉，测试文件也已清理。

撤销时应去掉本次性能项，恢复该主机路由原有属性，不能把早于访问修复的整份配置覆盖回来。已有连接也不应被当作新策略的验证对象，复测需要确认新连接实际采用的算法。此次没有为性能项重启 VPN，因此开机或服务重建后的自动恢复仍未验收。

这次确定的是发送端拥塞控制在该路径上有可观测收益。物理问题究竟位于哪段接入链路，仍没有定位；TCP 重传比例也不能直接换算成链路丢包率。Windows 客户端的系统版本、算法支持和实际 SMB 表现尚未测量，这组 Linux 数字不能用于承诺它们的收益。