孫家澤，劉瑋婷

(1.西安郵電大學 計算學院,陜西 西安 710121;2.西安郵電大學 陜西省網(wǎng)絡(luò)數(shù)據(jù)智能處理重點實驗室，陜西 西安 710121)

隨著短視頻、大型手游、直播平臺及社交網(wǎng)絡(luò)等各類移動應用軟件的快速發(fā)展，移動終端的普及度日漸提升[1]。同時，對于其他設(shè)備與移動終端間的數(shù)據(jù)傳輸需求也逐漸增加，Windows個人計算機(Personal Computer，PC)端與Android終端相互間傳遞文件的應用場景越來越多。

社會主流的PC端與Android終端通信方式主要包括3種：一是將Android終端通過通用串行總線[2](Universal Serial Bus，USB)端口與PC端相連，然后基于媒體傳輸協(xié)議[3](Media Transfer Protocol，MTP)、圖片傳輸協(xié)議(Picture Transfer Protocol，PTP)、樂器數(shù)字接口(Musical Instrument Digital Interface，MIDI)或利用Android終端上的安卓調(diào)試橋(Android Debug Bridge，ADB)接口進行通信[4-6]；二是通過藍牙進行通信；三是通過無線通信技術(shù)(Wireless Fidelity，Wi-Fi)進行通信。由于第二種及第三種通信方式對于沒有藍牙也沒有無線網(wǎng)絡(luò)驅(qū)動的臺式機無法實現(xiàn)，因此第一種成為使用最為廣泛的通信方式。

使用MTP進行PC端與Android終端間數(shù)據(jù)通信是最為廣泛的數(shù)據(jù)傳輸方式，該方式傳輸速率低是其不可忽視的問題。因此，一些研究者提出了不同的解決方案。文獻[7]提出一種文件傳輸性能優(yōu)化措施，通過減少循環(huán)的個數(shù)，提升了PC端到Android終端的傳輸性能。對比原有的MTP，傳輸626 M文件所耗費的時間由143.319 s降低至113 s，吞吐量增加約9.304 Mbit·s-1。該方法雖然對于PC端到Android終端單個文件傳輸速率提升效果明顯，但對于傳輸大量小文件的情況考慮不足，提升效果一般。文獻[8]提出一種文件傳輸速率最大化方法。該方法根據(jù)解鎖屏幕時已經(jīng)傳輸?shù)臄?shù)據(jù)量多少，計算繼續(xù)基于ADB接口進行傳輸耗時及基于MTP重新傳輸耗時，兩相比較選擇效率更高的傳輸方式。該方法依舊是基于MTP進行傳輸，若經(jīng)計算后使用MTP重傳所需時間更少，則全部數(shù)據(jù)由MTP進行傳輸。但是，MTP傳輸文件本身速率慢的問題依然沒有很好的解決。文獻[9]提出了一種優(yōu)化MTP的方法及系統(tǒng)，用于保證大文件傳輸速率。該方法根據(jù)傳輸?shù)臄?shù)據(jù)長度進行劃分。若傳輸?shù)臄?shù)據(jù)長度大于可識別閾值時，USB驅(qū)動控制器檢測最后一次發(fā)送數(shù)據(jù)中的短包，根據(jù)短包修正DMA請求數(shù)據(jù)長度。DMA根據(jù)修正之后的數(shù)據(jù)長度搬運對應的數(shù)據(jù)。該方法在傳輸大于4 G的大文件時，傳輸穩(wěn)定性及傳輸速率都有明顯提升，但對于傳輸較小數(shù)據(jù)量及大量小文件的數(shù)據(jù)傳輸速率幾乎沒有提升。

不同研究者對傳輸速率低提出了各自的解決方法，但對于大量小文件傳輸速率低的解決效果都不明顯。因此，擬提出一種應用層數(shù)據(jù)傳輸協(xié)議，即改進的媒體傳輸協(xié)議 (Improved Efficient Media Transfer Protocol，IMTP)。當用戶在PC端對Android終端文件進行操作時，先生成與操作相對應的請求報文，根據(jù)IMTP將數(shù)據(jù)進行封裝，再通過Socket發(fā)送給Android終端。Android終端接收后，根據(jù)IMTP進行解包，獲取PC端生成的請求報文。根據(jù)請求報文文本字段部分做出響應操作，并生成相應的響應報文。此外，根據(jù)IMTP將數(shù)據(jù)進行封裝，通過Socket流傳輸發(fā)送給PC端。最后，將所提的IMTP與傳統(tǒng)的PC端與Android終端之間數(shù)據(jù)傳輸所使用的MTP相比，驗證IMTP的有效性。

