在公网上， SFTP|SMB|WebDAV 哪种文件传输协议是最高效、低延迟的？适合传输大量小文件？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

请不要把任何和邀请码有关的内容发到 NAS 节点。

邀请码相关的内容请使用 /go/in 节点。

如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。

这是一个创建于 81 天前的主题，其中的信息可能已经有所发展或是发生改变。

对高效定义：协议传输延迟低，报文开销小，例如进入并列一个大目录并且可以瞬间完成，并且没有多少报文开销。

用途：在远程客户端上提供类似文件管理器的视图，因此，不考虑 tar 打包这种。

目前已知 SFTP 的开销是远小于 WebDAV+HTTPS 的。

FTP 、FTPS 费拉不堪，已经被淘汰。

那么 SFTP 、SMB-TCP 、SMB-QUIC 、SCP 比起来呢？或者还有什么别的协议？

42 条回复 • 2024-09-14 15:11:24 +08:00

kenneth104

81 天前

大量小文件，我觉得没办法

Jinnrry

81 天前

插眼。

但是我盲猜，这些协议都这么多年了，应该都优化了好多个版本了，讲道理，性能应该优化得大差不差了吧？特别是公网传输，我盲猜区别不大

killgfat

81 天前

SMB over Quic 有点太新了，不知道 Samba 什么时候能支持

kenvix

81 天前

@Jinnrry #2 我认为还是有的，协议本身可能 OK ，但是还得考虑实现的质量。以 FTP 为例，传输需要多次往返，就意味着效率非常差。以 WebDAV 为例，客户端和库的实现质量参差不齐，有的连 H2 都没实现，导致头部开销特别巨大。

tool2dx

81 天前

看掉包率了，如果大于 5 ～ 10%，只能上 KCP ，你也没别的解决办法。

我自己测试下来，不掉包 FTP 挺快的，但是没加密不安全。sftp 也是鱼龙混杂，我遇到过魔改 dropbear 的，那速度真是绝了，要多慢有多慢。

用 openssh 最新版本，感觉也还行。SMB 和 SFTP 不太好直接对比，前者 windows 后者 linux 。

ntedshen

81 天前

webdav 这玩意一发一堆 206 包，能快才见鬼。。。
性能也就 cyberduck 能打，我反正没见过第二个性能能看的客户端。。。

ftp 讲道理主要问题是端口一大堆，性能没问题。。。
ftps 走 tls 性能就不可能比 webdav 低，何况还有客户端支持，除非代码真的写太烂了。。。
但是上公网开一堆端口确实麻烦。。。

sftp 这玩意证书加密的，开销真的小么。。。

smb 这玩意的实现怕是比 webdav 都少，我反正没写过这玩意的代码。。。
不过倒是真没啥毛病。。。

lt0136

81 天前

对于大量小文件的场景，我用 tar cf - $DIR | ssh $HOST "tar xf -" ，感觉速度还行。

dasf53adf

81 天前

用 NFS 呢？

lt0136

81 天前

@lt0136 没仔细审题，不考虑 tar 。那没事了😂

0x663

81 天前

iSCSI 快一点吧？

bbsingao

81 天前

rclone 可以并发处理多个文件.你试试

ericFork

81 天前

试试 sshfs

billccn

81 天前

我约 10 年前临时外派到澳大利亚，但域控里我的 Home dir 还是在欧洲，只要打开个文件浏览器就得等几秒，当地办公室还是内网专线，在外面 VPN 就更怀疑人生，所以千万不要在非本地网情况下用 SMB 。我坚持了几天以后和欧洲的 IT 要了一个虚拟机，远程桌面回欧洲。

楼主的需求是需要管理文件比较多，还是需要打开文件比较多？前者可以考虑用 UDP 的远程桌面，这样丢包也不太影响操作效率。

@0x663 公网上跑 iSCSI ？妥妥要损坏文件系统

题外：公司在我外派结束不久还来调研我的体验，最后决定购买一套 Riverbed Steelhead 加速器，这个神奇的机器可以中间人一些常见的企业内网协议，然后通过它专有的协议解决长延迟、高丢包的传输，上线一周以后异地备份就从 5-6 个小时变成几十分钟，同事也反应跨区访问文件非常流畅。我今天搜了一下这个加速器好像不迭代了，不知道是不是因为企业都上云了。

