史孝波周松斌黃東運程韜波
(1.廣東工業(yè)大學 2.廣東省自動化研究所)
一種基于UDP的文件獲取協(xié)議的實現(xiàn)*
史孝波1,2周松斌2黃東運2程韜波2
(1.廣東工業(yè)大學 2.廣東省自動化研究所)
文件傳輸協(xié)議(file transfer protocol,F(xiàn)TP)是網絡傳輸文件的常用協(xié)議,內容較復雜。由于采用了傳輸控制協(xié)議(transport control protocol,TCP)提供的可靠傳輸服務,使用FTP傳輸文件時經常出現(xiàn)數據延遲問題。為此提出一種文件獲取協(xié)議(file obtain protocol,F(xiàn)OP)。FOP底層傳輸使用用戶數據報協(xié)議(user datagram protocol,UDP),無需非常復雜的傳輸模型即可實現(xiàn)在網絡上傳輸包括音視頻在內的多類型文件。同時介紹了FOP的工作原理和實現(xiàn)方法,編寫了基于FOP協(xié)議的客戶和服務器軟件。
FOP;文件傳輸;UDP;傳輸協(xié)議
21世紀人類社會已經進入了一個以計算機網絡為核心的信息化時代[1]。使用Internet提供的服務,人們能夠方便地訪問大量的信息。FTP是網絡文件傳輸的常用協(xié)議,通過兩個并發(fā)的TCP連接來完成網絡通信。FTP內部協(xié)議命令數目繁多,實現(xiàn)起來較為復雜。基于TCP的應用程序必須使用TCP所提供的可靠性、順序交付等服務,應用程序不能要求TCP去關閉某些不需要的功能,無論應用程序是否需要,TCP都要強制使用。在效率高于可靠性的應用中,要求數據盡量在主機之間流動,允許偶爾的數據丟失,但無法容忍由于可靠性帶來的延遲。對這些程序,TCP提供的可靠性、順序交付等不僅毫無價值,而且還會影響程序的正常行為。
基于以上問題,本文提出了一種文件獲取協(xié)議FOP。該協(xié)議具有易于實現(xiàn)、安全穩(wěn)定的特點,適合于傳輸多種類型的文件。以Visual Studio 2005為平臺,編寫基于FOP協(xié)議的客戶和服務器軟件。通過網絡通信實例,進一步闡述FOP協(xié)議的原理、特點和實現(xiàn)方法。
1.1 UDP客戶/服務器程序模型
與FTP采用TCP連接來完成數據傳輸的方式不同,F(xiàn)OP在傳輸層采用UDP協(xié)議。UDP為FOP的設計提供了基本的數據報傳輸機制。
UDP客戶/服務器程序模型如圖1所示。

圖1 UDP客戶/服務器程序模型
服務器創(chuàng)建socket之后,調用bind綁定本地地址,接收數據時調用函數recvfrom。recvfrom可以接收到達本地端口的任何數據,并保存數據發(fā)送方的地址。服務器把應答數據通過這個地址發(fā)送給客戶端。客戶端與服務器通信之前不需要建立連接,直接調用函數sendto發(fā)送數據,函數sendto在參數中已經指明了數據接收地址。
采用UDP模型的應用程序發(fā)送數據之前,不需要建立連接。數據發(fā)送完成后,也不用終止連接。只要應用程序有數據,就直接發(fā)送,沒有連接建立、維護、終止所帶來的開銷。由此給程序的設計帶來了靈活性和效率的提升。但是UDP也是不可靠的,對發(fā)送的數據,并不保證對方一定會收到,即使收到了也沒有確認。FOP的消息傳遞過程被設計為兩個階段來保證數據的重傳及確認,解決可靠性問題。第一階段,由客戶發(fā)出“內容發(fā)起請求”消息,服務器收到客戶消息后,向客戶發(fā)出“內容發(fā)起請求回應”消息;第二階段,客戶向服務器發(fā)出“請求進行內容傳送”消息,服務器收到客戶消息后,發(fā)出“進行內容傳送”消息。FOP消息傳遞流程如圖2所示。

圖2 FOP消息傳遞流程圖
1.2 FOP消息結構定義
FOP消息結構包括:FOP消息頭和FOP消息體兩部分。消息頭包括協(xié)議標識、應用標識、命令標識、內容類型等多個字段,固定為4個字節(jié)長度;消息體為傳輸數據的具體內容。每個字段的描述如表1所示(消息體只列舉了許可碼和數據包數量的定義)。

