TFTP协议分析.docx

上传人:b****5 文档编号:12542217 上传时间:2023-04-20 格式:DOCX 页数:20 大小:1,003.61KB
下载 相关 举报
TFTP协议分析.docx_第1页
第1页 / 共20页
TFTP协议分析.docx_第2页
第2页 / 共20页
TFTP协议分析.docx_第3页
第3页 / 共20页
TFTP协议分析.docx_第4页
第4页 / 共20页
TFTP协议分析.docx_第5页
第5页 / 共20页
点击查看更多>>
下载资源
资源描述

TFTP协议分析.docx

《TFTP协议分析.docx》由会员分享,可在线阅读,更多相关《TFTP协议分析.docx(20页珍藏版)》请在冰豆网上搜索。

TFTP协议分析.docx

TFTP协议分析

计算机网络作业

题目TFTP协议分析

学院电子工程学院

专业XXXXXXXXXXXX

学生姓名XXX(学号*****XXX)

导师姓名胡建伟

 

1.TFTP协议简介

TFTP(TrivialFileTransferProtocol,简单文件传输协议)是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议,提供不复杂、开销不大的文件传输服务。

端口号为69。

TFTP的版本2是因特网的正式标准[RFC1350]。

1.1概述

虽然TFTP也使用客户服务器方式,但它使用UDP数据报(但是我们也不能确定有些TFTP协议是基于其它传输协议完成的),因此TFTP需要自己的差错改正措施。

TFTP只支持文件传输而不支持交互。

TFTP没有一个庞大的命令集,因此它不具备通常的FTP的许多功能,它只能从文件服务器上获得或写入文件,不能列出目录,不进行认证,它传输8位数据。

TFTP协议概述:

1.简单文件传送协议(TrivialFileTransferProtocol)

2.最初用于引导无盘系统,被设计用来传输小文件

3.基于UDP协议实现,但也可以由其他协议实现

4.不具备FTP的许多功能

5.只能从服务器获取或写入文件,不能列出目录

6.不进行认证

1.2模式

与FTP相似,TFTP传输过程中也有传输模式之分,模式的意思是如何解释数据包里的内容,比如是字符串还是二进制等。

目前TFTP传输有三种模式:

•netascii型:

是8位的ASCII码形式(文本模式)

•octet型:

即普通的二进制型(二进制模式)

•mail型:

过时,不再使用

另外,通讯双方也可以自定义所需的传输模式。

1.3特点

TFTP的主要特点是:

(1)每次传送的数据报文中有512字节的数据,但最后一次可不足512字节。

(2)数据报文按序编号,从1开始。

(3)支持ASCII码或二进制传送。

(4)可对文件进行读或写。

(5)使用很简单的首部。

1.4优点

TFTP的优点主要有两个。

第一,TFTP可用于UDP环境。

例如,当需要将程序或文件同时向许多机器下载时就往往需要使用TFTP。

第二,TFTP代码所占的内存较小。

这对较小的计算机或某些特殊用途的设备是很重要的。

这些设备不需要硬盘,只需要固化了TFTP,UDP和IP的小容量只读存储器即可。

当接通电源后,设备执行只读存储器中的代码,在网络上广播一个TFTP请求。

网络上的TFTP服务器就发送响应,其中包括可执行二进制程序。

设备收到此文件后将其放入内存,然后开始运行程序。

这种方式增加了灵活性,也减少了开销。

2.TFTP包格式

因为TFTP使用UDP,而UDP使用IP,IP还可以使用其它本地通信方法。

因此一个TFTP包中会有以下几段:

本地媒介头,IP头,数据报头,TFTP头,剩下的就是TFTP数据了。

TFTP在IP头中不指定任何数据,但是它使用UDP中的源和目标端口以及包长度域。

由TFTP使用的包标记(TID)在这里被用做端口,因此TID必须介于0到65,535之间。

TFTP头中包括两个字节的操作码,这个码指出了包的类型,包头次序为:

  

TFTP共定义了五种类型的包格式,格式的区分由包数据前两个字节的Opcode字段区分,分别是:

•读文件请求包:

Readrequest,简写为RRQ,对应Opcode字段值为1

•写文件请求包:

Writerequest,简写为WRQ,对应Opcode字段值为2

•文件数据包:

Data,简写为DATA,对应Opcode字段值为3

•回应包:

Acknowledgement,简写为ACK,对应Opcode字段值为4

•错误信息包:

Error,简写为ERROR,对应Opcode字段值为5

1、读写请求包的格式如下图:

PRQ(读请求)报文由客户使用,用来建立一条从服务器读数据的连接。

WRQ(写请求)报文由客户使用,用来建立一条把数据写到服务器的连接,它的格式与PRQ相同,除了头部的操作码是2。

