速讀原著-TCP/IP(協議)

第15章 TFTP：簡單文件傳送協議

15.2 協議

在開始工做時，T F T P的客戶與服務器交換信息，客戶發送一個讀請求或寫請求給服務器。在一個無盤系統進行系統引導的正常狀況下，第一個請求是讀請求（ R R Q）。圖1 5 - 1顯示了5 種T F T P報文格式（操做碼爲1和2的報文使用相同的格式）。

T F T P報文的頭兩個字節表示操做碼。對於讀請求和寫請求（ W R Q），文件名字段說明客戶要讀或寫的位於服務器上的文件。這個文件字段以 0字節做爲結束（見圖 1 5 - 1）。模式字段是一個A S C I I碼串n e t a s c i i或o c t e t（可大小寫任意組合），一樣以0字節結束。n e t a s c i i表示數據是以成行的A S C I I碼字符組成，以兩個字節—回車字符後跟換行字符（稱爲 C R / L F）
做爲行結束符。這兩個行結束字符在這種格式和本地主機使用的行定界符之間進行轉化。o c t e t則將數據看做8 bit一組的字節流而不做任何解釋。

每一個數據分組包含一個塊編號字段，它之後要在確認分組中使用。以讀一個文件做爲例子，T F T P客戶須要發送一個讀請求說明要讀的文件名和文件模式 ( m o d e )。若是這個文件能被這個客戶讀取， T F T P服務器就返回一個塊編號爲 1的數據分組。T F T P客戶又發送一個塊編號爲1的A C K。T F T P服務器隨後發送塊編號爲 2的數據。T F T P客戶發回塊編號爲2的A C K。重複這個過程直到這個文件傳送完。除了最後一個數據分組可含有不足 5 1 2字節的數據，其餘每一個數據分組均含有5 1 2字節的數據。當T F T P客戶收到一個不足5 1 2字節的數據分組，就知道它收到最後一個數據分組。

在寫請求的狀況下，TFTP 客戶發送W R Q指明文件名和模式。若是該文件能被 該客戶寫，TFTP 服務器就返回塊編號爲 0的A C K包。該客戶就將文件的頭 5 1 2字節以塊編號爲1發出。服務器則返回塊編號爲1的A C K。

這種類型的數據傳輸稱爲中止等待協議。它只用在一些簡單的協議如 T F T P中。在2 0 . 3節中將看到T C P提供了不一樣形式的確認，能提供更高的系統吞吐量。 T F T P的優勢在於實現的簡單而不是高的系統吞吐量。

最後一種T F T P報文類型是差錯報文，它的操做碼爲 5。它用於服務器不能處理讀請求或寫請求的狀況。在文件傳輸過程當中的讀和寫差錯也會致使傳送這種報文，接着中止傳輸。差錯編號字段給出一個數字的差錯碼，跟着是一個 A S C I I表示的差錯報文字段，可能包含額外的操做系統說明的信息。

既然T F T P使用不可靠的U D P，T F T P就必須處理分組丟失和分組重複。分組丟失可經過發送方的超時與重傳機制解決（注意存在一種稱爲「魔術新手綜合症 ( s o r c e r e r’s apprentice s y n d r o m e )」的潛在問題，若是雙方都超時與重傳，就可能出現這個問題。 12.2 節 [ S t e v e n s 1990] 介紹了這個問題是如何發生的 )。和許多U D P應用程序同樣， T F T P報文中沒有檢驗和，
它假定任何數據差錯都將被 U D P的檢驗和檢測到（參見11 . 3節）。

本文同步分享在 博客「cwl_java」（CSDN）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。