在互联网中,大家能够相互连接,通信之后就有着一个人之常情的需求:相互传输文件,分享数据。
面对这个需求我们需要考虑几件事:
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并不要求客户端把整个文档拉过去,而是有选择的拉,如果读取一个文件,本地下载下来的仅仅是其中一部分,这样极大的节约了本地的资源。如果修改文件也是会把指令发到服务器端。服务器端会对文件进行修改。看起来很好,但是缺点也有,一旦服务器端崩溃,任何一方均没有文件的备份,即:数据丢失。