TFTP：簡單文件傳送協議

　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的檢驗和檢測到

原文轉自：http://www.kjueaiud.com