一種改進的媒體傳輸協議

孫家澤，劉瑋婷

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

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

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

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

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

1 協議設計

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

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

1.1 協議結構

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

圖1 IMTP結構

表1 協議字段描述

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

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

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

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

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

表2 響應碼及其含義解釋

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

1.2 數據交互過程

1.2.1 建立連接

考慮在交互過程考慮到同一PC端可同時管理多部Android終端設備，在建立連接時將Android終端作為客戶端，將PC端作為服務端。PC端在本地啟動一個ServerSocket，隨之綁定一個本地的端口，假設綁定的本地端口為8899。然后通過ADB調試橋將PC端端口映射到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綁定的端口號，假設server綁定的端口號為6100。最后，使用adb forward將Android終端端口映射到PC端，例如，adb forward tcp:6100 tcp:7100表示將Android終端6100端口映射到PC端7100端口，至此連接完成。IMTP建立連接過程如圖2所示。

圖2 IMTP建立連接過程

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

1.2.2 數據傳輸

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

圖3 MTP數據傳輸過程

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

圖4 IMTP數據傳輸過程

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

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

圖5 IMTP交互過程

2 實驗結果及分析

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

2.1 實驗設計

為驗證所提協議的有效性，基于Qt開發，在PC端實現一個簡單的數據傳輸系統，用于測試使用IMTP上傳單個文件、下載單個文件、上傳批量文件、下載批量文件及獲取批量文件屬性的性能。基于Android開發實現一個簡單的APP，用于連接Android終端和PC端。PC端與Android終端進行通信的數據傳輸系統功能模塊如圖6所示。

圖6 PC端與Android終端數據傳輸系統功能模塊

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

針對IMTP數據傳輸的3種情況，回答以下幾個問題。

問題1在傳輸文件屬性信息時，數據傳輸速率。

問題2在傳輸單個文件屬性數據及文件內容數據時，文件傳輸速率及穩定性。

問題3在傳輸批量文件屬性數據及文件內容數據時，文件傳輸速率及穩定性。

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

2.2 實驗結果分析

實驗一分別使用MTP和IMTP加載1 000個、2 000個、3 000個、6 000個及9 000個文件，對比使用MTP和IMTP在加載文件屬性信息所需要的時間。屬性信息傳輸所需平均時間越少，則數據傳輸速率越高，實驗結果如表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數據傳輸速率有所提升，且提升效果較為理想。

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

實驗二將上傳和下載1個100 M、1 G及4 G大小的文件，使用MTP和IMTP分別進行20次傳輸實驗。計算文件傳輸平均時間及文件傳輸平均速率。傳輸同樣大小的文件時，平均時間越少，則平均速率越大，即數據傳輸速率越高。實驗結果如表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次測試結果相對穩定，每次的文件傳輸平均速率相差普遍量級為10-1。同理，下載文件的文件傳輸速率隨著下載文件大小的變化有小幅波動，但總體變化不大。在傳輸同樣大小的文件時，20次測試結果相對穩定，每兩次的文件傳輸平均速率相差普遍量級為10-1。因此，使用IMTP傳輸單個文件時傳輸效果穩定。

實驗三對上傳及下載250個、1 000個及2 000個1 M的文件使用MTP和IMTP分別進行20次傳輸實驗，計算20次文件傳輸平均時間及文件傳輸平均速率。傳輸等量等大小文件時，平均時間越少，則平均速率越大，即數據傳輸速率越高。MTP與IMTP傳輸不同批量同樣大小文件傳輸時間及速率對比結果如表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時的速率，途中數據分布較集中，IMTP協議下20次測試結果相對穩定，每兩次文件傳輸平均速率相差量級為10-1。同理，由圖8(b)可以看出，使用IMTP下載250個1 M文件的文件傳輸速率也明顯高于使用MTP時的速率，且傳輸效果較穩定。

3 結語

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

隨著PC端與Android終端間需要數據傳輸的場景越來越廣泛，提升兩端數據傳輸速率從而提高用戶體驗感成為一個值得關注的研究方向。所提傳輸協議著重關注傳輸速率提升，對于數據傳輸的安全性欠缺一定考慮。因此，在后續工作中，可以考慮使用加密算法對數據進行局部加密。例如，僅對數據報文的頭部進行非對稱加密，以提升數據傳輸的安全性。