前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >速读原著-TCP/IP(FTP协议)

速读原著-TCP/IP(FTP协议)

作者头像
cwl_java
发布2020-03-18 11:17:37
8900
发布2020-03-18 11:17:37
举报
文章被收录于专栏:cwl_Javacwl_Java

第27章 FTP:文件传送协议

27.2 FTP协议

F T P与我们已描述的另一种应用不同,它采用两个 T C P连接来传输一个文件。

  1. 控制连接以通常的客户服务器方式建立。服务器以被动方式打开众所周知的用于F T P的端口( 2 1),等待客户的连接。客户则以主动方式打开 T C P端口2 1,来建立连接。控制连接始终等待客户与服务器之间的通信。该连接将命令从客户传给服务器, 并传回服务器的应答。由于命令通常是由用户键入的,所以I P对控制连接的服务类型就是“最大限度地减小迟延”。
  2. 每当一个文件在客户与服务器之间传输时,就创建一个数据连接。(其他时间也可以创建,后面我们将说到)。由于该连接用于传输目的,所以I P对数据连接的服务特点就是“最大限度提高吞吐量”。 图2 7 - 1描述了客户与服务器以及它们之间的连接情况从图中可以看出,交互式用户通常不处理在控制连接中转换的命令和应答。

这些细节均由两个协议解释器来完成。标有“用户接口”的方框功能是按用户所需提供各种交互界面(全屏幕菜单选择,逐行输入命令,等等),并把它们转换成在控制连接上发送的 F T P命令。类似地,从控制连接上传回的服务器应答也被转换成用户所需的交互格式。

从图中还可以看出,正是这两个协议解释器根据需要激活文件传送功能。

27.2.1 数据表示

F T P协议规范提供了控制文件传送与存储的多种选择。在以下四个方面中每一个方面都必须作出一个选择。

在这里插入图片描述
在这里插入图片描述
  1. 文件类型 (a) ASCII码文件类型 (默认选择)文本文件以NVT ASCII码形式在数据连接中传输。这要求发方将本地文本文件转换成NVT ASCII码形式,而收方则将NVT ASCII码再还原成本地文本文件。其中,用NVT ASCII码传输的每行都带有一个回车,而后是一个换行。这意味着收方必须扫描每个字节,查找C R、L F对(我们在第1 5 . 2节见过的关于T F I P的A S C I I码文件传输情况与此相同)。 (b) EBCDIC文件类型 该文本文件传输方式要求两端都是 E B C D I C系统。 © 图像文件类型(也称为二进制文件类型) 数据发送呈现为一个连续的比特流。通常用于传输二进制文件。 (d) 本地文件类型 该方式在具有不同字节大小的主机间传输二进制文件。每一字节的比特数由发方规定。对使用8 bit字节的系统来说,本地文件以8 bit字节传输就等同于图像文件传输。
  2. 格式控制 该选项只对A S C I I和E B C D I C文件类型有效。 (a) 非打印 (默认选择)文件中不含有垂直格式信息。 (b) 远程登录格式控制 文件含有向打印机解释的远程登录垂直格式控制。 © Fortran 回车控制 每行首字符是F o r t r a n格式控制符。
  3. 结构 (a) 文件结构 (默认选择)文件被认为是一个连续的字节流。不存在内部的文件结构。 (b) 记录结构 该结构只用于文本文件(A S C I I或E B C D I C)。 (c) 页结构 每页都带有页号发送,以便收方能随机地存储各页。该结构由 TO P S - 2 0操作系统提供(主机需求R F C不提倡采用该结构)。
  4. 传输方式 它规定文件在数据连接中如何传输。 (a) 流方式 (默认选择)文件以字节流的形式传输。对于文件结构,发方在文件尾提示关闭数据连接。对于记录结构,有专用的两字节序列码标志记录结束和文件结束。 (b) 块方式 文件以一系列块来传输,每块前面都带有一个或多个首部字节。 (c) 压缩方式 一个简单的全长编码压缩方法,压缩连续出现的相同字节。在文本文件中常用来压缩空白串,在二进制文件中常用来压缩 0字节(这种方式很少使用,也不受支持。现在有一些更好的文件压缩方法来支持 F T P)。

如果算一下所有这些选择的排列组合数,那么对传输和存储一个文件来说就有 7 2种不同的方式。幸运的是,其中很多选择不是废弃了,就是不为多数实现环境所支持,所以我们可以忽略掉它们。 通常由U n i x实现的FTP 客户和服务器把我们的选择限制如下: • 类型:A S C I I或图像。 • 格式控制:只允许非打印。 • 结构:只允许文件结构。 • 传输方式:只允许流方式。

这就限制我们只能取一、两种方式: A S C I I或图像(二进制)。该实现满足主机需求 R F C的最小需求(该 R F C也要求能支持记录结构,但只有操作系统支持它才行,而U n i x不行)。

很多非U n i x的实现提供了处理它们自己文件格式的 F T P功能。主机需求R F C指出“F T P协议有很多特征,虽然其中一些通常不实现,但对 F T P中的每一个特征来说,都存在着至少一种实现”。

27.2.2 FTP命令

命令和应答在客户和服务器的控制连接上以 NVT ASCII码形式传送。这就要求在每行结尾都要返回C R、L F对(也就是每个命令或每个应答)。

