掌桥专利:专业的专利平台
掌桥专利
首页

一种基于ARQ和UDP协议的TCP网络加速方法

文献发布时间:2023-06-19 10:14:56


一种基于ARQ和UDP协议的TCP网络加速方法

技术领域

本发明涉及属于通信软件技术领域,具体涉及一种基于ARQ和UDP协议的TCP网络加速方法。

背景技术

随着近年来宽带速度大幅提升,目前关于网络传输的手段主要包括ARQ、TCP、UDP等。首先,自动重传请求(ARQ,Automatic Repeat-reQuest)是OSI模型中数据链路层的错误纠正协议之一,它包括停止等待ARQ协议和连续ARQ协议,具有错误侦测、正面确认、逾时重传与负面确认继以重传等机制;其次,传输控制协议(TCP,Transmission ControlProtocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议,数据链路层采用连续ARQ(UNA)协议,强调数据的安全性,不同主机的应用层之间经常需要可靠的、像管道一样的连接;另外,用户数据报协议(UDP,User Datagram Protocol)是OSI参考模型中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务。

然而,对于TCP协议而言,为保证数据可靠其有下列缺点:慢,效率低,在传递数据之前要先建立连接,这会消耗时间;而且在数据传递时,确认机制、重传机制、拥塞机制等都会消耗大量时间。

此外,对于UDP协议而言,UDP报文没有可靠性保证、顺序保证和流量控制字段等,可靠性较差,但是正因为UDP协议的控制选项较少,在数据传输过程中延迟小、数据传输效率高。

随着全球视频直播业务、网络实时游戏业务快速增长,在跨国网络应用种,急需提供一种在UDP快速低时延的基础上,加上ARQ进行数据可靠性确认,而形成一种可靠的低时延的网络传输方法。

发明内容

本发明主要是提供一种解决在网络环境很差的场景下,TCP超时重传时延巨大的方法。首先,具有如下定义:conv:连接号、cmd:命令字、frg:分片、cwnd:接收窗口大小、ts:时间序列、sn:序列号、una:下一个可接收的序列号、len:数据长度。

本发明解决上述技术问题所提供的技术方案是:一种基于ARQ和UDP协议的TCP网络加速方法。

由于UDP本身是不可靠的,所以需要额外信息来保证传输数据的可靠性,因此,本方法在传输的数据上增加一个包头,用于实现ARQ技术,确保数据的可靠、有序,具体包括以下步骤:

步骤1、在客户端与服务端上分别与需要加速的应用层服务建立SOCKS连接。

步骤2、在服务端,根据配置文件配置密码,加密方式等;根据配置的目的地址,即需要与客户端通信的UDP地址,建立UDP通道;本机配置文件监听端口,即需要接受应用层数据的SOCKS地址,建立SOCKS连接;

步骤3、在服务端,通过回调的方式将UDP网络侧接收到的数据进行处理并暂存入接收队列;同时通过回调的方式将监听的SOCKS接收到的本地数据进行处理,并暂存入待发送队列。

步骤4、同时在服务端,进行主循环,将接收队列的数据拷贝写入至SOCKS连接端口;将待发送队列的数据,通过与客户端对接的UDP连接进行发送。

步骤5、在客户端,根据配置文件配置与服务器一致的密码,加密方式等;并根据服务器地址,端口,采用ARQ技术向服务端建立UDP通道;根据配置文件监听本地端口,即建立的SOCKS地址,用于接收用户应用流量或实现全局流量代理。

步骤6、在客户端,通过回调的方式将UDP网络侧接收到的数据进行处理并暂存入接收队列;同时通过回调的方式将监听的SOCKS接收到的本地数据进行处理,并暂存入待发送队列,此步骤与步骤3完全一致,都是基于对客户端与服务器UDP通道上的数据进行处理。

步骤7、同时在客户端,进行主循环,将接收队列的数据拷贝写入至SOCKS连接端口;将待发送队列的数据,通过与服务端对接的UDP连接进行发送,此步骤与步骤4逻辑一致。

进一步的技术方案是,所述步骤3和步骤6中将监听的SOCKS接收到的本地数据进行处理,并暂存入待发送队列,包括以下步骤:

A、根据待发送数据大小与本地窗口大小、远端窗口大小,对接收到的数据进行分片,并将数据拷入待发送缓冲队列。

B、根据封装4种报文类型的报文头,并将发送缓冲队列的数据拷贝至待发送队列。其中报文头参数详细定义如下:

B-1,conv(conversation),4字节,会话标识。由于UDP不是面向连接的,因此本方法自己实现了一套会话机制。conv由客户端随机生成,之后客户端和服务端交互的conv值均一致,以此来标识两个节点之间的通信是一个会话。

B-2.cmd(command),1字节,是标识本方法的报文类型。有以下ACK报文、数据报文、探测窗口报文、响应窗口报文4种。

B-3.frg(fragment),1字节,分段序号。本方法有两种模式,一种是stream模式,一种是message模式。当为stream模式时,frg的值始终为0;当为message模式时,传输的数据大小超过MTU限制,会被分成多个包,通过frg来标识不同包的序号,使得在不知道包到达的先后顺序的情况下也能够通过frg字段来重新按照顺序组装成原始数据。

B-4.wnd(window),2字节,窗口大小,自己(发送当前包的终端)能够接收数据量,窗口大小可以为0,当为0时,在发送数据前会进行探测窗口大小的操作。

B-5.ts(timestamp),4字节,当前毫秒时间戳。

B-6.Sn(sequence number),4字节,包序号,该包序号为当前会话中的序号,从0开始。

B-7.una,4字节,表示此编号前所有的包都已收到。

B-8.len,4字节,数据部分的长度。

C、校验发送队列的数据是否需要是否需要重新发送,并更新滑动窗口位置。

更进一步,其中,判断报文是否需要重传的方法包括:

方法一、超时重传。根据配置的加速类型设置报文超时时长,如果发送队列的报文在设置的超时时长内未收到ACK报文或下一个可接受的序列号确认则重发报文。

方法二、快速重传。根据ACK报文和下一个可接受的序列号确定报文被跳过的次数,如果该报文之后2个报文已经收到ACK确认,且una仍为当前报文,则知道该报文被跳过2次,认为该报文丢失,此时不用等待超时,直接重新发送该报文。例如,发送端发送了1,2,3,4,5几个包,然后收到远端的ACK:1,3,4,5,当收到ACK3时,发送端知道2被跳过1次,收到ACK4时,知道2被跳过了2次,此时可以认为2号丢失,不用等超时,直接重传2号包,大大改善了丢包时的传输速度

方法三、选择重传。本发明每个报文需要有单独的ACK报文,且都带有下一个可接受的序列号。所以即使部分ACK报文丢失,也能精确的定位到对端待接收的报文,只需重发真正丢失的报文。

进一步的技术方案是,所述步骤4和步骤7中所述将待发送队列的数据,通过UDP连接进行发送包括以下步骤:

一、通过FEC编码器对发送队列的报文进行编码。

二、生成校验和并根据配置的加密方法对发送队列的报文进行加密。

三、将加密之后的的数据采用UDP的方式进行发送。

进一步的技术方案是,所述步骤3和步骤6中将UDP网络侧接收到的数据进行处理并暂存入接收队列包括以下步骤:

a、根据配置的加密方法解密接收报文,并根据校验和确认报文是否有效。

b、对有效的报文使用FEC解码器进行解码。

c、将解码成功的数据,提取本发明的报文头,并针对4种不同的报文进行解析,其中报文头与报文类型与上面发送的格式进行对应。

d、根据序列号确认是否重复报文,将非重复报文考入待接收队列。

e、将待接收队列报文,拷贝至接收队列,并清除已拷贝的待接收队列报文。

f、根据下一个可接受的序列号确定是否滑动窗口,如果窗口滑动触发向UDP连接侧发送报文流程。

本发明的有益效果是:目前跨国网络传输一般采用加密或者压缩的方式提高数据传输效率,对跨国网络时延高,丢包率大等问题没有根本性改善。本发明提出滑动窗口,ARQ协议与UDP结合的方案,既解决了TCP传输时延高的问题,又解决UDP传输数据丢失的问题,从根本上改善网络环境;在继承传统数据压缩的基础上,结合前向纠错技术,自动修复报文,减少丢包重发,进一步加快数据传输速率;对数据进行加密传输,保证用户数据安全可靠。

附图说明

图1为本发明系统示意图;

图2为本发明系统数据处理流程图;

图3为本发明中步骤3中的报文头;

图4为本发明中步骤3中的发送示意图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明中的技术方案进行进出、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例,基于本发明中的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得所有其它实施例,都属于本发明的保护范围。

本发明使用的系统如图1所示,整个系统主要包含2个终端,其中客户端与服务端数据处理流程大体一致,都包括对网络侧UDP报文的发送和接收,以及对应用层用户或者服务的数据进行发送和接受,本发明基于方法创建的流程按步骤进行描述,但其实在部署完成之后上述的对网络侧UDP报文的发送和接收,以及对应用层用户或者服务的数据进行发送和接受完全是并行进行的。基于这个前提描述,结合附图,本发明具体实施步骤如下:

步骤1:在客户端与服务端分别与需要加速的应用层服务建立SOCKS连接,也可以使用其他的流量代理方法,只需要将用户的流量转发到本发明终端即可。

步骤2:在服务端,根据配置文件配置密码,加密方式;根据配置的监听端口,即需要接受应用层数据的SOCKS端口,建立SOCKS连接,并配置SOCKS缓冲区大小,用于接收来自SOCKS连接的数据;本机配置文件目的地址,监听本地UDP端口,即与客户端对接端口,并配置网络侧缓冲区大小,用于接收来自UDP网络连接的数据;根据配置文件配置发送与接收的滑动窗口大小;

步骤3、在服务端,通过回调的方式将UDP网络侧接收到的数据进行处理并暂存入接收队列,接收网络侧数据放到之前申请的缓冲区里面;根据配置的加密方法解密接收报文,并根据校验和确认报文是否有效;对有效的报文使用FEC解码器进行解析;将解码成功的数据,提取本发明的报文头,获取如图3所示的报文头的各个参数,根据cmd对4种不同的报文进行解析;根据序列号确认是否重复报文,将非重复报文考入待接收队列;根据接收窗口大小将待接收队列数据移动至接收队列;根据下一个可接受的序列号确定是否滑动窗口,如果窗口滑动触发向UDP连接侧发送报文流程,其中触发报文发送流程包括回ACK报文,回响应窗口报文以及发送窗口中检查需要重发的报文。

同时通过回调的方式将监听的SOCKS接收到的本地数据进行处理,并暂存入待发送队列,整个流程如4所示,首先根据待发送数据大小与本地窗口大小、远端窗口大小,对接收到的数据进行分片,并将数据拷入待发送缓冲队列;根据需要封装4种报文类型的报文头,其中报文格式如图3,并将发送缓冲队列的数据拷贝至待发送队列;校验发送队列的数据是否需要是否需要重新发送,并更新滑动窗口位置,其中校验数据是否需要重新发送的方法包括:超时重传,根据配置的加速类型设置报文超时时长;如果发送队列的报文在设置的超时时长内未收到ACK报文或下一个可接受的序列号确认则重发报文;快速重传,根据ACK报文和下一个可接受的序列号确定报文被跳过的次数;如果后2个报文已经收到确认,则知道该报文被跳过2次,认为该报文丢失,此时不用等待超时,直接重新发送该报文。比如说,发送端发送了1,2,3,4,5几个包,然后收到远端的ACK:1,3,4,5,当收到ACK3时,发送端知道2被跳过1次,收到ACK4时,知道2被跳过了2次,此时可以认为2号丢失,不用等超时,直接重传2号包;选择重传,本发明使用ARQ协议,每个报文需要有单独的ACK报文,且都带有下一个可接受的序列号,所以即使部分ACK报文丢失,也能精确的定位到对端待接收的报文,只需重发真正丢失的报文。

步骤4、同时在服务端,进行主循环,将接收队列的数据拷贝写入至SOCKS连接端口,同时将监听端口的数据拷贝到SOCKS数据缓存区,并触发应用侧的数据发送流程。本发明最终的数据接收方除了使用本地的SOCKS端口之外,也可以使用其他的IP地址和端口进行配置,之后的数据报文可通过TCP的方式进行二次传输,但是使用远端连接时需要确保目的端口就是本次数据传输的最终地址。

将待发送队列的数据,通过与客户端对接的UDP通道进行发送,循环检测待发送队列,如果待发送队列里面有数据,则将数据通过之前的UDP通道进行发送。

步骤5、在客户端,根据配置文件配置与服务器一致的密码,加密方式等;并根据服务器地址,端口,采用ARQ技术向服务端建立UDP通道;根据配置文件监听本地端口,即建立的SOCKS地址,用于接收用户应用流量或实现全局流量代理。

步骤6、在客户端,通过回调的方式将UDP网络侧接收到的数据进行处理并暂存入接收队列;同时通过回调的方式将监听的SOCKS接收到的本地数据进行处理,并暂存入待发送队列,此步骤与步骤3完全一致,都是基于对客户端与服务器UDP通道上的数据进行处理,只不过一个是在客户端运行,一个是在服务端运行。

步骤7、同时在客户端,进行主循环,将接收队列的数据拷贝写入至SOCKS连接端口;将待发送队列的数据,通过与服务端对接的UDP连接进行发送,此步骤与步骤4逻辑一致。

以上所述,并非对本发明作任何形式上的限制,虽然本发明已通过上述实施例揭示,然而并非用以限定本发明。任何熟悉本专业的技术人员,在不脱离本发明技术方案范围内,当可利用上述揭示的技术内容作出些变动或修饰为等同变化的等效实施例。但凡是未脱离本发明技术方案的内容,依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰,均仍属于本发明说明书技术方案的范围内。

相关技术
  • 一种基于ARQ和UDP协议的TCP网络加速方法
  • 一种基于ICMP、TCP、UDP协议的网络设备的网络拓扑自动发现方法
技术分类

06120112476870