專利名稱：基于tftp的文件傳輸方法、系統(tǒng)、客戶端和服務器的制作方法
技術領域：
本發(fā)明涉及通信領域，尤其涉及一種基于TFTP(Trivial File Transfer I^otocol，簡單文件傳輸協(xié)議)的文件傳輸方法、系統(tǒng)、客戶端和服務器。
背景技術：
在有線通信系統(tǒng)中，通常使用基于TCP(Transmission Control Protocol，傳輸控制協(xié)議)協(xié)議的FTP (File Transfer Protocol，文件傳輸協(xié)議)協(xié)議、HTTP (HyperText Transfer Protocol，超文本傳輸協(xié)議)協(xié)議或者使用基于UDP(User Datagram Protocol, 用戶數(shù)據包協(xié)議)協(xié)議的TFTP協(xié)議實現(xiàn)文件數(shù)據的傳輸?；贔TP協(xié)議和HTTP協(xié)議的傳輸具備連接狀態(tài)，因此傳輸較為可靠，但是其占用系統(tǒng)資源較多。而，基于TFTP協(xié)議的傳輸無連接狀態(tài)，因此占用系統(tǒng)資源較少，但是其沒有安全認證，難以保障系統(tǒng)的傳輸安全。

發(fā)明內容
有鑒于此，本發(fā)明提供一種基于TFTP的文件傳輸方法、系統(tǒng)、客戶端和服務器，提高了 TFTP傳輸系統(tǒng)的安全性。為解決上述問題，本發(fā)明提供一種基于TFTP的文件傳輸方法，包括客戶端向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；當所述服務器對所述客戶端的認證通過時，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸。優(yōu)選的，所述第一認證信息為用戶名和密碼。優(yōu)選的，所述客戶端向服務器發(fā)送第一認證信息具體為所述客戶端向所述服務器發(fā)送連接請求報文，通過新增所述連接請求報文的TFTP選項攜帶所述用戶名和密碼。優(yōu)選的，所述第一認證信息為在數(shù)據傳輸階段，所述客戶端向所述服務器發(fā)送的第一認證指令；和/或在所述數(shù)據傳輸階段之前的首次認證階段，所述客戶端向所述服務器發(fā)送的第二認證指令和/或第一密鑰文件。優(yōu)選的，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸之后還包括所述客戶端向所述服務器發(fā)送第二認證信息，以使所述服務器對所述客戶端進行認證，所述第二認證信息為在控制認證階段，所述客戶端向所述服務器發(fā)送的與所述文件數(shù)據相關的控制指令和/或第二密鑰文件；和/或在所述控制認證階段之前的二次認證階段，所述客戶端向所述服務器發(fā)送的第三認證指令和/或第三密鑰文件。優(yōu)選的，所述客戶端向所述服務器發(fā)送第二認證信息之后還包括所述客戶端接收所述服務器發(fā)送的組合認證結果，所述組合認證結果是由所述服務器對所述第一認證信息和/或所述第二認證信息進行任意組合得到的組合認證信息的認證結果。優(yōu)選的，所述客戶端為數(shù)據發(fā)送端，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸具體為所述客戶端向所述服務器發(fā)送數(shù)據報文，并啟動定時器計時；所述客戶端根據所述定時器的計時，判斷是否定時接收到所述服務器發(fā)送的對所述數(shù)據報文的確認報文；當沒有定時接收到所述確認報文時，所述客戶端重傳所述數(shù)據報文，并復位定時器重新計時。優(yōu)選的，所述客戶端重傳所述數(shù)據報文具體為所述客戶端判斷所述數(shù)據報文的傳輸次數(shù)是否超過預設次數(shù)；當所述數(shù)據報文的傳輸次數(shù)未超過預設次數(shù)時，所述客戶端重傳所述數(shù)據報文；當所述數(shù)據報文的傳輸次數(shù)超過預設次數(shù)時，所述客戶端中斷與所述服務器之間的文件數(shù)據的傳輸。優(yōu)選的，所述客戶端為數(shù)據接收端，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸具體為所述客戶端根據當前接收到的數(shù)據報文時，向所述服務器發(fā)送所述數(shù)據報文的確認報文，并啟動定時器計時；所述客戶端根據所述定時器的計時，判斷是否定時接收到所述服務器發(fā)送的對下一個數(shù)據報文；當沒有定時接收到所述下一個數(shù)據報文時，所述客戶端重傳所述確認報文，并復位定時器重新計時。優(yōu)選的，所述客戶端重傳所述確認報文具體為所述客戶端判斷所述確認報文的傳輸次數(shù)是否超過預設次數(shù)；當所述確認報文的傳輸次數(shù)未超過預設次數(shù)時，所述客戶端重傳所述確認報文；當所述確認報文的傳輸次數(shù)超過預設次數(shù)時，所述客戶端中斷與所述服務器之間的文件數(shù)據的傳輸。本發(fā)明還提供一種TFTP客戶端，包括請求認證模塊，用于向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；數(shù)據傳輸模塊，用于當所述服務器對所述客戶端的認證通過時，與所述服務器之間進行文件數(shù)據的傳輸。本發(fā)明還提供一種TFTP服務器，包括接收模塊，用于接收客戶端發(fā)送的第一認證信息；認證模塊，用于判斷所述第一認證信息是否合法；處理模塊，用于當所述第一認證信息合法時，向所述客戶端發(fā)送表示對所述客戶端的認證通過的認證應答信息，并與所述客戶端進行文件數(shù)據的傳輸。本發(fā)明還提供一種基于TFTP協(xié)議的文件傳輸系統(tǒng)，包括客戶端，用于向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；當所述服務器對所述客戶端的認證通過時，與所述服務器之間進行文件數(shù)據的傳輸；服務器，用于接收客戶端發(fā)送的第一認證信息，判斷所述第一認證信息是否合法，當所述第一認證信息合法時，向所述客戶端發(fā)送表示對所述客戶端的認證通過的認證應答信息，并與所述客戶端進行文件數(shù)據的傳輸。本發(fā)明具有以下有益效果在基于TFTP協(xié)議的文件傳輸過程中，執(zhí)行客戶端與服務器之間的安全認證，增強了系統(tǒng)防護機制。在基于TFTP協(xié)議的文件傳輸過程中，執(zhí)行數(shù)據重傳的可靠傳輸機制，提高了數(shù)據傳輸成功率。