表1 FOP消息結構定義
FOP使用UDP作為底層傳輸協(xié)議。UDP位于網絡通信協(xié)議族的第三層,默認使用IP作為下一層的傳輸協(xié)議。網絡傳輸的過程中,F(xiàn)OP消息被封裝在IP數據報中,如圖3所示。

圖3 封裝了FOP消息的IP數據報
消息體裝載客戶請求的數據內容,長度不定。數據內容由各種類型的字段組成,每個字段用來表示不同的內容。例如表1中的許可碼和數據包數量。字段標記占用1個字節(jié),每個字段開始必須由對應的1個字段結束。消息體的內容長度分為定長和不定長兩種。當消息體的內容是不定長時,還有長度標記,長度標記占2個字節(jié)。
1.3 FOP傳輸數據表示
通過對不同數據類型的編解碼,F(xiàn)OP實現(xiàn)了傳輸數據類型的多種選擇。客戶從服務器下載文件時,既可使用默認的文本類型,也可選擇其它文件類型。FOP支持文本、富文本、圖像、動畫、音視頻這5種文件類型。
目前FOP協(xié)議只支持文件式結構,即傳輸的文件中沒有內部結構,文件的數據內容以二進制流的方式傳輸。FOP支持多包發(fā)送,如果客戶請求的內容在編碼后的長度大于一個數據包所許可的最大長度,將拆分傳送。在文件的傳輸過程中,F(xiàn)OP一次支持傳送的數據包大小為1kb,最大數據包數量為65535個。
1.4 FOP的安全策略
FOP的安全策略是通過采用UDP作為底層傳輸協(xié)議,設置客戶的操作權限以及增加許可碼功能來實現(xiàn)的。
FOP底層的傳輸協(xié)議使用UDP。在開始傳輸數據之前不需要建立TCP連接,避免了連接模式帶來的安全隱患。連接模式的安全隱患體現(xiàn)在:連接一旦被黑客攻擊,防火墻將不會有任何動作去處理這個連接。因為連接是由服務器本身向外發(fā)出的。
通過軟件設計,可以指定用戶對FOP服務器文件的操作權限。例如設置用戶“只讀”權限,即用戶只能從服務器下載文件,從而限制非法用戶對服務器文件的篡改。
FOP服務器在接收客戶的文件獲取請求時,要求客戶提供許可碼。許可碼是服務器隨機生成的一組16位字符串,內容包括大小寫字母和數字,如圖4所示。在每次傳輸數據前,客戶通過第三方途徑(如手機短信、QQ等)得到服務器的許可碼。收到客戶的獲取文件請求時,F(xiàn)OP服務器驗證客戶的許可碼。對許可碼不正確的客戶,服務器將認為是非法客戶,其請求不做處理。

圖4 FOP服務器生成的16個許可碼
依照FOP協(xié)議規(guī)范,以Visual Studio 2005為平臺,編寫了基于FOP協(xié)議的客戶與服務器軟件。
2.1 軟件設計流程
FOP的軟件設計分為客戶程序設計和服務器程序設計兩個部分,如圖5所示。

圖5 FOP軟件設計流程圖
客戶程序的主要任務是從服務器下載資源文件。首先客戶端初始化,創(chuàng)建socket套接字。初始化成功后,向服務器發(fā)送預請求命令“CMD_PRE_CONTENT_REQUEST”。由于FOP使用Winsock編程,如果程序不確定有數據到來就調用recvfrom,則該套接字線程就會進入阻塞狀態(tài)。解決套接字線程阻塞的辦法是調用select,select在監(jiān)測緩沖區(qū)后,會立刻返回,然后給出返回值。這樣程序就可以繼續(xù)其它操作,而不會陷入阻塞狀態(tài)。當客戶收到服務器的響應后,發(fā)送數據請求命令“CMD_REQUEST_DELIVERY”,繼續(xù)進入監(jiān)測狀態(tài),直到有數據到來,將數據保存到指定的位置。
服務器程序的主要任務是為客戶提供下載資源,響應客戶程序的命令,傳輸數據。服務器程序也使用Winsock編程,程序流程與客戶程序的流程類似。服務器初始化成功后,開始等待客戶的命令。當收到客戶的預請求命令后,發(fā)送命令“CMD_PRE_CONT ENT_REQUEST_ACK”來響應客戶的請求,否則調用select函數來繼續(xù)等待客戶發(fā)送的命令。當服務器收到客戶的數據請求命令后,將數據發(fā)送給客戶,發(fā)送完成后,關閉套接字。
2.2 通信測試實驗
通信測試實驗在Windows XP Professional操作系統(tǒng)上進行,硬件基本配置:Intel(R) Core(TM)i3 CPU 2.39 GHz,1.92 GB內存。通過從FOP服務器下載一個音視頻文件來說明通信測試過程。
在服務器窗口,點擊“運行”按鈕,“運行”兩字變?yōu)椤胺掌饕呀涍\行”,表明服務器成功啟動。為服務器加載文本、圖像、動畫等資源文件,F(xiàn)OP服務器加載資源文件后如圖6所示。

