一种低延迟的文本信息传输方法与流程

本发明涉及一种低延迟的文本信息传输方法。

背景技术：

电信领域推出了基于IP包交换的融合通信业务规范RCS，基于RCS标准，不但能够实现类似于互联网的IM通信应用(如微信、WhatsApp、Line等)的丰富的消息功能，而且能做到在手机原生系统中，像发短信、打电话那样进行操作。而且，作为全球性的规范，RCS应用能够实现各家运营商之间互联互通。事实上，类似的基于SIP/XML协议的应用还有许多国际标准，如XMPP也可实现类似的功能。

RCS、XMPP等协议规范主要应用于丰富媒体(文字、语音、图片、视频、文件)的即时消息的传输，协议是基于文本的，具有灵活、易懂、易扩展的特点。

RCS、XMPP或类似基于文本的协议的缺点是，相比高度优化的私有协议的应用(如微信、WhatsApp、Line等)，其消息的延迟比较大。主要原因是，文本协议本身有较多冗余，加上报文头，其协议报文的体积很大；加上网络有丢包的情况时，网络重传会导致进一步的延迟。尽管SigComp(信令压缩协议)能够解决报文体积大的问题，但由于其实现复杂(需要支持动态加载虚拟机和压缩字典)，首次载入压缩效率低等问题，实际应用较少。

技术实现要素：

本发明所要解决的技术问题是针对上述现有技术提供一种低延迟的文本信息传输方法。

本发明解决上述技术问题所采用的技术方案为：一种低延迟的文本信息传输方法，其特征在于：在互通文本信息的第一终端和第二终端之间建立如下握手机制：

拥有压缩和解压缩能力的第一终端能处理没有压缩和解压缩能力的第二终端发来的文本信息；此时，第一终端和第二终端在进行文本信息互通时，将要传递的文本信息，按照没有压缩过的标准格式报文进行互通；

拥有压缩和解压缩能力的第一终端能处理拥有压缩和解压缩能力的第二终端发来的文本信息，其中第一终端和第二终端均拥有数据压缩字典，且第一终端拥有的数据压缩字典的版本号高于或等于第二终端均拥有数据压缩字典的版本号，版本号高的数据压缩字典的内容包含有版本号低的数据压缩字典内容；此时第一终端和第二终端在进行文本信息互通时，将要传递的文本信息，按照彼此之间版本号较低的数据压缩字典进行压缩后传输，收到文本信息的终端按照版本号较低的数据压缩字典进行解压缩得到要传递的文本信息。

作为改进，将互通文本信息的第一终端和第二终端之间使用频率大于设定阈值的字符或/和字符串，建立成一个基础版本的数据压缩字典，并将该基础版本的数据压缩字典均保存在第一终端和第二终端内。

再改进，在互通文本信息的第一终端和第二终端之间建立三种不同的信息互通类型：

第一类型：没有服务器参与，且第一终端具有压缩和解压缩能力，第二终端不具有压缩和解压缩能力：第一终端发送的第一个文本信息为没有压缩过的标准格式报文，该标准格式报文内携带有第一终端具备压缩和解压缩能力及其数据压缩字典的版本号，第二终端忽略第一个文本信息中的压缩能力字段后按照正常方式进行后续处理；

第二类型：没有服务器参与，且第一终端和第二终端均具有压缩和解压缩能力：第一终端发送的第一个文本信息为没有压缩过的标准格式报文，该标准格式报文内携带有第一终端具备压缩和解压缩能力及其数据压缩字典的版本号；第二终端收到第一终端发来的第一个文本信息后，提取第一终端的数据压缩字典的版本号，然后与自身携带的数据压缩字典的版本号进行对比，然后将回复的文本信息按第一终端和第二终端中版本低的数据压缩字典进行压缩，且对压缩后的文本信息增加报文头，报文头中说明了压缩算法和字典的版本号；第一终端收到回复的文本信息后根据报文头的说明，通过对应的解压模块使用低版本的数据压缩字典完成解压，同时在第一终端的通讯录中缓存更新第二终端的设备信息，该设备信息包括设备ID、用户ID及其数据压缩字典的版本号；此后，第一终端和第二终端所有的文本信息互通都使用确定的数据压缩字典版本进行压缩和解压；