圖1為本發(fā)明的基于TFTP的文件傳輸方法的一流程示意圖；圖2為本發(fā)明的采用選項安全認證機制的文件傳輸方法的流程示意圖；圖3為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的一程示意圖；圖4為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的另一流程示意圖5為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的又一流程示意圖；圖6為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的再一流程示意圖；圖7為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的又一流程示意圖；圖8為本發(fā)明的采用可靠傳輸機制的數(shù)據發(fā)送端的文件傳輸方的法流程示意圖；圖9為本發(fā)明的采用可靠傳輸機制的數(shù)據接收端的文件傳輸方的法流程示意圖；圖10為本發(fā)明的同時采用安全認證機制和可靠傳輸機制的文件傳輸方法的流程示意圖；圖11為本發(fā)明的TFTP客戶端的結構示意圖；圖12為本發(fā)明的TFTP服務器的結構示意圖；圖13為本發(fā)明的基于TFTP的文件傳輸系統(tǒng)的結構示意圖。
具體實施例方式下面結合附圖和實施例，對本發(fā)明的具體實施方式
作進一步詳細描述。如圖1所示為本發(fā)明的基于TFTP的文件傳輸方法的一流程示意圖，該文件傳輸方法包括以下步驟步驟101，客戶端向服務器發(fā)送第一認證信息，以使服務器對客戶端進行認證；步驟102，當服務器對客戶端的認證通過時，客戶端與服務器之間進行文件數(shù)據的傳輸。也就是說，在現(xiàn)有的TFTP文件傳輸流程中，加入客戶端向服務器進行認證的安全認證機制，以提高TFTP系統(tǒng)傳輸?shù)陌踩?。上述第一認證信息可以是多種形式，例如，可以為客戶端的用戶名和密碼，或者一認證指令，又或者一密鑰文件等?？蛻舳丝梢圆捎枚喾N安全認證機制向服務器進行認證，下面將舉例進行說明。
(一)選項安全認證機制所謂選項安全認證機制是指，對客戶端向服務器發(fā)送的連接請求報文進行修改， 新增TFTP選項攜帶上述第一認證信息，該連接請求報文包括寫請求報文和讀請求報文。本發(fā)明的連接請求報文的格式可以如下所示IopcI filename|0|mode|0|username|0|#usrval|0|password|0|#pwdval|0其中，Iopc 表示opcode字段，該字段值為1表示讀請求，為2表示寫請求；Filename 待讀、寫的文件名，可變長度，以一個字節(jié)全零結尾字段；Mode 文件傳輸模式“netaSCii ”，“octet”，或“mail ”，可變長度，以一個字節(jié)全
零結尾字段；username 用戶名選項(Username Option)，以一個字節(jié)全零結尾字段；#Usrval 用戶名值(ASCII表示)，可變長度，以一個字節(jié)全零結尾字段；Password 密碼選項(Password Option)，以一個字節(jié)全零結尾字段；#pwdVal 密碼值(ASCII表示)，可變長度，以一個字節(jié)全零結尾字段。如下所示為本發(fā)明的連接請求報文的一具體實施例1 Iopfile 0|octet|0|username 0 admin|0|password|0 admin|0該報文是一個讀請求報文，文件名為opfile，傳輸模式為octet，用戶名為admin，密碼為admin。請參考圖2，圖2為本發(fā)明的采用選項安全認證機制的文件傳輸方法的流程示意圖，假設客戶端是數(shù)據發(fā)送端，服務器是數(shù)據接收端，第一認證信息為客戶端的用戶名和密碼，所述文件傳輸方法包括以下步驟步驟201，客戶端向服務器發(fā)送寫請求報文，該寫請求報文通過新增TFTP選項攜帶用戶名和密碼。同時，該寫請求報文中還攜帶文件傳輸模式。步驟202，服務器接收到該寫請求報文時，提取該寫請求報文中的用戶名和密碼， 并認證該用戶名和密碼是否合法，如果合法，執(zhí)行步驟204，否則執(zhí)行步驟203 ；步驟203，服務器向客戶端發(fā)送表示認證未通過的非確認消息，例如錯誤碼值4 及錯誤信息“非法用戶名和密碼”(“Illegal username and password")；步驟204，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟205，客戶端接收到該確認消息后，向服務器端發(fā)送數(shù)據報文；步驟206，服務器接收到數(shù)據報文后，向客戶端發(fā)送ACK (確認接收)消息。( 二)擴展安全認證機制請參考圖3，圖3為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的一流程示意圖，假設客戶端是數(shù)據發(fā)送端，服務器是數(shù)據接收端，所述第一認證信息為一認證指令， 所述文件傳輸方法包括以下步驟步驟301，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶第一認證指令; 所述第一認證指令可以包含在該寫請求報文的文件名選項中。該第一認證指令可以為任意預定的指令信息，例如指令“AFFIRM” ；步驟302，服務器接收到該寫請求報文時，提取該寫請求報文中的第一認證指令， 并認證該第一認證指令是否合法，如果合法，執(zhí)行步驟304，否則執(zhí)行步驟303 ；步驟303，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟304，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟305，客戶端接收到該確認消息后，向服務器端發(fā)送數(shù)據報文塊；步驟306，服務器接收到數(shù)據報文后，向客戶端發(fā)送ACK (確認接收)消息。請參考圖4，圖4為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的另一流程示意圖，假設客戶端是數(shù)據發(fā)送端，服務器是數(shù)據接收端，所述文件傳輸方法包括以下步驟(1)首次認證階段步驟401，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶第二認證指令; 所述第二認證指令可以包含在該寫請求報文的文件名選項中。該第二認證指令可以為任意預定的指令信息，例如指令“Authentication” ；步驟402，服務器接收到該寫請求報文時，提取該寫請求報文中的第二認證指令， 并認證該第二認證指令是否合法，如果合法，執(zhí)行步驟404，否則執(zhí)行步驟403 ；步驟403，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟404，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟405，客戶端接收到該確認消息后，向服務器發(fā)送第一密鑰文件；步驟406，服務器接收到該第一密鑰文件后，認證該第一密鑰文件是否合法，如果合法，執(zhí)行步驟408，否則執(zhí)行步驟407 ；步驟407，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟408，服務器向客戶端發(fā)送表示認證通過的確認消息；上述首次認證階段中，是同時采用第一密鑰文件和第一指令信息作為上述第一認證信息完成客戶端的認證，當然，也可以采用其中之一作為上述第一認證信息完成客戶端的認證。(2)數(shù)據傳輸階段步驟409，客戶端向服務器發(fā)送寫請求報文；步驟410，服務器接收到該寫請求報文時，向客戶端發(fā)送ACK消息；步驟411，客戶端接收到該ACK消息后，向服務器端發(fā)送數(shù)據報文；步驟412，服務器接收到該數(shù)據報文后，向客戶端發(fā)送ACK消息。上述圖3所示的實施例中，是在數(shù)據傳輸階段進行安全認證，圖4所示的實施例中，是在數(shù)據傳輸階段之前的首次認證階段進行安全認證，當然，為了進一步提高TFTP系統(tǒng)傳輸?shù)陌踩?，還可以在上述兩個階段均進行安全認證。在有些情況下，數(shù)據發(fā)送端和數(shù)據接收端之間完成文件數(shù)據的傳輸后，數(shù)據發(fā)送端還需要向數(shù)據接收端發(fā)送控制指令，以控制數(shù)據接收端執(zhí)行相應的操作，該控制指令可以是傳輸繼續(xù)指令、系統(tǒng)重啟指令、配置更新指令等，傳輸控制指令的階段也稱為控制認證階段。為了提高TFTP系統(tǒng)傳輸?shù)陌踩?，本發(fā)明中，可以在控制認證階段，或者控制認證階段之前的二次認證階段，由客戶端向服務器發(fā)送第二認證信息，以使服務器對客戶端進行再次認證。請參考圖5，圖5為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的又一流程示意圖，假設客戶端是數(shù)據發(fā)送端，服務器是數(shù)據接收端，所述文件傳輸方法包括以下步驟(1)首次認證階段步驟501，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶第二認證指令；步驟502，服務器接收到該寫請求報文時，提取該寫請求報文中的第二認證指令， 并認證該第二認證指令是否合法，如果合法，執(zhí)行步驟504，否則執(zhí)行步驟503 ；步驟503，服務器向客戶端發(fā)送表示認證未通過的非確認消息；
步驟504，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟505，客戶端接收到該確認消息后，向服務器發(fā)送第一密鑰文件；步驟506，服務器接收到該第一密鑰文件后，認證該第一密鑰文件是否合法，如果合法，執(zhí)行步驟508，否則執(zhí)行步驟507 ；步驟507，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟508，服務器向客戶端發(fā)送表示認證通過的確認消息；(2)數(shù)據傳輸階段步驟509，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶第一認證指令；步驟510，服務器接收到該寫請求報文時，提取該寫請求報文中的第一認證指令， 并認證該第一認證指令是否合法，如果合法，執(zhí)行步驟512，否則執(zhí)行步驟511 ；
步驟511，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟512，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟513，客戶端接收到該確認消息后，向服務器端發(fā)送數(shù)據報文塊；步驟514，服務器接收到數(shù)據報文后，向客戶端發(fā)送ACK (確認接收)消息。(3)控制認證階段步驟515，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶控制指令；所述控制指令可以包含在寫請求報文的文件名選項中；所述控制指令可以為^continue”，表示傳輸繼續(xù)；或者，“update”，表示配置更新；或者“reboot”，表示系統(tǒng)重啟；步驟516，服務器接收到該寫請求報文時，提取該寫請求報文中的控制指令，并檢測該控制指令是否合法，如果合法，執(zhí)行步驟518，否則執(zhí)行步驟517 ；步驟517，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟518，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟519，客戶端接收到該確認消息后，向服務器端發(fā)送第二密鑰文件；步驟520，服務器接收到該第二密鑰文件后，檢測該第二密鑰文件是否合法，如果合法，執(zhí)行步驟522，否則執(zhí)行步驟21 ；步驟521，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟522，服務器向客戶端發(fā)送表示認證通過的確認消息。上述流程中，是在首次認證階段和數(shù)據傳輸階段均進行安全認證，當然，也可以僅在首次認證階段或僅在數(shù)據傳輸階段進行安全認證。另外，在控制認證階段進行了兩次認證控制指令的認證和第二密鑰文件的認證， 當然，也可以不進行第二密鑰文件的認證。此外，還可以在數(shù)據傳輸階段之后、控制認證階段之前，進行二次認證，以進一步提高TFTP系統(tǒng)傳輸?shù)陌踩?。請參考圖6，圖6為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的再一流程示意圖，假設客戶端是數(shù)據發(fā)送端，服務器是數(shù)據接收端，所述文件傳輸方法包括以下步驟(1)首次認證階段步驟601，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶第二認證指令；步驟602，服務器接收到該寫請求報文時，提取該寫請求報文中的第二認證指令， 并認證該第二認證指令是否合法，如果合法，執(zhí)行步驟604，否則執(zhí)行步驟603 ；步驟603，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟604，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟605，客戶端接收到該確認消息后，向服務器發(fā)送第一密鑰文件；步驟606，服務器接收到該第一密鑰文件后，認證該第一密鑰文件是否合法，如果合法，執(zhí)行步驟608，否則執(zhí)行步驟607 ；步驟607，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟608，服務器向客戶端發(fā)送表示認證通過的確認消息；(2)數(shù)據傳輸階段步驟609，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶第一認證指令；
步驟610，服務器接收到該寫請求報文時，提取該寫請求報文中的第一認證指令， 并認證該第一認證指令是否合法，如果合法，執(zhí)行步驟612，否則執(zhí)行步驟611 ；步驟611，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟612，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟613，客戶端接收到該確認消息后，向服務器端發(fā)送數(shù)據報文塊；步驟614，服務器接收到數(shù)據報文后，向客戶端發(fā)送ACK (確認接收)消息。(3) 二次認證階段步驟615，客戶端向服務器發(fā)送寫請求報文，所述寫該寫請求報文中攜帶第三認證指令；所述第三認證指令可以包含在該寫請求報文的文件名選項中。該第三認證指令可以為任意預定的指令信息；步驟616，服務器接收到該寫請求報文時，提取該寫請求報文中的第三認證指令， 并認證該第三認證指令是否合法，如果合法，執(zhí)行步驟618，否則執(zhí)行步驟617 ；步驟617，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟618，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟619，客戶端接收到該確認消息后，向服務器發(fā)送第三密鑰文件；步驟620，服務器接收到該第三密鑰文件后，認證該第三密鑰文件是否合法，如果合法，執(zhí)行步驟622，否則執(zhí)行步驟621 ；步驟621，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟622，服務器向客戶端發(fā)送表示認證通過的確認消息；(4)控制認證階段步驟623，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶控制指令；所述控制指令可以包含在寫請求報文的文件名選項中；步驟624，服務器接收到該寫請求報文時，提取該寫請求報文中的控制指令，并檢測該控制指令是否合法，如果合法，執(zhí)行步驟626，否則執(zhí)行步驟625 ；步驟625，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟626，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟627，客戶端接收到該確認消息后，向服務器端發(fā)送第二密鑰文件；步驟628，服務器接收到該第二密鑰文件后，檢測該第二密鑰文件是否合法，如果合法，執(zhí)行步驟630，否則執(zhí)行步驟629 ；步驟629，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟630，服務器向客戶端發(fā)送表示認證通過的確認消息。上述流程中，在首次認證階段和數(shù)據傳輸階段均進行安全認證，當然，也可以僅在首次認證階段或數(shù)據傳輸階段進行安全認證。此外，在首次認證階段進行了兩次認證，第二認證指令的認證和第一密鑰文件的認證，當然，也可以僅進行一次認證。另外，在二次認證階段進行了兩次認證，第三認證指令的認證和第三密鑰文件的認證，當然，也可以僅進行一次認證。另外，在控制認證階段進行了兩次認證控制指令的認證和第二密鑰文件的認證， 當然，也可以不進行第二密鑰文件的認證。在上述認證過程中，服務器還可以對接收到的第一認證信息和/或第二認證信息進行保存，在控制認證階段完成后，將存儲的第一認證信息和/或第二認證信息進行組合認證，當認證合法時，服務器向客戶端發(fā)送一指示認證通過的組合認證結果，當認證不合法時，服務器向客戶端發(fā)送一指示認證未通過的組合認證結果。請參考圖7，圖7為本發(fā)明的采用擴展安全認證機制的文件傳輸方法的又一流程示意圖，假設客戶端是數(shù)據發(fā)送端，服務器是數(shù)據接收端，所述文件傳輸方法包括以下步驟(1)首次認證階段步驟701，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶第二認證指令；步驟702，服務器接收到該寫請求報文時，提取該寫請求報文中的第二認證指令， 存儲該第二認證指令，并認證該第二認證指令是否合法，如果合法，執(zhí)行步驟704，否則執(zhí)行步驟703 ；步驟703，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟704，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟705，客戶端接收到該確認消息后，向服務器發(fā)送第一密鑰文件；步驟706，服務器接收到該第一密鑰文件后，認證該第一密鑰文件是否合法，如果合法，執(zhí)行步驟708，否則執(zhí)行步驟707 ；步驟707，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟708，服務器向客戶端發(fā)送表示認證通過的確認消息；(2)數(shù)據傳輸階段步驟709，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶第一認證指令；步驟710，服務器接收到該寫請求報文時，提取該寫請求報文中的第一認證指令， 存儲該第一認證指令，并認證該第一認證指令是否合法，如果合法，執(zhí)行步驟712，否則執(zhí)行步驟711 ；步驟711，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟712，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟713，客戶端接收到該確認消息后，向服務器端發(fā)送數(shù)據報文塊；步驟714，服務器接收到數(shù)據報文后，向客戶端發(fā)送ACK (確認接收)消息。(3) 二次認證階段步驟715，客戶端向服務器發(fā)送寫請求報文，所述寫該寫請求報文中攜帶第三認證指令；步驟716，服務器接收到該寫請求報文時，提取該寫請求報文中的第三認證指令， 存儲該第三認證指令，并認證該第三認證指令是否合法，如果合法，執(zhí)行步驟718，否則執(zhí)行步驟717 ；步驟717，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟718，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟719，客戶端接收到該確認消息后，向服務器發(fā)送第三密鑰文件；步驟720，服務器接收到該第三密鑰文件后，認證該第三密鑰文件是否合法，如果合法，執(zhí)行步驟722，否則執(zhí)行步驟721 ；步驟721，服務器向客戶端發(fā)送表示認證未通過的非確認消息；
步驟722，服務器向客戶端發(fā)送表示認證通過的確認消息；(4)控制認證階段步驟723，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶控制指令；所述控制指令可以包含在寫請求報文的文件名選項中；步驟724，服務器接收到該寫請求報文時，提取該寫請求報文中的控制指令，存儲該控制指令，并檢測該控制指令是否合法，如果合法，執(zhí)行步驟727，否則執(zhí)行步驟725 ；步驟725，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟726，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟727，客戶端接收到該確認消息后，向服務器端發(fā)送第二密鑰文件；步驟728，服務器接收到該第二密鑰文件后，檢測該第二密鑰文件是否合法，如果合法，執(zhí)行步驟730，否則執(zhí)行步驟729 ；步驟729，服務器向客戶端發(fā)送表示認證未通過的非確認消息；步驟730，服務器向客戶端發(fā)送表示認證通過的確認消息。(5)組合認證階段步驟731，服務器將存儲的第一認證指令、第二認證指令、第三認證指令和控制指令進行組合，得到一組合指令，并認證該組合指令是否合法，當該組合指令合法時，執(zhí)行步驟732，否則，執(zhí)行步驟733 ；步驟732，服務器執(zhí)行控制指令；步驟733，服務器向客戶端發(fā)送表示認證未通過的非確認消息。上述認證過程中，服務器可以保存上述任意一個階段的認證指令和/或密鑰文件，并根據保存的認證指令和/或密鑰文件，進行組合認證。上述實施例中的第一密鑰文件和第二密鑰文件可以相同，也可以不同，第一認證指令、第二認證指令和第三指令認證指令可以相同，也可以不同。為了能夠提高TFTP傳輸系統(tǒng)的數(shù)據傳輸成功率，本發(fā)明中的數(shù)據發(fā)送端和數(shù)據接收端之間進行文件數(shù)據傳輸過程中，還可以使用數(shù)據重傳等可靠傳輸機制。下面將分別就數(shù)據發(fā)送端和數(shù)據接收端的重傳機制進行說明。(1)數(shù)據發(fā)送端發(fā)送的數(shù)據報文丟失如圖8所示，假設客戶端為數(shù)據發(fā)送端，本發(fā)明實施例的文件傳輸方法還包括以下步驟步驟801，客戶端向服務器發(fā)送數(shù)據報文，并啟動定時器計時；步驟802，客戶端根據定時器的計時，判斷是否定時接收到服務器發(fā)送的對該數(shù)據報文的確認報文；如果是，執(zhí)行步驟803 ；否則，執(zhí)行步驟804 ；步驟803，客戶端按照步驟801-806，向服務器發(fā)送下一個數(shù)據報文；步驟804，客戶端判斷傳輸次數(shù)是否超過預設次數(shù)，如果是，執(zhí)行步驟806，否則， 返回步驟805 ；步驟805，客戶端重傳所述數(shù)據報文，并復位定時器重新計時；步驟806，客戶端中斷與服務器之間的文件數(shù)據的傳輸。同樣的，當服務器作為數(shù)據發(fā)送端時，也可以按照上述可靠傳輸機制進行數(shù)據報文的重傳。
12
(2)數(shù)據接收端發(fā)送的確認報文丟失如圖9所示，假設客戶端為數(shù)據接收端，本發(fā)明實施例的文件傳輸方法還包括以下步驟步驟901，客戶端根據當前接收到的數(shù)據報文時，向服務器發(fā)送該數(shù)據報文的確認報文，并啟動定時器計時；步驟902，客戶端根據定時器的計時，判斷是否定時接收到服務器發(fā)送的對下一個數(shù)據報文，如果是，執(zhí)行步驟903，否則，執(zhí)行步驟904 ；步驟903，客戶端按照步驟901-906，根據接收到該下一個數(shù)據報文，向服務器發(fā)送該下一個數(shù)據報文的確認報文；步驟904，客戶端對該確認報文的傳輸次數(shù)進行計數(shù)，并判斷傳輸次數(shù)是否超過預設次數(shù)，如果是，執(zhí)行步驟906，否則，返回步驟905 ；步驟905，客戶端重傳該確認報文，并復位定時器重新計時；步驟906，客戶端中斷與服務器之間的文件數(shù)據的傳輸。(3)數(shù)據接收端接收到重復的數(shù)據報文數(shù)據接收端接收到一數(shù)據報文時，可以記錄該數(shù)據報文的序號；檢測當前接收到的數(shù)據報文的序號是否與前面接收到的數(shù)據報文的序號重復，如果重復，則丟棄當前接收到的數(shù)據報文。上述客戶端可以為Modem終端，服務器可以為DSLAM(Digital Subscriber Line Access Multiplexer，數(shù)字用戶線路接入復用器)或終端管理系統(tǒng)，兩者之間通過局域網絡連接。上述實施例中，數(shù)據發(fā)送端可以通過修改向數(shù)據接收端發(fā)送的連接請求報文，與數(shù)據接收端協(xié)商重傳次數(shù)，具體的，可以新增連接請求報文的TFTP選項，攜帶重傳次數(shù)，修改后的連接請求報文可以如下所示|opc filename I0|mode |0|retrans|0|#times|0|其中，Opc 表示opcode字段，該字段值為1表示讀請求，為2表示寫請求；Filename 待讀、寫的文件名，可變長度，以一個字節(jié)全零結尾字段；Mode:文件傳輸模式“netascii"，“ octet"，或〃 mail"，可變長度，以一個字節(jié)全零結尾字段；Retrans 重傳次數(shù)選項(Retransmission Times option)，以一個字節(jié)全零結尾字段；#times 重傳次數(shù)(ASCII表示)，有效值介于〃 1〃和〃 255“次，可變長度，以一個字節(jié)全零結尾字段。如下所示為本發(fā)明的連接請求報文的一具體實施例1 |opfile|0Ioctet 0|retrans|0 3 0該連接請求報文是一個讀請求報文，文件名為opfile，傳輸模式為octet，重傳次數(shù)為3次。另外，在文件傳輸過程中，還可以將用于安全認證的第一認證信息和用于可靠傳輸?shù)闹貍鞔螖?shù)，同時由一連接請求報文攜帶。此外，上述連接請求報文中，還可以新增TFTP 選項，用于攜帶定時器的超時時間。
請參考圖10，圖10為本發(fā)明實施例的同時采用安全認證機制和可靠傳輸機制的文件傳輸方法的流程示意圖，假設客戶端是數(shù)據發(fā)送端，服務器是數(shù)據接收端，上述第一認證信息為客戶端的用戶名和密碼，所述文件傳輸方法包括以下步驟步驟1001，客戶端向服務器發(fā)送寫請求報文，該寫請求報文中攜帶用戶名、密碼、 重傳次數(shù)和定時器超時時間。同時，該寫請求報文中還攜帶文件傳輸模式，假設文件傳輸模式為octet模式，用戶名為admin，密碼為password，重傳次數(shù)為10次，定時器超時時間為 5秒。步驟1002，服務器接收到該寫請求報文時，提取該寫請求報文中的用戶名、密碼、 重傳次數(shù)和定時器超時時間，并認證該用戶名和密碼是否合法，如果合法，執(zhí)行步驟1004， 否則執(zhí)行步驟1003 ；步驟1003，服務器向客戶端發(fā)送錯誤碼值4及錯誤信息“非法用戶名和密碼”；步驟1004，服務器向客戶端發(fā)送表示認證通過的確認消息；步驟1005，客戶端接收到該確認消息后，向服務器端發(fā)送數(shù)據報文，并啟動定時器計時；步驟1006，客戶端判斷是否在5秒內接收到服務器發(fā)送的對該數(shù)據報文的確認報文；如果是，執(zhí)行步驟1007 ；否則，執(zhí)行步驟1008 ；步驟1007，客戶端按照步驟1005-1010，向服務器發(fā)送下一個數(shù)據報文；步驟1008，客戶端判斷傳輸次數(shù)是否超過預設次數(shù)，如果是，執(zhí)行步驟1010，否則，執(zhí)行步驟1009 ；步驟1009，客戶端重傳所述數(shù)據報文，并復位定時器重新計時；步驟1010，客戶端中斷與服務器之間的文件數(shù)據的傳輸。本發(fā)明還提供一種TFTP客戶端，如圖11所示，所述TFTP客戶端包括請求認證模塊1101，用于向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；數(shù)據傳輸模塊1102，用于當所述服務器對所述客戶端的認證通過時，與所述服務器之間進行文件數(shù)據的傳輸。所述客戶端按照上述實施例記載的文件傳輸方法進行文件數(shù)據的傳輸。本發(fā)明還提供一種TFTP服務器，如圖12所示，所述TFTP服務器包括接收模塊 1201，用于接收客戶端發(fā)送的第一認證信息；認證模塊1202，用于判斷所述第一認證信息是否合法；處理模塊1203，用于當所述第一認證信息合法時，向所述客戶端發(fā)送表示對所述客戶端的認證通過的認證應答信息，并與所述客戶端進行文件數(shù)據的傳輸。本發(fā)明還提供一種基于TFTP協(xié)議的文件傳輸系統(tǒng)，如圖13所示，所述文件傳輸系統(tǒng)包括客戶端1301，用于向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；當所述服務器對所述客戶端的認證通過時，與所述服務器之間進行文件數(shù)據的傳輸；服務器1302，用于接收客戶端發(fā)送的第一認證信息，判斷所述第一認證信息是否合法， 當所述第一認證信息合法時，向所述客戶端發(fā)送表示對所述客戶端的認證通過的認證應答信息，并與所述客戶端進行文件數(shù)據的傳輸。以上所述僅是本發(fā)明的優(yōu)選實施方式，應當指出，對于本技術領域的普通技術人員來說，在不脫離本發(fā)明原理的前提下，還可以作出若干改進和潤飾，這些改進和潤飾也應視為本發(fā)明的保護范圍。
權利要求
1.一種基于TFTP的文件傳輸方法，其特征在于，包括客戶端向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；當所述服務器對所述客戶端的認證通過時，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸。
2.如權利要求1所述的基于TFTP的文件傳輸方法，其特征在于，所述第一認證信息為用戶名和密碼。
3.如權利要求2所述的基于TFTP的文件傳輸方法，其特征在于，所述客戶端向服務器發(fā)送第一認證信息具體為所述客戶端向所述服務器發(fā)送連接請求報文，通過新增所述連接請求報文的TFTP選項攜帶所述用戶名和密碼。
4.如權利要求1所述的基于TFTP的文件傳輸方法，其特征在于，所述第一認證信息為在數(shù)據傳輸階段，所述客戶端向所述服務器發(fā)送的第一認證指令；和/或在所述數(shù)據傳輸階段之前的首次認證階段，所述客戶端向所述服務器發(fā)送的第二認證指令和/或第一密鑰文件。
5.如權利要求1或4所述的基于TFTP的文件傳輸方法，其特征在于，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸之后還包括所述客戶端向所述服務器發(fā)送第二認證信息，以使所述服務器對所述客戶端進行認證，所述第二認證信息為在控制認證階段，所述客戶端向所述服務器發(fā)送的與所述文件數(shù)據相關的控制指令和 /或第二密鑰文件；和/或在所述控制認證階段之前的二次認證階段，所述客戶端向所述服務器發(fā)送的第三認證指令和/或第三密鑰文件。
6.如權利要求5所述的基于TFTP的文件傳輸方法，其特征在于，所述客戶端向所述服務器發(fā)送第二認證信息之后還包括所述客戶端接收所述服務器發(fā)送的組合認證結果，所述組合認證結果是由所述服務器對所述第一認證信息和/或所述第二認證信息進行任意組合得到的組合認證信息的認證結果。
7.如權利要求1所述的基于TFTP的文件傳輸方法，其特征在于，所述客戶端為數(shù)據發(fā)送端，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸具體為所述客戶端向所述服務器發(fā)送數(shù)據報文，并啟動定時器計時；所述客戶端根據所述定時器的計時，判斷是否定時接收到所述服務器發(fā)送的對所述數(shù)據報文的確認報文；當沒有定時接收到所述確認報文時，所述客戶端重傳所述數(shù)據報文，并復位定時器重新計時。
8.如權利要求7所述的基于TFTP的文件傳輸方法，其特征在于，所述客戶端重傳所述數(shù)據報文具體為所述客戶端判斷所述數(shù)據報文的傳輸次數(shù)是否超過預設次數(shù)；當所述數(shù)據報文的傳輸次數(shù)未超過預設次數(shù)時，所述客戶端重傳所述數(shù)據報文；當所述數(shù)據報文的傳輸次數(shù)超過預設次數(shù)時，所述客戶端中斷與所述服務器之間的文件數(shù)據的傳輸。
9.如權利要求1所述的基于TFTP的文件傳輸方法，其特征在于，所述客戶端為數(shù)據接收端，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸具體為所述客戶端根據當前接收到的數(shù)據報文時，向所述服務器發(fā)送所述數(shù)據報文的確認報文，并啟動定時器計時；所述客戶端根據所述定時器的計時，判斷是否定時接收到所述服務器發(fā)送的對下一個數(shù)據報文；當沒有定時接收到所述下一個數(shù)據報文時，所述客戶端重傳所述確認報文，并復位定時器重新計時。
10.如權利要求9所述的基于TFTP的文件傳輸方法，其特征在于，所述客戶端重傳所述確認報文具體為所述客戶端判斷所述確認報文的傳輸次數(shù)是否超過預設次數(shù)；當所述確認報文的傳輸次數(shù)未超過預設次數(shù)時，所述客戶端重傳所述確認報文；當所述確認報文的傳輸次數(shù)超過預設次數(shù)時，所述客戶端中斷與所述服務器之間的文件數(shù)據的傳輸。
11.一種TFTP客戶端，其特征在于，包括請求認證模塊，用于向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；數(shù)據傳輸模塊，用于當所述服務器對所述客戶端的認證通過時，與所述服務器之間進行文件數(shù)據的傳輸。
12.—種TFTP服務器，其特征在于，包括接收模塊，用于接收客戶端發(fā)送的第一認證信息；認證模塊，用于判斷所述第一認證信息是否合法；處理模塊，用于當所述第一認證信息合法時，向所述客戶端發(fā)送表示對所述客戶端的認證通過的認證應答信息，并與所述客戶端進行文件數(shù)據的傳輸。
13.一種基于TFTP協(xié)議的文件傳輸系統(tǒng)，其特征在于，包括客戶端，用于向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；當所述服務器對所述客戶端的認證通過時，與所述服務器之間進行文件數(shù)據的傳輸；服務器，用于接收客戶端發(fā)送的第一認證信息，判斷所述第一認證信息是否合法，當所述第一認證信息合法時，向所述客戶端發(fā)送表示對所述客戶端的認證通過的認證應答信息，并與所述客戶端進行文件數(shù)據的傳輸。
全文摘要
本發(fā)明提供一種基于TFTP的文件傳輸方法、系統(tǒng)、客戶端和服務器，所述文件傳輸方法包括客戶端向服務器發(fā)送第一認證信息，以使所述服務器對所述客戶端進行認證；當所述服務器對所述客戶端的認證通過時，所述客戶端與所述服務器之間進行文件數(shù)據的傳輸。使用本發(fā)明，能夠提高TFTP傳輸系統(tǒng)的安全性。
文檔編號H04L1/16GK102355480SQ201110205630
公開日2012年2月15日 申請日期2011年7月21日 優(yōu)先權日2011年7月21日
發(fā)明者王九經 申請人:中興通訊股份有限公司