1 協(xié)議設(shè)計

在計算機科學領(lǐng)域，協(xié)議通常指的是網(wǎng)絡(luò)通信協(xié)議，即雙方實體完成通信或服務(wù)所必須遵守的規(guī)則和約定。在TCP/IP五層網(wǎng)絡(luò)模型中，不同層協(xié)議擔任著不同的工作[10-12]。應用層協(xié)議規(guī)定數(shù)據(jù)報文以何種形式進行封裝，以便通信雙發(fā)可以識別對方發(fā)送的數(shù)據(jù)信息。傳輸層協(xié)議規(guī)定通信雙方的連接方式，以便通信雙方以約定的方式建立連接，保證數(shù)據(jù)順序且無錯地從一端發(fā)送至另一端。網(wǎng)絡(luò)層協(xié)議將網(wǎng)絡(luò)地址翻譯成對應的物理地址，并決定將數(shù)據(jù)從發(fā)送方路由發(fā)送到接收方的發(fā)送方式。數(shù)據(jù)鏈路層協(xié)議將從網(wǎng)絡(luò)層接收到的數(shù)據(jù)分割成特定且可以被物理層傳輸?shù)膸Ｎ锢韺訁f(xié)議產(chǎn)生并檢測電壓，以便通信方發(fā)送和接收攜帶數(shù)據(jù)的信號。

目前，對于提升數(shù)據(jù)傳輸速率的解決方案主要在應用層和傳輸層進行[13]。考慮基于傳輸層對協(xié)議進行改進需要路由器的支持，不便于部署[14]，同時為保證數(shù)據(jù)傳輸?shù)目煽啃裕赥CP協(xié)議進行應用層協(xié)議的設(shè)計。因此，從協(xié)議結(jié)構(gòu)和數(shù)據(jù)交互過程兩方面，對協(xié)議進行設(shè)計。協(xié)議結(jié)構(gòu)規(guī)定協(xié)議字段組成及各字段含義，明確在發(fā)送請求及響應請求時數(shù)據(jù)報文的封裝方式，以便PC端與Android終端在通信過程中可以準確識別對方所發(fā)送的數(shù)據(jù)信息。數(shù)據(jù)交互過程規(guī)定通信雙方建立連接及發(fā)送和接收數(shù)據(jù)，所提協(xié)議僅進行一次交互，這是提升數(shù)據(jù)傳輸速率的關(guān)鍵。

1.1 協(xié)議結(jié)構(gòu)

基于應用層設(shè)計了IMTP，該協(xié)議主要用于PC端與Android終端間的數(shù)據(jù)通信。IMTP采用小端存儲模式，將數(shù)據(jù)的高字節(jié)保存在內(nèi)存的高地址中，數(shù)據(jù)的低字節(jié)保存在內(nèi)存的低地址中，其結(jié)構(gòu)如圖1所示。由圖1 可以看出，tlpb字段表示文本信令長度所占用的字節(jié)數(shù)，字段長度為4 bit，由此可知文本信令長度所占用的字節(jié)數(shù)X取值范圍為0～15個字節(jié)。tlp字段表示文本信令長度，則文本信令的長度的取值范圍為0～215×8+1-1個字節(jié)。同理，flpb字段表示多媒體文件長度所占用的字節(jié)數(shù)，字段長度為4 bit，由此可知媒體文件長度所占用字節(jié)數(shù)Y取值范圍為0～15個字節(jié)，flp字段表示媒體文件長度，則媒體文件的長度的取值范圍為0～215×8+1-1個字節(jié)。各字段的解釋及作用如表1所示。

圖1 IMTP結(jié)構(gòu)

表1 協(xié)議字段描述

