CN107864084A - 数据包的传输方法和装置 - Google Patents
数据包的传输方法和装置 Download PDFInfo
- Publication number
- CN107864084A CN107864084A CN201610844042.2A CN201610844042A CN107864084A CN 107864084 A CN107864084 A CN 107864084A CN 201610844042 A CN201610844042 A CN 201610844042A CN 107864084 A CN107864084 A CN 107864084A
- Authority
- CN
- China
- Prior art keywords
- network
- packet
- client
- network state
- packet loss
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
- H04L51/10—Multimedia information
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种数据包的传输方法和装置。其中,该方法包括:基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,其中,第一媒体信息包括第一数据包;在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,其中,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包;在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求。本发明解决了相关技术中由于网络拥堵造成的即时通讯质量较差的技术问题。
Description
技术领域
本发明涉及即时通讯领域,具体而言,涉及一种数据包的传输方法和装置。
背景技术
随着社会的发展,信息的交互显得越来越重要,为了满足信息的及时交互,即时通讯软件如雨后春笋般出现,如微信、QQ等,即时通讯软件的使用主要依赖于互联网,因此,网络的好坏程度将直接影响即时通讯软件的通讯质量。
目前,随着网络设备的大量普及,网络的承载压力也越来越大,在大量设备同时使用网络时就会造成网络的拥堵,从而影响到各个网络设备的网络通讯,如影响即时通讯软件的即时通讯,造成用户间的通讯质量较差。
针对相关技术中由于网络拥堵造成的即时通讯质量较差的问题,目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种数据包的传输方法和装置,以至少解决相关技术中由于网络拥堵造成的即时通讯质量较差的技术问题。
根据本发明实施例的一个方面,提供了一种数据包的传输方法,包括:基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,其中,第一媒体信息包括第一数据包,第一媒体信息是第二客户端与第一客户端进行音频通话或视频通话时传输的媒体信息;在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,其中,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包,预设条件用于指示预设网络重传第二数据包所需达到的网络条件;在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求。
根据本发明实施例的另一方面,还提供了一种数据包的传输装置,包括:第一判断单元,用于基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,其中,第一媒体信息包括第一数据包,第一媒体信息是第二客户端与第一客户端进行音频通话或视频通话时传输的媒体信息;第一获取单元,用于在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;第一执行单元,用于在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,其中,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包,预设条件用于指示预设网络重传第二数据包所需达到的网络条件;第二执行单元,用于在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求。
在本发明实施例中,基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,其中,第一媒体信息包括第一数据包,第一媒体信息是第二客户端与第一客户端进行音频通话或视频通话时传输的媒体信息;在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,其中,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包,预设条件用于指示预设网络重传第二数据包所需达到的网络条件;在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求,在网络情况允许的情况下,通过重传请求获取丢失的数据包,达到使媒体信息更为完整的目的,从而实现了提升即时通讯质量的技术效果,进而解决了相关技术中由于网络拥堵造成的即时通讯质量较差的技术问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据本发明实施例的数据包的传输方法的硬件环境的示意图;
图2是根据本发明实施例的一种通讯消息传输系统的示意图;
图3是根据本发明实施例的一种可选的数据包的传输方法的流程图;
图4是根据本发明实施例的一种可选的数据包的传输方法的流程图;
图5是根据本发明实施例的一种可选的数据包的传输装置的示意图;
图6是根据本发明实施例的一种可选的数据包的传输装置的示意图;以及,
图7是根据本发明实施例的一种终端的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例1
根据本发明实施例,提供了一种数据包的传输方法的方法实施例。
可选地,在本实施例中,上述方法可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。如图1所示,服务器102通过网络与终端104进行连接,上述网络包括但不限于:广域网、城域网或局域网,终端104并不限定于PC、手机、平板电脑等。本发明实施例的方法可以由服务器102来执行,也可以由终端104来执行,还可以是由服务器102和终端104共同执行。其中,终端104执行本发明实施例的方法也可以是由安装在其上的客户端来执行。
实时音视频通话的总体框图如图2所示,客户端B将接收到的声卡采集到的数据进行编码、发送,通过网络传输到客户端A(即通过原有数据流);客户端A对数据(即原有数据流中传输的数据)进行接收、解码,将解码后的数据送到声卡进行播放。客户端A接收数据时,如果发现有丢包现象(通过步骤S31的丢包检测实现),就可以向客户端B发送重传请求(即ARQ请求数据流中的请求),客户端B接收到重传请求之后,将所需的数据重新发一遍给客户端A,重新发的这一份数据即ARQ响应数据流中的响应数据。
在上述的传输方式中,未考虑网络的不同特性对于实际重传的影响,对于有些网络(如受限带宽网络),丢包是由于拥塞造成的,在这样的网络中发送重传请求、对端响应重传请求而重传数据,相当于进一步增加了网络的负担,使得拥塞现象更加严重,这时进行重传,不仅浪费带宽,还可能造成网络拥塞更加严重,由于网络拥塞的加剧,进而增加丢包,使通话质量恶化,从而造成恶性循环。
且该传输方法也未考虑语音实时通话的特性,实时通话对数据到达的时间有严格的要求,而重传是在检测到有丢包之后,再重新发送重传请求、等待对方重新发送响应数据,在这样的情况下,考虑到丢包检测、重传请求的发送以及响应数据的接收所需消耗的时间,这样经过一来一回就需要消耗一定的时间,如果这个时间过大,那么即使响应数据重新传到接收端了,对实时通信来说,也是没用的,这种网络状况下,重传数据的使用率会非常低,甚至根本不起作用。
为了考虑网络特性、语音实时通话特性对于即时通讯的影响,根据本发明实施例,提供了一种数据包的传输方法的方法实施例。
图3是根据本发明实施例的一种可选的数据包的传输方法的流程图,如图3所示,该方法可以包括以下步骤:
步骤S302,基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,第一媒体信息包括第一数据包,第一媒体信息是第二客户端与第一客户端进行音频通话或视频通话时传输的媒体信息;
步骤S304,在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;
步骤S306,在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包,预设条件用于指示预设网络重传第二数据包所需达到的网络条件;
步骤S308,在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求。
通过上述步骤S302至步骤S308,在第一媒体信息发生丢包的情况下,根据网络状态信息判断是否发送重传请求,在网络状况较为理想的情况下发送重传请求以获取丢失的数据包,达到使媒体信息更为完整的目的,在网络状况不理想的情况下,不发送重传请求,以避免加剧网络的拥堵状况,可以解决了相关技术中由于网络拥堵造成的即时通讯质量较差的技术问题,进而达到提高即时通讯质量的技术效果。
上述的客户端可以为通讯用的客户端,该客户端可以安装在计算机、移动设备上,优选地,客户端可以为对通讯的即时性要求较高的客户端,也即即时通讯客户端,如微信、QQ等;预设网络即客户端间通讯用的网络;媒体信息可以为动态的多媒体信息,如视频、音频、GIF图片等,也可以为静态信息,如文字信息、静态图片等;网络状态信息也即用于描述网络特征的信息,如网络传输速度、延迟等信息等。上述网络条件指传输第二数据包所需占用的最低网络资源,如用于限定预设网络重传第二数据包所需达到的最小的网络传输速度、最小延迟等条件。
需要说明的是,在相关技术中只要发生丢包就会发送重传请求,由于此时网络堵塞较为严重,在发送重传请求的同时,无疑加剧了网络的堵塞状况,进而会造成更多的数据包丢失,且由于网络堵塞情况严重,即使收到了响应数据包,响应数据包的有效性也大大降低,起不到提高通讯质量的效果,相反,由于网络堵塞的加重,会造成更多的数据包丢失。而在本申请的技术方案中,在网络状况不理想的情况下,不发送重传请求,以避免加剧网络的拥堵状况,相对于在相关技术中采用的手段,可减少后续丢包现象的发生,进而相对地提高了通讯质量。
步骤S302至步骤S308的执行主体可以是接收数据包的客户端(即第一客户端),即第一客户端根据自身需求向第二客户端发起重传请求,为了降低第一客户端的运行负载,也可以是客户端所属的应用服务器来执行步骤S302至步骤S308,由服务器对第一客户端的数据包接收情况进行监控,在确定了丢包之后,根据网络情况来向第二客户端申请丢失的数据包,这里的服务器可以为客户端的服务器,如在客户端为即时通讯应用时,服务器为即时通讯应用服务器。
本申请基于历史数据对当前网络特点进行分析,根据网络特性、接收语音数据的重要性来决定是否发送重传请求,同时,根据重传数据的利用率,实时调整重传控制的相关策略,使得在各种网络条件下,带宽利用率和重传使用率都达到最优。具体的实现方式如图3所示:
在步骤S302提供的技术方案中,基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包可以通过如下方式实现:根据第一数据包中的序号索引信息判断第一媒体信息是否发生丢包。
具体地,可以根据序号索引的连续性来确定,如收到了索引为7和9的数据包,那么可以确定索引为8的数据包丢失。另外,在数据包中会标识出对应于某一媒体信息的多个数据包的索引区间,例如,对于即时通讯应用中的一条语音,可以拆为100个数据包进行发送,那么在数据包中可以标识出该语音使用的索引区间为301至400,这样,在任意一个数据包丢失的时候均可以根据收到的数据包来确定。
在步骤S304提供的技术方案中,在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息,获取的信息主要包括用于表征第一网络状态的当前使用带宽、当前传输时延、当前丢包率以及用于描述允许连续丢包数量的第二预设值。
需要说明的是,上述的当前使用带宽用于表示当前使用码率。使用码率指的是当前通话实际使用的码率,包括发送码率和接收码率,发送码率是发送的总字节数除以通话时长,接收码率是接收的总字节数除以通话时长。例如,估计的带宽(即带宽阀值)远大于当前使用的发送码率,那么就说明带宽很充足,多发一些重传包也没关系,不会对网络造成压力。估计带宽,估计的是当前通话时链路的大概带宽情况,是一个实时变化的值。
在判断网络状态信息所指示的预设网络的第一网络状态是否与重传第二数据包所需的第二网络状态匹配之前,根据预设网络的带宽信息确定带宽阈值;根据预设网络的网络抖动信息确定传输时延阈值;根据历史丢包率和丢包模型确定丢包率阈值。
丢包率包括长时丢包率(即通话开始到当前时刻为止的丢包率)、短时丢包率(如5秒内的丢包率,用来指示网络丢包率是否发生突变)、连续丢包个数的累计直方图(用来表征丢包模型,即是均匀丢包的网络类型、还是突发大丢包比较多的网络类型)。
传输时延,是指节点在发送数据时使数据块从节点进入到传输媒体所需的时间,即一个站点从开始发送数据帧到数据帧发送完毕所需要的全部时间(或者是接收站点接收另一站点发送的数据帧的全部时间)。
在步骤S306或S308提供的技术方案中,在获取预设网络的网络状态信息之后、且在向第二客户端发送重传请求或取消向第二客户端发送重传请求之前,判断网络状态信息所指示的预设网络的第一网络状态是否与重传第二数据包所需的第二网络状态匹配;在第一网络状态与第二网络状态匹配的情况下,判断出网络状态信息满足预设条件;在第一网络状态与第二网络状态不匹配的情况下,判断出网络状态信息不满足预设条件。
具体地,判断网络状态信息所指示的预设网络的第一网络状态是否与重传第二数据包所需的第二网络状态匹配包括以下至少之一:判断带宽阈值与当前使用带宽的差值是否小于第一预设值;判断当前传输时延是否小于传输时延阈值;判断当前丢包率是否小于丢包率阈值;判断连续丢包的数量是否小于第二预设值;其中,预设判断结果用于指示第一网络状态与第二网络状态匹配,预设判断结果包括以下至少之一:判断出带宽阈值与当前使用带宽的差值小于第一预设值;判断出当前传输时延小于传输时延阈值;判断出当前丢包率小于丢包率阈值;判断出连续丢包的数量小于第二预设值。
可选地,在向第二客户端发送重传请求之前,通过对第一数据包中的媒体信息段进行信号特征分析确定丢失的第二数据包的语音特征;在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求包括:在网络状态信息满足预设条件,且语音特征包括浊音特征、语音特征以及语义特征中的至少一个的情况下,向第二客户端发送重传请求。
具体地,可对语音信号进行分析,如清音、浊音分析,语音、静音分析、语义重要性分析等,以调整网络参数阈值,比如,带宽足够时,只要检测到丢包就可以进行重传请求,带宽不够时,只对丢失的重要语音帧(即上述满足浊音特征、语音特征以及语义特征中的一个或多个的语音帧)进行重传请求。如对包括重要语义的语音数据包进行重传。
在步骤S306或S308执行完毕之后,在向第二客户端发送重传请求或取消向第二客户端发送重传请求之后,该方法还包括以下至少之一:根据前一次确定的带宽阈值和预设网络的当前带宽信息重新确定当前的带宽阈值;在接收到的第二数据包的数量与发送的重传请求的数量的第一比值小于第三预设值的情况下,增大丢包率阈值,并减小传输时延阈值;在接收到的有效的第二数据包与接收到的所有第二数据包间的第二比值小于第四预设值的情况下,增大丢包率阈值,并减小传输时延阈值。
上述的有效的第二数据包是指满足实时性要求的数据包,即在丢失后的预设时间内收到的数据包。
需要说明的是,带宽阈值、丢包率阈值、传输时延阈值等阈值可以在初始的时候根据经验设置一个初始值,步骤S302至步骤S308初次执行使用的是各个阈值的初始值,在运行的过程中,可以根据网络情况和实际的反馈情况进行自调整,以达到提高语音通信质量的目的。
在改变丢包率阈值和传输时延阈值的过程中,并不是一次性调整一个极大的数值,可以按照该参数的当前数值的某一百分比(如10%)进行增加或者减小,从而避免调整过度,以达到平滑过度的目的。
在步骤S306或S308执行完毕之后,在向第二客户端发送重传请求之后,接收第二客户端发送的第二数据包;根据第一数据包和第二数据包生成第二媒体信息;或在网络状态信息不满足预设条件的情况下,根据第一数据包生成第三媒体信息。
在接收到第一媒体信息的所有数据包的情况下,即接收到每一个丢失的第二数据包的情况下,恢复生成的第二媒体信息即第一媒体信息,即可以恢复得到一段完整的语音;由于出现了语音缺失,即出现了丢包,第三媒体信息相较于第一媒体信息,质量会相对较低。
在上述的实施例中,为了更清晰地描述重传的机制,如图2所示,重传控制流程主要包括:
步骤S31,丢包检测,根据接收到的数据包的包头信息中的序号索引信息,判断是否有丢包,例如,当前数据包的序号索引为25,而前一数据包的序号索引为24,由于两个数据包的序号索引是连续的,根据序号索引可知没有发生丢包,若前一数据包的序号索引为22,由于两个数据包的序号索引不是连续的,根据序号索引可知发生丢包,且丢包的数量为2(即丢失数据包的序号索引为23和24)。
步骤S32,请求控制,如果在步骤S31中检测到有丢包发生,则向对方(如客户端B)发送重传请求。
步骤S33,响应控制,根据接收到的重传请求信息,在历史缓存数据中,确定将哪些数据进行重传。确定的依据包括:重传数据与已发送数据的长度间隔,所需重传数据的重要等级。
在步骤S33的响应控制中,对于进行重传的控制,对于步骤S32的请求控制,均是检测到有丢包就发送重传请求,而发送重传请求信息也是需要消耗带宽的,在有些网络下,多消耗带宽可能造成网络拥塞的加剧,使通话质量更加恶化,或者由于实时通话的特性,造成重传数据的利用率太低,这时候步骤S32中的重新请求信息的发送就是不必要的;同时,在步骤S33的响应控制中,也没有考虑网络特性、重传的利用率等。因此,在这种重传控制方法中,重传数据的利用率和带宽的利用率都没有依据不同的网络特性加以控制。
下面结合图4进一步地详述本申请的技术方案,如图4所示:
步骤S401,丢包检测,根据包头信息中的序号索引信息,判断是否有丢包。
步骤S402,丢包判决,即判断是否发生丢包,如果步骤S401中检测到没有丢包,就执行步骤S409,如果检测到发生丢包,则执行步骤S403。
步骤S403,进行网络特性分析,网络特性包括但不限于:使用码率、估计带宽、丢包率、网络抖动、端到端的传输时延等。
上述的使用码率指的是当前通话实际使用的码率,包括发送码率和接收码率,发送码率是发送的总字节数除以通话时长,接收码率是接收的总字节数除以通话时长,例如,估计的带宽是512kbps,当前使用的发送码率是100kbps,那么就说明带宽很充足,多发一些重传包也没关系,不会对网络造成压力。
估计带宽,估计的是当前通话时链路的大概带宽情况,是一个实时变化的值。
丢包率包括长时丢包率(即通话开始到当前时刻为止的丢包率)、短时丢包率(如5秒内的丢包率,用来指示网络丢包率是否发生突变)、连续丢包个数的累计直方图(用来表征丢包模型,即是均匀丢包的网络类型、还是突发大丢包比较多的网络类型)。
网络抖动,是QOS(Quality Of Service,服务质量)中的概念,是指分组延迟的变化程度,如果网络发生拥塞,排队延迟将影响端到端的延迟,并导致通过同一连接传输的分组延迟各不相同,而抖动就是用来描述这样的延迟变化的程度。
步骤S404,根据步骤S403中分析的结果,计算相应的网络参数阈值。
(1)确定带宽阈值,根据估计的带宽,当使用码率(即当前使用带宽,如接收码率、发送码率)大于一定阈值时,就不允许发送ARQ请求(即重传请求)。
(2)确定传输时延阈值,根据网络抖动,确定传输时延阈值;在一定的抖动下,当传输时延大于某个阈值的时候,就不允许发送ARQ请求,因为这时候即使发送了ARQ请求,重传过来的响应数据也可能用不上,导致利用率太低。
(3)丢包率阈值,根据历史丢包率大小和丢包模型的分析确定当前丢包率下的阈值。比如在某些带宽不够的网络下、或者丢包率特别大的网络下,发送的数据越多,丢的数据也越多,这时候再发送ARQ请求就会增加网络负担,也即发送ARQ请求也是无用或者有害的。
例如,假设估计带宽是512kbps,而当前使用码率是100kbps,那么说明带宽比较充足,检测到有丢包就可以发送重传请求;假设估计带宽是512kbps,使用码率是450kbps,说明剩余带宽不是很充足,这时候,只有丢包率大于15%,且连续丢包个数的累计直方图显示连续丢多个(如4个)以上包的比例比较大的时候,才发重传请求。之所以这样考虑,是因为丢包率比较低的时候,虽然听觉上通话质量会有所下降,但还是不影响语义的理解;而丢包率大到一定程度时,就会影响语义的接收。带宽不太够的时候,为了避免多发的重传包对网络造成冲击,只有当丢包率达到一定大的时候才发重传请求。
步骤S405,统计重传请求的相关利用率。
(1)计算接收到的响应数据的数量与ARQ请求的数量之间的第一比值,客户端B缓存的历史数据是有一定的长度限制的,如果客户端A到客户端B的传输时延太大,客户端B收到的ARQ请求中携带的请求包数据信息已经在缓存数据之外,那么就不会对客户端A的ARQ请求进行响应,这时候计算出来的第一比值的数值就会特别低。为了避免客户端A发送太多ARQ请求而造成带宽浪费,需要降低ARQ请求的发送频率,即提高网络参数的相关阈值;
(2)计算响应数据的实际利用率,客户端B收到ARQ请求之后,在历史缓存数据中找到了相应的数据,将数据作为响应包重新发送给客户端A。这时候,如果客户端B到客户端A之间的传输时延太大,响应数据到达客户端A的时候已经不满足实时通话的数据要求,变成晚到的包需要主动丢掉,这时候虽然有响应数据,但是响应数据的利用率太低,如果一段时间内的实际利用率低,也需要降低ARQ的请求频率,即提高网络参数的相关阈值。
步骤S406,更新阈值。
由于网络带宽和传输时延等都是估计值,即使按估计带宽、使用码率、丢包率、传输时延等参数做了合理的控制,实际效果可能还是达不到理想效果,比如,可能带宽估计不够准确,增加了重传包之后,网络拥塞使得传输时延变大,发送了很多重传请求,但是收到的重传响应包很少,这时接收到的响应数据的数量与ARQ请求的数量之间的比值就会很低,比如发送了1000个重传请求,只收到了一个ARQ响应包,这个时候就要减少重传请求的频率。减少时不是一下减少很多,而是通过一步一步增加相关的网络参数来实现的,比如原来是丢包率大于10%、传输时延小于200ms时允许发送ARQ请求,现在提高门槛,只有丢包率大于20%、传输时延小于150ms时才允许发送ARQ请求。
步骤S407,信号特性分析。
对信号进行分析,如清音、浊音分析,语音、静音分析、语义重要性分析等,以调整步骤S406中的网络参数阈值,比如,带宽足够时,只要检测到丢包就可以进行重传请求,带宽不够时,只对丢失的重要语音帧进行重传请求。
比如,带宽估计是512kbps,使用码率是100kbps,说明带宽很充足,那么只要有丢包就可以发送重传请求;假设带宽估计是512kbps,而使用带宽是460kbps,说明带宽已经不是很充裕,那么只有发现丢失的包是重要信息的时候,才发送重传请求。
步骤S408,请求的综合判决。
综合判决时,带宽充裕,就可以多发一些重传请求,带宽不充裕时,只有重要信息丢失了才发重传请求。
步骤S409,不允许发送ARQ请求。
步骤S410,允许发送ARQ请求。
通过上述实施例,可使重传请求的发送自适应不同的网络特性,使得在各种网络环境下,带宽利用率和重传效率都达到最优。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
根据本发明实施例,还提供了一种用于实施上述数据包的传输方法的数据包的传输装置。图5是根据本发明实施例的一种可选的数据包的传输装置的示意图,如图5所示,该装置可以包括:第一判断单元52、第一获取单元54、第一执行单元56以及第二执行单元58。
第一判断单元52,用于基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,其中,第一媒体信息包括第一数据包,第一媒体信息是第二客户端与第一客户端进行音频通话或视频通话时传输的媒体信息;
第一获取单元54,用于在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;
第一执行单元56,用于在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,其中,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包,预设条件用于指示预设网络重传第二数据包所需达到的网络条件;
第二执行单元58,用于在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求。
需要说明的是,该实施例中的发起模块52可以用于执行本申请实施例1中的步骤S302,该实施例中的开启模块54可以用于执行本申请实施例1中的步骤S304,该实施例中的发送模块56可以用于执行本申请实施例1中的步骤S306,该实施例中的第一关闭模块58可以用于执行本申请实施例1中的步骤S308。
此处需要说明的是,上述模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例1所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在如图1所示的硬件环境中,可以通过软件实现,也可以通过硬件实现。
通过上述模块,在第一媒体信息发生丢包的情况下,根据网络状态信息判断是否发送重传请求,在网络状况较为理想的情况下发送重传请求以获取丢失的数据包,达到使媒体信息更为完整的目的,在网络状况不理想的情况下,不发送重传请求,以避免加剧网络的拥堵状况,可以解决了相关技术中由于网络拥堵造成的即时通讯质量较差的技术问题,进而达到提高即时通讯质量的技术效果。
上述的客户端可以为通讯用的客户端,该客户端可以安装在计算机、移动设备上,优选地,客户端可以为对通讯的即时性要求较高的客户端,也即即时通讯客户端,如微信、QQ等;预设网络即客户端间通讯用的网络;媒体信息可以为动态的多媒体信息,如视频、音频、GIF图片等,也可以为静态信息,如文字信息、静态图片等;网络状态信息也即用于描述网络特征的信息,如网络传输速度、延迟等信息。
需要说明的是,在相关技术中只要发生丢包就会发送重传请求,由于此时网络堵塞较为严重,在发送重传请求的同时,无疑加剧了网络的堵塞状况,进而会造成更多的数据包丢失,且由于网络堵塞情况严重,即使收到了响应数据包,响应数据包的有效性也大大降低,起不到提高通讯质量的效果,相反,由于网络堵塞的加重,会造成更多的数据包丢失。而在本申请的技术方案中,在网络状况不理想的情况下,不发送重传请求,以避免加剧网络的拥堵状况,相对于在相关技术中采用的手段,可减少后续丢包现象的发生,进而相对地提高了通讯质量。
上述的第一判断单元52、第一获取单元54、第一执行单元56以及第二执行单元58可以设置在第一客户端上,即第一客户端根据自身需求向第二客户端发起重传请求,为了降低第一客户端的运行负载,上述的第一判断单元52、第一获取单元54、第一执行单元56以及第二执行单元58也可以设置在应用服务器上,由服务器对第一客户端的数据包接收情况进行监控,在确定了丢包之后,根据网络情况来向第二客户端申请丢失的数据包,这里的服务器可以为客户端的服务器,如在客户端为即时通讯应用时,服务器为即时通讯应用服务器。
本申请基于历史数据对当前网络特点进行分析,根据网络特性、接收语音数据的重要性来决定是否发送重传请求,同时,根据重传数据的利用率,实时调整重传控制的相关策略,使得在各种网络条件下,带宽利用率和重传使用率都达到最优。具体的实现方式参照图3。
可选地,第一判断单元还用于根据第一数据包中的序号索引信息判断第一媒体信息是否发生丢包。
具体地,可以根据序号索引的连续性来确定,如收到了索引为7和9的数据包,那么可以确定索引为8的数据包丢失。另外,在数据包中会标识出对应于某一媒体信息的多个数据包的索引区间,例如,对于即时通讯应用中的一条语音,可以拆为100个数据包进行发送,那么在数据包中可以标识出该语音使用的索引区间为301至400,这样,在任意一个数据包丢失的时候均可以根据收到的数据包来确定。
可选地,该装置还包括:第二获取单元,用于在判断网络状态信息所指示的预设网络的第一网络状态是否与重传第二数据包所需的第二网络状态匹配之前,获取用于表征第一网络状态的当前使用带宽、当前传输时延、当前丢包率以及用于描述允许连续丢包数量的第二预设值;第三确定单元,用于根据预设网络的带宽信息确定带宽阈值;第四确定单元,用于根据预设网络的网络抖动信息确定传输时延阈值;第五确定单元,用于根据历史丢包率和丢包模型确定丢包率阈值。
可选地,该装置还包括:第二判断单元,用于在获取预设网络的网络状态信息之后、且在向第二客户端发送重传请求或取消向第二客户端发送重传请求之前,判断网络状态信息所指示的预设网络的第一网络状态是否与重传第二数据包所需的第二网络状态匹配;第一确定单元,用于在第一网络状态与第二网络状态匹配的情况下,判断出网络状态信息满足预设条件;第二确定单元,用于在第一网络状态与第二网络状态不匹配的情况下,判断出网络状态信息不满足预设条件。
可选地,第二判断单元包括:第一判断模块,用于判断带宽阈值与当前使用带宽的差值是否小于第一预设值;第二判断模块,用于判断当前传输时延是否小于传输时延阈值;第三判断模块,用于判断当前丢包率是否小于丢包率阈值;第四判断模块,用于判断连续丢包的数量是否小于第二预设值;其中,预设判断结果用于指示第一网络状态与第二网络状态匹配,预设判断结果包括以下至少之一:判断出带宽阈值与当前使用带宽的差值小于第一预设值;判断出当前传输时延小于传输时延阈值;判断出当前丢包率小于丢包率阈值;判断出连续丢包的数量小于第二预设值。
作为一种可选的实施例,装置还包括:第一更新单元,用于在向第二客户端发送重传请求或取消向第二客户端发送重传请求之后,根据前一次确定的带宽阈值和预设网络的当前带宽信息重新确定当前的带宽阈值;第二更新单元,用于在接收到的第二数据包的数量与发送的重传请求的数量的第一比值小于第三预设值的情况下,增大丢包率阈值,并减小传输时延阈值;第三更新单元,用于在接收到的有效的第二数据包与接收到的所有第二数据包间的第二比值小于第四预设值的情况下,增大丢包率阈值,并减小传输时延阈值。
需要说明的是,在改变丢包率阈值和传输时延阈值的过程中,并不是一次性调整一个极大的数值,可以按照该参数的当前数值的某一百分比(如10%)进行增加或者减小,从而避免调整过度,以达到平滑过度的目的。
可选地,该装置还包括:第六确定单元,用于在向第二客户端发送重传请求之前,通过对第一数据包中的媒体信息段进行信号特征分析确定丢失的第二数据包的语音特征;第一执行单元还用于在网络状态信息满足预设条件,且语音特征包括浊音特征、语音特征以及语义特征中的至少一个的情况下,向第二客户端发送重传请求。
具体地,可对语音信号进行分析,如清音、浊音分析,语音、静音分析、语义重要性分析等,以调整网络参数阈值,比如,带宽足够时,只要检测到丢包就可以进行重传请求,带宽不够时,只对丢失的重要语音帧进行重传请求。如对包括重要语义的语音数据包进行重传。
可选地,如图6所示,该装置还包括:接收单元60,用于在向第二客户端发送重传请求之后,接收第二客户端发送的第二数据包;第一生成单元62,用于根据第一数据包和第二数据包生成第二媒体信息;第二生成单元64,用于在网络状态信息不满足预设条件的情况下,根据第一数据包生成第三媒体信息。
在接收到第一媒体信息的所有数据包的情况下,即接收到每一个丢失的第二数据包的情况下,恢复的第二媒体信息即第一媒体信息,即可以恢复得到一段完整的语音;由于出现了语音缺失,即出现了丢包,第三媒体信息相较于第一媒体信息,质量会相对较低。
此处需要说明的是,上述模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例1所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在如图1所示的硬件环境中,可以通过软件实现,也可以通过硬件实现,其中,硬件环境包括网络环境。
实施例3
根据本发明实施例,还提供了一种用于实施上述方法的服务器或终端。
图7是根据本发明实施例的一种终端的结构框图,如图7所示,该终端可以包括:一个或多个(图中仅示出一个)处理器701、存储器703、以及传输装置705(如上述实施例中的发送装置),如图7所示,该终端还可以包括输入输出设备707。
其中,存储器703可用于存储软件程序以及模块,如本发明实施例中的方法和装置对应的程序指令/模块,处理器701通过运行存储在存储器703内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的方法。存储器703可包括高速随机存储器,还可以包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器703可进一步包括相对于处理器701远程设置的存储器,这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的传输装置705用于经由一个网络接收或者发送数据,还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中,传输装置705包括一个网络适配器(Network Interface Controller,NIC),其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中,传输装置705为射频(Radio Frequency,RF)模块,其用于通过无线方式与互联网进行通讯。
其中,具体地,存储器703用于存储应用程序。
处理器701可以通过传输装置705调用存储器703存储的应用程序,以执行下述步骤:基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,其中,第一媒体信息包括第一数据包,第一媒体信息是第二客户端与第一客户端进行音频通话或视频通话时传输的媒体信息;在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,其中,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包,预设条件用于指示预设网络重传第二数据包所需达到的网络条件;在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求。
处理器701还用于执行下述步骤:在向第二客户端发送重传请求之后,接收第二客户端发送的第二数据包;根据第一数据包和第二数据包生成第二媒体信息;在网络状态信息不满足预设条件的情况下,根据第一数据包生成第三媒体信息。
处理器701还用于执行下述步骤:在获取预设网络的网络状态信息之后、且在向第二客户端发送重传请求或取消向第二客户端发送重传请求之前,判断网络状态信息所指示的预设网络的第一网络状态是否与重传第二数据包所需的第二网络状态匹配;在第一网络状态与第二网络状态匹配的情况下,判断出网络状态信息满足预设条件;在第一网络状态与第二网络状态不匹配的情况下,判断出网络状态信息不满足预设条件。
处理器701还用于执行下述步骤:判断带宽阈值与当前使用带宽的差值是否小于第一预设值;判断当前传输时延是否小于传输时延阈值;判断当前丢包率是否小于丢包率阈值;判断连续丢包的数量是否小于第二预设值;其中,预设判断结果用于指示第一网络状态与第二网络状态匹配,预设判断结果包括以下至少之一:判断出带宽阈值与当前使用带宽的差值小于第一预设值;判断出当前传输时延小于传输时延阈值;判断出当前丢包率小于丢包率阈值;判断出连续丢包的数量小于第二预设值。
采用本发明实施例,提供了一种数据包的传输方法的方案。基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,其中,第一媒体信息包括第一数据包;在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,其中,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包;在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求,在网络情况允许的情况下,通过重传请求获取丢失的数据包,达到使媒体信息更为完整的目的,从而实现了提升即时通讯质量的技术效果,进而解决了相关技术中由于网络拥堵造成的即时通讯质量较差的技术问题。
可选地,本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例,本实施例在此不再赘述。
本领域普通技术人员可以理解,图7所示的结构仅为示意,终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices,MID)、PAD等终端设备。图7其并不对上述电子装置的结构造成限定。例如,终端还可包括比图7中所示更多或者更少的组件(如网络接口、显示装置等),或者具有与图7所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:闪存盘、只读存储器(Read-Only Memory,ROM)、随机存取器(RandomAccess Memory,RAM)、磁盘或光盘等。
实施例4
本发明的实施例还提供了一种存储介质。可选地,在本实施例中,上述存储介质可以用于执行数据包的传输方法的程序代码。
可选地,在本实施例中,上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。
可选地,在本实施例中,存储介质被设置为存储用于执行以下步骤的程序代码:
S1,基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断第二客户端通过预设网络向第一客户端发送的第一媒体信息是否发生丢包,其中,第一媒体信息包括第一数据包,第一媒体信息是第二客户端与第一客户端进行音频通话或视频通话时传输的媒体信息;
S2,在判断出第一媒体信息发生丢包的情况下,获取预设网络的网络状态信息;
S3,在网络状态信息满足预设条件的情况下,向第二客户端发送重传请求,其中,重传请求用于请求第二客户端重传第一媒体信息中丢失的第二数据包,预设条件用于指示预设网络重传第二数据包所需达到的网络条件;
S4,在网络状态信息不满足预设条件的情况下,取消向第二客户端发送重传请求。
可选地,存储介质还被设置为存储用于执行以下步骤的程序代码:在向第二客户端发送重传请求之后,接收第二客户端发送的第二数据包;根据第一数据包和第二数据包生成第二媒体信息;在网络状态信息不满足预设条件的情况下,根据第一数据包生成第三媒体信息。
可选地,存储介质还被设置为存储用于执行以下步骤的程序代码:在获取预设网络的网络状态信息之后、且在向第二客户端发送重传请求或取消向第二客户端发送重传请求之前,判断网络状态信息所指示的预设网络的第一网络状态是否与重传第二数据包所需的第二网络状态匹配;在第一网络状态与第二网络状态匹配的情况下,判断出网络状态信息满足预设条件;在第一网络状态与第二网络状态不匹配的情况下,判断出网络状态信息不满足预设条件。
可选地,存储介质还被设置为存储用于执行以下步骤的程序代码:判断带宽阈值与当前使用带宽的差值是否小于第一预设值;判断当前传输时延是否小于传输时延阈值;判断当前丢包率是否小于丢包率阈值;判断连续丢包的数量是否小于第二预设值;其中,预设判断结果用于指示第一网络状态与第二网络状态匹配,预设判断结果包括以下至少之一:判断出带宽阈值与当前使用带宽的差值小于第一预设值;判断出当前传输时延小于传输时延阈值;判断出当前丢包率小于丢包率阈值;判断出连续丢包的数量小于第二预设值。
可选地,本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例,本实施例在此不再赘述。
可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在上述计算机可读取的存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在存储介质中,包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。
在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的客户端,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (16)
1.一种数据包的传输方法,其特征在于,包括:
基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断所述第二客户端通过所述预设网络向所述第一客户端发送的第一媒体信息是否发生丢包,其中,所述第一媒体信息包括所述第一数据包,所述第一媒体信息是所述第二客户端与所述第一客户端进行音频通话或视频通话时传输的媒体信息;
在判断出所述第一媒体信息发生丢包的情况下,获取所述预设网络的网络状态信息;
在所述网络状态信息满足预设条件的情况下,向所述第二客户端发送重传请求,其中,所述重传请求用于请求所述第二客户端重传所述第一媒体信息中丢失的第二数据包,所述预设条件用于指示所述预设网络重传所述第二数据包所需达到的网络条件;
在所述网络状态信息不满足所述预设条件的情况下,取消向所述第二客户端发送所述重传请求。
2.根据权利要求1所述的方法,其特征在于,
在向所述第二客户端发送重传请求之后,所述方法还包括:接收所述第二客户端发送的所述第二数据包;根据所述第一数据包和所述第二数据包生成第二媒体信息;
在所述网络状态信息不满足预设条件的情况下,所述方法还包括:根据所述第一数据包生成第三媒体信息。
3.根据权利要求1所述的方法,其特征在于,在获取所述预设网络的网络状态信息之后、且在向所述第二客户端发送重传请求或取消向所述第二客户端发送所述重传请求之前,所述方法还包括:
判断所述网络状态信息所指示的所述预设网络的第一网络状态是否与重传所述第二数据包所需的第二网络状态匹配;
在所述第一网络状态与所述第二网络状态匹配的情况下,判断出所述网络状态信息满足所述预设条件;在所述第一网络状态与所述第二网络状态不匹配的情况下,判断出所述网络状态信息不满足所述预设条件。
4.根据权利要求3所述的方法,其特征在于,判断所述网络状态信息所指示的所述预设网络的第一网络状态是否与重传所述第二数据包所需的第二网络状态匹配包括以下至少之一:
判断带宽阈值与当前使用带宽的差值是否小于第一预设值;
判断当前传输时延是否小于传输时延阈值;
判断当前丢包率是否小于丢包率阈值;
判断连续丢包的数量是否小于第二预设值;
其中,预设判断结果用于指示所述第一网络状态与所述第二网络状态匹配,所述预设判断结果包括以下至少之一:判断出所述带宽阈值与所述当前使用带宽的差值小于所述第一预设值;判断出所述当前传输时延小于所述传输时延阈值;判断出所述当前丢包率小于所述丢包率阈值;判断出连续丢包的数量小于所述第二预设值。
5.根据权利要求4所述的方法,其特征在于,在判断所述网络状态信息所指示的所述预设网络的第一网络状态是否与重传所述第二数据包所需的第二网络状态匹配之前,所述方法还包括:
获取用于表征所述第一网络状态的所述当前使用带宽、所述当前传输时延、所述当前丢包率以及用于描述允许连续丢包数量的所述第二预设值;
根据所述预设网络的带宽信息确定所述带宽阈值;
根据所述预设网络的网络抖动信息确定所述传输时延阈值;
根据历史丢包率和丢包模型确定所述丢包率阈值。
6.根据权利要求1至5中任意一项所述的方法,其特征在于,在向所述第二客户端发送重传请求或取消向所述第二客户端发送所述重传请求之后,所述方法还包括以下至少之一:
根据前一次确定的带宽阈值和所述预设网络的当前带宽信息重新确定当前的带宽阈值;
在接收到的所述第二数据包的数量与发送的所述重传请求的数量的第一比值小于第三预设值的情况下,增大丢包率阈值,并减小传输时延阈值;
在接收到的有效的所述第二数据包与接收到的所有所述第二数据包间的第二比值小于第四预设值的情况下,增大所述丢包率阈值,并减小所述传输时延阈值。
7.根据权利要求1所述的方法,其特征在于,
在向所述第二客户端发送重传请求之前,所述方法还包括:通过对所述第一数据包中的媒体信息段进行信号特征分析确定丢失的所述第二数据包的语音特征;
在所述网络状态信息满足预设条件的情况下,向所述第二客户端发送重传请求包括:在所述网络状态信息满足所述预设条件,且所述语音特征包括浊音特征、语音特征以及语义特征中的至少一个的情况下,向所述第二客户端发送重传请求。
8.根据权利要求1所述的方法,其特征在于,判断所述第二客户端通过所述预设网络向所述第一客户端发送的第一媒体信息是否发生丢包包括:
根据所述第一数据包中的序号索引信息判断所述第一媒体信息是否发生丢包。
9.一种数据包的传输装置,其特征在于,包括:
第一判断单元,用于基于第一客户端通过预设网络接收到的第二客户端发送的第一数据包,判断所述第二客户端通过所述预设网络向所述第一客户端发送的第一媒体信息是否发生丢包,其中,所述第一媒体信息包括所述第一数据包,所述第一媒体信息是所述第二客户端与所述第一客户端进行音频通话或视频通话时传输的媒体信息;
第一获取单元,用于在判断出所述第一媒体信息发生丢包的情况下,获取所述预设网络的网络状态信息;
第一执行单元,用于在所述网络状态信息满足预设条件的情况下,向所述第二客户端发送重传请求,其中,所述重传请求用于请求所述第二客户端重传所述第一媒体信息中丢失的第二数据包,所述预设条件用于指示所述预设网络重传所述第二数据包所需达到的网络条件;
第二执行单元,用于在所述网络状态信息不满足所述预设条件的情况下,取消向所述第二客户端发送所述重传请求。
10.根据权利要求9所述的装置,其特征在于,所述装置还包括:
接收单元,用于在向所述第二客户端发送重传请求之后,接收所述第二客户端发送的所述第二数据包;
第一生成单元,用于根据所述第一数据包和所述第二数据包生成第二媒体信息;
第二生成单元,用于在所述网络状态信息不满足预设条件的情况下,根据所述第一数据包生成第三媒体信息。
11.根据权利要求9所述的装置,其特征在于,所述装置还包括:
第二判断单元,用于在获取所述预设网络的网络状态信息之后、且在向所述第二客户端发送重传请求或取消向所述第二客户端发送所述重传请求之前,判断所述网络状态信息所指示的所述预设网络的第一网络状态是否与重传所述第二数据包所需的第二网络状态匹配;
第一确定单元,用于在所述第一网络状态与所述第二网络状态匹配的情况下,判断出所述网络状态信息满足所述预设条件;
第二确定单元,用于在所述第一网络状态与所述第二网络状态不匹配的情况下,判断出所述网络状态信息不满足所述预设条件。
12.根据权利要求11所述的装置,其特征在于,所述第二判断单元包括:
第一判断模块,用于判断带宽阈值与当前使用带宽的差值是否小于第一预设值;
第二判断模块,用于判断当前传输时延是否小于传输时延阈值;
第三判断模块,用于判断当前丢包率是否小于丢包率阈值;
第四判断模块,用于判断连续丢包的数量是否小于第二预设值;
其中,预设判断结果用于指示所述第一网络状态与所述第二网络状态匹配,所述预设判断结果包括以下至少之一:判断出所述带宽阈值与所述当前使用带宽的差值小于所述第一预设值;判断出所述当前传输时延小于所述传输时延阈值;判断出所述当前丢包率小于所述丢包率阈值;判断出连续丢包的数量小于所述第二预设值。
13.根据权利要求12所述的装置,其特征在于,所述装置还包括:
第二获取单元,用于在判断所述网络状态信息所指示的所述预设网络的第一网络状态是否与重传所述第二数据包所需的第二网络状态匹配之前,获取用于表征所述第一网络状态的所述当前使用带宽、所述当前传输时延、所述当前丢包率以及用于描述允许连续丢包数量的所述第二预设值;
第三确定单元,用于根据所述预设网络的带宽信息确定所述带宽阈值;
第四确定单元,用于根据所述预设网络的网络抖动信息确定所述传输时延阈值;
第五确定单元,用于根据历史丢包率和丢包模型确定所述丢包率阈值。
14.根据权利要求9至13中任意一项所述的装置,其特征在于,所述装置还包括:
第一更新单元,用于在向所述第二客户端发送重传请求或取消向所述第二客户端发送所述重传请求之后,根据前一次确定的带宽阈值和所述预设网络的当前带宽信息重新确定当前的带宽阈值;
第二更新单元,用于在接收到的所述第二数据包的数量与发送的所述重传请求的数量的第一比值小于第三预设值的情况下,增大丢包率阈值,并减小传输时延阈值;
第三更新单元,用于在接收到的有效的所述第二数据包与接收到的所有所述第二数据包间的第二比值小于第四预设值的情况下,增大所述丢包率阈值,并减小所述传输时延阈值。
15.根据权利要求9所述的装置,其特征在于,
所述装置还包括:第六确定单元,用于在向所述第二客户端发送重传请求之前,通过对所述第一数据包中的媒体信息段进行信号特征分析确定丢失的所述第二数据包的语音特征;
所述第一执行单元还用于在所述网络状态信息满足所述预设条件,且所述语音特征包括浊音特征、语音特征以及语义特征中的至少一个的情况下,向所述第二客户端发送重传请求。
16.根据权利要求9所述的装置,其特征在于,所述第一判断单元还用于根据所述第一数据包中的序号索引信息判断所述第一媒体信息是否发生丢包。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610844042.2A CN107864084B (zh) | 2016-09-22 | 2016-09-22 | 数据包的传输方法和装置 |
PCT/CN2017/095309 WO2018054171A1 (zh) | 2016-09-22 | 2017-07-31 | 通话方法、装置、计算机存储介质及终端 |
EP17852241.3A EP3490199B1 (en) | 2016-09-22 | 2017-07-31 | Calling method and terminal |
US16/208,473 US10693799B2 (en) | 2016-09-22 | 2018-12-03 | Calling method and device, computer storage medium, and terminal |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610844042.2A CN107864084B (zh) | 2016-09-22 | 2016-09-22 | 数据包的传输方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107864084A true CN107864084A (zh) | 2018-03-30 |
CN107864084B CN107864084B (zh) | 2019-06-21 |
Family
ID=61698942
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610844042.2A Active CN107864084B (zh) | 2016-09-22 | 2016-09-22 | 数据包的传输方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107864084B (zh) |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108989135A (zh) * | 2018-09-29 | 2018-12-11 | 新华三技术有限公司合肥分公司 | 网络设备故障检测方法及装置 |
CN109361935A (zh) * | 2018-12-24 | 2019-02-19 | 广州微算互联信息技术有限公司 | 图片流视频传输方法与系统 |
CN109525447A (zh) * | 2019-01-07 | 2019-03-26 | 北京大米科技有限公司 | 一种调整网络传输带宽的方法、装置及电子设备 |
CN109787722A (zh) * | 2019-01-25 | 2019-05-21 | 北京数码视讯技术有限公司 | 数据传输方法、装置和服务器 |
CN109831282A (zh) * | 2019-01-31 | 2019-05-31 | 郑州云海信息技术有限公司 | 数据包重传、重传发送方法、系统、装置及可读存储介质 |
CN110417669A (zh) * | 2018-07-09 | 2019-11-05 | 腾讯科技(深圳)有限公司 | 数据包重传控制、网络拥塞检测方法和装置 |
CN111211933A (zh) * | 2018-11-22 | 2020-05-29 | 华为技术有限公司 | 一种确定传输链路的质量的方法及装置 |
CN111628992A (zh) * | 2020-05-26 | 2020-09-04 | 腾讯科技(深圳)有限公司 | 一种多人通话控制方法、装置、电子设备及存储介质 |
CN111953454A (zh) * | 2020-07-16 | 2020-11-17 | 西安万像电子科技有限公司 | 丢包重传方法、设备及存储介质 |
CN112069011A (zh) * | 2020-09-08 | 2020-12-11 | 西安万像电子科技有限公司 | 信息获取方法及装置、电子设备 |
CN112434904A (zh) * | 2020-10-23 | 2021-03-02 | 国网山东省电力公司日照供电公司 | 一种电力网络中电力数据通信验证系统 |
CN112533074A (zh) * | 2020-12-01 | 2021-03-19 | 国家电网有限公司 | 数据传输方法及装置 |
CN113037642A (zh) * | 2021-02-25 | 2021-06-25 | 深圳技术大学 | 物联网数据传输方法及传输系统 |
CN113794622A (zh) * | 2021-08-17 | 2021-12-14 | 北京达佳互联信息技术有限公司 | 消息处理方法、装置、电子设备及存储介质 |
CN113839830A (zh) * | 2021-07-15 | 2021-12-24 | 腾讯科技(深圳)有限公司 | 数据包多发参数的预测方法、装置与存储介质 |
CN113872733A (zh) * | 2021-09-29 | 2021-12-31 | 天翼物联科技有限公司 | 报文重发方法、装置、计算机设备及计算机可读存储介质 |
CN114095796A (zh) * | 2020-07-30 | 2022-02-25 | 中国移动通信集团终端有限公司 | 无效重传包减少方法、装置、设备及计算机存储介质 |
CN114124754A (zh) * | 2021-11-25 | 2022-03-01 | 随锐科技集团股份有限公司 | 用于处理多媒体网络中媒体数据包的方法及其相关产品 |
CN114172623A (zh) * | 2021-12-17 | 2022-03-11 | 深圳市领创星通科技有限公司 | 一种数据报文的重传控制方法、装置、设备及存储介质 |
CN114531429A (zh) * | 2020-10-30 | 2022-05-24 | 华为技术有限公司 | 用于传输媒体流的数据包的方法和通信装置 |
WO2022247550A1 (zh) * | 2021-05-25 | 2022-12-01 | 腾讯科技(深圳)有限公司 | 数据重传处理方法、装置、计算机设备和存储介质 |
CN115514815A (zh) * | 2022-07-13 | 2022-12-23 | 武汉依迅北斗时空技术股份有限公司 | 一种音视频数据采集方法及系统 |
CN115765934A (zh) * | 2021-09-03 | 2023-03-07 | 中国移动通信集团山东有限公司 | 一种数据传输方法和装置 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101114982A (zh) * | 2006-07-24 | 2008-01-30 | 互联天下科技发展(深圳)有限公司 | 一种基于IP网络的音视频QoS算法 |
CN101656747A (zh) * | 2009-09-25 | 2010-02-24 | 深圳创维数字技术股份有限公司 | 流媒体数据的传输方法及系统 |
CN101895466A (zh) * | 2010-07-02 | 2010-11-24 | 北京交通大学 | 一种降低sctp多路径传输数据包乱序影响的方法 |
CN102075312A (zh) * | 2011-01-10 | 2011-05-25 | 西安电子科技大学 | 基于视频服务质量的混合选择重传方法 |
CN102790666A (zh) * | 2011-05-17 | 2012-11-21 | 华为终端有限公司 | 差错控制的方法、接收端、发送端和系统 |
CN103338471A (zh) * | 2013-06-27 | 2013-10-02 | 南京邮电大学 | 基于模型的无线多跳网络服务质量指标评价方法 |
CN104579601A (zh) * | 2014-12-01 | 2015-04-29 | 华为技术有限公司 | 一种重传请求处理方法和装置 |
-
2016
- 2016-09-22 CN CN201610844042.2A patent/CN107864084B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101114982A (zh) * | 2006-07-24 | 2008-01-30 | 互联天下科技发展(深圳)有限公司 | 一种基于IP网络的音视频QoS算法 |
CN101656747A (zh) * | 2009-09-25 | 2010-02-24 | 深圳创维数字技术股份有限公司 | 流媒体数据的传输方法及系统 |
CN101895466A (zh) * | 2010-07-02 | 2010-11-24 | 北京交通大学 | 一种降低sctp多路径传输数据包乱序影响的方法 |
CN102075312A (zh) * | 2011-01-10 | 2011-05-25 | 西安电子科技大学 | 基于视频服务质量的混合选择重传方法 |
CN102790666A (zh) * | 2011-05-17 | 2012-11-21 | 华为终端有限公司 | 差错控制的方法、接收端、发送端和系统 |
CN103338471A (zh) * | 2013-06-27 | 2013-10-02 | 南京邮电大学 | 基于模型的无线多跳网络服务质量指标评价方法 |
CN104579601A (zh) * | 2014-12-01 | 2015-04-29 | 华为技术有限公司 | 一种重传请求处理方法和装置 |
Cited By (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110417669A (zh) * | 2018-07-09 | 2019-11-05 | 腾讯科技(深圳)有限公司 | 数据包重传控制、网络拥塞检测方法和装置 |
CN110417669B (zh) * | 2018-07-09 | 2022-08-26 | 腾讯科技(深圳)有限公司 | 数据包重传控制、网络拥塞检测方法和装置 |
CN108989135B (zh) * | 2018-09-29 | 2021-12-07 | 新华三技术有限公司合肥分公司 | 网络设备故障检测方法及装置 |
CN108989135A (zh) * | 2018-09-29 | 2018-12-11 | 新华三技术有限公司合肥分公司 | 网络设备故障检测方法及装置 |
CN111211933A (zh) * | 2018-11-22 | 2020-05-29 | 华为技术有限公司 | 一种确定传输链路的质量的方法及装置 |
CN111211933B (zh) * | 2018-11-22 | 2021-12-14 | 华为技术有限公司 | 一种确定传输链路的质量的方法及装置 |
CN109361935A (zh) * | 2018-12-24 | 2019-02-19 | 广州微算互联信息技术有限公司 | 图片流视频传输方法与系统 |
CN109525447B (zh) * | 2019-01-07 | 2022-05-31 | 北京大米科技有限公司 | 一种调整网络传输带宽的方法、装置及电子设备 |
CN109525447A (zh) * | 2019-01-07 | 2019-03-26 | 北京大米科技有限公司 | 一种调整网络传输带宽的方法、装置及电子设备 |
CN109787722A (zh) * | 2019-01-25 | 2019-05-21 | 北京数码视讯技术有限公司 | 数据传输方法、装置和服务器 |
CN109787722B (zh) * | 2019-01-25 | 2021-07-30 | 北京数码视讯技术有限公司 | 数据传输方法、装置和服务器 |
CN109831282A (zh) * | 2019-01-31 | 2019-05-31 | 郑州云海信息技术有限公司 | 数据包重传、重传发送方法、系统、装置及可读存储介质 |
CN109831282B (zh) * | 2019-01-31 | 2022-03-08 | 郑州云海信息技术有限公司 | 数据包重传、重传发送方法、系统、装置及可读存储介质 |
CN111628992B (zh) * | 2020-05-26 | 2021-04-13 | 腾讯科技(深圳)有限公司 | 一种多人通话控制方法、装置、电子设备及存储介质 |
CN111628992A (zh) * | 2020-05-26 | 2020-09-04 | 腾讯科技(深圳)有限公司 | 一种多人通话控制方法、装置、电子设备及存储介质 |
CN111953454A (zh) * | 2020-07-16 | 2020-11-17 | 西安万像电子科技有限公司 | 丢包重传方法、设备及存储介质 |
CN114095796A (zh) * | 2020-07-30 | 2022-02-25 | 中国移动通信集团终端有限公司 | 无效重传包减少方法、装置、设备及计算机存储介质 |
CN112069011A (zh) * | 2020-09-08 | 2020-12-11 | 西安万像电子科技有限公司 | 信息获取方法及装置、电子设备 |
CN112434904A (zh) * | 2020-10-23 | 2021-03-02 | 国网山东省电力公司日照供电公司 | 一种电力网络中电力数据通信验证系统 |
CN114531429A (zh) * | 2020-10-30 | 2022-05-24 | 华为技术有限公司 | 用于传输媒体流的数据包的方法和通信装置 |
CN112533074B (zh) * | 2020-12-01 | 2023-08-11 | 国家电网有限公司 | 数据传输方法及装置 |
CN112533074A (zh) * | 2020-12-01 | 2021-03-19 | 国家电网有限公司 | 数据传输方法及装置 |
CN113037642A (zh) * | 2021-02-25 | 2021-06-25 | 深圳技术大学 | 物联网数据传输方法及传输系统 |
WO2022247550A1 (zh) * | 2021-05-25 | 2022-12-01 | 腾讯科技(深圳)有限公司 | 数据重传处理方法、装置、计算机设备和存储介质 |
CN113839830B (zh) * | 2021-07-15 | 2023-10-24 | 腾讯科技(深圳)有限公司 | 数据包多发参数的预测方法、装置与存储介质 |
CN113839830A (zh) * | 2021-07-15 | 2021-12-24 | 腾讯科技(深圳)有限公司 | 数据包多发参数的预测方法、装置与存储介质 |
CN113794622A (zh) * | 2021-08-17 | 2021-12-14 | 北京达佳互联信息技术有限公司 | 消息处理方法、装置、电子设备及存储介质 |
CN115765934A (zh) * | 2021-09-03 | 2023-03-07 | 中国移动通信集团山东有限公司 | 一种数据传输方法和装置 |
CN113872733A (zh) * | 2021-09-29 | 2021-12-31 | 天翼物联科技有限公司 | 报文重发方法、装置、计算机设备及计算机可读存储介质 |
CN113872733B (zh) * | 2021-09-29 | 2024-01-05 | 天翼物联科技有限公司 | 报文重发方法、装置、计算机设备及计算机可读存储介质 |
CN114124754A (zh) * | 2021-11-25 | 2022-03-01 | 随锐科技集团股份有限公司 | 用于处理多媒体网络中媒体数据包的方法及其相关产品 |
CN114124754B (zh) * | 2021-11-25 | 2024-05-17 | 随锐科技集团股份有限公司 | 用于处理多媒体网络中媒体数据包的方法及其相关产品 |
CN114172623A (zh) * | 2021-12-17 | 2022-03-11 | 深圳市领创星通科技有限公司 | 一种数据报文的重传控制方法、装置、设备及存储介质 |
CN115514815A (zh) * | 2022-07-13 | 2022-12-23 | 武汉依迅北斗时空技术股份有限公司 | 一种音视频数据采集方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN107864084B (zh) | 2019-06-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107864084B (zh) | 数据包的传输方法和装置 | |
CN102724564B (zh) | 确定移动视频体验质量和视频代码转换的影响 | |
CN109314710A (zh) | 用于通信网络中的服务质量监测、策略执行和计费的系统和方法 | |
CN101433032B (zh) | 共享网络上的实时应用的质量保证 | |
CN106850402A (zh) | 消息的传输方法和装置 | |
CN104301249B (zh) | 一种sdn流表下发方法和装置 | |
CN105162555B (zh) | 一种码率调整方法及其终端 | |
CN107454276A (zh) | 一种用户终端设备及其数据转发方法、及通信系统 | |
CN106791575B (zh) | 一种数据发送的控制方法及设备 | |
CN109495660B (zh) | 一种音频数据的编码方法、装置、设备和存储介质 | |
CN107302802B (zh) | 一种数据传输的方法和装置 | |
CN106936730A (zh) | 一种报文发送方法、tcp代理以及tcp客户端 | |
CN106856457A (zh) | 一种数据传输方法、发送装置及接收装置 | |
CN103782554A (zh) | 数据分流方法,数据发送装置以及分流节点装置 | |
US9973438B2 (en) | Downlink flow management | |
CN115277581A (zh) | 网络传输的控制方法、装置、计算机设备、存储介质 | |
CN103685387B (zh) | 一种调度http请求的方法和浏览器装置 | |
CN102143040A (zh) | 流量控制的方法和装置 | |
CN108777665A (zh) | 一种数据传输方法、设备及系统 | |
CN115801691B (zh) | 数据丢包的处理方法、装置及存储介质 | |
CN110290552B (zh) | 缓存深度的测量方法和装置、存储介质、电子装置 | |
Levasseur et al. | Impact of acknowledgments on application performance in 4G LTE networks | |
Pokhrel et al. | Performance evaluation of video transmission over 802.11 n wireless network: A MAC layer perspective | |
CN107302504B (zh) | 一种基于虚拟发送队列的多路传输调度方法及系统 | |
CN113542215B (zh) | 一种提升流媒体传输性能的方法及相关装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |