§2.5应用层协议之网络世界中的文件传输

在互联网中，大家能够相互连接，通信之后就有着一个人之常情的需求：相互传输文件，分享数据。

面对这个需求我们需要考虑几件事：
1、现在的文件那么多种格式，不同的文件格式之间相互不兼容，应该怎么办？
2、传输文件的过程中是点对点的传输还是点对多点的传输？
3、如果是点对多点的传输那么提供文件的服务端，是不是会有很多文件可供人选择？是不是有不同的目录？
4、别人来我这里取文件是否需要进行验证身份？

面对这几个问题，就需要设计一个协议，来满足日常的文件传输需要。ftp协议便由此而生，除了以ftp为主要的文件传输协议之外，还有tftp协议、nfs协议也适用于日常的文件传输之中

FTP协议：

FTP协议（File Transfer Protocol）：FTP这一类的网络传输文件协议的出生就携带着使命，他们需要屏蔽各个文件不同的格式，不能因为一种文件格式不一样就单独开一个例子。因此FTP协议提出了4中传输文件类型：

统一文件格式：

• ASCII码文件类型：这是FTP协议默认的文件类型。在双方发送文件数据的时候，FTP协议会要求发送的一方把本地的文件转换为NVT ASCII码形式。在接收方收到了该文件之后，接收方会把接收到的NVT ASCII码还原成本地文件。这样就屏蔽了各个文件格式不同的情况
• EBCDIC文件类型：该文件类型不是FTP协议支持的主流的类型，如果使用该文件类型传输的话，要求两端都是EBCDIC系统。
• 图像文件类型：由于图形文件及文字处理程序等计算机程序都属于二进制文件。这些文件含有特殊的格式及计算机代码。因此FTP协议也需要支持该种文件的传输方式。在该种文件传输时数据发送呈现为一个连续的比特流。
• 本地文件类型：该方式在具有不同字节大小的主机间传输二进制文件。每一字节的比特数由发方规定。对使用8bit字节的系统来说，本地文件以8bit字节传输就等同于图像文件传输。

FTP协议通过以上四种文件类型，统一了需要传输的文件格式。这样不同格式的文件对于ftp协议都一样了，就可以顺利的传输了。

传输

在做完了发送文件之前的准备工作之后，就要面临一个问题了，文件的传输。
这里需要考虑几件事情，如果这个协议设计出来至让一个用户传输一个文件就没什么意义了，普适性的协议设计出来是为了覆盖绝大多数的场景。

1、传输的文件肯定是多个文件要被传输。这就涉及到需要在多级目录中找到这个文件。而返回上级目录，是需要指令的
2、文件传输的时候需要传输用户名和密码，部分的文件是需要有较高的权限才能进行读写传输。

这个时候就出现了一个问题：对于传输一个大文件的时候，使用者肯定不会是在这里干等着；而是会到达其他的目录层级去看看是否有其他的文件。那么传输的连接以及被传输大文件在占用了。此时切换目录的之类该如何传输呢？

在传输大文件的数据包里加入“特快专递”的报文用于传输指令以及用户名和密码？

这样会不会影响传输的稳定性呢？

面对这个问题，FTP协议选择了建立两个并行的TCP连接：数据连接和控制连接。

控制连接：用于在两个主机之间传输控制信息，基本的标识、用户名密码、改变远程目录等都是使用这个连接。
数据连接：专职用于传输用户需要的文件

FTP协议工作模式

• 首先ftp 服务器准备进行工作，FTP服务器的主进程主动打开被大家熟知的端口号（21）。
• 接着等待客户机上的客户进程发出来连接请求
• 收到客户机发来的请求之后，FTP服务器的主进程创建一个从属进程进行处理客户机的请求
• 创建的第一个从属进程一般是控制进程，该进程通过现有的连接创建一条控制连接。 客户机通过控制连接发送一些基本的指令，以及查看目录等。
• 当FTP服务器端通过控制连接收到了客户机发过来的文件传输请求时，便会再次创建一个从属进程。此从属进程会再次调用一个端口，通过该端口创建数据连接，进行数据的传输。
• 因为考虑到在数据传输过程中可能客户会发送其他的指令，控制连接全程在线等待客户的指令（这就会导致一个问题）
• 小贴士：现有的网络设备基本上都具有一个功能——节约资源。比如一个防火墙发现通过自身的一个连接长时间的没有数据通过，则会认为该连接无用，进而切断。这个时刻FTP协议的控制连接会被切断，数据连接会一并被终止。导致文件传输失败。
• 当数据传输完毕的时候，由于FTP协议以文件结尾作为关闭数据连接的标志，这时FTP协议会关闭数据连接。但是此时控制连接并未关闭，仍可以进而查找另一个文件进行传输。但是对于其他文件来说，传输时是一个新的数据连接。
• 最后用户觉得文件传输完毕了，进而进行关闭连接。此时控制连接被释放

FTP服务器的运行模式

FTP服务器的运行模式又有两种划分——主动模式和被动模式

在FTP服务器工作时，客户端首先在本地随机打开一个大于1024的端口，用于和服务器端的TCP 21 端口进行建立控制连接；通过该端口进行发送命令

主动模式下：客户机打开本地的端口（假设端口号是N）；并启动N+1端口的监听，客户端需要收发数据时，通过控制连接发送PORT 指令，在PORT指令中告诉服务器端，自己本身计划用来接收数据信息的端口号是N+1

传输数据时，服务器端使用自己的TCP 20号端口与客户端在PORT指令中指定的端口进行连接。这样一来方便服务器端进行管理，因为所有与客户端建立的数据连接都在20号端口上。

不过随着安全意识的加强，客户端的防火墙一般不会放行本地所有端口，而客户端建立的N+1端口又是随机的，很有可能本地是在监听此端口，但是安全设备却拒绝了外界企图与N+1端口进行连接。这样怎么做都是无法正常传输数据的。

被动模式下：客户机打开本地的端口（假设端口号是N）；并打开另一个端口N+1,。当N端口和FTP服务器的21号端口建立的控制连接之后，需要传输文件是客户机端会向服务器端提交PASV指令。之后服务器端通过PORT指令向客户机发送一段代码：一般都是“227 entering passive mode (A1,A2,A3,A4,B1,B2)”
A1-A4就是服务器自己的ip地址，通过该字段组合在一起告诉客户机自己的ip地址是多少，以便建立连接；B1，B2用于表征端口号。客户机本地计划监听的端口号是B1*256+B2。
收到了ip地址和端口号之后，客户机通过N+1端口与该端口建立连接。进而传输数据。

这样做了之后需要服务器端的防火墙进行配置策略进行放行。防止服务器端的高位端口被阻塞。

一方面是服务器端的防火墙，一方面是客户端的防火墙。在这两种情况下我们想要有一种兼得的模式，因为就算是被动模式，放行FTP服务器端的所有端口也是不安全的。折中的办法就是，在FTP服务器上人为的指定一个范围，服务器端创建端口时，只会在该范围内进行创建。这样，只要服务器端放行该范围内的端口即可。

其他协议

与文件传输相关的协议远远不止FTP一个协议，下面我们来介绍其他几种协议：

HTTP协议：

HTTP协议其实也是涉及到文件传输的一个协议，日常在浏览器上访问网页时，浏览器都会把HTML文档下载到本地。这个时候就用到了HTTP协议传输文件的功能；与FTP协议不同的是HTTP协议是一个内带控制信息的协议。

HTTP本质上是一个面向连接的无状态协议。这句话是什么意思呢？各位还没有看到我介绍其他层的协议，这里简单的说一下：面向连接——意味着通信可靠。会有一条下层会为HTTP协议专用连接用于该连接；无状态意味着该协议没有记忆力，此次登录和上次登录对于服务器端看来完全是两个人。这是为什么呢？其中的原因之一可能是：设计的时候因为HTTP协议为了传输超文本，其中是有大量的文字，必须要进行精准的传达。同事也是因为有大量的文字，使用者一时半会看不完；进而不需要记忆，一个文档可能会读很长时间，记忆着比较占资源

由于HTTP是一个无状态的，即获取到需要的HTML文档之后后面基本上不会有其他的，协议是一次性拉取，很少会涉及到查看目录、传输多个文件等情况；所以该协议内置了控制信息；使用一个连接即可

TFTP协议：

在前人对FTP协议进行设计的时候，设计的比较周全，也导致了FTP协议存在一定的臃肿；在日常生活中部分的使用者完全不需要FTP那么多详细的功能，仅仅需要对文件进行传输。这样就出现了一个很小很容易实现的新的文件传输协议——TFPT协议

TFTP协议没有FTP那么复杂，它只提供文件的传输；不提供文件的交互（失去了一大票功能，比如：查看文件目录；用户名密码的验证等）；另外由于时代的发展，所谓的“不可靠传输”也不是那么的不可靠，出差的概率较低，这样TFTP协议进行了进一步简化，不再要求下层协议使用可靠的传输，因为下层出差的概率低，它自身提供差错验证的措施。

TFTP差错验证的方式也很简单：
1、防止报文丢失：收发两端都有计时器（DATA计时器和ACK计时器），一旦在一段时间内没有收到对方的报文，意味着报文丢失，进而要求对方重传。不过该协议要求发送方一个一个传数据。

2、防止报文出错：TFTP使用的不可靠协议，自带校验和，如果报文错了校验和就不对。TFTP协议不会尝试去修复数据，直接丢弃故障的数据，要求发送端进行重传

3、防止报文重复：通过编号防止报文重复，重复即丢弃。

NFS协议：

NFS（Network File System）协议和FTP这一类文件传输协议有着本质的区别；之前的协议思路都是的文件进行传输，一次就会传输一整个文件过去。想要读取文件，就要获取一个本地的副本。想要修改文件，就要对本地副本进行修改，然后发回服务器端进行替换。而NFS设计的目的是：共享。

NFS并不要求客户端把整个文档拉过去，而是有选择的拉，如果读取一个文件，本地下载下来的仅仅是其中一部分，这样极大的节约了本地的资源。如果修改文件也是会把指令发到服务器端。服务器端会对文件进行修改。看起来很好，但是缺点也有，一旦服务器端崩溃，任何一方均没有文件的备份，即：数据丢失。