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)。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號(hào)聯(lián)系: 360901061
您的支持是博主寫作最大的動(dòng)力,如果您喜歡我的文章,感覺我的文章對(duì)您有幫助,請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點(diǎn)擊下面給點(diǎn)支持吧,站長非常感激您!手機(jī)微信長按不能支付解決辦法:請(qǐng)將微信支付二維碼保存到相冊(cè),切換到微信,然后點(diǎn)擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
