文件传输诸协议

文件传输诸协议把网络设备上最常见的几套「把一个文件搬到另一台机器」的做法并列记录：FTP、SFTP、TFTP、FTPS、WebDAV、rsync 与对象存储式上传。本页属现实技术说明，重点是它们不是同一件事的不同拼写——尤其是 SFTP 与 FTPS 的混淆。凡具体端口号与安全强度，均以对应文档与现网配置为准；本馆未逐格复核处已注明。

一、先看端口：一眼分辨

关于端口

端口号只是通行约定，任何服务都可以被改到别的端口。真正的分辨方法是握手特征：FTP 从 `220` 应答开始，SSH 系从版本串开始，TFTP 从 UDP 上的读/写请求开始。

二、FTP：双通道设计与它的后果

RFC 959 定义的 FTP 与众不同之处是两条连接：一条控制连接下命令，一条数据连接传内容与目录列表。

主动与被动

主动模式（PORT）：客户端告诉服务器「我某端口在听」，服务器反向连过来。在客户端位于 NAT 或防火墙后面的今天，这条基本走不通。

被动模式（PASV）：服务器开一个临时端口并告诉客户端，客户端连过去。这是现代部署的默认做法，代价是服务器侧需要一段可配置的端口范围，并且防火墙要放行这段范围。

IPv6 下对应的是 `EPSV`/`EPRT`（RFC 2428）。

常见命令与它们的用途

`USER`/`PASS` 认证，`SYST` 探平台，`TYPE` 选文本或二进制，`PASV`/`PORT` 建数据通道，`RETR`/`STOR` 收发文件，`LIST`/`NLST` 取目录，`MLSD` 取机器可读目录列表，`CWD`/`PWD`/`MKD`/`RMD` 目录操作，`RNFR`/`RNTO` 改名，`REST` 指定续传偏移，`QUIT` 退出。

三个设计留下的坑

一、`TYPE A`（ASCII）会改写换行。用它传图片、压缩包或二进制固件会静默损坏文件——这是最古老也最常见的事故之一。上传下载一律用二进制模式。

二、`LIST` 的输出格式不统一。各家服务器的目录列表字段与语言都不同，脚本解析 `LIST` 长期脆弱；机器可读的应用 `MLSD`（其规范口径本馆未复核）。

三、凭据明文。控制连接上的口令以明文传输，任何能在路径上抓包的人都能拿到。这是 FTP 在合规场景里被禁用的首要理由，不是「不够快」。

匿名 FTP

以 `anonymous` 加任意邮箱式口令登录的做法由 RFC 1579 记录，如今多被视为遗留（其当前状态本馆未复核）。公开分发已转向 HTTPS 与对象存储。

三、FTPS 与 SFTP：两条完全不同的加密路

最容易被搞错的一句

「我们把 FTP 换成 SFTP」和「我们把 FTP 换成 FTPS」不是同一个工程。前者通常只开放一个端口、认证并入 SSH 体系；后者保留 FTP 的双通道语义，防火墙与客户端策略都要跟着改。

四、TFTP：极简到只能干一件事

RFC 1350 定义的 TFTP 只有读与写，运行在 UDP 上，用「发一封等一封」的停止等待方式传输，默认数据块很小（512 字节口径）。它的扩展把块大小、超时与文件大小协商加了进来（RFC 2347 至 2349 一族）。

它为什么还活着

因为它小到可以被写进固件与网卡引导代码：无认证、无目录语义、无 TLS，也就没有依赖。

典型用途是网络启动（PXE/UEFI）、交换机路由器救援与配置加载、瘦终端取镜像。

它不能做什么

不能当通用文件服务用：除了停止等待的重试之外它几乎没有别的能力，没有访问控制，公网暴露的 TFTP 属于高风险配置。

五、HTTP 一系与「现代大文件」

WebDAV（RFC 4918）