文本信令根據(jù)操作分為請求消息和響應消息。請求消息指用戶在PC端對Android終端文件進行上傳、下載或獲取文件列表等操作時，生成的用于描述用戶操作的JS對象簡譜(JavaScript Object Notation,JSON)數(shù)據(jù)。響應消息指Android終端接收到來自PC端的請求消息，根據(jù)請求消息的內(nèi)容對文件進行相應操作后，生成的Android終端對于本次請求的響應結(jié)果的描述數(shù)據(jù)。

tlp字段根據(jù)tlpb字段存儲的值，向后讀取相應個字節(jié)數(shù)，即可獲得tlp。同理，flp字段根據(jù)flpb字段存儲的值，向后讀取相應的字段，即可獲得flp。考慮tlpb存儲內(nèi)容是不定的，因此tlp長度是根據(jù)tlpb存儲內(nèi)容進行變化的。td字段用于存儲文本信令內(nèi)容，其字段長度計算方法同tlp。fd字段用于存儲媒體文件內(nèi)容，其字段長度計算方法同flp。請求消息及響應消息的具體內(nèi)容如下。

1)請求消息。PC端發(fā)送一個IMTP請求到Android終端，該請求報文由請求頭部和請求數(shù)據(jù)兩個部分組成。請求頭部包含預留字段、協(xié)議版本號、文本信令長度占用字節(jié)數(shù)、多媒體長度占用字節(jié)數(shù)、文本信令長度及多媒體文件長度；請求數(shù)據(jù)段包含文本信令內(nèi)容及媒體文件信息內(nèi)容。請求消息即為請求數(shù)據(jù)段中文本信令的內(nèi)容。

當用戶在PC端進行操作時，生成請求消息。請求消息用于PC端發(fā)送請求至Android終端后，Android終端判斷本次PC端想要進行的操作。請求消息的數(shù)據(jù)段包括以下幾個部分：id 字段，標識，具有唯一性；cmd 字段，標識請求的目的，描述請求端需要響應端所做的操作；reply 字段，標識這是一條請求，值為 0；data 字段，傳遞此條請求的數(shù)據(jù)，附帶對操作有幫助的其他數(shù)據(jù)。例如，當PC端發(fā)出“獲取sdcard/ Android/1/test目錄下的1 000個子文件信息”請求時，生成請求消息{“id”: “xxxxxx”,“cmd”:“get_file_list”,“reply”:“0”,data{“parent_path”: “sdcard/Android/1/test/”}}。

2) 響應消息。Android終端對PC端的請求產(chǎn)生響應時，生成響應報文。IMTP響應報文由響應頭部和響應數(shù)據(jù)兩個部分組成。響應頭部包含預留字段、協(xié)議版本號、文本信令長度占用字節(jié)數(shù)、多媒體長度占用字節(jié)數(shù)、文本信令長度、多媒體文件長度。響應數(shù)據(jù)段包含文本信令內(nèi)容及媒體文件信息內(nèi)容。響應消息是響應數(shù)據(jù)段中文本信令內(nèi)容，用于描述PC端發(fā)送的請求的響應結(jié)果。響應消息包括以下幾個部分：id字段，與請求的id相對應，表示這是此請求的響應，具有唯一性；cmd字段，描述響應終端需完成的操作；reply字段，標識這是一條響應，值為 1；code字段，即響應碼，標識Android端進行操作的結(jié)果，不同響應碼對應不同的操作結(jié)果，具體響應碼及其含義解釋如表2所示；message字段，描述響應端操作的結(jié)果；data字段，響應消息的數(shù)據(jù)，用來附帶操作時的一些信息。

表2 響應碼及其含義解釋

例如，針對PC端發(fā)出“獲取sdcard/ Android/1/test目錄下的1 000個子文件”的請求，Android終端若順利獲取，則生成響應消息內(nèi)容為{“id”:“xxxxxx”,“cmd”: “get_file_list”,“reply”:“1”,“code”:“0”,“message”:“獲取成功”，data{“parent_path”: “sdcard/Android/1/test/”,“files”:[{data1},{data2},...]}}。若獲取失敗，則生成的響應消息內(nèi)容為{“id”:“xxxxxx”,“cmd”: “get_file_list”,“reply”:“1”,“code”:“-1”,“message”:“操作失敗”,data{}}。

1.2 數(shù)據(jù)交互過程

1.2.1 建立連接

