家里那台小主机上挂了三块盘，电视用 SMB 打开片库，iPhone 的文件 App 只认 WebDAV，去年买的老功放又只肯认 FTP。同一批文件，为了照顾这三样东西我开了三个端口，某天突然想知道：这几个协议到底差在哪，值不值得为它多开一个服务。
于是我把同一块盘、同一批文件，用五种方式各开了一遍，全部在本机回环上测，先把网卡这个变量摘掉，只看协议本身的开销。
测法：一个 1GB 大文件，加 2000 个碎文件
硬件是一台 Ryzen 5 3550H 的小主机，16GB 内存，SATA SSD，系统是 Windows 11 25H2。服务端统一用 rclone 1.75.2，一个二进制就能同时起 webdav、ftp、sftp、http 四个后端；SMB 用系统自带共享，没装第三方 Samba，避免引入实现差异。
样本两件：一个 1GB 的随机二进制文件，测顺序吞吐；2000 个 16KB 的小文件，共 32MB，测目录列举和小文件场景。每一项跑三轮取中位数，第一轮当预热不计入。
吞吐：SMB 875MB/s，rclone 那四种全卡在 200MB/s 以下
- 本机直读（基线）：读 1.10s，约 932MB/s
- SMB 共享：读 1.17s，约 875MB/s；写 3.81s
- HTTP：读 5.00s，约 205MB/s；只读后端，不能上传
- FTP：读 5.46s，约 188MB/s；写 7.02s
- WebDAV：读 5.54s，约 185MB/s；写 6.90s
- SFTP：读 8.16s，约 126MB/s；写 8.16s
先把基线摆出来：同一块盘直接读这个 1GB 文件，1.10 秒，932MB/s——文件在页缓存里，这基本是这台机器能跑到的上限。SMB 读同一个文件 1.17 秒，比直读只慢 6%，等于协议本身几乎不产生开销。剩下四种按 rclone 排：HTTP 205MB/s、FTP 188MB/s、WebDAV 185MB/s、SFTP 126MB/s。
这里得排除一个嫌疑：会不会是测量工具慢？我换成 node 原生 http 客户端去打 rclone 的 http 后端，5.62 秒，跟 curl 的 5.00 秒同一个量级，说明 200MB/s 是 rclone 服务端自己的天花板，不是客户端拖的。SMB 那一行用的是同一个 node 读流，所以两边可以直接对比。
写入方向差距更大：SMB 3.81 秒，WebDAV 6.90 秒，FTP 7.02 秒。也就是说手机往电脑备份照片，同样的千兆内网，走 SMB 比走 WebDAV 快接近一倍。注意 SMB 写入这 3.81 秒里包含了真正落盘和杀毒软件扫新文件的时间，波动也最大（三轮里有一轮 6.86 秒），但量级差距是稳的。
这组数字对大多数家庭网络其实没什么意义：千兆网口的上限就 125MB/s，上面任何一个协议都能吃满，4K 原盘 100Mbps 的码率更是连零头都用不到。它真正有意义的地方只有两个：一是你上了 2.5G 或万兆，那只有 SMB 能吃掉带宽，rclone 系全部卡在 200MB/s；二是你在同一台机器上做本地挂载、虚拟机共享目录这类不过网卡的事，SMB 基本等于直接读写本地盘。
我也顺手试了能不能把它调快。rclone 的 --buffer-size 默认是 16Mi，我分别用 0、16Mi、64Mi、256Mi 各跑三轮读同一个文件：0 是 7.10 秒（144MB/s），16Mi 是 5.34 秒，64Mi 是 5.33 秒，256Mi 是 5.31 秒。结论是关掉缓冲会掉三分之一，但从默认的 16Mi 再往上加没有任何收益——瓶颈不在缓冲区，改参数救不回来。
2000 个文件列一次目录，差了 20 倍
- SMB：11ms，二进制协议，没有文本开销
- FTP：90ms，响应 116KB
- HTTP 目录页：150ms，响应 1.0MB
- WebDAV：220ms，响应 1.25MB
- SFTP：370ms
WebDAV 慢的原因很具体：列目录走 PROPFIND，服务端要给每一个文件回一整段 XML，里面有 resourcetype、getcontentlength、getcontenttype、getetag、getlastmodified、displayname、supportedlock，2000 个文件就是 1.25MB，平均每个文件 625 字节。FTP 的 LIST 只回一行纯文本，58 字节一个文件，总共 116KB。
这就是为什么手机相册类 App 挂 WebDAV 目录，一进去转好几秒；而同一个目录用 FTP 客户端刷一下就出来了。目录越大差距越夸张，一万个文件的时候 WebDAV 那一条就是 6MB 的 XML，手机在弱 Wi-Fi 下会直接超时。
顺便说个容易看错的地方：HTTP 那一行 1.0MB 是 rclone 的目录页 HTML，属于页面写法，不是协议开销，别拿它当协议之间的对比。真正能横向比的是 FTP 的 116KB 和 WebDAV 的 1.25MB。
拖进度条那一下，比协议名字更要紧
看片最烦的不是加载慢，是拖进度条卡住。我测了从文件第 700MB 处读 1MB 的耗时：
- HTTP / WebDAV / FTP：首字节都在 10ms 以内，三种都支持 Range 请求，播放器点哪读哪；
- SFTP：430ms，每次都要重新开通道、等窗口；
- SMB：第一次打开 256ms，同一路径第二次、第三次是 4.3ms 和 7.4ms。
SMB 那个 256ms 是首次打开共享路径的固定成本，不是每次读都这样。播放器一旦打开文件就复用句柄，实际拖动的时候感觉不到。反倒是 SFTP 那 430ms 是实打实每次都要付，所以拿 SFTP 当片库源，快进体验会明显差一截。
一个 rclone 就能把四种协议同时开出来
这次测试的服务端全是 rclone 起的，命令很短，四条分别开在不同端口，指向同一个目录：
rclone serve webdav --addr 0.0.0.0:8080 --user u --pass p /data
rclone serve ftp --addr 0.0.0.0:2121 --user u --pass p /data
rclone serve sftp --addr 0.0.0.0:2222 --user u --pass p /data
rclone serve http --addr 0.0.0.0:8081 /data踩过的坑有两个。一是 rclone serve http 是只读的，只有目录页和下载，想上传必须用 webdav、ftp 或 sftp。二是用 rclone 自己当客户端连 sftp 后端时，连接串里直接写明文密码会报 base64 解码失败——它要的是 rclone obscure 转出来的混淆串，正确做法是先用 rclone obscure 你的密码 拿到串，写进配置文件再用远程名连接。
资源占用上，rclone 各后端的常驻内存都在 45–65MB 之间，不算轻但也不夸张；SFTP 那个最胖，跑完 6GB 读写之后到 200MB、累计吃掉 35 秒 CPU，加密是有代价的。
按设备选，别按跑分选
- 电视、盒子、Kodi、Infuse：选 SMB。安卓电视、Apple TV、Windows 全都原生支持，不用装任何东西，吞吐也最高。
- iPhone / iPad 文件 App、笔记软件、跨平台同步：选 WebDAV。iOS 原生就能挂，输个地址和账号即可；代价是目录大时慢，尽量按年份、按剧集分好子目录。
- 只认 FTP 的老设备：功放、打印机扫描、老相机、部分监控主机，只在内网开，别映射到公网。
- 需要走公网：WebDAV over TLS 或者 SFTP，绝对不要开裸 FTP，那是明文密码加明文文件。SFTP 最慢，但一个端口加一对密钥就能上，最省心。
- 千兆以内随便挑，2.5G 以上就别考虑 rclone 系了，直接上 SMB。
你们家里那台 NAS 或小主机，最后留下来的是哪个协议？