第三类型：有服务器参与，且第一终端和第二终端均具有压缩和解压缩能力：第一终端和第二终端首次连接服务器时，将其设备信息以及数据压缩字典的版本号发送给服务器，服务器保存记录；当第一终端需要与第二终端进行信息互通时，第一终端向服务器查询第二终端的设备信息以及数据压缩字典的版本号，服务器向第一终端返回第二终端设备信息以及数据压缩字典的版本号，第一终端将获取的第二终端设备信息以及数据压缩字典的版本号保存到本地；第一终端与第二终端进行信息互通时，用自身和对端都支持的最大数据压缩字典的版本进行压缩或解压缩处理。

再改进，在所述第二类型中，如果第一终端和第二终端任何一方的数据压缩字典升级，在发送的文本信息中增加更新后的数据压缩字典的版本号的报文头，第一终端或第二终端收到对方新的数据压缩字典的版本号时，然后跟自己所支持的数据压缩字典版本号比较，取两者较低的版本进行压缩或解压缩。

再改进，第一终端和第二终端在进行信息互通时，如果需要压缩文本信息，则采用GZIP压缩算法对文本信息进行压缩。

再改进，所述第二类型中，如果第二终端重新安装了数据压缩字典，且更新后的数据压缩字典的版本比之前已经确定的第一终端和第二终端互通时使用的数据压缩字典的版本要低；此时，第一终端发送文本信息给第二终端时，使用了之前已经确定的第一终端和第二终端互通时使用的数据压缩字典的进行压缩，由于第二终端无法进行解压处理，此时，第二终端立即向第一终端发送一个错误响应，或者直接忽略此文本信息；当第一终端收到错误响应时，或等待第二终端的响应超过预设时间阈值，预设时间阈值为1000ms～2000ms，第一终端重新发送没有压缩过的标准格式报文，然后第一终端和第二终端按照第二类型中描述的方式，重新确定第一终端和第二终端之间文本信息互通所使用的数据压缩字典版本号。

再改进，在所述第三类型中，当有新版本的数据压缩字典时，只需要在服务器端更新新版本的数据压缩字典，然后当第一终端和第二终端登录服务器时，或在第一终端和第二终端空闲时，将新版本的数据压缩字典发送给第一终端和第二终端。

再改进，在第一终端和第二终端进行信息互通时，通过前向纠错机制来发送文本信息，即通过增加冗余包的方式来增加信息互通成功率。

与现有技术相比，本发明的优点在于：采用本发明提供的文本信息传输方法，能实现平均比优化前提高一倍的传输速度，即减少一半延迟；在进一步方案中，压缩技术能使流量减少至原先的15％～20％。

附图说明

图1为本发明实施例中具有不同版本数据压缩字典的第一终端和第二终端之间文本信息互通框图；

图2为本发明实施例中在无服务器参与情况下具有压缩解压缩能力的第一终端跟不带压缩能力的第二终端之间的文本信息互通框图；

图3为本发明实施例中在无服务器参与情况下具有压缩解压缩能力的第一终端跟同样带压缩能力的第二终端之间的文本信息互通框图；

图4为本发明实施例中在有服务器参与情况下具有压缩解压缩能力的第一终端跟同样带压缩能力的第二终端之间的文本信息互通框图。

具体实施方式

以下结合附图实施例对本发明作进一步详细描述。

本发明提供的低延迟的文本信息传输方法，其核心宗旨在于：在互通文本信息的第一终端和第二终端之间建立如下握手机制：

拥有压缩和解压缩能力的第一终端能处理没有压缩和解压缩能力的第二终端发来的文本信息；此时，第一终端和第二终端在进行文本信息互通时，将要传递的文本信息，按照没有压缩过的标准格式报文进行互通；

