java实现FTP协议:数据传输模型和相关命令说明

上文说过，一旦FTP数据发送双方建立控制命令通道和数据传输通道后，双方就可以发送数据。在数据传输中，FTP协议又规定了三种模式，分别是流模式，块模式和压缩模式。

流模式其实就是简单的将要传输的数据比特以一种连续的非结构化的方式在TCP协议的帮助下发送给对方，这里它就是一段数据，不存在包头或字段这类有关数据组织结构的信息。由于被传输的信息是裸数据，没有任何结构化组织，因此发送的准确性完全依赖于传输方和下层协议的稳定性，特别是数据传输完成就得依靠关闭数据通道来表示。

相比于其他两种模式，流模式的特点是效率高，因此在协议的实现中使用广泛。同时它实现简单，并且它将所有要传输的数据进行无差别对待，别管要传输的数据结构如何，它通通将其看做为字节流，因此就能隔离数据结构的复杂性对传输协议实现的影响。由此效率高，实现简单，传输数据复杂性隔离这三个特点使得这种传输模式成为FTP的实现主流。

第二种块模式是指，将要传输的数据切割成长度固定的若干各部分，每个部分在发送时使用包头等字段进行封装，使得发送的数据块相互间形成独立的数据包。包头含有三字节字段，分别表示块的长度以及其他相关数据。同时还有一种特别的算法用于对数据块进行追踪，如果数据块传输出现问题算法还能中断或者重启传输流程。

第三种是压缩模式。它使用游程编码对发送数据进行压缩，同时将压缩相关信息以包头字段的方式进行组织，这样对方收到后知道如何对数据进行解压缩，因此压缩模式使用包头+数据体的方式进行数据的组织发送。压缩模式由于实现的复杂性，在FTP协议中很少使用，除非在特定网络条件下需要尽可能减少数据传输量以保证效率和准确性时，该模式才会被采用。

文件传输类似ctrl+c和ctrl+v，区别在于复制操作是在同一台电脑内将数据从一个目录转移到另一个目录，文件传输是将数据从一台电脑转移到另一台电脑。但这是这一区别产生了一些问题，例如在windows上文本文件的结尾使用CR+LF表示，但在Mac系统上文本文件结尾使用CR表示，于是把一个文本文件从Mac拷贝到windows，在文件末尾处就容易出问题，为此FTP协议在传输数据时对数据类型增加了若干考虑。

首先FTP协议把数据分成4种形式加以考虑，一是ASCII，也就是文本为字符形式；二是EBCDIC，这类文件也是字符形式只不过字符来自IBM的EBCDIC字符集；三是图像，这类文件可以不用考虑不同系统之间的区别；四是局部形式，这类文件的特点是，一个字节长度不是由8个比特组成，某些特殊操作系统就有这种特性。我们在实践中只考虑情况一和三，对于情况一，协议要负责把文件结尾的符号根据系统进行修改，情况二中的图像文件不仅仅包括图像，像zip文件这类有同一格式的文件都属于图像。

在传输ASCII文件时，发送方每读取一行内容后就在后面添加字符CR+LF，接收方读取到这两个字符组合后知道这是一行结束，然后根据当前所在系统修改，如果接收方是Mac系统，那么就将这两个字符改为CR。由于FTP会对传输数据进行修改，因此在传输一定不能把”图像“类型的文件设置成ASCII类型，要不然”图像“类型文件中的二进制字符被修改后在接收方就无法打开文件。

接下来我们看看协议的数据包格式，特别是控制命令的数据包格式。FTP的控制命令有3种，第一种是接入控制命令，他对应用户登录和认证。第二种是传输控制命令，它用于双方协定数据如何传输，例如设置传输文件的类型，设定主动或被动传输模式；第三是FTP服务命令，这些命令用于发起数据传输，修改或删除文件等等。FTP在传输控制命令时使用Telnet协议，因此命令会以纯字符的形式进行发送，下面我们以列表方式对命令内容进行描述：

接下来我们看看控制命令相关说明：

接下来我们看看服务命令的说明：

后面我们还会再列出一些命令，然后查看数据包结构

更详细的讲解和代码调试演示过程，请点击链接

更多技术信息，包括操作系统，编译器，面试算法，机器学习，人工智能，请关照我的公众号：