CN104038845B - 报文传输方法及装置 - Google Patents
报文传输方法及装置 Download PDFInfo
- Publication number
- CN104038845B CN104038845B CN201410306557.8A CN201410306557A CN104038845B CN 104038845 B CN104038845 B CN 104038845B CN 201410306557 A CN201410306557 A CN 201410306557A CN 104038845 B CN104038845 B CN 104038845B
- Authority
- CN
- China
- Prior art keywords
- tcp
- data message
- client device
- server
- 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.)
- Active
Links
Landscapes
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供报文传输方法及装置,所述方法包括:客户端设备与服务器之间建立用于传输直播业务的数据报文的TCP连接,接收所述服务器通过所述TCP连接持续传输的数据报文;判断接收的数据报文的丢包率是否小于丢包阈值;当小于所述丢包阈值时,根据接收的数据报文直接播放所述直播业务;当不小于所述丢包阈值时,向所述服务器请求重传丢失的数据报文。应用本发明实施例,客户端设备可以在数据报文丢包较少时,避免因为请求重传而产生的延迟,从而提高了直播业务的实时性。
Description
技术领域
本发明涉及网络通信技术领域,尤其涉及报文传输方法及装置。
背景技术
随着数据通信与多媒体业务需求的发展,适应移动数据、移动计算及移动多媒体运作需要的第四代移动通信(4G)开始兴起,其使得人们能够通过网络实现各种直播业务,例如,随时随地的视频交流,以及网上观看电影等。在实现直播业务时,用户的客户端设备可以与支持直播业务的服务器之间建立TCP(Transmission Control Protocol,传输控制协议)连接,然后由服务器通过该TCP连接向客户端设备传输直播业务的数据报文。
在传输数据报文的过程中,当由于网络拥塞或网络不稳定造成数据报文丢失时,TCP重传机制支持服务器向客户端设备重传丢失的数据报文,即当服务器未接收到客户端设备返回的数据报文的应答报文时,服务器会向客户端重传数据报文。但是,当重传的数据报文数量较少时,重传过程仍然需要客户端设备进行等待,由此使得客户端设备上的直播业务产生延迟,严重时可能中断直播业务,导致直播业务的实时性不高。
发明内容
本发明提供报文传输方法及装置,以解决现有TCP重传机制会造成直播业务延迟,导致直播业务的实时性不高的问题。
根据本发明实施例的第一方面,提供一种报文传输方法,所述方法应用在用于实现直播业务的客户端设备上,所述客户端设备与服务器之间建立用于传输所述直播业务的数据报文的TCP连接,所述方法包括:
接收所述服务器通过所述TCP连接持续传输的数据报文;
判断接收的数据报文的丢包率是否小于丢包阈值;
当小于所述丢包阈值时,根据接收的数据报文直接播放所述直播业务;当不小于所述丢包阈值时,向所述服务器请求重传丢失的数据报文。
根据本发明实施例的第二方面,提供一种报文传输方法,所述方法应用在用于实现直播业务的服务器上,所述服务器与客户端设备之间建立用于传输所述直播业务的数据报文的TCP连接,所述方法包括:
判断是否接收到所述客户端设备的重传请求,所述重传请求为所述客户端设备在接收的数据报文的丢包率不小于丢包阈值时发送的请求;
当未接收到所述重传请求时,通过所述TCP连接向所述客户端设备持续传输数据报文,当接收到所述重传请求时,向所述客户端设备发送重传的数据报文。
根据本发明实施例的第三方面,提供一种报文传输装置,所述装置应用在用于实现直播业务的客户端设备上,所述装置包括:
建立单元,用于在所述客户端设备与服务器之间建立用于传输所述直播业务的数据报文的TCP连接;
接收单元,用于接收所述服务器通过所述TCP连接持续传输的数据报文;
判断单元,用于判断接收的数据报文的丢包率是否小于丢包阈值;
执行单元,用于当小于所述丢包阈值时,根据接收的数据报文直接播放所述直播业务;当不小于所述丢包阈值时,向所述服务器请求重传丢失的数据报文。
根据本发明实施例的第四方面,提供一种报文传输装置,所述装置应用在用于实现直播业务的服务器上,所述装置包括:
建立单元,用于在所述服务器与客户端设备之间建立用于传输所述直播业务的数据报文的TCP连接;
判断单元,用于判断是否接收到所述客户端设备的重传请求,所述重传请求为所述客户端设备在接收的数据报文的丢包率不小于丢包阈值时发送的请求;
执行单元,用于当未接收到所述重传请求时,通过所述TCP连接向所述客户端设备持续传输数据报文,当接收到所述重传请求时,向所述客户端设备发送重传的数据报文。
本发明实施例中,当客户端设备与服务器之间建立TCP连接后,服务器可以持续向客户端设备传输数据报文,而客户端设备在数据报文的丢包率小于丢包阈值时,无需请求重传数据报文,而是根据接收的数据报文直接播放直播业务,因此使得客户端设备在数据报文丢包较少时,避免了因为请求重传而产生的延迟,从而提高了直播业务的实时性。
附图说明
图1是应用本发明实施例实现直播业务的应用场景示意图;
图2是本发明报文传输方法的一个实施例流程图;
图3是本发明报文传输方法的另一个实施例流程图;
图4是本发明报文传输方法的另一个实施例流程图;
图5是本发明报文传输控制装置所在设备的一种硬件结构图;
图6是本发明报文传输装置的一个实施例框图;
图7是本发明报文传输装置的另一个实施例框图。
具体实施方式
为了使本技术领域的人员更好地理解本发明实施例中的技术方案,并使本发明实施例的上述目的、特征和优点能够更加明显易懂,下面结合附图对本发明实施例中技术方案作进一步详细的说明。
参见图1,为应用本发明实施例实现直播业务的应用场景示意图:
图1中,服务器作为数据报文发送方,客户端设备作为数据报文接收方,该客户端设备可以具体为手机、PC(Personal Computer,个人计算机)等。其中,客户端设备与服务器之间建立TCP连接后,通过接收服务器传输的数据报文实现直播业务。本发明实施例中,客户端设备可以无需在接收到数据报文时返回应答报文,因此服务器可以持续向客户端设备传输直播业务的数据报文,当客户端设备检测到数据报文的丢包率较小时,可以不请求重传数据报文,而是直接播放直播业务,从而在丢包率较小的情况下,客户端设备上的直播业务不会延迟,以此保证直播业务的实时性。
参见图2,为本发明报文传输方法的一个实施例流程图,该实施例从客户端设备侧进行描述,包括以下步骤:
步骤201:客户端设备与服务器之间建立用于传输直播业务的数据报文的TCP连接。
本实施例中,客户端设备与服务器之间可以采用现有方式完成TCP连接的建立,在此不再赘述。
步骤202:客户端设备接收服务器通过TCP连接持续传输的数据报文。
本实施例中,客户端设备可以预先与服务器协商报文传输非应答机制,即客户端设备接收服务器发送的TCP协商报文,该TCP协商报文的TCP选项中可以携带用于指示所述TCP协商报文的第一类型值,以及重传阈值,客户端设备可以根据该重传阈值确定丢包阈值,然后向服务器返回TCP协商应答报文,所述TCP协商应答报文中携带第一类型值,以使服务器根据该第一类型值确定与客户端设备协商成功。
协商成功后,客户端设备在接收到数据报文后,不再向服务器返回应答报文,而服务器可以在不接收应答报文的情况下,持续向客户端设备传输数据报文。
步骤203:客户端设备判断接收的数据报文的丢包率是否小于丢包阈值,若是,则执行步骤204;否则,执行步骤205。
本实施例中,客户端设备可以按照预设的传输周期对丢包率进行判断,在每个传输周期开始时,客户端设备接收服务器传输的TCP保活报文,该TCP保活报文的TCP选项中携带用于指示该TCP保活报文的第二类型值,以及该传输周期内首个数据报文的序列号;客户端设备将首个数据报文的序列号作为统计值的初始值,每接收到一个数据报文时,将统计值加一,当所述传输周期到达时,根据统计值获得传输周期内数据报文的实际接收数量,然后根据该传输周期内数据报文的实际接收数量和数据报文的应接收数量统计该传输周期内数据报文的丢包率。
步骤204:根据接收的数据报文直接播放直播业务,结束当前流程。
步骤205:向服务器请求重传丢失的数据报文,结束当前流程。
本实施例中,当客户端设备判断接收的数据报文的丢包率不小于丢包阈值时,说明当前客户端设备侧丢包率较高,因此客户端设备可以向服务器发送TCP重传请求报文,TCP重传请求报文的TCP选项中携带用于指示该TCP重传请求报文的第三类型值,以及请求重传的数据报文的重传序列号,并接收服务器根据重传序列号返回的数据报文。
由上述实施例可见,当客户端设备与服务器之间建立TCP连接后,服务器可以持续向客户端设备传输数据报文,而客户端设备在数据报文的丢包率小于丢包阈值时,无需请求重传数据报文,而是根据接收的数据报文直接播放直播业务,因此使得客户端设备在数据报文丢包较少时,避免了因为请求重传而产生的延迟,从而提高了直播业务的实时性。
参见图3,为本发明报文传输方法的另一个实施例流程图,该实施例从服务器侧进行描述,包括以下步骤:
步骤301:服务器与客户端设备之间建立用于传输直播业务的数据报文的TCP连接。
步骤302:判断是否接收到客户端设备的重传请求,若是,则执行步骤303;否则,执行步骤304。
所述重传请求为所述客户端设备在接收的数据报文的丢包率不小于丢包阈值时发送的请求
步骤303:通过TCP连接向客户端设备持续传输数据报文,结束当前流程。
步骤304:向所述客户端设备发送重传的数据报文,结束当前流程。
图3所示实施例与前述图2所示实施例的描述一致,其区别仅在于执行主体不同,在此不再赘述。
由上述实施例可见,当客户端设备与服务器之间建立TCP连接后,服务器可以持续向客户端设备传输数据报文,而客户端设备在数据报文的丢包率小于丢包阈值时,无需请求重传数据报文,而是根据接收的数据报文直接播放直播业务,因此使得客户端设备在数据报文丢包较少时,避免了因为请求重传而产生的延迟,从而提高了直播业务的实时性。
参见图4,为本发明报文传输方法的另一个实施例流程图,该实施例通过客户端设备与服务器之间的交互,详细描述了本发明实施例的报文传输过程:
步骤400:服务器与客户端设备之间建立TCP连接。
本实施例中,客户端设备与服务器之间可以采用现有技术中的三次握手过程完成TCP连接的建立,在此不再赘述。
步骤401:服务器向客户端设备发送TCP协商报文。
本实施例中,服务器上可以预先配置一条“TCP NO ACK”命令,即“传输非应答”命令。根据该命令,当客户端设备连接到服务器时,服务器与该客户端设备协商“传输非应答机制”,即客户端设备不向服务器返回数据报文的应答报文,而服务器持续传输数据报文。
在协商时,服务器首先向客户端设备发送TCP协商报文,该TCP协商报文中的TCP选项中携带用于指示该TCP协商报文的第一类型值和重传阈值。如下表1所示,为一种TCP协商报文中的TCP选项示例:
表1
类型值(TYPE) | 长度值(LENGTH) | 属性值(VALUE) |
01 | 4 | 10% |
上表1中,类型值“01”表示该TCP协商报文为协商“传输非应答”机制的报文,长度值“4”表示属性值长度为4个字节,属性值“10%”表示服务器初始确认的重传阈值,即数据报文的丢包率超过“10%”时重传数据报文。
需要说明的是,如果服务器与客户端设备之间基于现有的TCP重传应答机制传输数据报文,则可以在TCP协商报文的TCP选项中携带类型值“00”,以此实现本发明实施例对现有TCP传输机制的兼容。
步骤402:客户端设备根据重传阈值确定丢包阈值。
客户端设备接收到服务器传输的TCP协商报文后,当确定TCP选项的类型值为“01”时,则可知接收到的报文为协商“传输非应答机制”的TCP协商报文,因此客户端设备按照长度值“4”读取其中的属性值“10%”。
其中,客户端设备可以将服务器设置的重传阈值“10%”直接确定为丢包阈值;或者,客户端设备上也可以预先设置一个重传阈值,当获取到服务器设置的重传阈值后,从两个重传阈值中选择一个较小值确定为丢包阈值。
步骤403:客户端设备向服务器返回TCP协商应答报文,该TCP协商应答报文中携带第一类型值。
当客户端设备根据TCP协商报文确定采用“传输非应答机制”与服务器之间进行数据报文传输时,则客户端设备向服务器返回TCP协商应答报文,该TCP协商应答报文的TCP选项的类型值内写入“01”,表示协商成功。
步骤404:服务器根据第一类型值确定与客户端设备协商成功。
服务器接收到TCP协商应答报文后,读取该TCP协商应答报文的TCP选项的类型值为“01”,则可以确定与客户端设备协商成功,协商结果为服务器在未接收到数据报文的应答报文时,可以不间断地按照设置的传输速率向客户端设备传输数据报文。
步骤405:在每个传输周期开始时,服务器向客户端设备发送TCP保活报文,该TCP保活报文携带当前传输周期内首个数据报文的序列号。
本实施例中,客户端设备可以按照设置的传输周期对数据报文的丢包率进行检测,该传输周期可以由客户端设备与服务器之间预先设定,例如,每个传输周期为2分钟。
在每个传输周期开始时,服务器可以向客户端设备发送TCP保活报文,该TCP保活报文的TCP选项中携带用于指示该TCP保活报文的第二类型值和当前传输周期内所传输数据报文的首个报文序列号。如下表2所示,为一种TCP保活报文中的TCP选项示例:
表2
类型值(TYPE) | 长度值(LENGTH) | 属性值(VALUE) |
02 | x | 101 |
上表2中,类型值“02”表示该报文为TCP保活报文,长度值“x”表示属性值长度为x个字节,属性值“101”表示本传输周期内,服务器要发送的首个数据报文的序列号为“101”。
步骤406:服务器接收到客户端设备返回的TCP保活报文的应答报文。
步骤407:服务器向客户端设备持续传输数据报文。
结合表2示例,假设每个传输周期服务器传输100个数据报文,则在当前传输周期,服务器可以按照设置的传输速率持续向客户端设备传输从序列号“101”到序列号“200”的数据报文,直至到当前传输周期结束。在传输过程中,客户端设备接收到数据报文时,无需向服务器返回应答报文。
步骤408:客户端设备将首个数据报文的序列号作为统计值的初始值,每接收到一个数据报文时,将统计值加一。
步骤409:当传输周期到达时,客户端设备根据统计值获得该传输周期内数据报文的实际接收数量。
结合步骤407,在当前传输周期内,客户端设备获取到首个数据报文的序列号为“101”,则客户端设备将统计值从101开始,每接收到一个数据报文,统计值加1,当传输周期到达时,将统计值与首个数据报文的序列号的差值作为当前传输周期内数据报文的实际接收数量。
步骤410:客户端设备根据每个传输周期内数据报文的实际接收数量和数据报文的应接收数量统计每个传输周期内数据报文的丢包率。
本步骤中,客户端设备可以与服务器之间预先设定每个传输周期所传输的数据报文的数量,例如,每个传输周期传输100个报文,则“100”即为数据报文的应接收数量;或者,如果服务器传输的每个数据报文中都携带了序列号,则客户端可以根据当前传输周期内最后一个数据报文中携带的序列号与当前传输周期内首个数据报文的序列号的差值获得该应接收数量。
客户端设备在获得了每个传输周期内数据报文的应接收数量和实际接收数量后,可以按照如下公式统计数据报文的丢包率:
丢包率=Σ实际接收数量/Σ应接收数量
步骤411:客户端设备判断丢包率是否小于丢包阈值,若是,则执行步骤412;否则,执行步骤413。
步骤412:客户端设备根据接收的数据报文直接播放直播业务,结束当前流程。
当步骤411的判断结果为丢包率小于丢包阈值,则说明客户端设备在当前传输周期内仅有少量丢包,因此客户端设备可以不向服务器请求重传丢失的数据报文,而是根据接收的数据报文直接播放直播业务,虽然播放过程可能会因为少量丢包而造成跳帧,但是能够保证播放的实时性,不影响用户观看。
步骤413:客户端设备向服务器请求重传丢失的数据报文,结束当前流程。
当步骤411的判断结果为丢包率不小于丢包阈值,则说明客户端设备在当前传输周期内丢包较多,因此客户端设备可以向服务器请求重传丢失的数据报文。此时,客户端设备可以向服务器发送TCP重传请求报文,TCP重传请求报文的TCP选项中携带用于指示该TCP重传请求报文的第三类型值,以及请求重传的数据报文的重传序列号,并接收服务器根据重传序列号返回的数据报文。如下表3所示,为一种TCP重传请求报文中的TCP选项示例:
表3
类型值(TYPE) | 长度值(LENGTH) | 属性值(VALUE) |
03 | y | ****** |
上表3中,类型值“03”表示该报文为TCP重传请求报文,长度值“y”表示属性值长度为y个字节,属性值“******”表示本传输周期内需要重传的数据报文的序列号。
由上述实施例可见,当客户端设备与服务器之间建立TCP连接后,服务器可以持续向客户端设备传输数据报文,而客户端设备在数据报文的丢包率小于丢包阈值时,无需请求重传数据报文,而是根据接收的数据报文直接播放直播业务,因此使得客户端设备在数据报文丢包较少时,避免了因为请求重传而产生的延迟,从而提高了直播业务的实时性
与前述报文传输方法实施例相对应,本发明还提供了报文传输装置的实施例。
本发明报文传输装置的实施例可以分别应用在客户端设备和服务器上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图5所示,为本发明报文传输装置所在设备的一种硬件结构图,除了图5所示的处理器、网络接口、内存以及非易失性存储器之外,实施例中装置所在的设备通常还可以包括其他硬件,如负责处理报文的转发芯片等等;从硬件结构上来讲该设备还可能是分布式的设备,可能包括多个接口卡,以便在硬件层面进行报文处理的扩展。
参见图6,为本发明报文传输装置的一个实施例框图,所述装置应用在用于实现直播业务的客户端设备上,所述装置包括:建立单元610、接收单元620、判断单元630和执行单元640。
其中,建立单元610,用于在所述客户端设备与服务器之间建立用于传输所述直播业务的数据报文的TCP连接;
接收单元620,用于接收所述服务器通过所述TCP连接持续传输的数据报文;
判断单元630,用于判断接收的数据报文的丢包率是否小于丢包阈值;
执行单元640,用于当小于所述丢包阈值时,根据接收的数据报文直接播放所述直播业务;当不小于所述丢包阈值时,向所述服务器请求重传丢失的数据报文。
在一个可选的实现方式中:
所述装置还可以包括(图6中未示出):协商单元,用于与所述服务器协商报文传输非应答机制,以使所述客户端设备在协商成功后不向所述服务器返回数据报文的应答报文;相应的,所述接收单元620,可以具体用于接收所述服务器根据所述报文传输非应答机制,通过所述TCP连接向所述客户端设备持续传输的数据报文。
在另一个可选的实现方式中:
所述协商单元可以包括:报文接收子单元,用于接收所述服务器发送的TCP协商报文,所述TCP协商报文的TCP选项中携带用于指示所述TCP协商报文的第一类型值,以及重传阈值;阈值确定子单元,用于根据所述重传阈值确定所述丢包阈值;报文应答子单元,用于向所述服务器返回TCP协商应答报文,所述TCP协商应答报文中携带所述第一类型值,以使所述服务器根据所述第一类型值确定与所述客户端设备协商成功。
在另一个可选的实现方式中:
所述接收单元620,还可以用于在每个传输周期开始时,接收所述服务器传输的TCP保活报文,所述TCP保活报文的TCP选项中携带用于指示所述TCP保活报文的第二类型值,以及所述传输周期内首个数据报文的序列号;
相应的,所述判断单元630可以包括(图6中未示出):丢包率获得子单元,用于根据所述TCP保活报文获得每个传输周期内接收的数据报文的丢包率;丢包阈值判断子单元,用于按照所述传输周期判断丢包率是否小于丢包阈值。
在另一个可选的实现方式中:
所述丢包率获得子单元可以包括:序列号统计模块,用于在每个传输周期内,将所述首个数据报文的序列号作为统计值的初始值,每接收到一个数据报文时,将所述统计值加一;报文数量获得模块,用于当所述传输周期到达时,根据所述统计值获得所述传输周期内数据报文的实际接收数量;
丢包率统计模块,用于根据所述传输周期内数据报文的实际接收数量和所述数据报文的应接收数量统计所述传输周期内数据报文的丢包率。
在另一个可选的实现方式中:
所述执行单元640可以包括(图6中未示出):重传请求子单元,用于向所述服务器发送TCP重传请求报文,所述TCP重传请求报文的TCP选项中携带用于指示所述TCP重传请求报文的第三类型值,以及请求重传的数据报文的重传序列号;重传接收子单元,用于接收所述服务器根据所述重传序列号返回的数据报文。
参见图7,为本发明报文传输装置的另一个实施例框图,所述装置应用在用于实现直播业务的服务器上,所述装置包括:建立单元710、判断单元720和执行单元730。
其中,建立单元710,用于在所述服务器与客户端设备之间建立用于传输所述直播业务的数据报文的TCP连接;
判断单元720,用于判断是否接收到所述客户端设备的重传请求,所述重传请求为所述客户端设备在接收的数据报文的丢包率不小于丢包阈值时发送的请求;
执行单元730,用于当未接收到所述重传请求时,通过所述TCP连接向所述客户端设备持续传输数据报文,当接收到所述重传请求时,向所述客户端设备发送重传的数据报文。
在一个可选的实现方式中:
所述装置还可以包括(图7中未示出):协商单元,用于与所述客户端设备协商报文传输非应答机制,以使所述客户端设备在协商成功后不向所述服务器返回数据报文的应答报文;相应的,所述执行单元730,可以具体用于根据所述报文传输非应答机制,通过所述TCP连接向所述客户端设备持续传输数据报文。
在另一个可选的实现方式中:
所述协商单元可以包括:报文发送子单元,用于向所述客户端设备发送TCP协商报文,所述TCP协商报文的TCP选项中携带用于指示所述TCP协商报文的第一类型值,以及重传阈值,以使所述客户端设备根据所述重传阈值确定所述丢包阈值;协商确认子单元,用于当接收到所述客户端设备返回的TCP协商应答报文后,根据所述TCP协商应答报文中携带的所述第一类型值确定与所述客户端设备协商成功。
在另一个可选的实现方式中:
所述装置还可以包括(图7中未示出):传输单元,用于在每个传输周期开始时,向所述客户端设备传输TCP保活报文,所述TCP保活报文的TCP选项中携带用于指示所述TCP保活报文的第二类型值,以及所述传输周期内首个数据报文的序列号,以使所述客户端设备根据所述TCP保活报文获得每个传输周期内接收的数据报文的丢包率,并按照所述传输周期判断丢包率是否小于丢包阈值。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本发明方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
由上述实施例可见,当客户端设备与服务器之间建立TCP连接后,服务器可以持续向客户端设备传输数据报文,而客户端设备在数据报文的丢包率小于丢包阈值时,无需请求重传数据报文,而是根据接收的数据报文直接播放直播业务,因此使得客户端设备在数据报文丢包较少时,避免了因为请求重传而产生的延迟,从而提高了直播业务的实时性。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本发明的真正范围和精神由下面的权利要求指出。
应当理解的是,本发明并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。
Claims (20)
1.一种报文传输方法,所述方法应用在用于实现直播业务的客户端设备上,所述客户端设备与服务器之间建立用于传输所述直播业务的数据报文的TCP连接,其特征在于,所述方法包括:
接收所述服务器通过所述TCP连接持续传输的数据报文;
判断接收的数据报文的丢包率是否小于丢包阈值;
当小于所述丢包阈值时,根据接收的数据报文直接播放所述直播业务;当不小于所述丢包阈值时,向所述服务器请求重传丢失的数据报文。
2.根据权利要求1所述的方法,其特征在于,所述接收所述服务器通过所述TCP连接持续传输的数据报文之前,所述方法还包括:
与所述服务器协商报文传输非应答机制,以使所述客户端设备在协商成功后不向所述服务器返回数据报文的应答报文;
所述接收所述服务器通过所述TCP连接持续传输的数据报文包括:接收所述服务器根据所述报文传输非应答机制,通过所述TCP连接向所述客户端设备持续传输的数据报文。
3.根据权利要求2所述的方法,其特征在于,所述与所述服务器协商报文传输非应答机制包括:
接收所述服务器发送的TCP协商报文,所述TCP协商报文的TCP选项中携带用于指示所述TCP协商报文的第一类型值,以及重传阈值;
根据所述重传阈值确定所述丢包阈值;
向所述服务器返回TCP协商应答报文,所述TCP协商应答报文中携带所述第一类型值,以使所述服务器根据所述第一类型值确定与所述客户端设备协商成功。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括:
在每个传输周期开始时,接收所述服务器传输的TCP保活报文,所述TCP保活报文的TCP选项中携带用于指示所述TCP保活报文的第二类型值,以及所述传输周期内首个数据报文的序列号;
所述判断接收的数据报文的丢包率是否小于丢包阈值包括:
根据所述TCP保活报文获得每个传输周期内接收的数据报文的丢包率;
按照所述传输周期判断丢包率是否小于丢包阈值。
5.根据权利要求4所述的方法,其特征在于,所述根据所述TCP保活报文获得每个传输周期内接收的数据报文的丢包率包括:
在每个传输周期内,将所述首个数据报文的序列号作为统计值的初始值,每接收到一个数据报文时,将所述统计值加一;
当所述传输周期到达时,根据所述统计值获得所述传输周期内数据报文的实际接收数量;
根据所述传输周期内数据报文的实际接收数量和所述数据报文的应接收数量统计所述传输周期内数据报文的丢包率。
6.根据权利要求1至5任一所述的方法,其特征在于,所述向所述服务器请求重传丢失的数据报文包括:
向所述服务器发送TCP重传请求报文,所述TCP重传请求报文的TCP选项中携带用于指示所述TCP重传请求报文的第三类型值,以及请求重传的数据报文的重传序列号;
接收所述服务器根据所述重传序列号返回的数据报文。
7.一种报文传输方法,所述方法应用在用于实现直播业务的服务器上,所述服务器与客户端设备之间建立用于传输所述直播业务的数据报文的TCP连接,其特征在于,所述方法包括:
判断是否接收到所述客户端设备的重传请求,所述重传请求为所述客户端设备在接收的数据报文的丢包率不小于丢包阈值时发送的请求;
当未接收到所述重传请求时,通过所述TCP连接向所述客户端设备持续传输数据报文,当接收到所述重传请求时,向所述客户端设备发送重传的数据报文。
8.根据权利要求7所述的方法,其特征在于,所述方法还包括:
与所述客户端设备协商报文传输非应答机制,以使所述客户端设备在协商成功后不向所述服务器返回数据报文的应答报文;
所述通过所述TCP连接向所述客户端设备持续传输数据报文包括:根据所述报文传输非应答机制,通过所述TCP连接向所述客户端设备持续传输数据报文。
9.根据权利要求8所述的方法,其特征在于,所述与所述客户端设备协商报文传输非应答机制包括:
向所述客户端设备发送TCP协商报文,所述TCP协商报文的TCP选项中携带用于指示所述TCP协商报文的第一类型值,以及重传阈值,以使所述客户端设备根据所述重传阈值确定所述丢包阈值;
当接收到所述客户端设备返回的TCP协商应答报文后,根据所述TCP协商应答报文中携带的所述第一类型值确定与所述客户端设备协商成功。
10.根据权利要求7至9任一所述的方法,其特征在于,所述方法还包括:
在每个传输周期开始时,向所述客户端设备传输TCP保活报文,所述TCP保活报文的TCP选项中携带用于指示所述TCP保活报文的第二类型值,以及所述传输周期内首个数据报文的序列号,以使所述客户端设备根据所述TCP保活报文获得每个传输周期内接收的数据报文的丢包率,并按照所述传输周期判断丢包率是否小于丢包阈值。
11.一种报文传输装置,所述装置应用在用于实现直播业务的客户端设备上,其特征在于,所述装置包括:
建立单元,用于在所述客户端设备与服务器之间建立用于传输所述直播业务的数据报文的TCP连接;
接收单元,用于接收所述服务器通过所述TCP连接持续传输的数据报文;
判断单元,用于判断接收的数据报文的丢包率是否小于丢包阈值;
执行单元,用于当小于所述丢包阈值时,根据接收的数据报文直接播放所述直播业务;当不小于所述丢包阈值时,向所述服务器请求重传丢失的数据报文。
12.根据权利要求11所述的装置,其特征在于,所述装置还包括:
协商单元,用于与所述服务器协商报文传输非应答机制,以使所述客户端设备在协商成功后不向所述服务器返回数据报文的应答报文;
所述接收单元,具体用于接收所述服务器根据所述报文传输非应答机制,通过所述TCP连接向所述客户端设备持续传输的数据报文。
13.根据权利要求12所述的装置,其特征在于,所述协商单元包括:
报文接收子单元,用于接收所述服务器发送的TCP协商报文,所述TCP协商报文的TCP选项中携带用于指示所述TCP协商报文的第一类型值,以及重传阈值;
阈值确定子单元,用于根据所述重传阈值确定所述丢包阈值;
报文应答子单元,用于向所述服务器返回TCP协商应答报文,所述TCP协商应答报文中携带所述第一类型值,以使所述服务器根据所述第一类型值确定与所述客户端设备协商成功。
14.根据权利要求11所述的装置,其特征在于,
所述接收单元,还用于在每个传输周期开始时,接收所述服务器传输的TCP保活报文,所述TCP保活报文的TCP选项中携带用于指示所述TCP保活报文的第二类型值,以及所述传输周期内首个数据报文的序列号;
所述判断单元包括:
丢包率获得子单元,用于根据所述TCP保活报文获得每个传输周期内接收的数据报文的丢包率;
丢包阈值判断子单元,用于按照所述传输周期判断丢包率是否小于丢包阈值。
15.根据权利要求14所述的装置,其特征在于,所述丢包率获得子单元包括:
序列号统计模块,用于在每个传输周期内,将所述首个数据报文的序列号作为统计值的初始值,每接收到一个数据报文时,将所述统计值加一;
报文数量获得模块,用于当所述传输周期到达时,根据所述统计值获得所述传输周期内数据报文的实际接收数量;
丢包率统计模块,用于根据所述传输周期内数据报文的实际接收数量和所述数据报文的应接收数量统计所述传输周期内数据报文的丢包率。
16.根据权利要求11至15任一所述的装置,其特征在于,所述执行单元包括:
重传请求子单元,用于向所述服务器发送TCP重传请求报文,所述TCP重传请求报文的TCP选项中携带用于指示所述TCP重传请求报文的第三类型值,以及请求重传的数据报文的重传序列号;
重传接收子单元,用于接收所述服务器根据所述重传序列号返回的数据报文。
17.一种报文传输装置,其特征在于,所述装置应用在用于实现直播业务的服务器上,所述装置包括:
建立单元,用于在所述服务器与客户端设备之间建立用于传输所述直播业务的数据报文的TCP连接;
判断单元,用于判断是否接收到所述客户端设备的重传请求,所述重传请求为所述客户端设备在接收的数据报文的丢包率不小于丢包阈值时发送的请求;
执行单元,用于当未接收到所述重传请求时,通过所述TCP连接向所述客户端设备持续传输数据报文,当接收到所述重传请求时,向所述客户端设备发送重传的数据报文。
18.根据权利要求17所述的装置,其特征在于,所述装置还包括:
协商单元,用于与所述客户端设备协商报文传输非应答机制,以使所述客户端设备在协商成功后不向所述服务器返回数据报文的应答报文;
所述执行单元,具体用于根据所述报文传输非应答机制,通过所述TCP连接向所述客户端设备持续传输数据报文。
19.根据权利要求18所述的装置,其特征在于,所述协商单元包括:
报文发送子单元,用于向所述客户端设备发送TCP协商报文,所述TCP协商报文的TCP选项中携带用于指示所述TCP协商报文的第一类型值,以及重传阈值,以使所述客户端设备根据所述重传阈值确定所述丢包阈值;
协商确认子单元,用于当接收到所述客户端设备返回的TCP协商应答报文后,根据所述TCP协商应答报文中携带的所述第一类型值确定与所述客户端设备协商成功。
20.根据权利要求17至19任一所述的装置,其特征在于,所述装置还包括:
传输单元,用于在每个传输周期开始时,向所述客户端设备传输TCP保活报文,所述TCP保活报文的TCP选项中携带用于指示所述TCP保活报文的第二类型值,以及所述传输周期内首个数据报文的序列号,以使所述客户端设备根据所述TCP保活报文获得每个传输周期内接收的数据报文的丢包率,并按照所述传输周期判断丢包率是否小于丢包阈值。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410306557.8A CN104038845B (zh) | 2014-06-30 | 2014-06-30 | 报文传输方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410306557.8A CN104038845B (zh) | 2014-06-30 | 2014-06-30 | 报文传输方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104038845A CN104038845A (zh) | 2014-09-10 |
CN104038845B true CN104038845B (zh) | 2017-10-17 |
Family
ID=51469411
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410306557.8A Active CN104038845B (zh) | 2014-06-30 | 2014-06-30 | 报文传输方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104038845B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111309363A (zh) * | 2020-03-07 | 2020-06-19 | 重庆邮电大学 | 基于Contiki操作系统的在线升级方法及装置 |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104378677B (zh) * | 2014-11-19 | 2017-06-20 | 青岛海信网络科技股份有限公司 | 一种车载终端视频切换控制方法 |
CN106411894A (zh) * | 2016-09-29 | 2017-02-15 | 天脉聚源(北京)传媒科技有限公司 | 一种视频传输方法及系统 |
CN106332145A (zh) * | 2016-10-04 | 2017-01-11 | 陕西尚品信息科技有限公司 | 一种移动Ad‑hoc网络中TCP连接性能的优化方法 |
CN108076381B (zh) * | 2016-11-11 | 2020-10-16 | 华为技术有限公司 | 视频显示方法、视频转发设备及系统 |
CN108243171B (zh) * | 2016-12-27 | 2020-12-22 | 北京新唐思创教育科技有限公司 | 在线直播互动系统及方法 |
CN107547302B (zh) * | 2017-06-22 | 2020-10-09 | 新华三技术有限公司 | 网络质量评估方法及装置 |
CN110418199B (zh) * | 2018-04-26 | 2023-03-03 | 视联动力信息技术股份有限公司 | 一种基于视联网的信息处理方法及系统 |
CN114095796A (zh) * | 2020-07-30 | 2022-02-25 | 中国移动通信集团终端有限公司 | 无效重传包减少方法、装置、设备及计算机存储介质 |
CN115065442B (zh) * | 2022-08-16 | 2022-11-18 | 深圳星云智联科技有限公司 | 数据传输方法及相关装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101222311A (zh) * | 2008-01-29 | 2008-07-16 | 杭州华三通信技术有限公司 | 实时报文丢包恢复方法、系统及接收端单元 |
CN101729228A (zh) * | 2008-10-31 | 2010-06-09 | 华为技术有限公司 | 丢包抑制重传的方法、网络节点和系统 |
CN103780971A (zh) * | 2012-10-23 | 2014-05-07 | 北京网动网络科技股份有限公司 | 一种互联网条件下基于rudp的实时视频传输方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5292444B2 (ja) * | 2011-02-17 | 2013-09-18 | 日本電信電話株式会社 | パケットロス率推定装置及び方法及びプログラム |
-
2014
- 2014-06-30 CN CN201410306557.8A patent/CN104038845B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101222311A (zh) * | 2008-01-29 | 2008-07-16 | 杭州华三通信技术有限公司 | 实时报文丢包恢复方法、系统及接收端单元 |
CN101729228A (zh) * | 2008-10-31 | 2010-06-09 | 华为技术有限公司 | 丢包抑制重传的方法、网络节点和系统 |
CN103780971A (zh) * | 2012-10-23 | 2014-05-07 | 北京网动网络科技股份有限公司 | 一种互联网条件下基于rudp的实时视频传输方法 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111309363A (zh) * | 2020-03-07 | 2020-06-19 | 重庆邮电大学 | 基于Contiki操作系统的在线升级方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN104038845A (zh) | 2014-09-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104038845B (zh) | 报文传输方法及装置 | |
CN110995697B (zh) | 一种大数据传输方法及系统 | |
US20200358886A1 (en) | Data Transmission Method, Apparatus, And System | |
US8281202B2 (en) | Method and apparatus for improving transmission time interval bundling | |
CN105871736A (zh) | 一种封包低延迟传输方法 | |
CN103269260A (zh) | 数据传输方法、数据接收端、数据发送端和数据传输系统 | |
US20060155870A1 (en) | Connectionless protocol | |
US8984158B2 (en) | Data communication system and method | |
JP5185955B2 (ja) | 物理伝送媒体が中断した場合のtcpデータ伝送プロセスを改善する方法 | |
CN112436924B (zh) | 一种数据传输方法及电子设备 | |
CN111294664A (zh) | 音视频传输数据方法、电子设备及存储介质 | |
Natarajan et al. | SCTP: What, why, and how | |
CN112565441A (zh) | 一种数据通信方法及电子设备 | |
CN114500528A (zh) | 一种基于云平台的数据传输方法及装置 | |
CN105227276A (zh) | 一种基于udt的对等网络数据传输方法 | |
CN114390054A (zh) | 一种核心网网络加速方法、电子设备及计算机存储介质 | |
CN107493260A (zh) | 用于数据传输的自适应段尺寸的装置、系统和方法 | |
CN106411677A (zh) | 一种确定vpn数据通道的最优mtu的方法和装置 | |
JP4506430B2 (ja) | アプリケーションモニタ装置 | |
CN104012054A (zh) | 视频处理方法、设备及系统 | |
CN116963175A (zh) | 数据传输方法、装置及系统 | |
CN105991348B (zh) | Tcp连接关闭方法及装置 | |
EP1427127A2 (en) | Communication control method, communication system and communication apparatus that can improve throughput | |
WO2017067224A1 (zh) | 一种报文处理方法及装置 | |
CN116032998A (zh) | 数据传输方法、装置、计算机可读存储介质及电子设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information | ||
CB02 | Change of applicant information |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant after: Xinhua three Technology Co., Ltd. Address before: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant before: Huasan Communication Technology Co., Ltd. |
|
GR01 | Patent grant | ||
GR01 | Patent grant |