CN104717259A - 分布式中转服务器网络辅助的多路径数据传输系统与方法 - Google Patents

分布式中转服务器网络辅助的多路径数据传输系统与方法 Download PDF

Info

Publication number
CN104717259A
CN104717259A CN201310689342.4A CN201310689342A CN104717259A CN 104717259 A CN104717259 A CN 104717259A CN 201310689342 A CN201310689342 A CN 201310689342A CN 104717259 A CN104717259 A CN 104717259A
Authority
CN
China
Prior art keywords
data
field
message
ctl
channel
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
Application number
CN201310689342.4A
Other languages
English (en)
Other versions
CN104717259B (zh
Inventor
尤佳莉
郑鹏飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhengzhou Xinrand Network Technology Co ltd
Original Assignee
Institute of Acoustics CAS
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Institute of Acoustics CAS filed Critical Institute of Acoustics CAS
Priority to CN201310689342.4A priority Critical patent/CN104717259B/zh
Publication of CN104717259A publication Critical patent/CN104717259A/zh
Application granted granted Critical
Publication of CN104717259B publication Critical patent/CN104717259B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明涉及一种分布式中转服务器网络辅助的多路径数据传输系统,包括:索引服务器、中转服务器和客户端;索引服务器、中转服务器与客户端之间通过网络连接;中转服务器有多个,形成一中转服务器覆盖网;各个模块在管理和数据两个层面上进行交流与通信,在管理层面上实现与中转服务器覆盖网相关的信息查询、信息管理服务;在数据层面上实现客户端之间进行的数据传输,为每一条客户端之间的连接建立数据传输通道并提供数据传输服务;索引服务器位于管理层面上,用于承担中转服务器覆盖网的管理职责;中转服务器在管理层面上接受索引服务器的管理,在数据层面上负责为传输通道中转数据;客户端位于数据层面,是用户实现数据传输的接口。

Description

分布式中转服务器网络辅助的多路径数据传输系统与方法
技术领域
本发明涉及计算机网络通信领域,特别涉及一种分布式中转服务器网络辅助的多路径数据传输系统与方法。
背景技术
当前Internet所依赖的数据传输协议存在这些缺陷:不能实时反映链路状态的改变,在遭遇链路故障时,需要的故障恢复时间较长;两个节点之间的数据传输路径通常不是最优的;当存在多条传输路径时,通常只能利用其中的一条进行传输,不能最大化利用网络能力。
从底层开始重新设计Internet会导致现存的绝大部分软件需要重新设计,几乎是不现实的,同时,覆盖网络(Overlay Network)提供了改善问题的另外一个途径。覆盖网络是在其他网络之上部署虚拟网络系统,其中节点通过逻辑链路建立连接,一条逻辑链路对应于一条或多条底层网络链路。分布式系统如云计算(Cloud Computing)、P2P网络、内容分发网络(Content Delivery Network)、应用层组播(Application LayerMulticast)等都是覆盖网络,因为它们部署于Internet之上。而Internet本身也可以认为是一个覆盖网络,因为它部署于电话网络之上。我们通常所说的覆盖网络一般都是指Internet之上的应用层网络。覆盖网络具有很强的灵活性,应用可以根据环境和需求定义自己的拓扑结构和路由协议,构建特定于应用的服务,从而大大扩展了Internet的服务。
许多学者提出了通过覆盖网络来提高应用程序数据包传输效率的方法,这些方法在网络的一些位置上部署流量中转节点,通过精心设计的覆盖路由(OverlayRouting)方案来决定数据包通过这些中转节点的转发路径,从而达到规避故障路径,提高传输效率的目的。
许多文献从理论上验证了这种思想的可行性,它们收集了大量的Internet真实数据,从RTT、丢包率、带宽等传输性能参数出发,对比了Internet默认路径和经过中间节点转发数据包的替代路径,得出以下结论:30%~80%的情况下,存在至少一条替代路径能够显著提高传输性能;在大多数情况下,只需要至多一跳中间节点就能够恢复60%~100%的Internet链路故障,平均恢复时间是18s,而Internet所需要的恢复时间一般长达几分钟。
虽然从理论上验证了这种思想的可行性,但是这种思想从来没有真正的付诸实践过。大部分方法都要求每一个中转节点获知覆盖网中所有其它可用中转节点的信息,在建立中转路径时进行计算,选出最合适的节点建立中转传输路径。大规模应用时,要满足这一要求所需要的计算量是不可接受的。多数方法在计算合适的中转节点时,要求获取Internet底层的自治系统(Autonomous System)信息、路由表、网络拓扑等信息,这就违反了Internet网络分层的原则。还有一些方法需要对TCP(Transmission Control Protocol)协议和网络设备进行修改,导致了方法不具有普适性,很难在Internet上得到推广。
发明内容
本发明的目的在于克服现有技术中的路由方法计算量大或不具有普适性的缺陷,从而提供一种分布式中转服务器网络辅助的多路径数据传输系统与方法。
为了实现上述目的,本发明提供了一种分布式中转服务器网络辅助的多路径数据传输系统,包括:索引服务器、中转服务器和客户端;所述索引服务器、中转服务器与客户端之间通过网络连接;所述的中转服务器有多个,分别位于网络的关键路径上,形成一中转服务器覆盖网;其中,
系统中的各个模块在管理和数据两个层面上进行交流与通信,在管理层面上实现与中转服务器覆盖网相关的信息查询、信息管理服务,模块在该层面中的通信使用安全、可靠、易于理解、易于扩展的传输协议,包括HTTP、HTML、XML、SOAP、JSON中的任意一个;在数据层面上实现客户端之间进行的数据传输,为每一条客户端之间的连接建立数据传输通道并提供数据传输服务,模块在数据层面中的通信使用基于UDP协议扩展的多路径数据传输协议;
所述索引服务器位于管理层面上,用于承担中转服务器覆盖网的管理职责;
所述中转服务器在管理层面上接受所述索引服务器的管理,在数据层面上负责为传输通道中转数据;
所述客户端位于数据层面,是用户实现数据传输的接口。
上述技术方案中,所述索引服务器用于:维护所述中转服务器的信息,每一个活跃的中转服务器都必须定期向其汇报服务器的状态;根据客户端的请求,为其计算并选择一些中转服务器,供客户端作为建立传输通道时候选的中转传输节点。
上述技术方案中,所述中转服务器用于:在管理层面上,监测包括本服务器可用的网络资源数量、负载、当前已建立的中转连接数、服务器的位置在内的多种信息,并定期向索引服务器汇报;在数据层面上,监听来自客户端的数据包,并负责转发。
上述技术方案中,所述客户端包括接收端和发送端,其中,在一条连接中,主动发起通道的客户端是发送端,被动接收通道的客户端是接收端;
所述发送端向所述索引服务器请求候选中转服务器的列表,当与数据接收端建立连接时,根据预设的策略从该列表中选出一部分中转服务器,向它们发起传输通道建立请求;在数据传输的过程中,发送端能够根据传输通道的状态,动态地增加、删除、替换掉传输通道。
上述技术方案中,一条连接的标识方式为:“发送端IP地址、发送端端口号、接收端IP地址、接收端端口号”;连接中的数据传输通道的标识方式为:“发送端IP地址、发送端端口号、接收端IP地址、接收端端口号、通道编号”。
上述技术方案中,每一条客户端之间的连接包含至少一个数据传输通道,每一个数据传输通道使用最多一跳中转服务器作为中转传输节点,且该连接中有且仅有一个不使用中转传输节点的数据传输通道。
上述技术方案中,所述基于UDP协议扩展的多路径数据传输协议中包括数据报文和控制报文;所述数据报文用于传输实际数据,所述控制报文用于传输控制消息;其中,
所述数据报文包括数据报文头部和所要传输的数据;数据报文头部包括以下字段:第0个bit用于指示报文是否为数据报文;第1个bit为R标志位;第2~7bit保留未用;第8~11bit为IPVer字段;第12~15bit为Shift字段;第16~31bit为Window字段;第32~47bit为Port字段;第48~63bit为Channel ID,是通道编号;第64~95bit为Channel Sequence Number,是通道字节流序列号;第96~127bit为SequenceNumber,是连接字节流序列号;第128~159bit为Time Stamp,是时间戳;最后是对端的地址Address,取决于IPVer指示的IP协议版本号,为32bit或者128bit;
所述控制报文包括控制报文头部和附加信息;控制报文头部包括:第0个bit为标识符,值为1时表示这个报文为控制报文;第1~7bit为Control Type字段,指示控制报文类型;第8~11bit为IPVer字段,标识报文头内的IP地址是IPv4还是IPv6;第12~15bit为Shift字段,指定Window字段的左移量,取值0~14;第16~31bit为Window字段,用于通知数据传输另一方可用的接收窗口大小;第32~47bit为Port字段,是对端的端口;第48~63bit为Channel ID,是通道编号;第64~95bit为Field1字段,由控制报文解释;第96~127bit为Field 2字段,由控制报文解释;第128~159bit为Time Stamp,是时间戳;最后是对端的地址Address,取决于IPVer指示的IP协议版本号,为32bit或者128bit;附加信息字段由控制报文类型决定其包含的实际信息;
根据Control Type的数值,控制报文可分为:
0x1,CTL_CONNECT:通道握手报文,由发送端在通道建立时发送;Field 1是通道发送端初始字节流编号,Field 2是连接发送端初始字节流编号,AdditionalInformation包含最大分节大小信息;
0x2,CTL_CONNECT_ACK:连接回复报文,由接收端在收到CTL_CONNECT时回复使用;Field 1是通道发送端初始字节流编号,Field 2是连接发送端初始字节流编号,Additional Information除了包含MSS信息外,还包括相应CTL_CONNECT报文的两个初始字节流编号;
0x3,CTL_ACK:ACK报文,用于确认已接收到的数据;Field 1是通道累积字节流序列号,Field 2是连接累积字节流序列号,Additional Information无数据;
0x4,CTL_NAK:NAK报文,用于确认丢失的数据,供数据发送方重传;Field1是通道累积字节流序列号,Field 2是连接累积字节流序列号,Additional Information包含一组序列号范围,每两个序列号表示一个丢失范围“范围起始序列号,范围终止序列号+1”,序列号都是连接字节流序列号或通道字节流序列号;
0x5,CTL_CLOSE_CHANNEL:通道关闭报文,用于发送端关闭通道;Field 1、Field 2、Additional Information无定义;
0x6,CTL_CLOSE_CHANNEL_ACK:通道关闭ACK,用于接收端回复CTL_CLOSE_CHANNEL;Field 1、Field 2、Additional Information无定义;
0x7,CTL_CLOSE_CHANNEL_ACK2:通道关闭ACK的ACK,用于发送端回复CTL_CLOSE_CHANNEL_ACK;Field 1、Field 2、Additional Information无定义;
0x8,CTL_CLOSE_CONNECTION:连接关闭报文,用于直接关闭连接,可以由发送端或接收端发起;Field 1、Field 2、Additional Information无定义;
0x9,CTL_CLOSE_CONNECTION_ACK:连接关闭ACK,用于回复CTL_CLOSE_CONNECTION;Field 1、Field 2、Additional Information无定义;
0x10,CTL_CLOSE_CONNECTION_ACK2:连接关闭ACK的ACK,用于发送端回复CTL_CLOSE_CONNECTION_ACK;Field 1、Field 2、Additional Information无定义;
0x11,CTL_KEEP_ALIVE:通道保活报文,Field 1、Field 2、Additional Information无定义;
0x3ff,CTL_ERROR,错误信息报文,Field 1定义错误代号,Field 2、AdditionalInformation由相关错误填写;
0x11~0xff:协议保留报文类型编号,用于未来扩展;
0x100~0x2ff:上层应用自定义报文。
本发明还提供了在所述的分布式中转服务器网络辅助的多路径数据传输系统上实现的数据传输方法,用于在不通过中转服务器,发送端与接收端之间直接进行数据传输的数据传输通道上传输数据包,包括:
步骤301)、数据发送方构造数据包,所构造数据包中的Address字段为接收地址,Port字段为接收端端口,此外,该数据包中还带有用于指示第一类通道的相关标记,如通道编号为一特殊值;
步骤302)、数据接收方收到数据包后,通过数据包IP协议部分的源地址和源端口判断是否属于本连接,若属于,则进一步判断数据包各项字段的有效性,提取并缓存数据报文的有效数据,最后发送ACK或NAK报文应答。
本发明又提供了在所述的分布式中转服务器网络辅助的多路径数据传输系统上实现的数据传输方法,用于在发送端与接收端之间通过中转服务器建立的数据传输通道上传输数据包,包括:
步骤401)、数据发送方构造数据包,所构造数据包中的Address字段为接收地址,Port字段为接收端端口;
步骤402)、数据包到达通道使用的中转服务器,中转服务器提取数据包Address和Port字段获得数据接收方的地址和端口号,并将两个字段改写成发送端地址和端口号,接下来,数据包被发送给接收端;
步骤403)、数据接收方收到数据包,根据Address字段和Port字段判断数据包是否处于本连接,以及通道编号是否合法;若属于本连接且通道编号合法,则进一步判断数据包各项字段的有效性,提取并缓存数据报文的有效数据,最后发送ACK或NAK报文应答。
本发明的优点在于:
本发明的多路径数据传输方法使用独立的管理系统管理分布式的中转服务器,为客户端提供候选的中转服务器,从而减轻客户端的计算负担,该方法同时设计了能够提供可靠数据传输的基于UDP的多路径数据传输协议。
附图说明
图1是本发明的多路径数据传输系统的结构示意图;
图2是数据报文的数据结构示意图;
图3是控制报文的数据结构示意图。
具体实施方式
现结合附图对本发明作进一步的描述。
本申请人通过研究对网络传输有以下认识:由于评价一条覆盖路径的指标并不是唯一的,因此,即使穷尽所有的可能选择也不一定能选出“最优”的中转传输路径,事实上,大部分时候只需要寻找“满意”的路径即可,因此,完全可以在计算中转路径时,只计算部分中转节点,然后在传输过程中通过测得的性能参数再进行调整;相比TCP协议,UDP(User Datagram Protocol)协议只提供最简单的不可靠信息传送服务,不保证数据包的传输顺序,也不保证数据包能够一定到达接收端,虽然这种特征导致该协议不如TCP运用广泛,但是基于UDP协议进行扩展,为其添加必要的特性,却可以避免直接修改操作系统的网络协议栈和网络设备,使本发明具有普适性。
参考图1,本发明的多路径数据传输系统包括索引服务器、中转服务器和客户端;所述索引服务器、中转服务器与客户端之间通过网络连接。该系统中的各个模块分别在管理和数据两个层面上进行交流与通信,在管理层面上主要实现中转服务器覆盖网络相关的信息查询、信息管理服务,模块在该层面中的通信可使用安全、可靠、易于理解、易于扩展的传输协议,如HTTP、HTML、XML、SOAP、JSON等协议;在数据层面上主要实现客户端之间进行的数据传输,为每一条客户端之间的连接建立多条传输通道,提供可靠数据传输服务,模块在该层面中的通信使用基于UDP协议扩展的多路径数据传输协议。
下面分别对系统中的各个模块的功能进行说明。
所述索引服务器用于承担中转服务器覆盖网的管理职责,其位于管理层面。主要职能包括:维护系统中的中转服务器的信息,每一个活跃的中转服务器都必须定期向其汇报服务器的状态;根据客户端的请求,为其计算并选择一些中转服务器,供客户端作为建立传输通道时候选的中转传输节点。
所述中转服务器在管理层面上接受所述索引服务器的管理,在数据层面上负责为传输通道中转数据。主要职能包括:在管理层面上,监测本服务器可用的网络资源数量、负载、当前已建立的中转连接数、服务器的位置等信息,定期向索引服务器汇报;在数据层面上,监听来自客户端的数据包,并负责转发。一般地,为了保证传输通道的性能,所述中转服务器应该具有较高的网络吞吐量和较多的空闲网络资源,并位于Internet的关键路径上。所述中转服务器的数目一般有多个。
所述客户端是用户实现数据传输的接口,其位于数据层面。客户端可以进一步分为接收端和发送端,其划分原则是:一条连接中,主动发起通道的客户端是发送端,被动接收通道的客户端是接收端。发送端(定期或者在需要时)向所述索引服务器请求候选中转服务器的列表,当与数据接收端建立连接时,根据预设的策略从列表中选出一部分中转服务器,向它们发起传输通道建立请求。在传输过程中,发送端可以根据传输通道的状态,动态地增加、删除、替换掉传输通道。
以上是对系统中各个模块的功能描述。在本申请中,客户端之间通过连接以及连接中的通道传输数据,下面对连接以及通道做进一步的描述。
本申请中所涉及的每一个连接都包含至少1个数据传输通道,每1个数据传输通道使用最多1跳中转服务器作为中转传输节点,有且仅有一个唯一的通道,不使用中转传输节点。假设存在一个中转服务器网络,包含3个中转服务器A,B,C。某一时刻,客户端M想向客户端N传输数据,于是选择中转服务器A,B建立传输通道,数据传输通道可以描述为M→A→N和M→B→N,此外,由于M、N直接传输的性能也很好,M→N也是连接的一个数据传输通道。
在网络中,客户端之间所建立的每一条连接的数据传输是全双工的,但在本申请中为了避免管理的复杂程度,所有通道的建立、拆除操作均由发送端发起,而发送端由每一个连接中第一个通道的发起过程决定,第一个通道的发起方为连接发送端,第一个通道的接收方为连接接收端,此后,在连接的生存周期内,发送端和接收端的身份不会发生改变。
在本申请中,每一条连接由“发送端IP地址、发送端端口号、接收端IP地址、接收端端口号”这一四元组唯一标识,连接中的每一个通道由“发送端IP地址、发送端端口号、接收端IP地址、接收端端口号、通道编号”这一五元组唯一标识。由于通道由连接发送端建立,因此,通道编号也由发送端分配。之前提到,通道可分为两种类型,第一类是发送端与接收端之间直接相连的通道,第二类是经由中转服务器的通道,第一类通道较为特殊,为了与其它通道做区分,可对此类通道采用特殊的通道编号方式,如将此类通道的编号固定为0。
每一条连接的每一条通道都是单独维护、面向连接的,连接本身也是面向连接的。连接在最后一个通道断开时自动断开,或者由发送端或接收端主动断开。通道和连接的状态只在发送端和接收端维护,中转服务器不维护任何状态信息,只是根据数据包的相关信息进行转发。
本发明在数据传输时所采用的协议是在UDP协议的基础上扩展实现的,依据该协议,在网络中传输的数据包包括:数据报文和控制报文;其中的数据报文用于传输实际数据,控制报文用于传输控制消息。下面对数据报文和控制报文分别予以说明。
一、数据报文
数据报文是面向字节流的。每个数据报文包含两个序列号,一个是通道字节流序列号,一个是连接字节流序列号。通道字节流序列号是每个通道独立维护的,连接字节流序号是由整个连接维护的。接收端根据这两个序列号进行数据排序,并判断数据的缺失情况。
数据报文包括数据报文头部和所要传输的数据。在图2中给出了本发明中所涉及的数据报文的数据格式,如图所示,数据报文头部包括以下字段(由于传输是全双工的,因此以下所指数据发送方和数据接收方都有可能是发送端或接收端):第0个bit用于指示报文是否为数据报文;第1个bit为R标志位;第2~7bit保留未用;第8~11bit为IPVer字段;第12~15bit为Shift字段;第16~31bit为Window字段;第32~47bit为Port字段;第48~63bit为Channel ID,是通道编号;第64~95bit为ChannelSequence Number,是通道字节流序列号;第96~127bit为Sequence Number,是连接字节流序列号;第128~159bit为Time Stamp,是时间戳;最后是对端的地址Address,取决于IPVer指示的IP协议版本号,可能为32bit(IPv4)或者128bit(IPv6)。
下面对数据报文中各个字段的具体含义进行说明。
0bit标志位:标志位值为0时表示这个报文为数据报文;
R标志位:指示接收方是否检查通道标号有效性。该标志位主要应对这样一种情况,某一通道断开,但是该通道尚有未传输完的数据包,此时,连接需要将这些数据包在其它通道上进行传输。由于每个通道会检查通道编号是否正确,因此,需要一个特殊的标志位来关闭该检查;
IPVer:指示对端IP地址的版本号,4代表IPv4,6代表IPv6,其它字段无效;
Shift:窗口偏移,指定Window字段的左移量,0~14;
Window:窗口大小,用于通知对方可用的接收窗口大小,从而控制发送速度。与Shift字段共同使用,可以保证使得窗口大小最大值达到65535*2^14bit;
Port:对端的端口号;
Channel ID:通道标号;
Channel Sequence Number:通道字节流编号;
Sequence Number:连接字节流编号;
Time Stamp:时间戳;
Address:对端的IP地址,该字段根据IPVer指示的IP协议版本,长度可能为4字节(IPv4)或32字节(IPv6);
Data:有效数据。
二、控制报文
控制报文包括控制报文头部和附加信息(Additional Information)。在图3中给出了本发明中所涉及的控制报文的数据格式,如图所示,控制报文头部包括:第0个bit为标识符,值为1时表示这个报文为控制报文;第1~7bit为Control Type字段,指示控制报文类型;第8~11bit为IPVer字段,标识报文头内的IP地址是IPv4还是IPv6;第12~15bit为Shift字段,指定Window字段的左移量,取值0~14;第16~31bit为Window字段,用于通知数据传输另一方可用的接收窗口大小;第32~47bit为Port字段,是对端的端口(若控制报文由发送端发出,则所述对端为接收端,反之,所述对端为发送端);第48~63bit为Channel ID,是通道编号;第64~95bit为Field 1字段,由控制报文解释;第96~127bit为Field 2字段,由控制报文解释;第128~159bit为Time Stamp,是时间戳;最后是对端的地址Address,取决于IPVer指示的IP协议版本号,可能为32bit(IPv4)或者128bit(IPv6)。附加信息字段由控制报文类型决定其包含的实际信息。
根据Control Type的数值,控制报文可分为:
0x1(CTL_CONNECT):通道握手报文,由发送端在通道建立时发送。Field 1是通道发送端初始字节流编号,Field 2是连接发送端初始字节流编号,AdditionalInformation包含最大分节大小(MSS)信息;
0x2(CTL_CONNECT_ACK):连接回复报文,由接收端在收到CTL_CONNECT时回复使用。Field 1是通道发送端初始字节流编号,Field 2是连接发送端初始字节流编号,Additional Information除了包含MSS信息外,还包括相应CTL_CONNECT报文的两个初始字节流编号;
0x3(CTL_ACK):ACK报文,用于确认已接收到的数据。Field 1是通道累积字节流序列号,Field 2是连接累积字节流序列号,Additional Information无数据;
0x4(CTL_NAK):NAK报文,用于确认丢失的数据,供数据发送方重传。Field 1是通道累积字节流序列号,Field 2是连接累积字节流序列号,Additional Information包含一组序列号范围,每两个序列号表示一个丢失范围[范围起始序列号,范围终止序列号+1),序列号都是连接字节流序列号或通道字节流序列号;
0x5(CTL_CLOSE_CHANNEL):通道关闭报文,用于发送端关闭通道。Field 1、Field 2、Additional Information无定义;
0x6(CTL_CLOSE_CHANNEL_ACK):通道关闭ACK,用于接收端回复CTL_CLOSE_CHANNEL。Field 1、Field 2、Additional Information无定义;
0x7(CTL_CLOSE_CHANNEL_ACK2):通道关闭ACK的ACK,用于发送端回复CTL_CLOSE_CHANNEL_ACK。Field 1、Field 2、Additional Information无定义;
0x8(CTL_CLOSE_CONNECTION):连接关闭报文,用于直接关闭连接,可以由发送端或接收端发起。Field 1、Field 2、Additional Information无定义;
0x9(CTL_CLOSE_CONNECTION_ACK):连接关闭ACK,用于回复CTL_CLOSE_CONNECTION。Field 1、Field 2、Additional Information无定义;
0x10(CTL_CLOSE_CONNECTION_ACK2):连接关闭ACK的ACK,用于发送端回复CTL_CLOSE_CONNECTION_ACK。Field 1、Field 2、Additional Information无定义;
0x11(CTL_KEEP_ALIVE):通道保活报文,Field 1、Field 2、Additional Information无定义;
0x3ff(CTL_ERROR),错误信息报文,Field 1定义错误代号,Field 2、AdditionalInformation由相关错误填写;
0x11~0xff:协议保留报文类型编号,用于未来扩展;
0x100~0x2ff:上层应用自定义报文。
从对控制报文的上述描述来看,在本发明中,一条连接可利用累积确认报文(ACK)确认已经成功传输的数据,利用否认报文(NAK)汇报丢失的数据。ACK报文包含一个通道字节流序列号和一个连接字节流序列号,位于序列号之前的通道和连接数据全部被成功接收。NAK报文包含若干连接字节流数据序列号范围和通道字节流序列号范围,范围内的数据都未被接收到。ACK报文沿相应数据报文的通道反向返回,数据报文中可以包含时间戳信息,用于估算往返延时(Round-trip Delay)。NAK报文可以沿原通道或者任意一条通道发送,推荐使用传输性能比较高的通道,在发送时可以多个副本沿不同的通道同时发送,以减少报文丢失的概率。
本发明的多路径数据传输方法包括建立通道、传输数据、关闭通道、关闭连接四个阶段,下面分别对这些阶段中的相关步骤做具体描述。
前文中提到,连接中的数据传输通道分为两类,第一类是不使用中转服务器,发送端与接收端之间直接进行数据传输(下文中也可将此类数据传输通道称为第一类通道);第二类是通过中转服务器在发送端与接收端之间建立的传输通道(下文中也可将此类数据传输通道称为第二类通道)。下面分别对这两类数据传输通道的建立过程进行说明。
第一类通道的建立步骤如下:
步骤101)、发送端构造CTL_CONNECT报文,该报文包含通道初始序列号、连接初始序列号、最大分节大小等信息,该报文将由发送端直接发送给接收端。为了区分其它的通道,可以采用多种方式,例如该通道的通道编号为一个特殊值(0或其它)。
步骤102)、接收端接收到CTL_CONNECT报文,判断报文是否合法,如果报文合法,构造并返回CTL_CONNECT_ACK。
步骤103)、发送端接收到CTL_CONNECT_ACK,发送端的通道建立过程已经完成,可以等待一段时间(暂时没有可发送的有效数据)或者立刻发送一个数据报文(有效数据可以为空),接收端接收到该数据报文后,接收端的通道建立过程完成。如果该通道是连接建立的第一个通道,通道的建立同时意味着连接的建立。
在上述步骤中,如果发生CTL_CONNECT、CTL_CONNECT_ACK丢失的情况,会导致相关报文的重传。如果重传超过一定次数或时间,通道将建立失败。在步骤102)中,如果检验CTL_CONNECT报文不合法,将返回CTL_ERROR报文。
第二类通道的步骤如下:
步骤201)、发送端获得可用于建立通道的中转服务器信息;该中转服务器信息的获取方式可以有多种,如从索引服务器实时请求的,或从发送端已缓存的信息中获取。
步骤202)、发送端构造CTL_CONNECT报文,该报文包含接收端IP地址、接收端端口号、通道初始序列号、连接初始序列号、最大分节大小、一个尚未使用的通道编号等信息,该报文由发送端发送给中转服务器。
步骤203)、中转服务器从所接收的CTL_CONNECT报文中提取接收端IP地址和接收端端口号信息,然后按照控制报文的来源将Address和Port字段修改为发送端IP地址和发送端端口号,该控制报文接着被发往接收端。
步骤204)、接收端接收到CTL_CONNECT报文,判断报文是否合法,如果报文合法,构造并返回CTL_CONNECT_ACK。
步骤205)、CTL_CONNECT_ACK经中转服务器中转后转发给发送端。
步骤206)、发送端接收到CTL_CONNECT_ACK,发送端的通道建立过程已经完成,可以等待一段时间(暂时没有可发送的有效数据)或者立刻发送一个数据报文(有效数据可以为空),接收端接收到该数据报文后,接收端的通道建立过程完成。如果该通道是连接建立的第一个通道,通道的建立同时意味着连接的建立。
在上述步骤中,如果发生CTL_CONNECT、CTL_CONNECT_ACK丢失的情况,会导致相关报文的重传。如果重传超过一定次数或时间,通道将建立失败。在步骤204)中,如果检验CTL_CONNECT报文不合法,将返回CTL_ERROR报文。
在通道建立后,一个数据包(包括数据报文和控制报文)通过通道实现从发送端到接收端的传输。数据包在第一类通道和第二类通道上的传输过程略有不同,下面分别加以描述。
数据包在第一类通道上的传输包括以下步骤:
步骤301)、数据发送方构造数据包,所构造数据包中的Address字段为接收地址,Port字段为接收端端口,此外,该数据包中还带有用于指示第一类通道的相关标记,如通道编号为一特殊值;
步骤302)、数据接收方收到数据包后,通过数据包IP协议部分的源地址和源端口判断是否属于本连接,若属于,则进一步判断数据包各项字段的有效性,提取并缓存数据报文的有效数据,最后发送ACK或NAK报文应答。
数据包在第二类通道上的传输包括以下步骤:
步骤401)、数据发送方构造数据包,所构造数据包中的Address字段为接收地址,Port字段为接收端端口。
步骤402)、数据包到达通道使用的中转服务器,中转服务器提取数据包Address和Port字段获得数据接收方的地址和端口号,并将两个字段改写成发送端地址和端口号,接下来,数据包被发送给接收端。
步骤403)、数据接收方收到数据包,根据Address字段和Port字段判断数据包是否处于本连接,以及通道编号是否合法;若属于本连接且通道编号合法,则进一步判断数据包各项字段的有效性,提取并缓存数据报文的有效数据,最后发送ACK或NAK报文应答。
所述通道数据传输方法有几个优点:状态信息只在数据传输的端点上维护,中转服务器无需维护任何状态信息,使得系统在设计上得到简化;能够处理发送方、接收方位于NAT(网络地址转换,Network Address Translation)设备后面的情况。
在某一数据传输通道上,当数据传输过程完成,或数据传输的性能不满足要求时,该数据传输通道会被关闭。第一类通道与第二类通道的通道关闭过程略有不同,下面分别加以陈述。
第一类通道的关闭过程包括如下步骤:
步骤501)、发送端构造CTL_CLOSE_CHANNEL报文,该报文沿通道发送给接收端。
步骤502)、接收端接收到CTL_CLOSE_CHANNEL报文后,判断报文是否合法,如果报文合法,构造并发送CTL_CLOSE_CHANNEL_ACK报文至发送端。
步骤503)、发送端接收到CTL_CLOSE_CHANNEL_ACK报文后,向接收端回复CTL_CLOSE_CHANNEL_ACK2报文,此时,发送端的通道关闭过程已经完毕,但是还需要等待一段时间才能真正关闭通道。
步骤504)、CTL_CLOSE_CHANNEL_ACK2报文经过通道发送给接收端。接收端通道关闭完毕,且不需要等待时间。
第二类通道的关闭过程包括如下步骤:
步骤601)、发送端构造CTL_CLOSE_CHANNEL报文,该报文沿通道发送给中转服务器。
步骤602)、中转服务器将所接收的CTL_CLOSE_CHANNEL报文转发给接收端。
步骤603)、接收端接收到CTL_CLOSE_CHANNEL报文后,判断报文是否合法,如果报文合法,构造并发送CTL_CLOSE_CHANNEL_ACK报文。
步骤604)、CTL_CLOSE_CHANNEL_ACK报文被中转服务器转发给发送端。
步骤605)、发送端接收到CTL_CLOSE_CHANNEL_ACK报文后,向接收端回复CTL_CLOSE_CHANNEL_ACK2报文,此时,发送端的通道关闭过程已经完毕,但是还需要等待一段时间才能真正关闭通道。
步骤606)、CTL_CLOSE_CHANNEL_ACK2报文经过中转服务器后转发给接收端。接收端通道关闭完毕,且不需要等待时间。
在实际的网络中,CTL_CLOSE_CHANNEL、CTL_CLOSE_CHANNEL_ACK、CTL_CLOSE_CHANNEL_ACK2报文都可能发生丢失,发送端和接收端需要做必要的处理。如果发送端在发送完CTL_CLOSE_CHANNEL后等待一段超时时间仍未接收到CTL_CLOSE_CHANNEL_ACK,将重传CTL_CLOSE_CHANNEL;如果接收端在发送完CTL_CLOSE_CHANNEL_ACK后等待一段超时时间仍未接收到CTL_CLOSE_CHANNEL_ACK2,将重传CTL_CLOSE_CHANNEL_ACK。重传次数有一定上限,如果重传超过一定次数或时间,通道将直接关闭。在步骤503)和步骤605)中等待一段时间才真正关闭通道的原因就是为了响应重传的CTL_CLOSE_CHANNEL_ACK。
如果当前关闭的通道是连接中的最后一个通道,整个连接也将被关闭。
根据用户需要,发送端或者接收端可以主动关闭两者之间的连接,而不必等到连接中的所有通道都关闭后才关闭连接。连接主动关闭的过程可以由发送端或者接收端发起,下面以发送端发起为例对连接主动关闭过程进行说明,接收端发起的连接主动关闭过程与之相比没有本质区别:
步骤701)、发送端构造CTL_CLOSE_CONNECTION报文,该报文沿任意通道发送给接收端,为了增加传输的可靠性,可以是多个通道并发传输。
步骤702)、接收端接收到CTL_CLOSE_CONNECTION报文后,判断报文是否合法,如果报文合法,构造并发送CTL_CLOSE_CONNECTION报文,发送给发送端,报文同样沿任意通道发送给接收端,为了增加传输的可靠性,可以是多个通道并发传输。
步骤703)、发送端接收到CTL_CLOSE_CONNECTION_ACK报文后,向接收端回复CTL_CLOSE_CONNECTION_ACK2报文,此时,发送端的连接关闭过程已经完毕,但是还需要等待一段时间才能真正关闭通道。
步骤704)、CTL_CLOSE_CONNECTION_ACK2报文沿任意通道发送给接收端,为了增加传输的可靠性,可以是多个通道并发传输。接收端通道关闭完毕,且不需要等待时间。
在实际的网络中,CTL_CLOSE_CONNECTION、CTL_CLOSE_CONNECTION_ACK、CTL_CLOSE_CONNECTION_ACK2报文都可能发生丢失,发送端和接收端需要做必要的处理。如果发送端在发送完CTL_CLOSE_CONNECTION后等待一段超时时间仍未接收到CTL_CLOSE_CONNECTION_ACK,将重传CTL_CLOSE_CONNECTION;如果接收端在发送完CTL_CLOSE_CONNECTION_ACK后等待一段超时时间仍未接收到CTL_CLOSE_CONNECTION_ACK2,将重传CTL_CLOSE_CONNECTION_ACK。重传次数有一定上限,如果重传超过一定次数或时间,连接也会被关闭。步骤703)中等待一段时间才真正关闭连接的原因就是为了响应重传的CTL_CLOSE_CONNECTION_ACK。
为了便于理解,下面结合一个具体的实例对本发明做进一步说明。
假设服务提供商在网络中部署了6个中转服务器,分别位于吉林、北京、山西、江苏、上海、广东,索引服务器位于北京。
假设某公司需要从北京分公司传送一批数据到上海分公司,传输流程如下:
1、上海分公司的客户端打开8878端口监听来自北京分公司的数据传输请求。
2、北京分公司的客户端打开7768端口,准备向上海分公司8878端口发起连接。
3、北京分公司的客户端向索引服务器请求中转服务器信息,索引服务器发现北京、山西、江苏、上海这四个中转服务器更有可能为其提供优质的服务,因此将它们返回给发送端。
4、客户端的配置限制其同一时刻最多为一条连接建立3条通道,中转服务器的选择使用随机策略。对于即将发起的连接,北京客户端选择江苏和山西中转服务器作为中转服务器,此外,还有一条不使用中转服务器的直传通道,下一跳节点就是上海分公司接收客户端。北京客户端向它们发送CTL_CONNECT报文。
5、山西中转服务器在4488端口接收到CTL_CONNECT报文,并选择上海分公司客户端8878端口作为下一跳,对数据包做必要的修改后,将CTL_CONNECT报文传递下去。
6、上海分公司客户端8878端口接收到山西中转服务器4488端口的CTL_CONNECT报文,返回CTL_CONNECT_ACK报文作为回复给山西中转服务器4488端口。
7、山西中转服务器4488端口收到CTL_CONNECT_ACK报文,转发给北京客户端7768端口;
8、北京客户端7768端口收到山西中转服务器4488端口的CTL_CONNECT_ACK报文,通道建立成功,由于这是第一条建立成功的通道,意味着连接建立成功。此后,北京客户端7768端口可以利用该通道传输数据;
9、在执行步骤5-步骤8的同时,以江苏中转服务器为中转节点的通道也建立成功,过程与步骤5-步骤8类似,不再赘述。直传通道除了没有使用中转节点,其它步骤也类似,不再赘述。
10、发送端在传输数据过程中使用3条通道做并发传输,接收端在收到数据后对数据进行ACK和NAK确认;
11、一段时间后,发送端发现经由江苏中转服务器的通道性能延时较高,决定断开通道,于是沿着该通道发送CTL_CLOSE_CHANNEL报文,在接收到接收端的CTL_CLOSE_CHANNEL_ACK报文后,发送CTL_CLOSE_CHANNEL_ACK2通道,在接收端收到CTL_CLOSE_CHANNEL_ACK2时通道断开成功;
12、一段时间后,发送端发现连接的通道数小于3,尝试建立1条新的通道,上海中转服务器被选中,过程与步骤5-步骤8类似;
13、所有数据传输完毕后,发送端发送CTL_CLOSE_CONNECTION报文,该报文可以从任意一个通道发送;。
14、接收端接收到CTL_CLOSE_CONNECTION报文,返回CTL_CLOSE_CONNECTION_ACK2;
15、发送端接收到CTL_CLOSE_CONNECTION_ACK,返回CTL_CLOSE_CONNECTION_ACK2,发送端断开连接成功,并等待一段时间,以回复CTL_CLOSE_CONNECTION_ACK2丢失情况下重传的CTL_CLOSE_CONNECTION_ACK。
16、接收端接收到CTL_CLOSE_CONNECTION_ACK2,接收端断开连接成功。
最后所应说明的是,以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,对本发明的技术方案进行修改或者等同替换,都不脱离本发明技术方案的精神和范围,其均应涵盖在本发明的权利要求范围当中。