从客户发向服务器的 Te l n e t命令(以I A C打头)只有中断进程( < I A C , I P >)和Te l n e t的同步信号(紧急方式下 < I A C , D M >)。我们将看到这两条 Te l n e t命令被用来中止正在进行的文件传输,或在传输过程中查询服务器。另外,如果服务器接受了客户端的一个带选项的 Te l n e t命令(W I L L,W O N T,D O或D O N T),它将以DONT 或W O N T响应。

这些命令都是3或4个字节的大写A S C I I字符,其中一些带选项参数。从客户向服务器发送的F T P命令超过3 0种。图2 7 - 2给出了一些常用命令,其中大部分将在本章再次遇到。

在这里插入图片描述
在这里插入图片描述

下节我们将通过一些例子看到,在用户交互类型和控制连接上传送的 F T P命令之间有时是一对一的。但也有些操作下,一个用户命令产生控制连接上多个 F T P命令。

27.2.3 FTP应答

应答都是A S C I I码形式的3位数字,并跟有报文选项。其原因是软件系统需要根据数字代码来决定如何应答,而选项串是面向人工处理的。由于客户通常都要输出数字应答和报文串,一个可交互的用户可以通过阅读报文串(而不必记忆所有数字回答代码的含义)来确定应答的含义。

应答3位码中每一位数字都有不同的含义(我们将在第 2 8章看到简单邮件传送输协议,S M T P,使用相同的命令和应答约定)。 图2 7 - 3给出了应答代码第1位和第2位的含义。

在这里插入图片描述
在这里插入图片描述

第3位数字给出差错报文的附加含义。例如,这里是一些典型的应答,都带有一个可能的报文串。 • 125 数据连接已经打开;传输开始。 • 200 就绪命令。 • 214 帮助报文(面向用户)。 • 331 用户名就绪,要求输入口令。 • 425 不能打开数据连接。 • 452 错写文件。 • 500 语法错误(未认可的命令)。 • 501 语法错误(无效参数)。 • 502 未实现的M O D E (方式命令)类型。 通常每个F T P命令都产生一行回答。例如, Q U I T命令可以产生如下应答:

代码语言:javascript
复制
221 Goodbye.

如果需要产生一条多行应答,第1行在3位数字应答代码之后包含一个连字号,而不是空格,最后一行包含相同的3位数字应答代码,后跟一个空格符。例如,HELP命令可以产生如下应答:

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

27.2.4 连接管理

数据连接有以下三大用途:

  1. 从客户向服务器发送一个文件。
  2. 从服务器向客户发送一个文件。
  3. 从服务器向客户发送文件或目录列表。

F T P服务器把文件列表从数据连接上发回,而不是控制连接上的多行应答。这就避免了行的有限性对目录大小的限制,而且更易于客户将目录列表以文件形式保存,而不是把列表显示在终端上。

我们已说过,控制连接一直保持到客户-服务器连接的全过程,但数据连接可以根据需要随时来,随时走。那么需要怎样为数据连接选端口号,以及谁来负责主动打开和被动打开?首先,我们前面说过通用传输方式( U n i x环境下唯一的传输方式)是流方式,并且文件结尾是以关闭数据连接为标志。这意味着对每一个文件传输或目录列表来说都要建立一个全新的数据连接。其一般过程如下:

  1. 正由于是客户发出命令要求建立数据连接,所以数据连接是在客户的控制下建立的。
  2. 客户通常在客户端主机上为所在数据连接端选择一个临时端口号。客户从该端口发布一个被动的打开。
  3. 客户使用P O RT命令从控制连接上把端口号发向服务器。
  4. 服务器在控制连接上接收端口号,并向客户端主机上的端口发布一个主动的打开。服务器的数据连接端一直使用端口 2 0。 图2 7 - 4给出了第3步执行时的连接状态。假设客户用于控制连接的临时端口是 11 7 3,客户用于数据连接的临时端口是 11 7 4。客户发出的命令是P O RT命令,其参数是6个A S C I I中的十进制数字,它们之间由逗点隔开。前面 4个数字指明客户上的 I P地址,服务器将向它发出主动打开(本例中是1 4 0 . 2 5 2 . 1 3 . 3 4),而后两位指明16 bit端口地址。由于16 bit端口地址是从这两个 数字中得来,所以其值在本例中就是 4×256+150 = 11 7 4。 图2 7 - 5给出了服务器向客户所在数据连接端发布主动打开时的连接状态。服务器的端点是端口2 0。
在这里插入图片描述
在这里插入图片描述

服务器总是执行数据连接的主动打开。通常服务器也执行数据连接的主动关闭,除非当客户向服务器发送流形式的文件时,需要客户来关闭连接(它给服务器一个文件结束的通知)。

客户也有可能不发出P O RT命令,而由服务器向正被客户使用的同一个端口号发出主动打开,来结束控制连接。这是可行的,因为服务器面向这两个连接的端口号是不同的:一个是2 0,另一个是2 1。不过,下节我们将看到为什么现有实现通常不这样做。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-03-16 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第27章 FTP:文件传送协议
    • 27.2 FTP协议
      • 27.2.1 数据表示
      • 27.2.2 FTP命令
      • 27.2.3 FTP应答
      • 27.2.4 连接管理
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档