拥有压缩和解压缩能力的第一终端能处理拥有压缩和解压缩能力的第二终端发来的文本信息，其中第一终端和第二终端均拥有数据压缩字典，且第一终端拥有的数据压缩字典的版本号高于或等于第二终端均拥有数据压缩字典的版本号，版本号高的数据压缩字典的内容包含有版本号低的数据压缩字典内容；此时第一终端和第二终端在进行文本信息互通时，将要传递的文本信息，按照彼此之间版本号较低的数据压缩字典进行压缩后传输，收到文本信息的终端按照版本号较低的数据压缩字典进行解压缩得到要传递的文本信息。

以GZIP(RFC 1952，GZIP file format specification version 4.3)或类似的压缩算法为例，GZIP是基于LZ77和Huffman编码，比较适合对文本数据进行压缩处理，因此通常也会应用于压缩HTTP报文(RFC 2616)，因此，本发明可以将它应用于压缩SIP/SDP/XML等类似的文本协议，当然也可以采用其他压缩算法；下文以SIP呼叫信令INVITE为例展开描述，然而实际也适用于任何其它以文本协议为基础的实时通信应用，如发送IM消息或通知等等。

GZIP的压缩率取决于被压缩报文的大小，也取决于压缩参考字典的相关性和大小，因此对于压缩字典的动态维护是比较重要的。

图1描述了基于GZIP压缩系统的数据压缩字典可不断增量而扩展版本的概念，并且其为向下兼容的；意思即为，拥有高版本的数据压缩字典的压缩编解码系统可以处理相同或较低版本的数据压缩字典的压缩数据。如图1，第一终端使用的数据压缩字典版本号为Dict v1.1，其可以跟第二终端使用的数据压缩字典版本号为Dict v1.1互通，即实现压缩、解压的过程；第二终端还拥有更高版本的数据压缩字典Dict v1.2，事实上第一终端和第二终端还可以跟任何支持数据压缩字典版本号为Dict v1.0或Dict v1.1的终端互通。

由于实际应用中，我们往往事先知道有哪些字符或字符串是经常使用的，比如SIP、SDP、INVITE、200OK等等，我们可以预设一个Dict v1.0作为基础版本的数据压缩字典，并将该基础版本的数据压缩字典均保存在第一终端和第二终端内经过实际测试，针对性的规定一个大概20Kbytes大小的数据字典，基于GZIP压缩后，RCS/SIP/XMPP报文体积平均可减小到原来的15％～20％。

本发明还充分考虑了各个版本的互通性和平滑升级问题，在互通文本信息的第一终端和第二终端之间建立三种不同的信息互通类型：

第一类型：没有服务器参与，且第一终端具有压缩和解压缩能力，第二终端不具有压缩和解压缩能力，如图2：第一终端发送的第一个文本信息为没有压缩过的标准格式报文，该标准格式报文内携带有第一终端具备压缩和解压缩能力及其数据压缩字典的版本号，第二终端忽略第一个文本信息中的压缩能力字段后按照正常方式进行后续处理；

第二类型：没有服务器参与，且第一终端和第二终端均具有压缩和解压缩能力，如图3：第一终端发送的第一个文本信息为没有压缩过的标准格式报文，该标准格式报文内携带有第一终端具备压缩和解压缩能力及其数据压缩字典的版本号；第二终端收到第一终端发来的第一个文本信息后，提取第一终端的数据压缩字典的版本号，然后与自身携带的数据压缩字典的版本号进行对比，然后将回复的文本信息按第一终端和第二终端中版本低的数据压缩字典进行压缩，且对压缩后的文本信息增加报文头，报文头中说明了压缩算法和字典的版本号；第一终端收到回复的文本信息后根据报文头的说明，通过对应的解压模块使用低版本的数据压缩字典完成解压，同时在第一终端的通讯录中缓存更新第二终端的设备信息，该设备信息包括设备ID、用户ID及其数据压缩字典的版本号；此后，第一终端和第二终端所有的文本信息互通都使用确定的数据压缩字典版本进行压缩和解压；

