TFTP介紹2

TFTP(TrivialFileTransferProtocol)即簡單檔案傳送協議，最初打算用於引導無盤系統（通常是工作站或X終端）。和將在第27章介紹的使用TCP的檔案傳送協議（FTP）不同，為了保持簡單和短小，TFTP將使用UDP。TFTP的代碼（和它所需要的UDP、IP和裝置驅動程式）都能適合唯讀記憶體。

（BootstrapProtocol）中還會遇到TFTP。在圖5-1中，當從網路上引導sun主機時，也曾遇到過TFTP，sun主機通過RARP獲得它的IP地址後，將發出一個TFTP請求。RFC1350[Sollins1992]是第2版TFTP的正式規範。第12章[Stevens1990]提供了實現TFTP客戶和伺服器的全部原始碼，並介紹了一些使用TFTP的編程技術。

協議

　　在開始工作時，TFTP的客戶與伺服器交換資訊，客戶發送一個讀請求或寫請求給伺服器。在一個無盤系統進行系統引導的正常情況下，第一個請求是讀請求（RRQ）。顯示了5種TFTP報文格式（作業碼為1和2的報文使用相同的格式）。

　　TFTP報文的頭兩個位元組表示作業碼。對於讀請求和寫請求（WRQ），檔案名稱欄位說明客戶要讀或寫的位於伺服器上的檔案。這個檔案欄位以0位元組作為結束（見圖15-1）。模式欄位是一個ASCII碼串netascii或octet（可大小寫任意組合），同樣以0位元組結束。netascii表示資料是以成行的ASCII碼字元組成，以兩個位元組—斷行符號字元後跟換行字元（稱為CR/LF）作為行結束符。這兩個行結束字元在這種格式和本地主機使用的行定界符之間進行轉化。octet則將資料看作8bit一組的位元組流而不作任何解釋。

　　每個資料分組包含一個塊編號欄位，它以後要在確認分組中使用。以讀一個檔案作為例子，TFTP客戶需要發送一個讀請求說明要讀的檔案名稱和檔案模式(mode)。如果這個檔案能被這個客戶讀取，TFTP伺服器就返回一個塊編號為1的資料分組。TFTP客戶又發送一個塊編號為1的ACK。TFTP伺服器隨後發送塊編號為2的資料。TFTP客戶發回塊編號為2的ACK。重複這個過程直到這個檔案傳送完。除了最後一個資料分組可含有不足512位元組的資料，其他每個資料分組均含有512位元組的資料。當TFTP客戶收到一個不足512位元組的資料分組，就知道它收到最後一個資料分組。

　　在寫請求的情況下，TFTP客戶發送WRQ指明檔案名稱和模式。如果該檔案能被該客戶寫，TFTP伺服器就返回塊編號為0的ACK包。該客戶就將檔案的頭512位元組以塊編號為1發出。伺服器則返回塊編號為1的ACK。

　　這種類型的資料轉送稱為停止等待協議。它只用在一些簡單的協議如TFTP中。在20.3節中將看到TCP提供了不同形式的確認，能提供更高的系統輸送量。TFTP的優點在於實現的簡單而不是高的系統輸送量

 

5種TFTP報文格式

最後一種TFTP報文類型是差錯報文，它的作業碼為5。它用於伺服器不能處理讀請求或寫請求的情況。在檔案傳輸過程中的讀和寫差錯也會導致傳送這種報文，接著停止傳輸。差錯編號欄位給出一個數位差錯碼，跟著是一個ASCII表示的差錯報文欄位，可能包含額外的作業系統說明的資訊。

　　既然TFTP使用不可靠的UDP，TFTP就必須處理分組丟失和分組重複。分組丟失可通過發送方的逾時與重傳機制解決（注意存在一種稱為“魔術新手綜合症(sorcerer’sapprenticesyndrome)”的潛在問題，如果雙方都逾時與重傳，就可能出現這個問題。12.2節[Stevens1990]介紹了這個問題是如何發生的)。和許多UDP應用程式一樣，TFTP報文中沒有檢驗和，它假定任何資料差錯都將被UDP的檢驗和檢測到

本篇文章來源於 中國協議分析網|www.cnpaf.net 原文連結：http://www.cnpaf.net/Class/TCPANDIP/200408/320.html