给 HTTP 加上写语义：`PROPFIND`/`MKCOL`/`PUT`/`COPY`/`MOVE`/`LOCK`。适合「像访问文件夹一样访问远端」的场景，但它带着文件系统的假设（锁、原子性）跑在不可靠网络上，跨广域网时性能与一致性都要单独验证。

断点续传与分块

Range 请求让「传一半接着传」成为 HTTP 的常规能力；分块上传与「先上传片段、再合并」是对象存储面对大文件的标准做法。

对象存储式上传

预签名 URL、分段上传、服务端复制——这类接口的通行事实标准来自某家公有云的对象存储 API，而非正式标准文档。它们的价值在于：不需要在防火墙上开洞，不需要长连接，凭据是有时效的。

超宽距加速

高带宽时延积的链路上，单条 TCP 流的窗口会先撞墙；多流并行、专用拥塞控制与前向纠错一类的做法被用于跨洲大文件搬运。本馆只记其名目，不为其效果背书。

六、rsync 与「同步」不是一回事

rsync 的长处是先算差异、只补差量，并保留权限与时间戳，因此适合备份与目录镜像。它常常直接跑在 SSH 上，从而不必单独开端口。

「传输协议」与「同步语义」的区别值得写在选型表里：一次成功的传输不等于两端一致；一致性需要校验（清单、哈希）与冲突策略，而这通常不在传输协议的能力范围内。

七、共享文件系统访问：常被当成传输协议

SMB（445）与 NFS（2049）提供的是远程文件语义：应用以为自己在读写本地文件，协议按字节范围工作。它们与「把文件从 A 搬到 B」的区别是：断点概念不适用、依赖在线与低时延、权限模型（域/密钥表）完全不同。跨广域网把 SMB 当传输用是常见的设计错误。

八、怎么选：三件事决定

1. 信任模型：谁能拿到凭据？凭据是否会明文出现在抓包里？是否要接入统一认证与审计？——决定 FTP 能不能留、要不要证书与密钥。
2. 穿越：中间有几层 NAT 与防火墙？能否开被动端口范围？是否只允许出向 443？——决定 FTPS 与 SFTP 谁更好办。
3. 失败之后：能不能续传、要不要校验、失败是否留痕？——决定对象存储分块与 rsync 这类方案的价值。

一句结论

传输协议的差异主要在语义与信任上，不在速度上。绝大多数「传得慢」的原因是带宽、往返时延与单流窗口，而不是协议名字。

九、六个安全与合规提醒

• 仍在提供明文 FTP 的设备，把它的账号视同已泄露；口令复用会把风险带到别处。
• 面向公网的匿名上传目录是常见的恶意软件落地点；必须限配额、限类型、限速率并留日志。
• 「能登录」不等于「只能看自己的目录」：检查根目录锁定、符号链接逃逸与越权改名。
• 二进制与文本模式（FTP）或换行处理（脚本）造成的静默损坏，要靠校验和发现，不要靠肉眼。
• 传输日志的保留期与内容，常受合规要求约束；不同辖区不同，本馆不给现值。
• 强算法与密钥长度的具体要求随时间与标准版本变化，本馆不写「某算法绝对安全」。

参见

• 网络标准入门 · 双绞线与8P8C · 光电模块 · 光纤与连接器
• 网络管理协议与发现协议 · 无线局域网标准 · 以太网速率谱系

出处

• FTP：RFC 959；安全扩展：RFC 2228、RFC 4217；IPv6 扩展：RFC 2428；匿名用法：RFC 1579。TFTP：RFC 1350 与选项扩展 RFC 2347–2349。WebDAV：RFC 4918。SFTP：IETF 草案族（draft-ietf-secsh-filexfer 系列），从未成为正式 RFC 标准。^[1]
• rsync、scp、对象存储多段上传与预签名 URL 为事实标准或工具行为，无正式标准文档；本馆按其通行行为描述，不复述实现细节。
• 「怎么选」与「六个安全与合规提醒」为本馆撮合的操作归纳，属「本馆推定」。