第二类型还可以考虑通信对端中版本数据压缩字典回退到更早期的版本的异常情况，如果第二终端重新安装了数据压缩字典，且更新后的数据压缩字典的版本比之前已经确定的第一终端和第二终端互通时使用的数据压缩字典的版本要低；此时，第一终端发送文本信息给第二终端时，使用了之前已经确定的第一终端和第二终端互通时使用的数据压缩字典的进行压缩，由于第二终端无法进行解压处理，此时，第二终端立即向第一终端发送一个错误响应，或者直接忽略此文本信息；当第一终端收到错误响应时，或等待第二终端的响应超过预设时间阈值，预设时间阈值为1000ms～2000ms，第一终端重新发送没有压缩过的标准格式报文，然后第一终端和第二终端按照第二类型中描述的方式，重新确定第一终端和第二终端之间文本信息互通所使用的数据压缩字典版本号。如果由于网络延迟或丢包等原因，第二终端的响应没有在超时之前发送给第一终端造成的误判，由于第一终端和第二终端还是可以处理无压缩的文本信息，因此逻辑上也能正常工作；之后，再次建立压缩能力和字典版本号的确认握手后，仍可按图3的类似流程实现互通，并享受压缩的好处。

因此，我们在原有通信终端上加入一层“信令压缩模块”，对于压缩后的数据加上4个字节的头部描述Comp Header：一个字节为压缩算法类型、一个字节为字典版本号、另一个字节为交验字节、剩余一字节为保留8位，压缩数据本身格式由GZIP或类似算法定义，本文不再描述，信令压缩模块接收文本信息后，子模块Selector根据检查头部Comp Header来判断是否需要解压，以及解压数据压缩字典的版本号，来选择直接透传给上层，还是通过某版本数据压缩字典进行解压处理后再将原始未压缩数据传给上层，反方向的，信令压缩模块接收上层原始文本信息，和对端版本类型指示“未知”、或“压缩算法，字典版本号”来处理：如果是未知，则在原始的SIP文本信息中插入如“GZIP Comp,Dict v1.1”，根据本端的压缩算法，字典版本号，发送未压缩报文；如果是已知对端“压缩算法，字典版本号”，则跟本端“压缩算法，字典版本号”进行匹配，取两者较低版本的字典进行压缩后发送压缩报文；

第三类型：有服务器参与，且第一终端和第二终端均具有压缩和解压缩能力，如图4所示：第一终端和第二终端首次连接服务器时，将其设备信息以及数据压缩字典的版本号发送给服务器，服务器保存记录；当第一终端需要与第二终端进行信息互通时，第一终端向服务器查询第二终端的设备信息以及数据压缩字典的版本号，服务器向第一终端返回第二终端设备信息以及数据压缩字典的版本号，第一终端将获取的第二终端设备信息以及数据压缩字典的版本号保存到本地；第一终端与第二终端进行信息互通时，用自身和对端都支持的最大数据压缩字典的版本进行压缩或解压缩处理；

在所述第三类型中，当有新版本的数据压缩字典时，只需要在服务器端更新新版本的数据压缩字典，然后当第一终端和第二终端登录服务器时，或在第一终端和第二终端空闲时，将新版本的数据压缩字典发送给第一终端和第二终端。

在第三类型场景下，如果碰到终端回退到不支持信令压缩的老版本时，终端登录到服务器时不会带上支持信令压缩及字典版本号的信息，服务器就保存此终端属性，当另一个终端以压缩信令呼叫此终端，且还未来得及进行能力查询时，服务器返回错误码，则呼叫端重新以同一会话ID发送未压缩的信令进行后续的交互。服务器处理第二终端换回不支持压缩功能版本的异常，如果第一终端在呼叫前对此回退到不支持信令压缩的老版本的终端进行能力查询，则可提前更新此好友属性，直接采用不压缩的方式进行交互。