RRQ和WRQ包(代码分别为1和2)中,文件名是NETASCII码字符,以0结束。

而MODE域包括了字符串"netascii","octet"或"mail",名称不分大小写。

接收到NETASCII格式数据的主机必须将数据转换为本地格式。

OCTET模式用于传输文件,这种文件在源机上以8位格式存储。

假设每个机器都存在一个8位的格式,这样的假设是最一般的。

比如DEC-20,这是一种36位机,我们可以假设它是4个8位外加另外4位而构成。

如果机器收到OCTET格式文件,返回时必须与原来文件完全一样。

在使用MAIL模式时,用户可以在FILE处使用接收人地址,这个地址可以是用户名或用户名@主机的形式,如果是后一种形式,允许主机使用电子邮件传输此文件。

如果使用MAIL类型,包必须以WRQ开始,否则它与NETASCII完全一样。

我们的讨论建立在发送方和接收方都在相同模式的情况下,但是双方可以以不同的模式进行传输。

例如一个机器可以是一台存储服务器,这样一台服务器需要将NETASCII格式转换为自己的格式。

另外,我们可以设想DEC-20这种机器,它使用36位字长,用户这边可以使用特殊的机制一次读取36位,而服务器却可以仍然使用8位格式。

在这两种情况下,我们看到了两台机器使用不同格式的情况。

可以在两台主机间定义其它的传输方式,但是定义要小心,因为这种传输方式不为人知,而且也没有权威机构为其指定名称或定义它的模式。

2、DATA(数据)报文由客户和服务器使用,用来传送数据块,其格式如

下图所示:

数据包的操作码为3,它还包括有一个数据块号和数据。

数据块号域从1开始编码,每个数据块加1,这样接收方可以确定这个包是新数据还是已经接收过的数据。

数据域从0字节到512字节。

如果数据域是512字节则它不是最后一个包,如果小于512字节则表示这个包是最后一个包。

除了ACK和用于中断的包外,其它的包均得到确认。

发出新的数据包等于确认上次的包。

WRQ和DATA包由ACK或ERROR数据包确认,而RRQ数据包由DATA或ERROR数据包确认。

3、ACK(确认)报文由客户和服务器使用,用来确认已收到数据块,这个报文只有

四字节,其格式如下图所示:

ACK包操作码为4,其中的包号为要确认的数据包的包号。

WRQ数据包被ACK数据包确认,WRQ数据包的包号为0。

 

4、ERROR(错误)报文由客户或服务器使用,用于当一条连接不能建立或在数据传输

中出现了问题,它可以作为PRQ或WRQ的负面响应,但不能用于对受损或重复报文

的声明,其格式如下图:

此包可以被其它任何类型的包确认。

错误码指定错误的类型。

错误的值和错误的意义如下:

0未定义,请参阅错误信息(如果提示这种信息的话)

1.文件未找到

2.访问非法

3.磁盘满或超过分配的配额

4.非法的TFTP操作

5.未知的传输ID

6.文件已经存在

7.没有类似的用户

3.TFTP通信流程

任何传输起自一个读取或写入文件的请求,这个请求也是连接请求。

如果服务器批准此请求,则服务器打开连接,数据以定长512字节传输。

每个数据包包括一块数据,服务器发出下一个数据包以前必须得到客户对上一个数据包的确认。

如果一个数据包的大小小于512字节,则表示传输结束。

如果数据包在传输过程中丢失,发出方会在超时后重新传输最后一个未被确认的数据包。

通信的双方都是数据的发出者与接收者,一方传输数据接收应答,另一方发出应答接收数据。

大部分的错误会导致连接中断,错误由一个错误的数据包引起。

这个包不会被确认,也不会被重新发送,因此另一方无法接收到。

如果错误包丢失,则使用超时机制。

错误主要是由下面三种情况引起的:

不能满足请求,收到的数据包内容错误,而这种错误不能由延时或重发解释,对需要资源的访问丢失(如硬盘满)。

TFTP只在一种情况下不中断连接,这种情况是源端口不正确,在这种情况下,指示错误的包会被发送到源机。

这个协议限制很多,这些都是为了实现起来比较方便而进行的。

初始连接时需要发出WRQ(请求写入远程系统)或RRQ(请求读取远程系统),收到一个确定应答,一个确定可以写出的包或应该读取的第一块数据。

通常确认包包括要确认的包的包号,每个数据包都与一个块号相对应,块号从1开始而且是连续的。

因此对于写入请求的确定是一个比较特殊的情况,因此它的包的包号是0。

如果收到的包是一个错误的包,则这个请求被拒绝。

创建连接时,通信双方随机选择一个TID,因为是随机选择的,因此两次选择同一个ID的可能性就很小了。

每个包包括两个TID,发送者ID和接收者ID。

