关于通信网络和文件传输协议之间的关系
文件传输协议( FTP ) 是一种标准网络协议,用于通过基于 TCP/IP 的网络(例如Internet)交换和操作文件。文件传输协议是建立在客户端与服务器架构上,并在客户端和服务器应用程序之间使用单独的控制和数据连接。文件传输协议 也经常用作应用程序组件,为程序内部功能自动传输文件。文件传输协议可用于基于用户的密码验证或匿名用户访问。
文件传输协议的目标是:
促进文件(计算机程序和/或数据)的共享。
鼓励间接或隐含地使用远程计算机。
保护用户免受不同主机之间文件存储系统的变化。
可靠、高效地传输数据。
用户的可读性。
文件传输协议在传输控制协议 (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 上侦听数据连接将发送命令“post 192,168,0,1,192,2”。端口字段应解释为 p1×256 + p2 = 端口,或在本例中为 192×256 + 2 = 49154。
在被动模式下,FTP 服务器打开一个动态端口,向 FTP 客户端发送要连接的服务器的 IP 地址和它正在侦听的端口(一个 16 位值,分为高字节和低字节,如上所述)通过控制流并等待来自 FTP 客户端的连接。在这种情况下,FTP 客户端将连接的源端口绑定到动态端口。
要使用被动模式,客户端发送PASV命令,服务器将向该命令回复类似于“227 进入被动模式 (127,0,0,1,192,52)”的内容。IP 地址和端口的语法与 PORT 命令的参数相同。
在扩展被动模式下,FTP 服务器的操作与被动模式完全相同,但它只传输端口号(不分为高字节和低字节)并且客户端假定它连接到最初连接的同一 IP 地址至。
当数据通过数据流传输时,控制流处于空闲状态。这可能会导致通过防火墙的大数据传输出现问题,从而在长时间闲置后使会话超时。虽然文件很可能成功传输,但控制会话可能会被防火墙断开,从而导致生成错误。
文件传输协议支持使用 REST 命令恢复中断的下载。客户端将它已经收到的字节数作为参数传递给 REST 命令并重新开始传输。例如,在某些命令行客户端中,有一个经常被忽略但很有价值的命令“reget”(意思是“再次获取”),它将导致中断的“获取”命令在通信中断后继续执行,希望能完成。
恢复上传并不容易。尽管 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 模式。一些客户端尝试通过检查文件的名称或内容,或通过确定服务器是否运行具有相同文本文件格式的操作系统来确定所需的传输模式。
镭速自主研发的文件传输协议——raysync
镭速自主研发的文件传输协议解决客户跨国传输、远距离传输、大文件传输等问题,最大限度提高带宽效能,从而提高工作效率;
镭速传输协议主要传输技术指标参考
100Mbps 网络带宽下,不同的丢包率/时延传输对比
镭速传输协议支持的最大传输带宽
单个镭速传输协议进程/线程支持 1Gbps;
于用户传输带宽大于 1Gbps 的场景,可以通过部署负载均衡设备,在负载均衡设备后,部 署多个镭速传输协议进程/线程,可以支持水平扩展,传输能力无上限;
镭速文件传输协议FTP加速产品是专为企业定制开发的一款完全替代现有文件传输协议FTP的高效传输软件,能够在现有结构的基础上实现文件的高速传输,使用镭速文件传输协议FTP加速后,文件传输协议FTP传输速度可提升10-100倍;
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 一起使用而设计的特殊类型)。
FTP 服务器返回代码通过其中的数字指示其状态。各数字含义的简要说明如下:
1xx:积极的初步答复。请求的操作正在启动,但在它开始之前会有另一个回复。
2xx:肯定完成回复。请求的操作已完成。客户端现在可以发出新命令。
3xx:肯定的中间回复。命令成功,但在服务器可以对请求采取行动之前需要进一步的命令。
4xx:瞬态否定完成回复。命令没有成功,但客户端可以自由地再次尝试命令,因为失败只是暂时的。
5xx:永久否定完成回复。该命令未成功,客户端不应尝试再次重复该命令。
x0x:失败是由于语法错误。
x1x:此响应是对信息请求的回复。
x2x:该响应是与连接信息相关的回复。
x3x:该响应是与计费和授权相关的回复。
x4x:尚未指定
x5x:这些响应指示服务器文件系统相对于请求的传输或其他文件系统操作的状态。
匿名 FTP
提供 FTP 服务的主机可以另外提供匿名 FTP 访问。当提示输入用户名时,用户通常使用“匿名”帐户登录服务。尽管通常要求用户发送他们的电子邮件地址来代替密码,但实际上几乎没有对提供的数据执行验证。
由于现代 FTP 客户端通常对用户隐藏匿名登录过程,因此 ftp 客户端将提供虚拟数据作为密码(因为应用程序可能不知道用户的电子邮件地址)。例如,以下 ftp 用户代理为匿名登录指定列出的密码:
Mozilla Firefox (3.0.7) —mozilla@example.com
KDE Konqueror (3.5) —anonymous@
wget (1.10.2) — -wget@
lftp (3.4.4) — lftp@