TFTP協(xié)議詳解

一 TFTP協(xié)議簡(jiǎn)介

TFTP協(xié)議全稱為Trivial File Transfer Protocol。目標(biāo)是在UDP之上上建立一個(gè)類似于FTP的但僅支持 文件上傳 和下載功能的傳輸協(xié)議，所以它不包含F(xiàn)TP協(xié)議中的目錄操作和用戶權(quán)限等內(nèi)容。

與FTP相似，TFTP傳輸過程中也有傳輸模式之分，模式的意思是如何解釋數(shù)據(jù)包里的內(nèi)容，比如是字符串還是二進(jìn)制等。目前有三種模式：

• l netascii型：一種修改的8bit ascii碼
• l octet型：即binary普通的二進(jìn)制型
• l mail型：過時(shí)，不再使用

另外，通訊雙方也可以自定義所需的傳輸模式。

二 TFTP協(xié)議分析

本分析以RFC1350為主，結(jié)合Ethereal截包軟件。TFTP服務(wù)器使用Cisco TFTP Server。客戶器使用Cisco TFTP Client。

2.1 TFTP包格式

TFTP共定義了五種類型的包格式，格式的區(qū)分由包數(shù)據(jù)前兩個(gè)字節(jié)的Opcode字段區(qū)分，分別是：

• l 讀文件請(qǐng)求包：Read request，簡(jiǎn)寫為RRQ，對(duì)應(yīng)Opcode字段值為1
• l 寫文件請(qǐng)求包：Write requst，簡(jiǎn)寫為WRQ，對(duì)應(yīng)Opcode字段值為2
• l 文件數(shù)據(jù)包：Data，簡(jiǎn)寫為DATA，對(duì)應(yīng)Opcode字段值為3
• l 回應(yīng)包：Acknowledgement，簡(jiǎn)寫為ACK，對(duì)應(yīng)Opcode字段值為4
• l 錯(cuò)誤信息包：Error，簡(jiǎn)寫為ERROR，對(duì)應(yīng)Opcode字段值為5

1. 讀寫文件請(qǐng)求包 RRQ/WRQ

讀寫文件請(qǐng)求包的內(nèi)容如圖2.1所示。

圖2.1 讀寫文件請(qǐng)求包

圖2.2是利用Ethereal截獲的寫文件請(qǐng)求包。

圖2.2 Ethereal截獲的寫文件請(qǐng)求包

從圖2.2可以看出，雖然RFC1350中描述的讀寫文件請(qǐng)求包中并未明確包含option字段，但由于Mode項(xiàng)表示的是一個(gè)字符串，故可以把相關(guān)內(nèi)容組合成一個(gè)字符串?dāng)?shù)組放到Mode段里邊。

這個(gè)包里的option選項(xiàng)有：

• l 數(shù)據(jù)包大小（blksize）為512字節(jié)
• l 超時(shí)時(shí)間（timeout）10秒
• l 文件大小（tsize）6656000字節(jié)

2. 文件數(shù)據(jù)包 DATA

數(shù)據(jù)包的格式如圖2.3所示。

圖2.3 DATA包格式

圖2.4 Ethereal截獲的DATA包

圖2.4為Ethereal截獲的數(shù)據(jù)包。

從圖2.4可以看出，該包的包號(hào)由Block字段給出，目前該包號(hào)為1，最大值為65535，輪流使用。數(shù)據(jù)包的起始包號(hào)從1開始。

另外，TFTP規(guī)定，DATA包中數(shù)據(jù)大小最大為512字節(jié)。當(dāng)DATA包中數(shù)據(jù)字節(jié)小于512時(shí)，就表示這是讀寫文件數(shù)據(jù)的最后一個(gè)包了，我們姑且可稱之為結(jié)束DATA包。

3. 回應(yīng)包 ACK

回應(yīng)包格式如圖2.5所示。

圖2.5 ACK包格式

圖2.6所示為Ethereal截獲的對(duì)上面的DATA包回復(fù)的ACK包。

圖2.6 對(duì)Block1數(shù)據(jù)包的回應(yīng)包

ACK中的包號(hào)為鎖確認(rèn)的數(shù)據(jù)包的包號(hào)，例如數(shù)據(jù)包的包號(hào)為100，則該ACK包的包號(hào)也為100。

4. 錯(cuò)誤信息包 ERROR