考慮在交互過程考慮到同一PC端可同時管理多部Android終端設(shè)備，在建立連接時將Android終端作為客戶端，將PC端作為服務(wù)端。PC端在本地啟動一個ServerSocket，隨之綁定一個本地的端口，假設(shè)綁定的本地端口為8899。然后通過ADB調(diào)試橋?qū)C端端口映射到Android終端，例如adb reverse tcp:8899 tcp:8888表示將PC端綁定的8899端口映射到Android終端口8888端口。接下來PC端通過am smart指令啟動Android終端APP應用，并攜帶映射的端口號。緊接著Android終端啟動APP，再啟動一個AndroidService，并在Service里面啟動一個server。Android終端通過socket告知PC端此server綁定的端口號，假設(shè)server綁定的端口號為6100。最后，使用adb forward將Android終端端口映射到PC端，例如，adb forward tcp:6100 tcp:7100表示將Android終端6100端口映射到PC端7100端口，至此連接完成。IMTP建立連接過程如圖2所示。

圖2 IMTP建立連接過程

在建立連接時，將Android終端作為客戶端，由Android終端主動發(fā)起連接請求，PC端接收到Android終端發(fā)送的連接請求后進行連接。Android終端與PC端連接成功后，便可開始進行數(shù)據(jù)傳輸操作。在PC端與Android終端建立連接后，由PC端對Android終端文件進行管理，請求由PC端主動發(fā)起。因此，一旦PC端與Android終端的連接建立，可以將PC端視為客戶端，將Android終端視為服務(wù)端進行通信。

1.2.2 數(shù)據(jù)傳輸

IMTP與MTP有一定的相似性。MTP的一個完整的會話分為請求階段、數(shù)據(jù)傳輸階段及響應階段等3個階段[3,15]。其中，數(shù)據(jù)傳輸階段是可選的、單向的。因此，客戶端與服務(wù)端之間的數(shù)據(jù)傳輸可以分為圖3所示的3種情況。由圖3可以看出，圖3(a)表示沒有數(shù)據(jù)傳輸時，客戶端發(fā)送請求到服務(wù)器端，服務(wù)器端接收到后，返回響應給客戶端。圖3(b)表示有數(shù)據(jù)從客戶端傳輸?shù)椒?wù)器端時，客戶端先發(fā)送請求到服務(wù)器端，服務(wù)器端接收到后，客戶端再發(fā)送數(shù)據(jù)到服務(wù)器端，服務(wù)器端接收到后，返回響應給客戶端。這個過程中客戶端發(fā)送了兩次請求給服務(wù)器端。同理，圖3(c)表示有數(shù)據(jù)從服務(wù)器端發(fā)送到客戶端時，服務(wù)器端發(fā)送兩次響應給客戶端。

圖3 MTP數(shù)據(jù)傳輸過程

IMTP數(shù)據(jù)可分為請求消息、文件數(shù)據(jù)及響應消息等3個部分。其中，文件數(shù)據(jù)是可選的、單向的。可選的是規(guī)定PC端發(fā)送請求消息后，Android終端直接返回響應消息，請求時攜帶文件內(nèi)容數(shù)據(jù)不是必須的。例如，PC端請求獲取某個文件屬性信息時，無需進行文件數(shù)據(jù)的傳輸。而PC端請求上傳某個文件時，需要進行文件的傳輸，此時，在發(fā)送請求時攜帶文件內(nèi)容數(shù)據(jù)。單向的是指文件數(shù)據(jù)流向為PC端到Android終端(P→A，文件上傳)或Android終端到PC端(A→P，文件下載)。IMTP數(shù)據(jù)傳輸過程如圖4所示。

圖4 IMTP數(shù)據(jù)傳輸過程

由圖4可以看出，圖4(a)表示沒有文件數(shù)據(jù)傳輸時，PC端發(fā)送請求到Android終端，Android終端接收到后，返回響應給PC端。圖4(b)表示有文件從PC端傳輸?shù)紸ndroid終端時，PC端將請求和文件數(shù)據(jù)一同發(fā)送到Android終端，Android終端接收到后，返回響應給PC端。這個過程中，PC端發(fā)送了一次攜帶文件的請求給Android終端，Android返回一次響應給PC端。同理，圖4(c)表示有文件從Android終端傳輸?shù)絇C端時，PC端發(fā)送一次請求給Android終端，Android返回一次攜帶文件的響應給PC端。

