TFTP 协议中对报文的实例解析

beyes

TFTP 共有 5 种类型的报文，它们分别是：
RRQ (读请求报文)
WRQ (写请求报文)
DATA (数据报文)
ACK (确认报文)
ERROR (差错报文)

下面以一个实例来分析涉及到的几个报文(RRQ, DATA, ACK)，写请求报文 WRQ 和 差错报文 ERROR 没有涉及，但类似分析。

试验环境在局域网中，有两台机器，一台服务器(系统为 CentOS 5.4 Linux) IP 是 10.36.64.47 ，一台客户端机器 IP 是:  10.36.64.31 ，抓包软件在服务器上使用图形工具 Wireshark 。

在服务器上把 TFTP 架设好后，然后在客户机进行连接。客户机的 tftp　客户端是 windows 平台下的命令行工具，它的用法和 linux 里的客户端用法有所差别，但不影响此次的协议分析。

FTFP 服务器的主目录下我放有一个纯文本文件 hello.txt ，里面的内容是一行 hello world 。现在用客户端去连接服务器，然后使用 get 命令把这个文本文件下载到本地，然后退出 TFTP ，这个过程结束后，会在 wireshak 里看到抓到的数据包报告，如下图所示：

从上图可以看到，第 1 行的第 6 栏里，对应的报文是 RRQ (Read Request 的缩写)；第 2 行的是 Data 数据报文；第 3 行是确认报文 ACK 。

下面对 RRQ 报文进行解析：
RRQ 读请求报文是由客户端使用的，它的作用是建立一条从服务器读数据的连接，它的格式如下：

OpCode=1(2字节)

文件名(长度可变)

全为0(1字节)

方式(长度可变)

全为0(1字节)

其中,
OpCode 这是第 1 个字段，占了 2 个字节。对 RRQ 报文来说，它的值为 1 。

文件名： 这个字段定义了要传送文件的文件名字符串(ASCII 编码)，由于报文名是可变长度的，因此在结束时要有全 0 的 1 字节字段作为记号，就像 C 语言中的字符串后面要有个 '\0' 结束符。

方式：这个字段也是个可变长度字符串。方式字段用另一个全 0 的 1 字节字段作为结束。方式可以是两种字符串中的一种："netascii"(对于 ASCII 文件)或 "octet"(对于二进制文件)。

下面我们在 wireshar 里验证上面的事实，如下图所示：

上图中，第一栏里已经请出标明了协议类型(TFTP)，Opcode, 文件名，类型。在第 2 栏的灰色字体加亮二进制字节里可以按照 RRQ 报文格式依次对照下来，一目了然。

下面解析数据报文 DATA 部分：
数据(DATA)报文由客户或服务器使用，用来传送数据块，格式如下：

OpCode=3(2字节)

块数(2字节)

数据部分(0~512字节)

OpCode ： 这是第 1 个字段，2 个字节长度，对于 DATA 报文来说，它的值为 3 。

块号： 这个 2 字节字段包含块号。数据的发送端(客户或服务器)使用这个字段安排序号。所有的块都用数字顺序编号，从 1 开始。这里的意思就是说，一个数据块为 512 个字节，有多于 512 字节的数据传送，就会占据 2 个块，那么这里的值就为 2 ，依次类推。

数据： 在所有的 DATA 报文中，这个块必须准确地等于 512 字节，但最后一个块必须在 0~511 字节之间。一个非 512 字节的块用作一个信号，表示发送端已经发完了所有的数据。换言之，它用作文件结束的指示符。若文件中的数据碰巧是 512 字节的整数倍，那么发送端必须再发送一个具有 0 字节的额外的块以表示传输的结束。数据可用 NVT ASCII (netascii) 或 二进制八位组(octet)来传送

下图是数据报文的内容，这里连文件中中的内容(数据部分)也可以看到，如下图所示：


下面解析 ACK 报文：
确认(ACK) 报文由客户或服务器使用，用来确认收到的数据块。这个报文只有 4 字节长。格式如下所示：

OpCode=4

块数

OpCode ： 第 1 个字段是 2 字节的操作码。对 ACK 报文来说，这个值为 4 。

块号： 下一个字段是 2 字节字段，它包含收到的块好。

ACK 报文也可以是 WRQ 报文的响应。服务器发送这个报文只是它已经准备好接收来自客户的数据。在这种情况下块号字段的值为 0。我们上面的例子是对 RRQ 报文的响应，也就是说，客户机确认了服务器的 1 个块内容的传送。如下图所示：


最后，还有 WRQ 和 ERROR 没有做实验解析，但分析过程是一样的。