錯(cuò)誤包格式如圖2.7所示。

圖2.7 ERROR包格式

其中，RFC1350中ErrorCode定義了7個(gè)值，其值和含義分別如下：

• l 0 Not defined, see error message(if any)
• l 1 File not found
• l 2 Access violation
• l 3 Disk full or allocation exceeded
• l 4 Illegal TFTP operation
• l 5 Unknown transfer ID
• l 6 File already exists
• l 7 No such user

圖2.8為Ethereal截獲的ERROR包。

圖2.8 錯(cuò)誤包

紅色警告的原因是因?yàn)樵撟址匆?結(jié)尾。可能是客戶端的軟件bug

TFTP規(guī)定，ERROR包不會(huì)重傳也不需要確認(rèn)，所以有可能對(duì)方收不到ERROR包，TFTP建議采用某種ERROR包超時(shí)處理機(jī)制，但并沒有給出具體信息。

2.2 TFTP工作流程

TFTP的工作都是由客戶端發(fā)起一個(gè)RRQ或者WRQ開始的。這里分別以WRQ和RRQ為例，講述讀寫的工作過程，以及錯(cuò)誤處理等內(nèi)容。

用S表示Server，C表示Client。

1. WRQ工作流程

• l S在端口為69的UDP上等待C發(fā)出寫文件請(qǐng)求包
• l C通過UDP發(fā)送符合TFTP請(qǐng)求格式的WRQ包給S。從UDP包角度看，該UDP包的源端口由C隨意選擇，而目標(biāo)端口則是S的69。
• l S收到C的這個(gè)請(qǐng)求包后，需發(fā)送ACK給C。對(duì)于寫請(qǐng)求包，S發(fā)送的ACK包確認(rèn)號(hào)為0。
• l C發(fā)送DATA數(shù)據(jù)給S，S接收數(shù)據(jù)并寫文件
• l 當(dāng)C發(fā)送的DATA數(shù)據(jù)長度小于512字節(jié)時(shí)，S認(rèn)為這次WRQ請(qǐng)求完成

這里我們要明確一點(diǎn)，如果有多個(gè)C同時(shí)向S發(fā)起請(qǐng)求的話，S如何正確發(fā)送包到對(duì)應(yīng)的C呢。

在TFTP中，一次請(qǐng)求中所有包的源和目標(biāo)都由Transfer ID(TID)來標(biāo)示。TFTP規(guī)定TID值就是UDP包中的源和目標(biāo)端口。也就是說，一次請(qǐng)求過程中，S和C通過UDP包的源和目標(biāo)端口來判斷這個(gè)包是不是發(fā)給自己的。

以WRQ為例，C向S的69端口發(fā)送一個(gè)文件請(qǐng)求包，這個(gè)文件請(qǐng)求包中UDP的源端口號(hào)為C的TID（假設(shè)C選擇4845作為它的TID），目標(biāo)端口為69（這個(gè)時(shí)候由于請(qǐng)求還未接受，所以這次請(qǐng)求的UDP包中目標(biāo)端口不是TID）。S收到這個(gè)請(qǐng)求后，將另外采用一個(gè)UDP端口（應(yīng)該另啟動(dòng)了一個(gè)UDP Socket）假設(shè)為4849來回復(fù)這個(gè)請(qǐng)求的ACK。這樣，這個(gè)回復(fù)的UDP包的源端口就是S的TID（=4849），目標(biāo)就是C的UDP端口（TID=4845）。以后，這次請(qǐng)求的后續(xù)所有包都在端口為4845和4849中來往。

上述過程隱含了一定程度上的容錯(cuò)處理。例如，C收到一個(gè)TID不是4849的包，則認(rèn)為這個(gè)包是錯(cuò)誤的。

另外，S對(duì)于每個(gè)請(qǐng)求，都要采用一個(gè)不重復(fù)的新的UDP端口號(hào)作為它的TID，也就是說，S上同時(shí)存在的n個(gè)請(qǐng)求的TID都將不同。

這里再介紹下TFTP的回復(fù)ACK機(jī)制。雖然TFTP中有指定的ACK包作為回應(yīng)，但在普遍意義上，DATA包和ERROR包都可以作為上一次發(fā)送包的響應(yīng)。