圖5描述了IMTP數(shù)據(jù)交互過程。IMTP報文首部和IMTP數(shù)據(jù)段構(gòu)成了IMTP數(shù)據(jù)包。發(fā)送端首先在應用層，根據(jù)IMTP將數(shù)據(jù)封裝成IMTP數(shù)據(jù)包。然后到達傳輸層，在傳輸層使用TCP協(xié)議對應用層封裝好的數(shù)據(jù)包進行封裝，得到TCP數(shù)據(jù)包。接下來到達網(wǎng)絡(luò)層，在網(wǎng)絡(luò)層使用IP協(xié)議對傳輸層封裝好的TCP數(shù)據(jù)包進行進一步封裝，得到IP數(shù)據(jù)包。最后，到達鏈路層，在鏈路層使用Ethernet協(xié)議封裝后，將數(shù)據(jù)發(fā)送至接收端。接收端接收到數(shù)據(jù)后，首先經(jīng)過鏈路層解碼得到IP數(shù)據(jù)。然后繼續(xù)向上傳遞經(jīng)過網(wǎng)絡(luò)層解碼得到TCP數(shù)據(jù)包。接下來繼續(xù)向上傳遞經(jīng)過傳輸層解碼得到IMTP數(shù)據(jù)包。最后，經(jīng)過應用層解碼得到具體數(shù)據(jù)。

圖5 IMTP交互過程

2 實驗結(jié)果及分析

實驗使用PC端設(shè)備為Lenovo xiaoxinPro 14，運行內(nèi)存為16 GB，處理器型號為AMD Ryzen 7 5800H Radeon Graphics，操作系統(tǒng)版本為Windows 11 家庭中文版 64位。Android終端硬件設(shè)備為Xiaomi Redmi K40，運行內(nèi)存為12 GB，處理器型號為高通驍龍870，操作系統(tǒng)版本為MIUI 12.5.19穩(wěn)定版。

2.1 實驗設(shè)計

為驗證所提協(xié)議的有效性，基于Qt開發(fā)，在PC端實現(xiàn)一個簡單的數(shù)據(jù)傳輸系統(tǒng)，用于測試使用IMTP上傳單個文件、下載單個文件、上傳批量文件、下載批量文件及獲取批量文件屬性的性能?；贏ndroid開發(fā)實現(xiàn)一個簡單的APP，用于連接Android終端和PC端。PC端與Android終端進行通信的數(shù)據(jù)傳輸系統(tǒng)功能模塊如圖6所示。

圖6 PC端與Android終端數(shù)據(jù)傳輸系統(tǒng)功能模塊

文件傳輸模塊包括上傳單個文件、下載單個文件、上傳批量文件及下載批量文件模塊。文件管理模塊包括文件加載模塊。其中，文件傳輸模塊下的功能模塊生成請求報文時，要包含文件內(nèi)的具體數(shù)據(jù)，數(shù)據(jù)量較大；而文件管理模塊下的功能模塊生成請求報文無需攜帶文件內(nèi)的具體數(shù)據(jù)，數(shù)據(jù)量較小。PC端數(shù)據(jù)處理模塊負責對PC端生成的請求報文進行壓縮處理并按照協(xié)議對數(shù)據(jù)進行打包，也負責對接收到來自Android終端的數(shù)據(jù)包進行解包并對響應報文進行解壓縮處理。同理，Android終端數(shù)據(jù)處理模塊也進行類似工作，通信模塊負責PC端與Android終端之間的數(shù)據(jù)通信。

針對IMTP數(shù)據(jù)傳輸?shù)?種情況，回答以下幾個問題。

問題1在傳輸文件屬性信息時，數(shù)據(jù)傳輸速率。

問題2在傳輸單個文件屬性數(shù)據(jù)及文件內(nèi)容數(shù)據(jù)時，文件傳輸速率及穩(wěn)定性。

問題3在傳輸批量文件屬性數(shù)據(jù)及文件內(nèi)容數(shù)據(jù)時，文件傳輸速率及穩(wěn)定性。

