跳到主要内容

2.3 FTP模型

根据上述定义, 可以为FTP服务绘制以下模型 (如图1所示).

                                            -------------
|/---------\|
|| User || --------
||Interface|`<--->`| User |
|\---------/| --------
---------- | User-PI |
|/------\| FTP Commands | User-DTP |
||Server|`<---------------->`| |
|| PI || FTP Replies -------------
|\------/|
|/------\|
||Server||
|| DTP ||
|\------/|
----------

Server-FTP User-FTP

图1 FTP使用模型

在此模型中, 用户协议解释器 (User-PI) 发起控制连接. 控制连接遵循Telnet协议, 在用户的发起下, 用户PI和服务器PI之间发送一组标准命令和回复. 此连接用于传输描述要执行功能的命令以及对这些命令的回复. 这些命令可能表明需要建立第二个连接 (数据连接) 来执行数据传输功能. 用户数据传输进程 (User-DTP) 应在指定的数据端口上"监听", 这应在发送传输请求命令之前完成. 服务器从其数据传输进程 (Server-DTP) 发起数据连接, 并连接到监听的数据端口. 连接建立的方向很重要. 在另一种情况下, 用户可能会发起到服务器DTP的数据连接. 这类连接被定义为被动连接.

数据连接在传输时打开, 传输完成时关闭. 通过数据连接传输的数据包括要存储在服务器主机上的数据、从服务器主机检索的数据或用于执行服务器端功能的数据. 在第三种情况下, 通过数据连接传输的信息可能供服务器站点的应用程序使用, 而不是实际存储为文件. 这些数据连接的一般用途包括在服务器站点的检索、存储和执行.

通信

用户PI和服务器PI通过交换标准FTP命令集来执行用户协议. 数据传输通过在单独的数据连接上传输数据来执行. 此过程允许控制和数据传输在独立路径上进行.

用户PI发起所有命令, 服务器PI以FTP回复响应. 用户PI可以在不等待回复的情况下发送多个FTP命令. 服务器PI将按照收到命令的顺序回复每个发送的FTP命令. 如果服务器PI由于之前命令的结果正在执行耗时操作, 回复可能会延迟. 如果发生这种情况, 服务器PI可能会发送初步回复, 表明命令已收到但处理尚未完成. 操作完成后, 服务器PI将发送完成回复.

FTP回复旨在确保文件传输过程中请求和动作的同步, 并保证用户进程始终知道服务器的状态. 每个命令必须至少生成一个回复, 尽管可能有多个. 在后一种情况下, 多个回复必须易于区分. 此外, 某些命令以顺序组出现, 例如USER、PASS和ACCT, 或RNFR和RNTO. 如果所有前面的命令都成功, 回复会显示中间状态的存在. 序列中任何一点的失败都需要从头重复整个序列.

数据连接

传输数据的机制包括将数据连接设置到适当的端口并选择传输参数. 在传输发生之前, 双方必须就数据连接的参数达成一致. 这些参数包括: 数据端口、表示类型、结构和传输模式.

表示类型定义文件数据的表示方式. 这包括数据类型 (ASCII、EBCDIC或图像) 和格式控制. 结构定义文件的结构方式. 支持三种结构: 文件结构、记录结构和页结构. 传输模式定义数据的传输方式. 定义了三种传输模式: 流模式、块模式和压缩模式.

这些参数的选择通过用户PI和服务器PI之间的FTP命令和回复交换来协商. 这些参数的默认值在协议中定义. 如果用户未指定参数, 则假定使用默认值.