Claims (9)

1.一种分布式中转服务器网络辅助的多路径数据传输系统,其特征在于,包括:索引服务器、中转服务器和客户端;所述索引服务器、中转服务器与客户端之间通过网络连接;所述的中转服务器有多个,分别位于网络的关键路径上,形成一中转服务器覆盖网;其中,
系统中的各个模块在管理和数据两个层面上进行交流与通信,在管理层面上实现与中转服务器覆盖网相关的信息查询、信息管理服务,模块在该层面中的通信使用安全、可靠、易于理解、易于扩展的传输协议,包括HTTP、HTML、XML、SOAP、JSON中的任意一个;在数据层面上实现客户端之间进行的数据传输,为每一条客户端之间的连接建立数据传输通道并提供数据传输服务,模块在数据层面中的通信使用基于UDP协议扩展的多路径数据传输协议;
所述索引服务器位于管理层面上,用于承担中转服务器覆盖网的管理职责;
所述中转服务器在管理层面上接受所述索引服务器的管理,在数据层面上负责为传输通道中转数据;
所述客户端位于数据层面,是用户实现数据传输的接口。
2.根据权利要求1所述的分布式中转服务器网络辅助的多路径数据传输系统,其特征在于,所述索引服务器用于:维护所述中转服务器的信息,每一个活跃的中转服务器都必须定期向其汇报服务器的状态;根据客户端的请求,为其计算并选择一些中转服务器,供客户端作为建立传输通道时候选的中转传输节点。
3.根据权利要求1所述的分布式中转服务器网络辅助的多路径数据传输系统,其特征在于,所述中转服务器用于:在管理层面上,监测包括本服务器可用的网络资源数量、负载、当前已建立的中转连接数、服务器的位置在内的多种信息,并定期向索引服务器汇报;在数据层面上,监听来自客户端的数据包,并负责转发。
4.根据权利要求1所述的分布式中转服务器网络辅助的多路径数据传输系统,其特征在于,所述客户端包括接收端和发送端,其中,在一条连接中,主动发起通道的客户端是发送端,被动接收通道的客户端是接收端;
所述发送端向所述索引服务器请求候选中转服务器的列表,当与数据接收端建立连接时,根据预设的策略从该列表中选出一部分中转服务器,向它们发起传输通道建立请求;在数据传输的过程中,发送端能够根据传输通道的状态,动态地增加、删除、替换掉传输通道。
5.根据权利要求4所述的分布式中转服务器网络辅助的多路径数据传输系统,其特征在于,一条连接的标识方式为:“发送端IP地址、发送端端口号、接收端IP地址、接收端端口号”;连接中的数据传输通道的标识方式为:“发送端IP地址、发送端端口号、接收端IP地址、接收端端口号、通道编号”。
6.根据权利要求1所述的分布式中转服务器网络辅助的多路径数据传输系统,其特征在于,每一条客户端之间的连接包含至少一个数据传输通道,每一个数据传输通道使用最多一跳中转服务器作为中转传输节点,且该连接中有且仅有一个不使用中转传输节点的数据传输通道。
7.根据权利要求1所述的分布式中转服务器网络辅助的多路径数据传输系统,其特征在于,所述基于UDP协议扩展的多路径数据传输协议中包括数据报文和控制报文;所述数据报文用于传输实际数据,所述控制报文用于传输控制消息;其中,
所述数据报文包括数据报文头部和所要传输的数据;数据报文头部包括以下字段:第0个bit用于指示报文是否为数据报文;第1个bit为R标志位;第2~7bit保留未用;第8~11bit为IPVer字段;第12~15bit为Shift字段;第16~31bit为Window字段;第32~47bit为Port字段;第48~63bit为Channel ID,是通道编号;第64~95bit为Channel Sequence Number,是通道字节流序列号;第96~127bit为SequenceNumber,是连接字节流序列号;第128~159bit为Time Stamp,是时间戳;最后是对端的地址Address,取决于IPVer指示的IP协议版本号,为32bit或者128bit;
所述控制报文包括控制报文头部和附加信息;控制报文头部包括:第0个bit为标识符,值为1时表示这个报文为控制报文;第1~7bit为Control Type字段,指示控制报文类型;第8~11bit为IPVer字段,标识报文头内的IP地址是IPv4还是IPv6;第12~15bit为Shift字段,指定Window字段的左移量,取值0~14;第16~31bit为Window字段,用于通知数据传输另一方可用的接收窗口大小;第32~47bit为Port字段,是对端的端口;第48~63bit为Channel ID,是通道编号;第64~95bit为Field1字段,由控制报文解释;第96~127bit为Field2字段,由控制报文解释;第128~159bit为Time Stamp,是时间戳;最后是对端的地址Address,取决于IPVer指示的IP协议版本号,为32bit或者128bit;附加信息字段由控制报文类型决定其包含的实际信息;
根据Control Type的数值,控制报文可分为:
0x1,CTL_CONNECT:通道握手报文,由发送端在通道建立时发送;Field 1是通道发送端初始字节流编号,Field 2是连接发送端初始字节流编号,AdditionalInformation包含最大分节大小信息;
0x2,CTL_CONNECT_ACK:连接回复报文,由接收端在收到CTL_CONNECT时回复使用;Field 1是通道发送端初始字节流编号,Field 2是连接发送端初始字节流编号,Additional Information除了包含MSS信息外,还包括相应CTL_CONNECT报文的两个初始字节流编号;
0x3,CTL_ACK:ACK报文,用于确认已接收到的数据;Field 1是通道累积字节流序列号,Field 2是连接累积字节流序列号,Additional Information无数据;
0x4,CTL_NAK:NAK报文,用于确认丢失的数据,供数据发送方重传;Field1是通道累积字节流序列号,Field 2是连接累积字节流序列号,Additional Information包含一组序列号范围,每两个序列号表示一个丢失范围“范围起始序列号,范围终止序列号+1”,序列号都是连接字节流序列号或通道字节流序列号;
0x5,CTL_CLOSE_CHANNEL:通道关闭报文,用于发送端关闭通道;Field 1、Field 2、Additional Information无定义;
0x6,CTL_CLOSE_CHANNEL_ACK:通道关闭ACK,用于接收端回复CTL_CLOSE_CHANNEL;Field 1、Field 2、Additional Information无定义;
0x7,CTL_CLOSE_CHANNEL_ACK2:通道关闭ACK的ACK,用于发送端回复CTL_CLOSE_CHANNEL_ACK;Field 1、Field 2、Additional Information无定义;
0x8,CTL_CLOSE_CONNECTION:连接关闭报文,用于直接关闭连接,可以由发送端或接收端发起;Field 1、Field 2、Additional Information无定义;
0x9,CTL_CLOSE_CONNECTION_ACK:连接关闭ACK,用于回复CTL_CLOSE_CONNECTION;Field 1、Field 2、Additional Information无定义;
0x10,CTL_CLOSE_CONNECTION_ACK2:连接关闭ACK的ACK,用于发送端回复CTL_CLOSE_CONNECTION_ACK;Field 1、Field 2、Additional Information无定义;
0x11,CTL_KEEP_ALIVE:通道保活报文,Field 1、Field 2、Additional Information无定义;
0x3ff,CTL_ERROR,错误信息报文,Field 1定义错误代号,Field 2、AdditionalInformation由相关错误填写;
0x11~0xff:协议保留报文类型编号,用于未来扩展;
0x100~0x2ff:上层应用自定义报文。
8.在权利要求7所述的分布式中转服务器网络辅助的多路径数据传输系统上实现的数据传输方法,用于在不通过中转服务器,发送端与接收端之间直接进行数据传输的数据传输通道上传输数据包,包括:
步骤301)、数据发送方构造数据包,所构造数据包中的Address字段为接收地址,Port字段为接收端端口,此外,该数据包中还带有用于指示第一类通道的相关标记,如通道编号为一特殊值;
步骤302)、数据接收方收到数据包后,通过数据包IP协议部分的源地址和源端口判断是否属于本连接,若属于,则进一步判断数据包各项字段的有效性,提取并缓存数据报文的有效数据,最后发送ACK或NAK报文应答。
9.在权利要求7所述的分布式中转服务器网络辅助的多路径数据传输系统上实现的数据传输方法,用于在发送端与接收端之间通过中转服务器建立的数据传输通道上传输数据包,包括:
步骤401)、数据发送方构造数据包,所构造数据包中的Address字段为接收地址,Port字段为接收端端口;
步骤402)、数据包到达通道使用的中转服务器,中转服务器提取数据包Address和Port字段获得数据接收方的地址和端口号,并将两个字段改写成发送端地址和端口号,接下来,数据包被发送给接收端;
步骤403)、数据接收方收到数据包,根据Address字段和Port字段判断数据包是否处于本连接,以及通道编号是否合法;若属于本连接且通道编号合法,则进一步判断数据包各项字段的有效性,提取并缓存数据报文的有效数据,最后发送ACK或NAK报文应答。
CN201310689342.4A 2013-12-16 2013-12-16 分布式中转服务器网络辅助的多路径数据传输系统与方法 Active CN104717259B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201310689342.4A CN104717259B (zh) 2013-12-16 2013-12-16 分布式中转服务器网络辅助的多路径数据传输系统与方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201310689342.4A CN104717259B (zh) 2013-12-16 2013-12-16 分布式中转服务器网络辅助的多路径数据传输系统与方法