随着电信和互联网的基础设施的快速发展，网络的带宽越来越大，信令相对于以几兆到几百兆级别的网络链路而言，实际上只占用非常小比例的带宽。一般的一个SIP呼叫信令报文大概只有3～4Kbytes，如果希望500ms送达，理论所需要占用带宽为4*8*1000/500＝64kbps；如果使用GZIP进行压缩后，大概只有0.5Kbytes，理论所需要占带宽8kbps。如果是5Mbps网络可用带宽，那么4Kbytes报文的按理论传输最快速率计算，只需要4*8*1000/(5*1024)＝6.25ms就能传输完成，压缩后的报文大小约为0.5Kbytes，最快只需要不到1ms就能传输完成。然而实际考虑到网络的固有延迟，包括交换机路由器的处理延迟，电信号传输延迟(光速)，实际的延迟会有几十毫秒到几百毫秒。有一点可以确定的是，如果不考虑丢包，在5M带宽及以上级别的网络环境下传输4K字节跟0.5K字节或者10K字节，从网络层(IP层)的角度来看，总的延迟差距不大，应该在20ms以内。但在传输层和应用层角度看，信令是需要可靠传输的，不得不考虑丢包问题，通常我们通过握手(ACK或NACK)重传实现可靠性，因此每个丢包都会引起增加至少一个RTT(往返延迟时间)或500毫秒(未收到ACK自动重发)的额外延迟。考虑到一般MTU为1500字节，4K字节需要拆分为3个包发送，设当前丢包率10％(我们监测到的全球互联网的平均丢包率)，那么3个包一次完整到达的概率为pow((1-10％),3)＝72.9％，也就是说，在不能完整到达的情况下，延迟至少会增加一个RTT，还有较大概率会增加2～3个RTT的延迟，根据我们监测数据全球互联网视频通话的平均RTT达500ms。如果，报文只有0.5K字节，即只需要一个打包，那么完整到达的概率就是90％。从应用层来看，一个信令发送最简单的过程是“终端--服务端--终端”，即一个来回有4次传输，如果信令报文大小是4K，设丢包率10％，则一次最简单的业务流程不重传的概率为pow((1-10％),12)＝28.24％；而信令压缩后的不重传概率为pow((1-10％),4)＝65.61％。因此由于丢包现象的存在，基于4K字节的信令的应用层看到的延迟会远远高于压缩后0.5K字节的情况。

如果我们通过采用reed-solomon(Reed,Irving S.；Solomon,Gustave(1960),"Polynomial Codes over Certain Finite Fields",Journal of the Society for Industrial and Applied Mathematics(SIAM)8(2):300–304,doi:10.1137/0108018)的算法实现FEC，即发送n个包，其中的k个包为原始需要发送的包，n-k为冗余包个数，则在n个包中任意传输成功k个及以上的包，都能恢复出所有原始发送数据，这里n为6，k为4，冗余2个包，传输过程中丢任意2个包都能够恢复。按照这种算法，设PAR(Packet arrival rate)为包到达率(PAR＝1-丢包率)，设PFA(probability of an integral frame arrival)为完整数据帧(所有原始数据)的到达概率，则有如下计算公式：

按照上面的例子，对于未压缩的报文，增加2个FEC冗余包，则n＝5,k＝3,PAR＝90％；则一个通路的信令完整到达概率为99.14％；4个通路即一个应用层会话一次性完成的概率为pow(99.144％,4)＝96.6％。对于压缩后的报文，增加一个冗余包，则一个通路信令完整到达的概率为99％；4个通路即一个应用层会话一次性完成的概率为pow(99％,4)＝96.1％。如前所述，在以兆带宽为单位的环境下，增加几个包的FEC冗余增加的流量比较有限，且并不会增加延迟；由于一次成功完成应用层会话的业务的概率大大提升，而无须重传引入多个RTT的延迟。

通过上述信令压缩和前向纠错的方法，可降低码率、提高会话一次成功率，从而实现低延迟的可靠数据的传输，尤其适用于SIP/RCS协议中会话建立过程，提高用户体验。建议对呼叫敏感的业务默认增加1～2个冗余，对于发送IM等业务，考虑到减少冗余，兼顾发送实时性，可根据会话过程中统计的丢包率，来动态设定冗余比例。