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

[kenvix]

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

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

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

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

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

[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]

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