針對這3個問題設(shè)計3個實驗。實驗一根據(jù)傳輸平均時間、實驗二和實驗三根據(jù)傳輸平均時間及平均速率對速率提升效果進行評價。

2.2 實驗結(jié)果分析

實驗一分別使用MTP和IMTP加載1 000個、2 000個、3 000個、6 000個及9 000個文件，對比使用MTP和IMTP在加載文件屬性信息所需要的時間。屬性信息傳輸所需平均時間越少，則數(shù)據(jù)傳輸速率越高，實驗結(jié)果如表3所示。使用MTP加載1 000個、2 000個、3 000個、6 000個及9 000個文件耗時分別為4.28 s、8.05 s、11.26 s、22.31 s及33.33 s，同情況下使用IMTP耗時分別為1.04 s、2.24 s、3.44 s、7.04 s及11.23 s。由此可知，使用IMTP比使用MTP獲取文件屬性信息耗時減少70.48%。因此，IMTP獲取批量文件屬性信息較MTP數(shù)據(jù)傳輸速率有所提升，且提升效果較為理想。

表3 獲取批量文件屬性信息時間對比

實驗二將上傳和下載1個100 M、1 G及4 G大小的文件，使用MTP和IMTP分別進行20次傳輸實驗。計算文件傳輸平均時間及文件傳輸平均速率。傳輸同樣大小的文件時，平均時間越少，則平均速率越大，即數(shù)據(jù)傳輸速率越高。實驗結(jié)果如表4所示。

表4 傳輸單個文件時間及速率對比

使用IMTP上傳100 M、500 M及1 G大小的文件平均時間分別為3.49 s、16.63 s及34.31 s文件傳輸平均速率分別為229.20 Mbit·s-1、240.32 Mbit·s-1及246.40 Mbit·s-1，較同情況下使用MTP進行文件傳輸平均時間分別減少1.59 s、2.11 s及2.32 s，平均傳輸速率分別增加71.68 Mbit·s-1、26.96 Mbit·s-1及22.70 Mbit·s-1。使用IMTP下載100 M、500 M及1 G文件平均時間分別為2.90 s、12.05 s及26.38 s，文件傳輸平均速率分別為275.84 Mbit·s-1、306.48 Mbit·s-1及310.48 Mbit·s-1，較同情況下使用MTP進行文件傳輸平均時間分別減少0.99 s、2.77 s及3.88 s，平均傳輸速率分別增加70.14 Mbit·s-1、53.60 Mbit·s-1及39.76Mbit·s-1。由此可知，上傳單個文件時，使用IMTP比MTP平均時間減少16.30%，文件傳輸平均速率提升22.77%；下載單個文件時，使用IMTP比MTP平均時間減少18.59%，文件傳輸平均速率提升23.33%。使用IMTP傳輸不同大小單個文件速率對比情況，具體如圖7所示。

圖7 使用IMTP傳輸單個文件速率對比

由圖7可以看出，使用IMTP上傳1個100 M文件時，文件傳輸速率分布在228 Mbit·s-1上下。當上傳1個500 M的文件時，文件傳輸速率分布在240 Mbit·s-1上下。上傳1 G文件時，文件傳輸速率也集中在240 Mbit·s-1上下。上傳文件時的文件傳輸速率隨著上傳文件大小的變化有一定波動，但總體變化不大。在傳輸同樣大小的文件時，20次測試結(jié)果相對穩(wěn)定，每次的文件傳輸平均速率相差普遍量級為10-1。同理，下載文件的文件傳輸速率隨著下載文件大小的變化有小幅波動，但總體變化不大。在傳輸同樣大小的文件時，20次測試結(jié)果相對穩(wěn)定，每兩次的文件傳輸平均速率相差普遍量級為10-1。因此，使用IMTP傳輸單個文件時傳輸效果穩(wěn)定。

實驗三對上傳及下載250個、1 000個及2 000個1 M的文件使用MTP和IMTP分別進行20次傳輸實驗，計算20次文件傳輸平均時間及文件傳輸平均速率。傳輸?shù)攘康却笮∥募r，平均時間越少，則平均速率越大，即數(shù)據(jù)傳輸速率越高。MTP與IMTP傳輸不同批量同樣大小文件傳輸時間及速率對比結(jié)果如表5所示。

表5 傳輸同樣大小批量文件時間及速率對比

