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

[kenvix]

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

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

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

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

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

[kenneth104]

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

[Jinnrry]

插眼。

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

[killgfat]

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

[kenvix]

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

[tool2dx]

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

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

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

[ntedshen]

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

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

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

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

[lt0136]

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

[dasf53adf]

用 NFS 呢？

[lt0136]

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

[0x663]

iSCSI 快一点吧？

[bbsingao]

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

[ericFork]

试试 sshfs

[billccn]

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

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

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

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

[fuis]

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

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

[libook]

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

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

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

[hetal]

rsync 最好用

[dann73580]

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

[wheat0r]

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

[lonelyparasol]

SMB 只在 Windows 局域网用过

[google2023]

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

[GeekGao]

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

[phithon]

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

[yinmin]

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

[xinmans]

S3 或者 oss

[Autonomous]

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

[jim9606]

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

[hrdom]

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

[SkywalkerJi]

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

[geekvcn]

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

[baobao1270]

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

[kkocdko]

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

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

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

[ShinichiYao]

目的机开 SMB ，源机全选文件然后压缩到...选目的机

[cheng6563]

smb/nfs 就是最快的，但你必须套层 VPN 不然没法在公网上用，那么性能问题就在你 VPN 上了。
其他需要加密的速度都不怎样,sftp 应该稍微好一点
FTP 协议太古老了，与现在的网络搭配起来很蛋疼

[xdzhang]

公网我用的 webDAV ，内网用的 nfs 。

[onichandame]

有开发资源的话用 s3 吧

[sm1314]

syncthing ，底层用的类似 p2p 的协议，上层有自己的增删改同步控制，很好用，性能没比较过

[sunnysab]

插一句，公网，40-50ms 延迟的情况下，连回家里 NAS 看电影，我感觉 SMB （ samba ）的表现不如 nginx 的 static file sharing 。峰值和平均速度都会低一些。

[AirCrusher]

rclone 可行

[hyperbin]

@Jinnrry 协议都是有应用场景的，有些协议就不会考虑公网场景

[adoal]

过公网的大量数据传输，只建议针对具体业务场景做整体方案设计（至少包含网络拓扑等基础设施建设），而不是纠结传输协议的比较。

[kirory]

nginx 开 HTTP2 和 auto index ，浏览器可以直接看，要打包下载可以写个 js 遍历一遍

[starinmars]

公网还是 http 比较稳定吧