关于文件传输协议的历史，带你了解文件传输协议

FTP（“文件传输协议”）是所有基于TCP的现代文件传输协议的鼻祖。FTP的默认端口是端口21。不管您对这个古老而扩展的文件传输协议有何个人感受或经验，您都必须熟练使用文件传输协议才能在任何现代文件传输情况下均有效，因为将所有其他文件传输协议都与之进行了比较。还应该知道FTP / S是什么以及它是如何工作的，因为FTP和SSL / TLS的组合将为未来几年的许多安全文件传输提供支持。

历史

1、第一代文件传输协议（1971-1980）

FTP的原始规范（RFC 114）由MIT的Abhay Bhushan于1971年发布。该标准引入了直到今天仍然存在的许多概念和约定，包括：

ASCII与“二进制”传输；

用户名身份验证（在此阶段密码“精细”且“不建议”）；

“检索”，“存储”，“追加”，“删除”和“重命名”命令；

部分和可恢复的文件传输；

协议“设计为可扩展”；

两个独立的通道：一个用于“控制信息”，另一个用于“数据”；

未解决的字符翻译和阻塞因素问题；

2、第二代文件传输协议（1980-1997）

第二代FTP（RFC 765）由ITI的Jon Postel于1980年推出。该标准淘汰了RFC 114，并引入了直到今天仍然有效的更多概念和约定，包括：

单独的客户端/服务器功能和两个单独的渠道的正式体系结构；

所有服务器所需的最低实现；

站点到站点传输（又名FXP）；

使用“ TYPE”命令参数（例如“ A”或“ E”）要求服务器执行其最佳字符并阻止翻译工作；

密码验证和键入密码的客户端掩码约定；

新的“ ACCT”命令指示身份验证期间的备用用户上下文；

新的“ LIST”，“ NLST”和“ CWD”命令使最终用户可以体验熟悉的基于目录的界面；

新的“ SITE”和“ HELP”命令使最终用户可以询问服务器其功能以及如何访问该功能；

修改了“ RETR”，“ STOR”，“ APPE”，“ DELE”，“ RNFR / RNTO”和“ REST”命令，以替换以前版本中更短的命令。

一个新的“ NOOP”命令可以简单地从远程服务器获取响应。

使用“ I”表示二进制数据（“ I”表示“图像”）

被动（又称“防火墙友好”）传输模式

3位数字后跟文本命令响应约定。3位数命令响应的第一位数的含义是：

1xx：初步肯定答复；用户应该期待另一个最终答复。

2xx：最终的肯定答复：任何尝试的方法都有效。用户可以尝试其他命令。

3xx：中级肯定答复：用户在多命令链中输入的最后一个命令有效，用户应在链中输入下一个预期命令。（在身份验证期间很常见，例如“ 331用户名正确，需要密码”）

4xx：中级肯定答复：用户在多命令链中输入的最后一个命令不起作用，但是鼓励用户再次尝试或重新开始命令序列。（在数据传输过程中被关闭的端口阻塞很常见，例如“ 425无法打开数据连接”）

5xx：最终否定答复：刚刚尝试的任何方法均无效。

ISI的Jon Postel和Joyce Reynolds于1985年推出了新的第二代规范（RFC 959）。该标准已淘汰RFC 765，但仅引入了一些新概念和约定。最重要的增加是：

新的“ CDUP”，“ RMD / MKD”和“ PWD”命令进一步增强了最终用户的远程目录体验。

在这一点上，FTP协议已经在几乎所有已编写的IP可寻址操作系统上进行了测试，并且可以使Internet扩展到学术界以外。特定于供应商或非RFC的约定填补了RFC 959所未涵盖的所有壁ni，但核心协议在过去的十年中保持不变。

从1991年到1994年，由于Gopher系统允许用户通过以前在分散的拨号系统上隔离的高速TCP链接查找和共享文件和内容，FTP可以说是“园区中最酷的协议”。

RFC 959下的FTP甚至幸免于端口过滤和基于代理的防火墙的发明。部分原因是由于广泛使用的PASV命令序列使数据连接成为入站连接。在某种程度上，这也是因为防火墙甚至路由器供应商都特别注意解决这种最流行协议的多端口，会话感知特性，即使在实施NAT时也是如此。

3、第三代文件传输协议（1997年至今）

第三代和最新的FTP是对RFC 959未解决的两项技术的反应：SSL / TLS和IPv6。但是，RFC 959在这一代并没有被取代：相反，它通过解决这些现代技术挑战的三个关键RFC得到了增强。

4、第三代（1997年至今）：FTPS

RFC 959未解决的第一种技术是使用SSL（后来的TLS）保护TCP流的安全。当SSL与FTP结合使用时，它创建了新的FTPS协议。几年前，Netscape通过将SSL与HTTP结合创建了“ HTTPS”。“ FTPS”上的“ trailing S”保留了此约定。