使用IMTP上傳250個、1 000個及2 000個1 M文件平均耗時分別為15.32 s、88.34 s及354.82 s，文件傳輸平均速率分別為130.48 Mbit·s-1、90.56 Mbit·s-1及45.12 Mbit·s-1，較同情況下使用MTP傳輸文件，平均時間分別減少12.95 s、123.76 s及365.94 s，文件傳輸平均速率分別增加59.76 Mbit·s-1、52.88 Mbit·s-1及22.96 Mbit·s-1。使用IMTP下載250個、1 000個及2 000個1 M文件平均耗時分別為7.07 s、26.19 s及49.93 s，文件傳輸平均速率分別為282.88 Mbit·s-1、305.44 Mbit·s-1及320.48 Mbit·s-1，較同情況下使用MTP傳輸文件，平均耗時分別減少3.81 s、17.03 s及43.09 s，平均傳輸速率分別增加99.04 Mbit·s-1、120.40 Mbit·s-1及148.48Mbit·s-1。由此可知，在上傳批量文件時，使用IMTP比MTP耗時減少51.64%，平均速率增加108.401%。在下載批量文件時，使用IMTP比MTP耗時減少41.46%，平均速率增加68.42%。具體的傳輸250個1 M文件速率對比情況如圖8所示。

圖8 傳輸250個1 M文件速率對比

由圖8(a)可以看出，使用MTP上傳250個文件的文件傳輸速率分布在70 Mbit·s-1上下。使用IMTP下載250個1 M文件的文件傳輸分布在130.4 Mbit·s-1上下。使用IMTP上傳250個1 M文件的文件傳輸速率明顯高于使用MTP時的速率，途中數(shù)據(jù)分布較集中，IMTP協(xié)議下20次測試結(jié)果相對穩(wěn)定，每兩次文件傳輸平均速率相差量級為10-1。同理，由圖8(b)可以看出，使用IMTP下載250個1 M文件的文件傳輸速率也明顯高于使用MTP時的速率，且傳輸效果較穩(wěn)定。

3 結(jié)語

為了提升PC端與Android終端的數(shù)據(jù)傳輸速率的問題，提出了一種應用層數(shù)據(jù)傳輸協(xié)議IMTP。該協(xié)議包含字段文本信令長度所占字節(jié)數(shù)、媒體文件長度所占字節(jié)數(shù)、文本信令長度、媒體文件長度、文本信令及媒體文件，其中媒體文件是可選項，當沒有文件傳輸時，媒體文件長度所占字節(jié)數(shù)為0。當PC端發(fā)送請求時，判斷是否包含文件上傳操作，若包含，則根據(jù)IMTP結(jié)構(gòu)對文本信令及文件數(shù)據(jù)進行打包，反之僅打包文本信令。打包完成后發(fā)送至Android終端。然后Android終端根據(jù)IMTP結(jié)構(gòu)對打包的數(shù)據(jù)進行解析，完成相應操作后，產(chǎn)生響應，判斷響應內(nèi)容是否包含文件數(shù)據(jù)，若包含，則根據(jù)IMTP結(jié)構(gòu)對文本信令及文件數(shù)據(jù)進行打包，反之僅打包文本信令。打包完成后，發(fā)送至PC端，PC端根據(jù)IMTP結(jié)構(gòu)對數(shù)據(jù)進行解析。該協(xié)議在傳輸文件和傳輸文件信息的速率提升方面都有顯著效果。在針對批量小文件傳輸速率提升問題上，其效果尤為明顯，同時在針對單個文件傳輸時速率提升。

隨著PC端與Android終端間需要數(shù)據(jù)傳輸?shù)膱鼍霸絹碓綇V泛，提升兩端數(shù)據(jù)傳輸速率從而提高用戶體驗感成為一個值得關(guān)注的研究方向。所提傳輸協(xié)議著重關(guān)注傳輸速率提升，對于數(shù)據(jù)傳輸?shù)陌踩郧啡币欢紤]。因此，在后續(xù)工作中，可以考慮使用加密算法對數(shù)據(jù)進行局部加密。例如，僅對數(shù)據(jù)報文的頭部進行非對稱加密，以提升數(shù)據(jù)傳輸?shù)陌踩浴?/p>