通信网络/文件传输协议
文件传输协议 (FTP) 是一种标准网络协议,用于通过基于 TCP/IP 的网络(例如 互联网)交换和操作文件。FTP 建立在客户端-服务器架构之上,并在客户端和服务器应用程序之间使用单独的控制和数据连接。FTP 也经常用作应用程序组件,以自动传输文件以供程序内部功能使用。FTP 可以与基于用户的密码身份验证或匿名用户访问一起使用。
FTP 的目标,如其 RFC 所述,是
- 促进文件共享(计算机程序和/或数据)。
- 鼓励间接或隐式使用远程计算机。
- 屏蔽用户在不同主机之间文件存储系统上的差异。
- 可靠且高效地传输数据。
- 授予最终用户可读性。
FTP 运行在传输控制协议 (TCP) 之上。通常,FTP 服务器在众所周知的端口号 21(IANA 保留)上侦听来自客户端的传入连接。与来自 FTP 客户端的此端口的连接形成控制流,命令通过该控制流传递到 FTP 服务器,并收集响应。FTP 使用带外控制;它在其他端口号上打开专用的数据连接。数据流的参数取决于具体请求的传输模式。数据连接通常使用端口号 20。
在主动模式中,FTP 客户端打开一个动态端口,在控制流上向 FTP 服务器发送它正在侦听的动态端口号,并等待来自 FTP 服务器的连接。当 FTP 服务器启动与 FTP 客户端的数据连接时,它将源端口绑定到 FTP 服务器上的端口 20。
为了使用主动模式,客户端发送一个 PORT 命令,其中包含 IP 和端口作为参数。IP 和端口的格式为“h1,h2,h3,h4,p1,p2”。每个字段是主机 IP 的 8 位的十进制表示,后面跟着所选的数据端口。例如,具有 IP 地址 192.168.0.1 的客户端,它在端口 49154 上侦听数据连接,将发送命令“PORT 192,168,0,1,192,2”。端口字段应解释为 p1×256 + p2 = 端口,或者在本例中为 192×256 + 2 = 49154。
在被动模式中,FTP 服务器打开一个动态端口,通过控制流向 FTP 客户端发送要连接的服务器 IP 地址和它正在侦听的端口(一个分成高字节和低字节的 16 位值,如上所述),并等待来自 FTP 客户端的连接。在这种情况下,FTP 客户端将连接的源端口绑定到动态端口。
要使用被动模式,客户端发送PASV命令,服务器将以类似于“227 Entering Passive Mode (127,0,0,1,192,52)”的响应进行回复。IP 地址和端口的语法与 PORT 命令参数的语法相同。
在扩展被动模式中,FTP 服务器的操作方式与被动模式完全相同,但它只传输端口号(而不是分成高字节和低字节),客户端应该假定它连接到最初连接的同一个 IP 地址。
当通过数据流传输数据时,控制流处于空闲状态。这会导致通过防火墙进行大型数据传输出现问题,因为防火墙会在长时间的空闲后超时会话。虽然文件可能已成功传输,但防火墙可能会断开控制会话,从而导致生成错误。
FTP 协议支持使用 REST 命令恢复中断的下载。客户端将已接收的字节数作为参数传递给 REST 命令,然后重新启动传输。例如,在某些命令行客户端中,有一个经常被忽略但很有价值的命令“reget”(表示“重新获取”),它会导致在通信中断后继续中断的“get”命令,希望能够完成。
恢复上传并不容易。虽然 FTP 协议支持 APPE 命令将数据追加到服务器上的文件,但客户端不知道传输中断的确切位置。它必须通过其他方式获取文件的大小,例如通过目录列表或使用 SIZE 命令。
在 ASCII 模式(见下文)中,如果客户端和服务器使用不同的行尾字符,恢复传输可能会很麻烦。
在通过网络传输数据时,可以使用多种数据表示形式。两种最常见的传输模式是
- ASCII 模式
- 二进制模式:在“二进制模式”下,发送机器逐字节地发送每个文件字节,因此接收者按接收到的方式存储字节流。(FTP 标准称之为“IMAGE”或“I”模式)
在 ASCII 模式下,任何形式的非纯文本数据都会被破坏。当使用 ASCII 类型的传输发送文件时,单个字母、数字和字符使用其 ASCII 字符代码发送。接收机器将这些代码保存到适当格式的文本文件中(例如,Unix 机器将其保存为 Unix 格式,Windows 机器将其保存为 Windows 格式)。因此,如果使用 ASCII 传输,可以假定发送的是纯文本,接收计算机将其保存为自己的格式。文本格式之间的转换可能需要用目标平台上的行尾和文件尾字符替换源平台上使用的字符,例如,从 Unix 机器接收文件的 Windows 机器将用回车换行对替换换行符。它也可能涉及字符转换;例如,当从 IBM 大型机传输到使用 ASCII 的系统时,大型机上使用的 EBCDIC 字符将转换为其 ASCII 等效项,而当从使用 ASCII 的系统传输到大型机时,ASCII 字符将转换为其 EBCDIC 等效项。
默认情况下,大多数 FTP 客户端使用 ASCII 模式。一些客户端尝试通过检查文件名或内容,或确定服务器是否运行具有相同文本文件格式的操作系统,来确定所需的传输模式。
FTP 规范还列出了以下传输模式
- EBCDIC 模式 - 此模式传输字节,但它们使用 EBCDIC 而不是 ASCII 编码。因此,例如,ASCII 模式服务器
- 本地模式 - 此模式专为与面向字而不是面向字节的系统一起使用而设计。例如,模式“L 36”可用于在两台 36 位机器之间传输二进制数据。在 L 模式下,字被打包成字节,而不是被填充。一些 FTP 服务器接受“L 8”作为“I”的等效项。
实际上,这些额外的传输模式很少使用。但是,它们仍然被一些旧的大型机系统使用。
文本(ASCII/EBCDIC)模式也可以使用所用回车控制的类型进行限定(例如,TELNET NVT 回车控制,ASA 回车控制),尽管现在很少使用。
请注意,术语“模式”在技术上是不正确的,尽管 FTP 客户端经常使用它。在 RFC 959 中,“MODE”是指协议数据流的格式(STREAM、BLOCK 或 COMPRESSED),而不是底层文件的格式。通常称为“模式”的实际上是“TYPE”,它指定文件的格式而不是数据流的格式。FTP 还支持文件结构的规范(“STRU”),它可以是 FILE(面向流的文件)、RECORD(面向记录的文件)或 PAGE(专为与 TENEX 一起使用而设计的特殊类型)。PAGE STRU 对于非 TENEX 系统来说实际上没有用处,RFC 1123 第 4.1.2.3 节建议不要实现它。
FTP 服务器返回码通过其中的数字指示其状态。下面简要说明了各种数字的含义
- 1xx:正向初步回复。正在启动请求的操作,但在开始之前将有另一个回复。
- 2xx:正向完成回复。请求的操作已完成。客户端现在可以发出新命令。
- 3xx:正向中间回复。命令已成功,但需要进一步命令才能使服务器对请求采取行动。
- 4xx:瞬态负向完成回复。命令未成功,但客户端可以自由地尝试重新执行该命令,因为该错误只是暂时的。
- 5xx:永久性负向完成回复。命令未成功,客户端不应尝试再次执行该命令。
- x0x:错误是由于语法错误造成的。
- x1x:此响应是对信息请求的回复。
- x2x:此响应是对与连接信息相关的回复。
- x3x:此响应是对与记账和授权相关的回复。
- x4x:尚未指定
- x5x:这些响应指示服务器文件系统相对于请求的传输或其他文件系统操作的状态。
提供 FTP 服务的主机可能还会提供匿名 FTP 访问。用户通常在被提示用户名时使用“匿名”帐户登录。虽然通常会要求用户提供他们的电子邮件地址代替密码,但实际上对所提供数据的验证很少或根本没有进行。
由于现代 FTP 客户端通常会隐藏匿名登录过程,因此 ftp 客户端会提供虚拟数据作为密码(因为用户的电子邮件地址可能对应用程序未知)。例如,以下 ftp 用户代理为匿名登录指定了列出的密码
- Mozilla Firefox (3.0.7) —
[email protected]
- KDE Konqueror (3.5) —
anonymous@
- wget (1.10.2) —
-wget@
- lftp (3.4.4) —
lftp@
在 Windows 中输入 ftp /?,或在 Unix 中输入 ftp --help,以获取命令参数。
连接到服务器后,输入 help 以显示不同的可用命令。
要使用鼠标操作文件,请下载一个好的 FTP 客户端,它将提供界面(例如 这个 Filezilla 不需要任何安装)。