Publications (2)

Publication Number Publication Date
CN104717259A true CN104717259A (zh) 2015-06-17
CN104717259B CN104717259B (zh) 2018-05-22

Family

ID=53416216

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201310689342.4A Active CN104717259B (zh) 2013-12-16 2013-12-16 分布式中转服务器网络辅助的多路径数据传输系统与方法

Country Status (1)

Country Link
CN (1) CN104717259B (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105656790A (zh) * 2016-01-28 2016-06-08 昭文科技(北京)股份有限公司 多路径数据传输方法及装置
CN105791054A (zh) * 2016-04-22 2016-07-20 西安交通大学 一种基于流分类实现的自主可控可靠组播传输方法
CN107070613A (zh) * 2017-03-22 2017-08-18 公安部交通管理科学研究所 分布式网络环境下数据可靠传输方法
CN108173851A (zh) * 2017-12-28 2018-06-15 南京大学 一种用于空间信息网络的高效多媒体传输方法
CN110401962A (zh) * 2019-08-13 2019-11-01 翱捷科技(深圳)有限公司 自动调整数据报文长度的LoRaWAN系统及其方法
CN110599754A (zh) * 2019-09-11 2019-12-20 杭州电子科技大学信息工程学院 基于互联网的水质监测系统
CN111200830A (zh) * 2020-01-02 2020-05-26 腾讯科技(深圳)有限公司 数据传输方法及装置、电子设备
CN111567011A (zh) * 2018-01-29 2020-08-21 华为技术有限公司 使用跨层信息提高视频服务和WEB服务的QoE的方法
WO2023030475A1 (zh) * 2021-09-03 2023-03-09 华为技术有限公司 报文处理的方法、装置以及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060198695A1 (en) * 2005-03-04 2006-09-07 Fujitsu Limited Relay device
CN101521628A (zh) * 2009-01-16 2009-09-02 深圳市迈科龙电子有限公司 一种数据文件自动中转传输和路由的方法
CN101729589A (zh) * 2008-10-14 2010-06-09 北京大学 一种提高端到端数据传输速率的方法及系统
CN101778093A (zh) * 2009-01-13 2010-07-14 蒋一 基于udp协议的数据传输方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060198695A1 (en) * 2005-03-04 2006-09-07 Fujitsu Limited Relay device
CN101729589A (zh) * 2008-10-14 2010-06-09 北京大学 一种提高端到端数据传输速率的方法及系统
CN101778093A (zh) * 2009-01-13 2010-07-14 蒋一 基于udp协议的数据传输方法
CN101521628A (zh) * 2009-01-16 2009-09-02 深圳市迈科龙电子有限公司 一种数据文件自动中转传输和路由的方法

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105656790B (zh) * 2016-01-28 2019-03-05 东智安通(北京)科技有限公司 多路径数据传输方法及装置
CN105656790A (zh) * 2016-01-28 2016-06-08 昭文科技(北京)股份有限公司 多路径数据传输方法及装置
CN105791054A (zh) * 2016-04-22 2016-07-20 西安交通大学 一种基于流分类实现的自主可控可靠组播传输方法
CN105791054B (zh) * 2016-04-22 2018-10-19 西安交通大学 一种基于流分类实现的自主可控可靠组播传输方法
CN107070613A (zh) * 2017-03-22 2017-08-18 公安部交通管理科学研究所 分布式网络环境下数据可靠传输方法
CN107070613B (zh) * 2017-03-22 2020-04-10 公安部交通管理科学研究所 分布式网络环境下数据可靠传输方法
CN108173851B (zh) * 2017-12-28 2020-07-03 南京大学 一种用于空间信息网络的高效多媒体传输方法
CN108173851A (zh) * 2017-12-28 2018-06-15 南京大学 一种用于空间信息网络的高效多媒体传输方法
CN111567011B (zh) * 2018-01-29 2021-08-03 华为技术有限公司 使用跨层信息提高视频服务和WEB服务的QoE的方法
CN111567011A (zh) * 2018-01-29 2020-08-21 华为技术有限公司 使用跨层信息提高视频服务和WEB服务的QoE的方法
CN110401962A (zh) * 2019-08-13 2019-11-01 翱捷科技(深圳)有限公司 自动调整数据报文长度的LoRaWAN系统及其方法
CN110401962B (zh) * 2019-08-13 2020-04-24 翱捷科技(深圳)有限公司 自动调整数据报文长度的LoRaWAN系统及其方法
CN110599754A (zh) * 2019-09-11 2019-12-20 杭州电子科技大学信息工程学院 基于互联网的水质监测系统
CN111200830A (zh) * 2020-01-02 2020-05-26 腾讯科技(深圳)有限公司 数据传输方法及装置、电子设备
WO2023030475A1 (zh) * 2021-09-03 2023-03-09 华为技术有限公司 报文处理的方法、装置以及系统

Also Published As

Publication number Publication date
CN104717259B (zh) 2018-05-22

Similar Documents

Publication Publication Date Title
CN104717259A (zh) 分布式中转服务器网络辅助的多路径数据传输系统与方法
CN106936709B (zh) 远程服务访问路径控制方法和相关设备
CN107864228B (zh) 一种内容分发网络中的连接建立方法及系统
CN102932461B (zh) 网络加速传输方法及装置
CN104023006B (zh) 一种基于应用层中继的多径传输系统及方法
JP6777650B2 (ja) Tcpトンネル及びネイティブtcp情報に基づくバンドリングシナリオにおけるパケットのスケジューリングのための方法及びシステム
US20150373135A1 (en) Wide area network optimization
CN102780712B (zh) 会话的切换方法及装置
CN109041272A (zh) 一种LoRa自组网的组网方法及其通信方法
CN114631297B (zh) 用于多路径通信的方法和网络设备
EA018130B1 (ru) Способ выборочного перехвата сеанса
TW201729568A (zh) 網路系統及建立資料連線的方法
CN103379182A (zh) 数据传输方法和客户端
CN106302213A (zh) 一种数据传输的方法及装置
JP5760736B2 (ja) 通信装置
EP3632081B1 (en) Session layer communications using an id-oriented network
CN107104892A (zh) 网络加速的方法和装置
US7286546B2 (en) Method and system for providing reliable and fast communications with mobile entities
EP2124397A1 (en) A method for transfering the ip transmission session and the equipment whereto
JP2001067291A (ja) ネットワーク監視方式
CN102752331A (zh) 对等网络中实现策略控制的方法、资源控制代理及系统
US20140369189A1 (en) Method of controlling packet transmission in network system and network system transmitting packet using pseudo-tcp agent
CN110474830B (zh) 一种基于端口转发的p2p隧道通信方法
US20090052446A1 (en) Communications Interface
CN102480425A (zh) 点对点p2p网络中的消息路由的方法及系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210729

Address after: Room 1601, 16th floor, East Tower, Ximei building, No. 6, Changchun Road, high tech Industrial Development Zone, Zhengzhou, Henan 450001

Patentee after: Zhengzhou xinrand Network Technology Co.,Ltd.

Address before: 100190, No. 21 West Fourth Ring Road, Beijing, Haidian District

Patentee before: INSTITUTE OF ACOUSTICS, CHINESE ACADEMY OF SCIENCES