fuis

81 天前

公网的话，如果只能上面的选项选择，我可能只会选 WebDAV ，毕竟支持广泛；私网的话肯定是 SMB over RDMA 延迟最低，适合大量小文件。

然后我对这个描述有些疑问，“例如进入并列一个大目录并且可以瞬间完成，并且没有多少报文开销”，瞬间完成，跟报文开销的关系并不大吧。常见的 S3 走 https ，list objects 也是很快的（带分页），并且也可以支持大量小文件。我猜测这个问题的原始问题在于需要有一个对象的元数据服务，因为缺少这个服务导致了需要走 list 接口

libook

81 天前

SMB 很多压测数据表明很慢，实际使用确实很慢，小文件是灾难；
WebDav 协议很重也快不了；
这三者相对来说 SFTP 最快。

不加密的协议可能会更快，比如 NFS ，但因为本身连认证都没有，所以不大适合临时性的文件传输和公网的传输，适合局域网内长期独占挂载。

同样走 SSH 的话，可能 scp>rsync>sftp>sshfs ，当然具体也看参数优化和传输的文件情况。

hetal

81 天前

rsync 最好用

dann73580

81 天前

rclone 作为客户端并发远远快于其他的方式，另一段我个人是挂载的 sftp 。在一个有 60w 小文件，10t 总大小的场景，两端延迟超过 150ms,传输速度在 500Mbps 浮动，我觉得很不错的水平。

wheat0r

81 天前

webdav 的优势是实现简单、容易加密，别的就算了

lonelyparasol

81 天前

SMB 只在 Windows 局域网用过

google2023

81 天前

@ntedshen ftp 的被动模式端口，也是可以定制的，所以不需要太多端口。但 ftp 肯定不适合传大量小文件，频繁建立 tcp 连接，以及配套的 ftp 控制命令，都很耗费时间，小文件多传输效率会很低

GeekGao

81 天前

SFTP 仍然是首选，因为它平衡了安全性和效率
rsync 可以作为备选，特别是如果需要增量更新功能

phithon

81 天前

一直用 rsync+ssh ，小文件很快

yinmin

81 天前 via iPhone

在公网上传输大量小文件，优选 rsync 超快

xinmans

81 天前

S3 或者 oss

Autonomous

81 天前

webdav 支持的地方比较多，比如 obsidian 的 remotely-save 插件就支持 webdav 但不支持 sftp

jim9606

81 天前

我觉得 WebDAV 最容易优化。
考虑通过 WebDAV 下载大量文件相当于大量 GET 请求，那就可以用上 HTTP 的那些优化技巧，例如 stream multiplexing 。这个甚至不涉及协议定义，看客户端有没有实现而已。
FTP 是一个有状态协议，所以搞并发要靠多连接了，而且要把数据连接和控制连接复用一下。
按微软说法，SMB over QUIC 是会用上 QUIC 的并行、拥塞控制和丢失恢复的，所以看 smb 核心协议有没有充分利用了。不过看文档 SMB over QUIC 好像没法在非域控环境下使用。

hrdom

81 天前

rsync
ftp 传小文件非常慢
SFTP 和 WebDAV 没试过

SkywalkerJi

80 天前

大文件的话肯定是 FTP 效率最高，那些游戏和电影的分发，第一波分流都是通过高速 FTP ，之后才是 PTBT 之类。

geekvcn

80 天前

大量小文件不适合用互联网传送，请打包压缩再传输，不要自己找不自在

baobao1270

80 天前 via Android

iSCSI over Wireguard 应该对小文件更友好吧

kkocdko

80 天前

最快的是 smb-quic 或者 webdav-http2 。我选择后者，因为过 tcp 在我这里 cpu 占用比较低。

上面有人提到会发一堆 206, 这是错误的。这是 webdav 客户端的实现问题。完全可以不发，等到最后结束了再发。

还有一个方案，就是 rsync ，我觉得 rsync 在性能上碾压一切，但是你是否认同 rsync 是与 webdav/ftp/smb 同类的东西呢？它在很多客户端上一样可以挂载使用，只是不那么通用而已。