TFTP協議
文檔的現狀
這個RFC文檔被網絡協會列爲準IAB標準，需要進一步的討論和修改。通過IAB標準可以查看這個協議的狀態。可以任意的發佈本協議。
概況
TFTP是一個傳輸文件的簡單協議,可以從它的名字看出。每個非結尾數據報被單獨的確認。本文檔描述TFTP的協議和種類。也解釋一些設計TFTP協議的原因。
背景
這個協議原本由Noel Chiappa設計，由 Noel Chiappa、 Bob Baldwin和 Dave Clark重新設計，並由Steve Szymanski校驗。現在的這個版本， LarryAllen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin,David Reed, Craig Milo Rogers, Kathy Yellick 和原本作者進行了修訂。轉發和確認機制受到TCP的影響，錯誤機制受 PARC的EFTP異常消息。
1992年5月，重新修訂了本協議的BUG，其他的小問題由 Noel Chiappa 來做。
(美國）國防高級研究計劃局支持此協議的研究，由海軍研究辦公室監製號碼爲： N00014-75-C-0661。
1.目的
TFTP是一個傳輸文件的簡單協議，它已經基於UDP協議實現了,因此可以在不同網絡的主機間進行傳送。此協議設計的時候是進行小文件傳輸的。因此它容易實現，不具備通常的FTP的許多功能，它只能從文件服務器上獲得或寫入文件，不能列出目錄，不進行認證，它傳輸8位數據。
傳輸中有三種模式：netascii，這是8位的ASCII碼形式，另一種是octet，這是8位源數據類型；最後一種mail已經不再支持，它將返回的數據直接返回給用戶而不是保存爲文件。可以由協作的主機間自己定義模式。
參考[4]可以總結出更多的建議。
2.概況
任何傳輸起自一個讀取或寫入文件的請求，這個請求也是連接請求。如果服務器批准此請求，連接就建立了，數據以定長512字節傳輸。每個數據包包括一塊數據，發出下一個數據包以前必須得到對上一個數據包的確認。如果一個數據包的大小小於512字節，則表示傳輸結束。如果數據包在傳輸過程中丟失，發出方會在超時後重新傳輸最後一個未被確認的數據包。通信的雙方都是數據的發出者與接收者，一方傳輸數據接收應答，另一方發出應答接收數據。
大部分的錯誤會導致連接中斷，錯誤由一個錯誤的數據包引起。這個包不會被確認，也不會被重新發送，因此另一方無法接收到,這種連接中斷可以由超時機制來檢查。錯誤主要是由下面三種情況引起的：不能滿足請求；收到的數據包內容錯誤，而這種錯誤不能由延時或重發解釋；對需要資源的訪問丟失（如硬盤滿）。TFTP只在一種作物情況下不中斷連接，這種情況是源端口不正確，在這種情況下，指示錯誤的包會被髮送到源機。這個協議限制很多，這是都是爲了實現起來比較方便而進行的。例如，固定的長度方便本地存儲，對每一個數據報進行確認方便流式控制和對接受的數據包進行排序。
3.與其它協議的聯繫
因爲TFTP使用UDP，而UDP使用IP。因此一個TFTP包中會有以下幾段：IP頭，UDP報頭，TFTP頭，剩下的就是TFTP數據了。此外，數據報還需要像LNI， ARPA的頭部以便在在本地傳輸。如圖3-1所示。TFTP在IP頭中不指定任何數據，但是它使用UDP中的源和目標端口以及包長度域。由TFTP使用的包標記（TID）在數據包層被用做端口，因此TID必須介於0到65,535之間。對它的初始化我們在後面討論。TFTP頭中包括兩上字節的操作碼，這個碼指出了包的類型,這個操作碼和其他類型的操作碼我們在後面的章節中進行討論。
---------------------------------------------------
| Local Medium | Internet | Datagram | TFTP |
---------------------------------------------------
圖3-1:包頭次序
4.初始連接
初始連接時候需要發出WRQ（請求寫入遠程系統）或RRQ（請求讀取遠程系統），收到一個確定應答，是確定可以寫出的包或應該讀取的第一塊數據。通常確認包包括要確認的包的包號，每個數據包都與一個塊號相對應，塊號從1開始而且是連續的。因此對於寫入請求的確定是一個比較特殊的情況，因此它的包的包號是0。如果收到的包是一個錯誤的包，則這個請求被拒絕。創建連接時，通信雙方隨機選擇一個TID，是隨機選擇的，因此兩次選擇同一個TID的可能性就很小了。每個包包括兩個TID，發送者TID和接收者TID。這些TID用於在UDP(或其他數據包協議)通信時選擇端口，請求主機選擇TID的方法上面已經說過了，在第一次請求的時候它會將請求發到TID 69，也就是服務器的69端口上。應答時，服務器使用一個選擇好的TID作爲源TID，並用上一個包中的TID作爲目的ID進行發送。這兩個被選擇的TID在隨後的通信中會被一直使用。下例是一個寫入的例子，其中WRQ，ACK和DATA代表寫入請求，確認和數據。
1.主機A向主機B發出WRQ，其中端口爲69
2. B機向A機發出ACK，塊號爲0，包括B和A的TID
此時連接建立，第一個數據包以序列號1從主機開始發出。以後兩臺主機要保證以開始時確定的TID進行通信。如果源ID與原來確定的ID不一樣，這個包會被認識爲發送到了錯誤的地址而被拋棄。錯誤消息包是被髮送到發送不正確包的端口，因而不影響繼續傳輸文件，這種情況僅適合接受到包端口不正確。如果支持協議不允許，這種情況就不會發生。
關於上述情況，下面這個例子演示了一個正確的協議操作。設想發送方發出一個請求，這個請求在網絡的那個設備中被複製成兩個包，接收方先後接收到兩個包。接收方會認爲爲這是兩個獨立的請求，會返回兩個應答。當這兩個應答其中之一被接收到時，連接已經建立。第二個應答再到達時，這個包會被拋棄，而不會因爲接收到第二個應答包而導致第一個建立的連接失敗。
5. TFTP包(作到這裏了)
TFTP支持五種類型的包，在上面都涉及到了：
opcode operation
1 Read request (RRQ)
2 Write request (WRQ)
3 Data (DATA)
4 Acknowledgment (ACK)
5 Error (ERROR)
包頭中包括了這個包所指定的操作碼。
2 bytes string 1 byte string 1 byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------
Figure 5-1: RRQ/WRQ包
RRQ和WRQ包（代碼分別爲1和2）的格式如上所示。文件名是NETASCII碼字符，以0結束。而MODE域包括了字符串"netascii"，"octet"或"mail"，名稱不分大小寫。接收到NETASCII格式數據的主機必須將數據轉換爲本地格式。OCTET模式用於傳輸在源機上以8位格式存儲的文件。假設每個機器都存在一個8位的格式，這樣的假設是最一般的。比如DEC-20，這是一種36位機，我們可以假設它是4個8位外加另外4位而構成。如果機器收到OCTET格式文件，返回時必須與原來文件完全一樣。在使用MAIL模式時，用戶可以在FILE處使用接收人地址，這個地址可以是用戶名或用戶名@主機的形式，如果是後一種形式，允許主機使用電子郵件傳輸此文件。如果使用MAIL類型，包必須以WRQ開始，否則它與NETASCII完全一樣。
我們的討論建立在發送方和接收方都在相同模式的情況下，但是雙方可以以不同的模式進行傳輸。例如一個機器可以是一臺存儲服務器，這樣一臺服務器需要將NETASCII格式轉換爲自己的格式。另外，我們可以設想DEC-20這種機器，它使用36位字長，用戶這邊可以使用特殊的機制一次讀取36位，而服務器卻可以仍然使用8位格式。在這兩種情況下，我們看到了兩臺機器使用不同格式的情況。可以在兩臺主機間定義其它的傳輸方式，但是定義要小心，因爲這種傳輸方式不爲人知，而且也沒有權威機構爲其指定名稱或定義它的模式。
2 bytes 2 bytes n bytes
----------------------------------
| Opcode | Block # | Data |
----------------------------------
Figure 5-2: DATA包
數據在數據包中傳輸，其格式如上圖所示。數據包的OP碼爲3，它還包括有一個數據塊號和數據。數據塊號域從1開始編碼，每個數據塊加1，這樣接收方可以確定這個包是新數據還是已經接收過的數據。數據域從0字節到512字節。如果數據域是512字節則它不是最後一個包，如果小於512字節則表示這個包是最後一個包。除了ACK和用於中斷的包外，其它的包均得到確認。發出新的數據包等於確認上次的ACK包。WRQ和DATA包由ACK或ERROR數據包確認，而RRQ和數據包由DATA或ERROR數據包確認。下圖即是一個ACK包，操作碼爲4。其中的包號爲要確認的數據包的包號。
2 bytes 2 bytes
---------------------
| Opcode | Block # |
---------------------
Figure 5-3: ACK包
WRQ數據包被ACK數據包確認，WRQ數據包的包號爲0。
2 bytes 2 bytes string1 byte
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------
Figure 5-4: ERROR包
一個ERROR包，它的操作碼是5，它的格式如上所示。此包可以被其它任何類型的包確認。錯誤碼指定錯誤的類型。錯誤的值和錯誤的意義在附錄中。錯誤信息是供程序員使用的,應該是netascii類型。像其他的字符，它的中斷連接標誌是srting域爲0。
6.正常終止
傳輸的結束由DATA數據標記，數據區爲0-511個字符。這個包可以被ACK數據包確認。接收方在發出對最後數據包的確認後可以斷開連接，當然，適當的等待是比較好的，如果最後的確定包丟失可以再次傳輸。如果發出確認後仍然收到最後數據包，可以確定最後的確認丟失。發送最後一個DATA包的主機必須等待對此包的確認或超時。如果響應是ACK，傳輸完成。如果發送方超時並不準備重新發送並且接收方有問題或網絡有問題時，發送也正常結束。也有可能這種情況傳輸是不成功的，但無論如何連接都將被關閉。
7.早終結
如果請求不能被滿足，或者在傳輸中發生錯誤，然後發送了ERROR包。這僅是一種傳輸友好的方式，這種包不會被確認也不會被重新傳輸，因此這種包可能永遠不會被接收到。因此需要用超時來偵測錯誤。
I.附錄
包頭的次序
2 bytes
----------------------------------------------------------
| Local Medium | Internet | Datagram | TFTP Opcode |
----------------------------------------------------------
TFTP格式
Type Op #沒有包頭的格式
2 bytes string 1 bytestring 1 byte
-----------------------------------------------
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
WRQ -----------------------------------------------
2 bytes 2 bytes n bytes
---------------------------------
DATA | 03 | Block # | Data |
---------------------------------
2 bytes 2 bytes
-------------------
ACK | 04 | Block # |
--------------------
2 bytes 2 bytes string1 byte
----------------------------------------
ERROR | 05 | ErrorCode | ErrMsg | 0 |
----------------------------------------
讀文件的初始連接
1.主機A發RRQ到A，包括源=A的ID和目的=69
2. 主機B發送DATA，其中包號=1，這個包被傳送到A，攜帶源B的TID，目的A的TID
錯誤碼
Value Meaning
0 未定義，請參閱錯誤信息（如果提示這種信息的話）
1 文件未找到
2 訪問非法
3 磁盤滿或超過分配的配額
4 非法的TFTP操作
5 未知的傳輸ID
6 文件已經存在
7 沒有類似的用戶
Internet用戶數據報頭
（這個只是提供便利，TFTP不一定非要在UDP上實現。）
Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
域的值
Source Port由傳輸發起方選擇
Dest. Port 由目的地選擇（如果是RRQ或WRQ，其值爲69）
Length 包括UDP包頭的包長度
Checksum 校驗碼，如果是0，則未使用校驗。參考2描述了計算校驗碼的規則
注意：TFTP將傳輸標記TID傳送給UDP作爲源和目的端口
參考文獻
[1] USAStandard Code for Information Interchange, USASI X3.4 – 1968.
[2] Postel,J.,“Telnet Protocol Specification” RFC 764, USC/Information Sciences Institute, June, 1980.
[3] Braden,R., Editor,“Requirements for Internet Hosts – Applicationand Support”, RFC 1123, USC/Information SciencesInstitute, October 1989
安全問題
因爲TFTP沒有監權控制機制，因此服務器安全問題應該多加考慮。通常TFTP允許下載數據而不允許上傳數據。
本文檔作者的聯繫方式
Karen R.Sollins
MassachusettsInstitute of Technology
Laboratoryfor Computer Science
545Technology Square
Cambridge,MA 02139-1986
Phone: (617)253-6006
Email:[email protected]