圖6 加載了資源文件的FOP服務器
創(chuàng)建服務器成功后,啟動客戶端。在客戶端IP地址欄輸入服務器的地址“192.168.0.100”,端口號選擇“9158”,下載的文件類型選擇“音視頻”。點擊“請求資源”按鈕,此時會彈出“另存為”的窗口。把文件保存在指定位置,這時音視頻文件playgame.flv便成功地從FOP服務器下載到了客戶端。
打開從FOP服務器下載的音視頻文件,文件內容完整清晰。選擇不同的下載文件類型,進行了文本、圖像等其它類型文件的通信實驗。并調用TRACE函數,跟蹤了數據包的傳送情況,結果統(tǒng)計如表2所示。

表2 FOP傳送各類文件統(tǒng)計表
由于FOP一次支持傳送的數據包大小為1kb,最大數據包數量為65535個。觀察表2中的數據可以看出,在文件傳輸過程中,沒有出現(xiàn)丟包狀況,證明使用FOP協(xié)議傳輸文件是可靠的。
與傳統(tǒng)的用FTP實現(xiàn)網絡文件傳輸的辦法相比,F(xiàn)OP文件獲取協(xié)議更易理解和掌握。基于FOP協(xié)議的應用程序無需建立復雜的傳輸模型即可實現(xiàn)互相交換消息,而且其底層使用UDP作為數據傳輸協(xié)議,沒有連接建立、維護、終止所帶來的開銷,能夠達到較高的通信效率,適合于對效率要求較高的場合,如圖像傳送和廣播消息等。FOP協(xié)議同樣對開發(fā)實時的語音傳輸、多媒體應用等具有一定的借鑒意義。
[1] 趙強.基于FTP協(xié)議的文件傳輸服務器的研究[D].大連:大連海事大學,2008.
[2] 孫韓林,金躍輝,高雪松,等.FTP協(xié)議的測試及分析[J].計算機工程,2008,34(23):133-138.
[3] 張會勇.WinSock網絡編程經絡[M].北京:電子工業(yè)出版社,2012:41-51.
[4] 李祥.基于Web的網絡文件管理系統(tǒng)的研究與實現(xiàn)[D].蘭州:蘭州大學,2010.
A Realization of File Obtain Protocol Based on UDP
Shi Xiaobo1,2Zhou Songbin2Huang Dongyun2Cheng Taobo2
(1.Guangdong University of Technology 2.Institute of Automation, Guangdong)
The File Transfer Protocol is a common protocol for file transfer in network, but the contents of FTP is complicated. FTP has often data transmission delay problem when transferring files, this is due to FTP uses the service provided by Transport Control Protocol. Therefore this paper presents a File Obtain Protocol. FOP uses User Datagram Protocol as the underlying transport protocol, FOP can transfer multiple types of files without complicated transmission model, these files include audio, video and so on. This paper introduces the working principle and realization method of the FOP,and the client software and server software based on FOP.
FOP; File Transfer; UDP; Transfer Protocol
史孝波,男,1986年生,研究生,研究方向:網絡化測控。E-mail: shixiaobo987@126.com
周松斌,男,1978年生,副研究員,研究方向:網絡化測控。
黃東運,男,1975年生,碩士,研究方向:機器視覺、圖像識別。
程韜波,男,1964年生,研究員,研究方向:復雜系統(tǒng)和智能控制。