一种改进的媒体传输协议

孙家泽，刘玮婷

(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终端间需要数据传输的场景越来越广泛，提升两端数据传输速率从而提高用户体验感成为一个值得关注的研究方向。所提传输协议着重关注传输速率提升，对于数据传输的安全性欠缺一定考虑。因此，在后续工作中，可以考虑使用加密算法对数据进行局部加密。例如，仅对数据报文的头部进行非对称加密，以提升数据传输的安全性。