一般來說，C發(fā)送了一個(gè)非結(jié)束DATA包給S，如果在超時(shí)時(shí)間內(nèi)，C未收到S發(fā)送的ACK，則C繼續(xù)發(fā)送這個(gè)DATA直到S回復(fù)ACK。這種情況是比較好理解的。

但假如S回復(fù)了上一個(gè)非結(jié)束DATA包ACK后，C在S的超時(shí)時(shí)間內(nèi)沒有發(fā)送下一個(gè)DATA包，則S將繼續(xù)發(fā)送這個(gè)ACK。從這個(gè)角度看，S等待的這個(gè)新DATA包是對(duì)上一次ACK的確認(rèn)。

2. RRQ的工作流程

RRQ和WRQ類似。

• l S在端口為69的UDP上等待C發(fā)出讀文件請(qǐng)求包
• l C通過UDP發(fā)送符合TFTP請(qǐng)求格式的RRQ包給S。
• l S收到C的這個(gè)請(qǐng)求包后，將直接發(fā)送DATA包給C，這個(gè)DATA包中含S選擇的TID作為UDP的源端口和C的TID作為UDP目標(biāo)端口，起始包號(hào)為1。
• l C接收來自S的DATA包并回復(fù)ACK。直到請(qǐng)求完成

3. 連接和錯(cuò)誤處理

UDP實(shí)際上沒有連接的概念。但從上面分析的RRQ和WRQ看，S在69端口上等待請(qǐng)求，而且S總是生成一個(gè)新的UDP來完成和C的交互。這個(gè)過程和TCP的listen以及Accept非常類似。所以TFTP把這種交互也稱作connection。只不過這種連接是隱含在請(qǐng)求中的。

一般情況下，連接的建立由一次成功的請(qǐng)求來發(fā)起，當(dāng)最后一個(gè)DATA包發(fā)送完畢并且ACK回復(fù)了后，則連接正常關(guān)閉。在傳輸過程中，如果出現(xiàn)錯(cuò)誤，假設(shè)S向C發(fā)送了一個(gè)ERROR包，如果C收到ERROR包，則連接關(guān)閉。如果C沒有收到ERROR包，則需要啟動(dòng)ERROR超時(shí)檢測(cè)機(jī)制。需要強(qiáng)調(diào)的是對(duì)于ERROR包，S和C都不會(huì)重傳也不需要ACK確認(rèn)。

TFTP建議在連接正常關(guān)閉的情況，S可在發(fā)送確認(rèn)結(jié)束DATA包的ACK后稍等片刻后再關(guān)閉連接。例如，當(dāng)C發(fā)送結(jié)束DATA包后，S回復(fù)ACK后再等一段時(shí)間才關(guān)閉。再次等待時(shí)間中，如果ACK包丟失，C將再次發(fā)送結(jié)束DATA包或者超時(shí)處理。S如果又收到一次結(jié)束DATA包后，就知道ACK包丟失了。S可以關(guān)閉連接也可以再次發(fā)送ACK包。

2.3 TFTP總結(jié)

整體上來說，TFTP的一個(gè)重要特點(diǎn)就是簡(jiǎn)單及易于實(shí)現(xiàn)，這也是設(shè)計(jì)TFTP協(xié)議的一個(gè)初衷。

優(yōu)點(diǎn)：

• l 每個(gè)數(shù)據(jù)包大小固定，這樣在內(nèi)存分配處理的時(shí)候比較直接
• l 實(shí)現(xiàn)簡(jiǎn)單
• l 每個(gè)數(shù)據(jù)包都有確認(rèn)機(jī)制，可以實(shí)現(xiàn)一定程度的可靠性

缺點(diǎn)：

• l 傳輸效率不高
• l 滑動(dòng)窗口機(jī)制太簡(jiǎn)單，并且該窗口僅有一個(gè)包的大小
• l 超時(shí)處理機(jī)制并不完善，RFC1350并沒有給出詳細(xì)的處理機(jī)制說明

三 范例

這里用流程圖表示S和C端的實(shí)現(xiàn)過程。

服務(wù)器端：

圖3.1 服務(wù)端工作流程

客戶端：

圖3.2 客戶端工作流程

根據(jù)上面這兩個(gè)流程圖，可以很容易實(shí)現(xiàn)TFTP的客戶端和服務(wù)器端，具體的超時(shí)重傳和錯(cuò)誤處理機(jī)制，可以自己設(shè)計(jì)并實(shí)現(xiàn)。

TFTP協(xié)議詳解