通过将SSL与FTP结合在一起的努力，Bellcore提出了RFC 2228，并且在FTPS实施中出现了三向分裂。这种分裂在当今的行业中仍然存在，但已被简化为仅两个主要实现：“隐式”和“显式” FTPS。（最初有两个“显式” FTPS的竞争实现，但一个赢了。）

尚存的“隐式”和“显式” FTPS模式之间的区别是：

隐式FTPS要求FTP控制通道在传递任何命令之前协商并完成SSL / TLS会话。因此，通过这种命令通道的任何FTP命令都将受到SSL / TLS的隐式保护。

许多从业者认为这是FTPS的更安全和可靠的版本，因为没有FTP命令在明晰的中间路由器中发送过，因此没有机会误解在显式模式下使用的明文命令。

显式FTPS要求FTP控制通道使用明文TCP通道进行连接，然后选择使用显式FTP命令（例如“ AUTH”，“ PROT”和“ PBSZ”）对命令通道进行加密。

显式FTPS是FTPS的“正式”版本，因为它是IBM的Paul Ford-Hutchinson在RFC 4217中指定的唯一FTPS。没有RFC涵盖“隐式模式”，并且可能永远不会有“隐式模式” RFC。但是，显式模式的明文命令很容易被中间系统破坏，或者通过偶尔通过初始明文通道发送的“ USER”命令而导致证书泄漏。

几乎所有的商业FTP供应商和许多可行的非商业或开源FTP软件包都已经实现了RFC 2228。这些相同的供应商和软件包中的大多数也已实现RFC 4217。

5、第三代（1997年至今）：IPv6

RFC 959未解决的第二种技术是IPv6。1971-1985年RFC中有许多结构绝对需要IPv4地址。（SEVERAL FOLKS）的RFC 2428回答了这一挑战。通过引入巧妙的小EPSV命令，该规范还考虑了通过防火墙和NAT的网络使用FTPS的早期和糟糕的经验。

但是，EPSV命令本身并不能解决文件传输社区正在使遗留客户端和服务器（即那些未实现RFC 2428的客户端和服务器）在早期仍未成熟的防火墙集合中工作的巨大问题。 2000年代。为了满足这一需求，围绕服务器定义的端口范围的社区约定在2003年左右出现。通过采用该约定，服务器管理员可以在防火墙中打开端口21和“较小范围的数据端口”，以限制他的暴露范围。 /否则，她将开放所有高端口到FTP服务器。

尽管RFC 2428至今（截至2011年）已有13年的历史，但在现代FTP中对IPv6和EPSV命令的支持仍然很少见。IPv6和FTP身份作为协议“被设计为可扩展”的缓慢采用，使服务器管理员和FTP开发人员通过坚持使用IPv4并实施防火墙和NAT解决方案已有十多年的时间，从而避免了剩下的问题。尽管如此，对IPv6和EPSV的支持仍然是对不可避免的未来的强大防御。明智地对待那些未能实施RFC 2428或对RFC 2428不感兴趣的文件传输供应商和开源项目。

最佳实践：互操作性最低的FTP实现将完全符合RFC 959（FTP的1985年修订版）。所有可靠的文件传输供应商和项目都已经实现了RFC 2228（添加SSL / TLS），并应提供客户端证书身份验证支持作为其当前实现的一部分。任何认真考虑对其FTP软件提供长期支持的供应商或项目，已经实施了RFC 2428（IPv6和EPSV），或已将其计划在其开发计划中。前瞻性供应商和项目已经在考虑各种FTP IETF草案，这些草案将完整性检查和更多目录命令标准化。

镭速文件传输协议特点：

镭速传输协议主要技术原理

镭速传输协议主要通过如下两方面来改善传输效率：更有效的拥塞判断及处理； 更准确及时地进行丢包判断恢复制机制；

更有效的拥塞判断及处理

目前主流的拥塞判断是基于二十几年前的网络情况设计的，其基本假设是任何丢包都反映了网络拥塞。这一假设与现代网络情况已完全脱节。现代网络丢包常常并不是由拥塞因素引起的。这一脱节导致传输协议常常进入过于保守的传输状态。

镭速传输协议拥塞检测算法会自动收集路径上已有的背景传输信息（丢包、时延以及抖动），根据传输速度准确判断出实际的拥塞情况，既不过于保守也不过于激进，可以有效充分利用路径带宽。

镭速传输提供一站式文件传输加速解决方案，旨在为IT、影视、生物基因、制造业等众多行业客户实现高性能、安全、稳定的数据传输加速服务。传统文件传输方式（如FTP/HTTP/CIFS）在传输速度、传输安全、系统管控等多个方面存在问题，而镭速文件传输解决方案通过自主研发、技术创新，可满足客户在文件传输加速、传输安全、可管可控等全方位的需求。