这些ID用于在UDP通信时选择端口,请求主机选择ID的方法上面已经说过了,在第一次请求的时候它会将请求发到TID69,也就是服务器的69端口上。

应答时,服务器使用一个选择好的TID作为源TID,并用上一个包中的TID作为目的ID进行发送。

这两个被选择的ID在随后的通信中会被一直使用。

TFTP协议的通信流程如下图所示:

 

4.实验

4.1实验环境

本实验以虚拟机里的两个32位windowsXP系统作为TFTP服务器和TFTP客户机。

以CiscoTFTPServer搭建TFTP服务器和TFTP客户端。

该软件的相关介绍如下:

1、软件简介

CISCO公司出品的TFTP服务器,常用于CISCO路由器的IOS升级与备份工作。

也可用于个人建立TFTP服务器,进行文件传输。

软件中附带了一个命令行方式的TFTP客户端,文件名为TFTP.EXE,用它可以测试你建立的TFTP服务器。

2、已知问题

当多个客户端同时访问TFTP服务器,并且“选项”中的“显示传输进程”开启后,会导致TFTP服务器挂掉。

要避免此问题的发生,请将“选项”中的“显示文件传输进程”选项取消即可。

3、TFTP客户端用法

TFTP[-i][-bblocksize][-v][-ttimeout][-s]host[GET|PUT]source[destination]

-i以二进制方式传输

-b传输过程中使用的块大小(默认为512字节).8-65464字节

-v传输过程中显示详细的信息(冗余模式).

-t超时(默认为10秒).可以设置为1-255秒

-s不使用tsize选项(默认启用).

host指定本地或远程主机

GET下载文件

PUT传文件

source指定要传输的文件名

destination指定传输的目的地

例:

tftp-i192.168.0.8get1.txt

从192.168.0.8这个主机中下载1.txt这个文件到当前目录

tftp-i192.168.0.8puttest.txt

将本地当前目录中的test.txt文件上传到192.168.0.8主机中

服务器端根目录如下图所示:

客户端根目录如下图所示:

 

服务器系统信息:

客户机系统信息:

 

4.2实验说明

实验过程在客户机CMD命令行中进行,因命令行中的文件路径与文件名均不能包含空格,故CiscoTFTPServer软件的使用与软件说明有所出入。

实验过程中要保持服务器端软件一直运行。

实验过程中在客户端抓取数据包,并命名为“TFTPclient.pcapng”。

4.3实验过程

将客户机C盘根目录下的test1.txt上传到TFTP服务器,将TFTP服务器根目录下的test2.txt下载到客户机。

服务器端根目录如下图所示:

客户端待上传文件:

实验前服务器端软件界面:

实验过程(客户端):

实验后服务器端软件界面:

实验后服务器端根目录:

实验后客户端下载的文件:

4.4实验分析

现对实验过程中在客户端抓的包进行简单分析。

实验整个过程共抓取56个数据包(实验过程未运行其它软件),将TFTP包过滤出来,共有7个,如下图所示:

实验第一条指令是

,也就是将本地C盘根目录下的test1.txt文件上传到服务器。

抓取的1号包如下图:

1号包为客户端发给服务端的WRQ包,向TFTP服务器请求上传文件test1.txt。

2号包如下图所示:

服务器收到客户端的上传请求后向客户端发送确认包,同意客户端上传文件test1.txt。

3号包如下图所示:

客户端收到服务端发来的确认包后,开始上传文件,因上传的文件较小,小于512字节,故用一个DATA包就传完数据。

上传的文件test1.txt的内容如下图:

经与3号包对比,test1.txt的内容全被3号包包含。

4号包如下图所示:

4号为客户端上传文件完成后服务端发给客户端的确认包,告知客户端上传的文件已收到,上传结束。

54号包如下图所示:

此包为指令

发出后抓取的TFTP包,指令表示客户端向服务端请求下载文件test2.txt。

55号包如下图所示:

服务端收到客户端的下载请求后马上将客户端请求的数据下传至客户端,并不对客户端的身份进行确认。

因传送的文件较小,仅为92字节,未超过512字节,故用一个DATA包就将文件传送完毕。

56号包如下图所示:

此包为客户端下载完成后发给服务端的确认包,告知服务端已下载完成。

 

5.总结

整体上来说,TFTP的一个重要特点就是简单及易于实现,这也是设计TFTP协议的一个初衷。

优点:

∙l每个数据包大小固定,这样在内存分配处理的时候比较直接

∙l实现简单

∙l每个数据包都有确认机制,可以实现一定程度的可靠性

缺点:

∙l传输效率不高

∙l滑动窗口机制太简单,并且该窗口仅有一个包的大小

∙l超时处理机制并不完善,RFC1350并没有给出详细的处理机制说明

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 幼儿教育 > 幼儿读物

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1