高速文件传输简史：从 FTP、TCP 扩充到 QUIC

从 FTP 的控制与数据连接、TCP 窗口扩充，到 UDP 加速、并行传输与 QUIC，了解各项技术解决的文件交付问题。

WarpSend Team 内容核查 Charlie 2026年5月25日更新 2026年9月24日 3 分钟阅读

跨洲交付大量数据时，带宽、延迟、可靠性与应用程序的处理方式必须一起考虑。文件传输技术的演进，也一直围绕这些问题：如何让更多数据持续在途、如何恢复丢失的数据包，以及如何减少每个文件的协调成本。

从 FTP、TCP 扩充到 UDP 传输与代管交付服务，这些技术形成了不同的选择。了解各自解决的问题，比单看协议年份更有助于评估今天的工作流程。

1971–1985：FTP 创建互通的文件传输方式

1971 年的 RFC 114 是早期文件传输提案之一。FTP 随网络演进而多次修订，1985 年的 RFC 959记录了发展过程，并定义以 TCP 运作的控制连接与数据连接。

这种分工让不同主机能交换指令与文件。常见串流 mode 以关闭数据连接表示文件结束，因此大量小文件的传输会反复创建数据路径；控制连接则可以保留。这个成本在高延迟网络上更容易影响总工时。

RFC 1323于 1992 年提出窗口缩放与时间戳记等扩充，让 TCP 在高带宽延迟乘积路径上维持更多在途数据。1996 年的 RFC 2018则定义选择性确认，让接收端更精确地回报哪些数据已收到。

TCP 本来就能连续发送窗口内的数据，并非每个数据包都停下来等待确认。这些改进扩大了可用窗口与丢包恢复能力；现代 TCP 的性能仍取决于实作、设置与路径条件。

UDT在 UDP 上提供可靠传输与可调整的拥塞控制，针对高带宽、高延迟网络的数据搬移。Aspera 的 FASP 也以 UDP 数据传输与应用层控制处理长距离交付。这些设计需要自行管理可靠性、速率与网络共用，UDP 本身不会保证文件完整或自动加速。

另一条路线是并行 TCP。GridFTP 扩充 FTP 的平行与分布式数据传输能力；它使用 TCP，不能和 UDP 协议归为同一种传输架构。不同方案都在减少闲置或协调成本，但采取的机制并不相同。

Meta 的 Warp Speed Data Transfer（WDT）提供可嵌入的函数库与命令行工具，通过多条 TCP 路径在两个系统之间搬移数据。它说明了并行传输可以创建在 TCP 之上，性能并不只取决于是否采用 UDP。

TCP 拥塞控制也持续发展。评估传输工具时，需要比较实际使用的内核、算法、窗口与应用程序设置，不能将早期 TCP 的限制视为所有现代连接的固定表现。

RFC 9000将 QUIC 定义为创建在 UDP 上、具有多路串流与安全机制的传输协议。它把可靠传输、流量控制与连接管理放在 QUIC 层处理，并为 HTTP/3 提供传输基础。

QUIC 是通用传输协议，可以承载多种应用。实际文件交付还需要处理文件夹、续传、权限与完整性等问题，因此支持 QUIC 并不等于已经提供完整的文件工作流程。

云端暂存改变的是交付时序：发送者先上传，服务保留一份可下载副本，收件者之后再取用。这适合跨时区与多人交件，但要纳入保留期限、存储与流量计费，以及数据所在位置。

端点直传则适合双方设备可连接、希望直接把内容写到目的端的情境。这两种模式可以并用，不必把每一项交付都限制在相同路径。

WarpSend 把端点直传、加密 Shuttle 暂存、浏览器分享与收件、文件夹同步集成为工作流程。直连成功时，文件内容不存入云端对象存储；需要异步交付时，则可选择适合的代管路径。

选工具时，先确认数据必须送到哪里、何时完成、是否需要保留版本，再用代表性数据测试。你可以参考长距离传输指南创建测试，或试用 WarpSend。现行服务与计费方式见价格页。