亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

TFTP協(xié)議詳解

系統(tǒng) 2766 0

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

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

2-2

圖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

圖2.3 DATA包格式

圖2.4 Ethereal截獲的DATA包

2-4

圖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

圖2.5 ACK包格式

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

2-6

圖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

圖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

圖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

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

客戶端:

3-2

圖3.2 客戶端工作流程

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

TFTP協(xié)議詳解


更多文章、技術(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ì)您有幫助就好】

您的支持是博主寫作最大的動(dòng)力,如果您喜歡我的文章,感覺我的文章對(duì)您有幫助,請(qǐng)用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會(huì)非常 感謝您的哦!!!

發(fā)表我的評(píng)論
最新評(píng)論 總共0條評(píng)論
主站蜘蛛池模板: 大陆一级毛片免费视频观看i | 亚洲视频一二 | 亚洲福利一区二区 | 欧美日韩高清 | 国产99久9在线 | 欧美综合图区亚欧综合图区 | 久久毛片免费看一区二区三区 | 国产免费a视频 | 国内永久第一免费福利视频 | 青草青在线免费视频 | 日日噜噜噜夜夜爽爽狠狠图片 | 奇米视频在线 | 爱操tv| 久久这里只有免费精品6www | 久久无码精品一区二区三区 | 夜夜爽夜夜叫夜夜高潮漏水 | 老太婆性杂交毛片 | 素人259luxu在线观看暴露 | se94se欧美综合色 | 久久国产一久久高清 | 夜夜爽网站 | 国产日韩一区二区三区在线播放 | 午夜精品久久久久久久2023 | 五月天国产| 福利视频久久 | 狠狠色噜噜狠狠狠狠69 | 米奇7777狠狠狠狠视频影院 | 欧美69xx | 久久久这里只有精品加勒比 | 亚洲国产成+人+综合 | 在线免费观看a视频 | 不卡猪| 久热免费视频 | 国产一区日韩二区欧美三 | 欧美综合中文字幕久久 | 高清不卡一区二区 | 99精品国产成人一区二区在线 | 国产一级二级在线观看 | 国产成人久久 | 99热99re8国产在线播放 | 欧美一区二区三区免费视频 |