TFTP協議詳解

一 TFTP協議簡介

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

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

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

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

二 TFTP協議分析

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

2.1 TFTP包格式

TFTP共定義了五種類型的包格式，格式的區分由包數據前兩個字節的Opcode字段區分，分別是：

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

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

讀寫文件請求包的內容如圖2.1所示。

圖2.1 讀寫文件請求包

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

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

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

這個包里的option選項有：

• l 數據包大?。╞lksize）為512字節
• l 超時時間（timeout）10秒
• l 文件大?。╰size）6656000字節

2. 文件數據包 DATA

數據包的格式如圖2.3所示。

圖2.3 DATA包格式

圖2.4 Ethereal截獲的DATA包

圖2.4為Ethereal截獲的數據包。

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

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

3. 回應包 ACK

回應包格式如圖2.5所示。

圖2.5 ACK包格式

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

圖2.6 對Block1數據包的回應包

ACK中的包號為鎖確認的數據包的包號，例如數據包的包號為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結尾?？赡苁强蛻舳说能浖ug

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

2.2 TFTP工作流程

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

用S表示Server，C表示Client。

1. WRQ工作流程

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

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

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

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

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

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

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

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

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

2. RRQ的工作流程

RRQ和WRQ類似。

• l S在端口為69的UDP上等待C發出讀文件請求包
• l C通過UDP發送符合TFTP請求格式的RRQ包給S。
• l S收到C的這個請求包后，將直接發送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。只不過這種連接是隱含在請求中的。

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

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

2.3 TFTP總結

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

優點：

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

缺點：

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

三 范例

這里用流程圖表示S和C端的實現過程。

服務器端：

圖3.1 服務端工作流程

客戶端：

圖3.2 客戶端工作流程

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

TFTP協議詳解