tftp文件傳輸協議詳解
時間：2018-07-30 來源：未知
TFTP是一個傳輸文件的簡單協議，它基于UDP協議而實現，但是我們也不能確定有些TFTP協議是基于其它傳輸協議完成的。
此協議設計的時候是進行小文件傳輸的。因此它不具備通常的FTP的許多功能，它只能從文件服務器上獲得或寫入文件，
不能列出目錄，不進行認證，它傳輸8位數據。傳輸中有三種模式：netascii，這是8位的ASCII碼形式，另一種是octet，
這是8位源數據類型;最后一種mail已經不再支持，它將返回的數據直接返回給用戶而不是保存為文件。
任何傳輸起自一個讀取或寫入文件的請求，這個請求也是連接請求。如果服務器批準此請求，則服務器打開連接，
數據以定長512字節傳輸。每個數據包包括一塊數據，服務器發出下一個數據包以前必須得到客戶對上一個數據包的確認。
如果一個數據包的大小小于512字節，則表示傳輸結束。如果數據包在傳輸過程中丟失，
發出方會在超時后重新傳輸最后一個未被確認的數據包。通信的雙方都是數據的發出者與接收者，一方傳輸數據接收應答，
另一方發出應答接收數據。大部分的錯誤會導致連接中斷，錯誤由一個錯誤的數據包引起。這個包不會被確認，
也不會被重新發送，因此另一方無法接收到。如果錯誤包丟失，則使用超時機制。錯誤主要是由下面三種情況引起的：
不能滿足請求，收到的數據包內容錯誤，而這種錯誤不能由延時或重發解釋，對需要資源的訪問丟失(如硬盤滿)。
TFTP只在一種情況下不中斷連接，這種情況是源端口不正確，在這種情況下，指示錯誤的包會被發送到源機。
這個協議限制很多，這些都是為了實現起來比較方便而進行的。
TFTP是一個簡單的協議，適合于只讀存儲器，僅用于無盤系統進行系統引導，它只使用幾種報文格式，是一種停止等待協議
特點：
1、簡單
2、占用資源小
3、適合傳遞小文件
4、適合在局域網進行傳遞
5、端口號為69
6、基于UDP實現
缺陷：
TFTP分組中并不提供用戶名和口令。這是TFTP的一個特性(即"安全漏洞")。由于TFTP是設計用于系統引導進程，它不可能提供用戶名和口令。
目前大多數TFTP服務器提供了一個選項來限制只能訪問特定目錄下的文件，這個目錄中只包含無盤系統進行系統引導時所需的文件
當服務器找到需要現在的文件后，會立刻打開文件，把文件中的數據通過TFTP協議發送給客戶端
如果文件的總大小較大(比如3M)，那么服務器分多次發送，每次會從文件中讀取512個字節的數據發送過來
因為發送的次數有可能會很多，所以為了讓客戶端對接收到的數據進行排序，所以在服務器發送那512個字節數據的時候，會多發2個字節的數據，用來存放序號，并且放在512個字節數據的前面，序號是從1開始的
因為需要從服務器上下載文件時，文件可能不存在，那么此時服務器就會發送一個錯誤的信息過來，為了區分服務發送的是文件內容還是錯誤的提示信息，所以又用了2個字節 來表示這個數據包的功能(稱為操作碼)，并且在序號的前面。
為了允許多個客戶端同時進行系統引導，TFTP服務器必須提供一定形式的并發。因為UDP在一個客戶與一個服務器之間并不提供唯一連接，TFTP服務通過對每個客戶提供一個新的UDP端口來提供并發。這樣允許不同的客戶輸入數據報，然后由服務器中的UDP模塊根據目的端口號進行區分，而不是由服務器本身來進行區分。
因為udp的數據包不安全，即發送方發送是否成功不能確定，所以TFTP協議中規定，為了讓服務器知道客戶端已經接收到了剛剛發送的那個數據包，所以當客戶端接收到一個數據包的時候需要向服務器進行發送確認信息，即發送收到了，這樣的包成為ACK(應答包)
為了標記數據已經發送完畢，所以規定，當客戶端接收到的數據小于516(2字節操作碼+2個字節的序號+512字節數據)時，就意味著服務器發送完畢了
