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

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

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

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

S3 或者 oss

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

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

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

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

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