TFTP協(xié)議詳解

一 TFTP協(xié)議簡介

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

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

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

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

二 TFTP協(xié)議分析

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

2.1 TFTP包格式

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

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

1. 讀寫文件請求包 RRQ/WRQ

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

圖2.1 讀寫文件請求包

圖2.2是利用Ethereal截獲的寫文件請求包。

圖2.2 Ethereal截獲的寫文件請求包

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

這個包里的option選項有：

• l 數(shù)據(jù)包大小（blksize）為512字節(jié)
• l 超時時間（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可以看出，該包的包號由Block字段給出，目前該包號為1，最大值為65535，輪流使用。數(shù)據(jù)包的起始包號從1開始。

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

3. 回應(yīng)包 ACK

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

圖2.5 ACK包格式

圖2.6所示為Ethereal截獲的對上面的DATA包回復的ACK包。

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

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

4. 錯誤信息包 ERROR

錯誤包格式如圖2.7所示。

圖2.7 ERROR包格式

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

• 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 錯誤包

紅色警告的原因是因為該字符串未以0結(jié)尾。可能是客戶端的軟件bug

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

2.2 TFTP工作流程

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

用S表示Server，C表示Client。

1. WRQ工作流程

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

這里我們要明確一點，如果有多個C同時向S發(fā)起請求的話，S如何正確發(fā)送包到對應(yīng)的C呢。

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

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

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

另外，S對于每個請求，都要采用一個不重復的新的UDP端口號作為它的TID，也就是說，S上同時存在的n個請求的TID都將不同。

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

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

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

2. RRQ的工作流程

RRQ和WRQ類似。

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

3. 連接和錯誤處理

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

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

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

2.3 TFTP總結(jié)

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

優(yōu)點：

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

缺點：

• l 傳輸效率不高
• l 滑動窗口機制太簡單，并且該窗口僅有一個包的大小
• l 超時處理機制并不完善，RFC1350并沒有給出詳細的處理機制說明

三 范例

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

服務(wù)器端：

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

客戶端：

圖3.2 客戶端工作流程

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

TFTP協(xié)議詳解