CN1476181A - 一种分布式的卫星网络tcp性能加速协议格式和方法 - Google Patents
一种分布式的卫星网络tcp性能加速协议格式和方法 Download PDFInfo
- Publication number
- CN1476181A CN1476181A CNA031474705A CN03147470A CN1476181A CN 1476181 A CN1476181 A CN 1476181A CN A031474705 A CNA031474705 A CN A031474705A CN 03147470 A CN03147470 A CN 03147470A CN 1476181 A CN1476181 A CN 1476181A
- Authority
- CN
- China
- Prior art keywords
- agency
- client
- take
- data
- connection
- 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
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及卫星通信技术领域，加速协议方法，包括：当Client与Server之间建立一条TCP连接；GW1向GW2双方建立一条XP连接；GW2与Server之间，建立一条TCP连接；本发明实现基于分布式性能提升代理的卫星网络环境TCP(传输控制协议)加速协议：XP协议。专门针对卫星网络长时延、高误码率和非对称信道特点进行设计和优化，主要用于在一条端到端TCP连接中透明替代途经单跳段卫星网络的TCP协议。本文对XP协议及其在连接建立、数据传输和连接释放等阶段所采用的一些关键技术进行了描述和分析，其中主要包括：可靠高效的两路握手连接建立算法，基于发送方主动请求的延迟确认算法，基于窗口的流量控制和拥塞控制，和基于两阶段多路握手的连接释放算法。
Description
技术领域
本发明涉及卫星通信技术领域，特别是一种分布式的卫星网络TCP性能加速协议格式和方法。
背景技术
卫星通信具有覆盖面广、带宽分配灵活、资源利用率高、用户接入方便、故障恢复迅速和不受各种地域条件限制等优点，可广泛用于长距离Internet/Intranet接入，并可满足政府、企业和家庭等各类数据通信需求，特别适用于远郊、农村和山区等地面光纤网络难于普及或使用价格昂贵的地方，以及部分移动终端用户。各种卫星通信系统必将在下一代Internet中发挥重要作用。
TCP(传输控制协议)是目前Internet/Intranet上应用最为广泛的传输层协议，并已成为端到端可靠数据传输的事实标准。据统计，目前Internet上95％以上的数据流使用TCP作为其低层传输协议。然而当将TCP协议应用于卫星网络环境时，由于卫星信道区别于地面链路的一些固有特点，严重影响了TCP的性能，降低了卫星信道带宽的利用率。卫星信道的特点及其对TCP性能的影响，主要可以归纳为以下几个方面：
长的反馈回路。这是由于卫星信道的长传输时延所造成的。例如同步地球轨道卫星(GEO)的典型单向时延约为250ms。这意味着发送方发出数据之后需要等待较长时间才能收到从对方返回来的确认。这会影响TCP的慢启动算法(slow-start)，使其需要花费较长时间才能达到最优的传输速率，从而变成了真正的“慢”启动，导致严重的带宽浪费。
大的带宽时延乘积(bandwidth*RTT)。这就要求TCP必须维持一个大的发送窗口才能充分利用带宽。但TCP标准的最大发送窗口为64KB，许多TCP实现中缺省的发送窗口是SKB，因此在卫星信道中只能获得较小的吞吐量。
高误码率。卫星信道与其它地面通信介质如光纤、电缆等相比，具有较高的误码率。TCP协议默认数据包丢失为网络拥塞的标志，并调用慢启动算法来减小窗口值以避免拥塞。但由于信道传输误码所引起的数据包丢失与网络发生拥塞所引起的数据包丢失并不相同，在卫星信道上采用传统TCP判断拥塞方式从而减小拥塞窗口进入拥塞避免的方法并不合适，而只会降低网络吞吐量。非对称网络环境。由于用于向卫星发送数据的设备价格比较昂贵，因此卫星通信一般采用非对称信道。例如一台连接到卫星网络的主机可以在下行链路(用于接收数据，一般流量较大)采用卫星信道，而在上行链路(用于发送数据，一般流量较小)采用低速地面连接(如拨号Modem)。或者上下行都采用卫星信道，但上行带宽远远低于下行带宽。由于TCP采用反向链路中的响应请求(ACK)来触发发送方数据的持续发送，因此这种上下行链路带宽的不对称会导致上行链路中响应请求(ACK)的拥塞，并反过来影响下行链路的传输性能。
关于如何提高卫星网络环境下TCP的性能，人们已经进行了许多研究。RFC2488列举了如何利用标准的TCP拥塞控制机制(慢启动/拥塞避免和快速重传/快速恢复)来缓解TCP性能降低的一些建议。RFC2760对当前正在研究的各种卫星网络环境TCP性能提升算法进行了调研和归纳，如针对慢启动而采用的大的初始化窗口(Large Initial Window)、字节计数(Byte Counting)和慢启动之后的延迟确认(DelayAcknowl edgement after Slow Start)，针对包丢失恢复而采用的前向响应请求(Forward Acknowledgement)，以及针对上下行非对称信道带宽而采用的响应请求拥塞控制(Acknowledgement Congestion Control)和响应请求过滤(Acknowledgement Filtering)等。
上述优化算法大部分是针对TCP协议本身进行改进，它们保持了TCP协议端到端的语义(semantics)，但需要对客户和(或)服务器端的TCP协议栈进行修改，有的甚至需要修改路由器上的IP层协议，因此会带来兼容性问题，不便于大范围的推广使用。另外一种用于提高卫星等特定网络环境TCP性能的方法是采用性能提升代理(Performance EnhancingProxies)。性能提升代理(PEP)这个概念本身并不仅仅针对TCP或卫星网络，它可以位于一条网络路径中的任一位置和协议层，用于有针对性地解决由于某一特定链路或子网的特殊性而带来的网络协议性能低下问题。RFC3135对目前广泛使用和正在研究中的各种PEP的分类和实现机制等进行了总结和讨论，其中按分布性将性能提升代理(PEP)分为集中式性能提升代理(Centralized PEP)和分布式性能提升代理(DistributedPEP)两大类。集中式性能提升代理(Centralized PEP)仅在一条网络路径中的一个节点上实现单一性能提升代理(PEP)。而分布式性能提升代理(Distributed PEP)则可以在多个节点上包含两到多个性能提升代理(PEP)。典型的分布式(Distributed PEP)一般驻留于一条特殊通信链路的两端，并采用专有协议对包围于其中的特殊链路性能进行优化。
采用分布式性能提升代理(Distributed PEP)是提高卫星网络环境传输控制协议TCP性能的一种有效方法。分布式性能提升代理(Distributed PEP)可以对TCP连接进行透明拦截，而不需要对通信双方的协议栈和应用程序做任何改动，因此兼容性好，便于实施；而且由于在两个性能提高代理之间可以采用专门针对卫星网络而设计的专有协议进行通信，因此与上述端到端的TCP优化相比，可以跟更加充分地利用带宽资源，提高信道吞吐量。
发明内容
本发明的目的在于提供一种分布式的卫星网络TCP性能加速协议格式和方法，并实现了一个新的基于分布式性能提高代理的卫星网络环境TCP性能加速协议：XP协议。其具体做法为：在一条卫星链路的两端分别设置一个性能提高代理网关，从而将一条端到端TCP连接分成为三段：性能提高代理网关(PEP)两侧的地面链路上仍采用标准的TCP协议，而在两个性能提高代理网关之间的卫星链路上则采用专有XP协议。
XP协议是专门针对卫星网络环境而设计的一个简单、可靠、面向连接的传输协议，用于在一条端到端TCP连接中透明替换途经卫星网络的TCP协议。它在充分利用卫星信道提供的带宽资源的同时，又保证了数据传输的高度可靠性。由于三段网络连接中的每一段都使用的是针对其传输链路而言最优化的网络传输协议，因此整个端到端的传输性能也就可以达到最好。
XP协议建立在用户数据报协议UDP(User Datagram Protocol)之上，并在应用层实现。UDP是一个无连接、不可靠的传输层协议，它对所传输的数据报文几乎不做任何控制和处理，因此也较少性能上的消耗。基于UDP在应用层开发传输协议，可以充分利用UDP提供的套接字(Socket)接口，灵活方便地对所传输数据实施自己的控制，同时对内存缓冲区等资源的管理也更为灵活。但由于UDP是不可靠的，因此如何既充分利用UDP的高效性，同时又使其安全可靠，是XP协议设计中需要考虑的最关键问题。
(1)本发明分别针对XP协议连接建立、数据传输和连接释放等
不同阶段，提出了相应的机制和算法来保证数据传输的高效
性和协议的可靠性。XP协议的主要特点如下：
(2)提出并实现了一个可靠的两路握手连接建立机制，可加快连
接建立过程，并有效消除两路握手可能带来的半连接问题。
(3)在数据传输过程中始终使用最大发送窗口发送数据，避免了
TCP中因慢启动(Slow Start)而带来的带宽浪费，有效提
高了信道吞吐量。并采用了基于窗口的流量控制和拥塞控
制，可在系统运行中根据连接数量的变化动态改变各连接的
窗口上限，从而在最大限度利用带宽的情况下保证多连接共
享信道的公平性。与BST协议中采用的速率控制(Rate
Control)相比，该算法的使用更为灵活高效。
(4)提出并实现了基于数据发送方主动请求ACK的延迟确认算
法，有效解决了因上下行信道带宽不对称而带来的反向链路
ACK拥塞问题。同时采用了基于数据驱动的差错控制机制，
加快了出错重传的反应时间。
(5)提出并实现了基于两阶段多次握手的连接释放算法，克服了
单纯采用基于数据驱动的差错控制所带来的数据完整性隐
患，保证了数据传输的完整性和可靠性。典型的应用环境：
我们的XP(加速协议)协议可广泛应用于卫星Ihternet的接入系统中，该协议克服了卫星链路的长延时给TCP协议带来的负面影响，使得卫星Internet接入成为另外一种具有吸引力的宽带接入方式。图1是我们的一种典型应用环境。上行请求采用拨号连接上行，下行数据使用卫星链路高速下载。
本发明的目的是通过以下的技术方案实现的：
附图说明
图1是典型应用环境网络拓扑图；
图2是XP协议在网络和协议栈中的位置图；
图3是XP协议状态转换图；
图4是XP协议头格图；
图5是XP协议上行数据包格式图；
图6是XP协议下行数据包格式图；
图7是XP协议连接请求包格式图；
图8是XP协议连接应答包格式图；
图9是P协议SACK(有选X择响应)包格式图；
图10是XP协议NACK(重传请求响应)包格式图。
协议栈模型
XP协议在整个网络和协议栈中的位置如图2所示。图1、图2中；
XP协议加速原理采用以下方法进行：
1.如图2所示，当Client(客户机)向Server(服务器)发起
TCP连接请求时，GWl(客户端加速代理)对其进行透明拦截，
代理Server与Client建立一条TCP连接；
2.GW1(客户端加速代理)向GW2(局端加速代理)发起连接请
求，双方建立一条XP连接；
3.GW2(局端加速代理)再向Server发起TCP连接请求，代理Client
与Server建立一条TCP连接；
4.当Client向Server发送数据时，实际上是首先通过TCP发送
至GW1(客户端加速代理)，GW1(客户端加速代理)将其转换成
为XP后发送至GW2(局端加速代理)，再由GW2(局端加速代
理)将其转换成为TCP协议发送至Server；
5.Server通过TCP连接将数据发送给GW2(局端加速代理)，GW2
(局端加速代理)将其转换成XP后，发送至GW1(客户端加速
代理)；
6.GW1(客户端加速代理)收到GW2发送过来的XP数据后，首先将
其转换为TCP协议数据，然后通过TCP连接将数据发送至
Client。
所有这些中间的协议转换对于Client和Server来说都是完全透明的，它们都以为相互之间维持的仍是一个端到端的TCP连接。因此可以将GW1(客户端加速代理)与GW2(局端加速代理)之间的XP连接看成是一个透明的传输通道。协议状态转换
如图3所示，XP协议的协议状态转换按以下方法进行：
1.XP协议的建立首先从GW1(客户端加速代理)开始，当GW1(客户端加速代理)截获到来自Client(客户机)的TCP连接请求并与Client(客户机)建立TCP(传输控制协议)连接后，向GW2(局端加速代理)发送XP连接请求(CONN_REQ)，进入连接准备状态(READY)；
2.当GW2(局端加速代理)接收到来自GW1(客户端加速代理)的CONN_REQ后，也进入连接准备状态(READY)，然后试图与Server建立TCP连接；如果TCP连接建立失败，则向GW1(客户端加速代理)返回一个否定性的XP连接确认(CONN_ACK)，转入连接释放状态(CLOSED)；否则向GW1(客户端加速代理)发送肯定性的XP连接确认(CONN_ACK)，进入连接建立状态(ESTABLISHED)；
3.当GW1(客户端加速代理)接收到GW2(局端加速代理)发回来的CONN_ACK后，如果其中有否定性标志，则转入连接释放状态；否则进入连接建立状态(ESTABLISHED)。
4.数据传输结束后，双方通过两阶段多路握手机制来释放连接，经过预释放状态(PRECLOSE_A或PRECLOSE_P)最后返回至完全释放状态(CLOSED)。
5.在数据传输状态和预释放状态，如果空闲时间超过某个设定值，则返回完全释放状态。协议的数据结构
在GW1(客户端加速代理)和GW2(局端加速代理)之间的XP连接上传输的数据块称之为报文。所有报文(包括控制报文和数据报文)都包含一个固定大小的XP协议头和0到多个字节的数据内容。XP协议目前定义了连接请求(CONN_REQ)、连接确认(CONN_ACK)、数据(DATA)、带ACK请求的数据(DATA_ASKACK)、确认(ACK)、选择性确认(SACK)、否定性确认(NACK)、预释放(PRECLOSE)、释放(CLOSE)和终止半连接(ABORT)等多种类型的报文，并可以根据需要进行灵活扩充。
本发明的协议使用的主要的包格式数据结构如图4-图10。
1.XP协议头长度为8个字节，其格式如图4所示。
类型：占用一个字节长度，用于指示报文的类型。
保留字：占用一个字节长度，用于以后扩展。
连接标识：ConnID字段在建立连接时由GW2(局端加速代理)生成，用于在由GW2(局端加速代理)服务的全局范围内唯一标识一条XP连接；
序列号：占用4个字节长度，用于标识当前报文的序列号。
2.XP协议上行数据包格式如图5所示。
类型：占用一个字节长度，其值为上行数据包类型。
保留字：占用一个字节长度，用于以后扩展。
连接标识：占用两个字节长度，用于唯一标识一条XP连接。
序列号：占用4个字节长度，用于标识当前报文的序列号。
数据长度：占用4个字节长度，用于指示该报文负载部分的长度。
数据负载：最大长度为512个字节。
3.XP协议下行数据包格式如图6所示。
类型：占用一个字节长度，其值为下行数据包类型。
保留字：占用一个字节长度，用于以后扩展。
连接标识：占用两个字节长度，用于唯一标识一条XP连接。
序列号：占用4个字节长度，用于标识当前报文的序列号。
数据长度：占用4个字节长度，用于指示该报文负载部分的长度。
数据负载：最大长度为1448个字节。
4.XP协议连接请求包格式如图7所示。
类型：占用一个字节长度，其值为连接请求包格式的类型。
保留字：占用一个字节长度，用于以后扩展。
连接标识：占用两个字节长度，用于唯一标识一条XP连接。
序列号：占用4个字节长度，用于标识当前报文的序列号。接收端监听端口号：占用两个字节，用于监听来自客户机的连接请求。
局端监听端口号：占用两个字节，是GW2(局端加速代理)用于监听来自GW1(客户端加速代理)XP连接请求的端口号。
局端XP连接对应端口号：占用两个字节，该端口号对应于一个XP连接，GW2通过该端口指定的套接字发送和接收数据。
接收缓冲区大小：占用两个字节，是指用于接收XP数据缓冲区的大小。
发出连接请求的客户机的IP地址：占用四个字节，对应于客户端局域网内发出TCP请求的客户机的IP地址。
TCP服务器的IP地址：占用四个字节，对应于客户机想要访问的TCP服务器的IP地址。
数据捎带：最大长度为512字节，为了加快XP连接建立过程，可以使用数据捎带，数据捎带内容是TCP服务器相关信息。
5.XP协议连接应答包格式如图8所示。
类型：占用一个字节长度，其值为连接应答包格式类型。
保留字：占用一个字节长度，用于以后扩展。
连接标识：占用两个字节长度，用于唯一标识一条XP连接。
序列号：占用4个字节长度，用于标识当前报文的序列号。
接收网卡的IP地址：占用4个字节长度，该IP地址是用于接收与发送XP数据的网卡的IP地址。
接收端口号：占用两个字节长度，用于接收XP数据的端口号。
接收缓冲区大小：占用两个字节长度，使用接收XP数据缓冲区大小。
6.XP协议SACK(有选择相应)包格式如图9所示
类型：占用一个字节长度，其值为有选择相应类型。
保留字：占用一个字节长度，用于以后扩展。
连接标识：占用两个字节长度，用于唯一标识一条XP连接。
起始序列号：占用四个字节长度，对应于重传的XP数据包的起始序列号。
结束序列号：占用四个字节长度，对应于重传的XP数据包的结束序列号。
7.XP协议NACK(重传请求响应)包格式如图10所示
类型：占用一个字节长度，其值为重传请求响应类型。
保留字：占用一个字节长度，用于以后扩展。
连接标识：占用两个字节长度，用于唯一标识一条XP连接。
结束序列号：占用四个字节，标识已经接收到的对后一个XP数据包的序列号。期待接收的序列号：占用四个字节，标识准备接收的XP数据包序列号的大小。协议实现连接建立
与TCP连接建立的三路握手不同，XP协议采用两路握手机制建立连接，并可以在建立连接的控制报文中捎带数据，从而加快连接建立过程，提高信道吞吐量。
连接的建立必须保证可靠，防止任何死锁、重复和数据丢失等现象。本节将对XP协议的连接建立过程进行描述，并对其可靠性进行分析。连接建立采用方法步骤如下：
XP连接的建立采用非对称方式，由GW1主动发起请求。
1.GW1(客户端加速代理)中驻留有一个监听代理对象。当Client(客户端)发起一个到Server的TCP连接请求时，该连接被GW1(客户端加速代理)中的监听代理对象所截获，并首先在Client(客户端)和GW1(客户端加速代理)之间建立起一条TCP连接。然后GW1(客户端加速代理)创建一个新的连接代理对象来接管并全权负责与新连接相关的所有事务。新的连接代理对象进入XP(加速协议)连接准备状态，并生成一个全局唯一的UDP端口号用于在新连接上接收数据。
2.GW1(客户端加速代理)首先向GW2(局端加速代理)发送一个CONN_REQ，其中包括真正要建立TCP连接的Server端IP地址和端口号，GW1(客户端加速代理)准备(从GW2)接收该新连接数据的IP地址和UDP端口号，以及GW1(客户端加速代理)的UDP接收缓冲区大小。然后GW1(客户端加速代理)等待接收来自GW2(局端加速代理)的连接确认。如果超时未收到连接确认，则重发连接请求，直至达到限定的最高次数后放弃。
3.在GW2(局端加速代理)中也驻留有一个监听代理对象，在周知的UDP端口上接收来自(客户端加速代理)的XP连接请求。当它接收到来自(客户端加速代理)的一个CONN_REQ时，也创建一个新的连接代理对象来接管并全权负责与新连接相关的所有事务。该新的连接代理对象进入XP连接准备状态。它首先生成一个全局唯一的UDP端口号用于在新连接上接收数据，并生成一个全局唯一的标识符(ConnID)用来标识即将建立的XP连接。然后根据接收到的真正Server地址与Server端建立TCP连接。如果TCP连接建立失败，则向GW1(客户端加速代理)发回一个否定性的CONN_ACK，并放弃建立连接；否则向GW1(客户端加速代理)发回一个肯定性的CONN_ACK，其中包括GW2(局端加速代理)准备(从GW1)接收该新连接数据的IP地址和UDP端口号，以及新生成的连接标识符(ConnID)，然后转入连接建立状态(CONNSTAT_ESTABLISHED)。
4.当(客户端加速代理)上新的连接代理对象接收到来自GW2(局端加速代理)的第一个肯定性CONN_ACK后，也随即进入连接建立状态。两路握手可靠性分析
可以分以下几种情况对XP两路握手机制的可靠性进行分析。
(1)GW1(客户端加速代理)发出一个CONN_REQ之后，该报文在到达GW2之前丢失。这种情况下GW1(客户端加速代理)只需要在超时之后重发即可。如果多次发送不成功，则说明链路不可用，只好放弃连接。
(2)GW1(客户端加速代理)发出的CONN_REQ成功到达GW2(局端加速代理)，GW2(局端加速代理)向GW1(客户端加速代理)发回来的否定性CONN_ACK丢失。这种情况下GW2(局端加速代理)已经放弃建立新的连接；GW1(客户端加速代理)在超时重发后要么从GW2(局端加速代理)得到新的否定性CONN_ACK，要么超过重试的最高次数，任何情况下GW1(客户端加速代理)和GW2(局端加速代理)都会放弃建立新的连接，返回CLOSED状态。
(3)GW1(客户端加速代理)发出的CONN_REQ成功到达GW2(局端加速代理)，GW2(局端加速代理)向GW1(客户端加速代理)发回来的肯定性CONN_ACK丢失。这时GW2(局端加速代理)认为已经与GW1(客户端加速代理)建立了新的连接，并且如果有从Server接收到数据的话，会通过该连接向GW1(客户端加速代理)转发。但是GW1(客户端加速代理)由于没有收到CONN_ACK，超时之后它还会向GW2(局端加速代理)发送新的CONN_REQ。GW2(局端加速代理)收到新的CONN_REQ后，会重新创建新的连接代理对象，并向GW1(客户端加速代理)中的同一个连接代理对象返回新的CONN_ACK。在XP协议中，GW1(客户端加速代理)中的某一个连接代理对象只与它收到的第一个CONN_ACK的对方代理对象建立连接，因此它只要在超过限定重试次数之前接收到一个CONN_ACK，就一定能够与GW2(局端加速代理)建立起一条XP连接。但这样会带来一个问题，即在GW2(局端加速代理)上会存在一到多个半连接，也就是说它们自以为与GW1(客户端加速代理)建立了连接，但实际上GW1(客户端加速代理)并未与它们建立连接。解决半连接有以下两种情况。一种半连接从Server接收不到数据，所以也不会向GW1(客户端加速代理)发送数据。由于是半连接，它自然也不会从GW1(客户端加速代理)接收到任何数据。这种半连接在空闲时间超时之后将自动返回CLOSED状态。另一种半连接会从Server接收到数据，因此会向GW1(客户端加速代理)转发。这样不仅浪费带宽资源，而且会影响到GW1(客户端加速代理)端的UDP接收缓冲区。解决的办法是利用XP协议头中的连接标识(ConnID)字段。当GW1(客户端加速代理)上的一个连接代理对象接收到一个报文是，它会首先检查ConnID字段，如果发现与自己的连接标识不一致，它就丢弃该报文，并向GW2(局端加速代理)发回一个控制报文(ABORT)，通知对方拥有该ConnID的连接是一个半连接。GW2(局端加速代理)收到该控制报文后便主动终止该半连接，使其返回到CLOSED状态。
以上三种情况覆盖了XP连接建立的全路径，从而可以保证了两路握手的可靠性。数据传输阶段采用以下方法步骤进行：
GW1(客户端加速代理)和GW2(局端加速代理)进入连接建立状态后，便开始正常的数据传输。由于GW1(客户端加速代理)与GW2(局端加速代理)之间的卫星网络只有一个跳段，不会存在网络拥塞问题，因此XP不采用类似TCP的慢启动算法来减小发送窗口以避免拥塞，而是在数据传输的一开始便采用最大可能的窗口值来发送数据，从而可以充分利用带宽资源，获得最大可能的吞吐量。
在尽量提高信道吞吐量的同时，XP还必须在UDP之上采取必要的连接控制机制，以确保数据传输的可靠性。这些机制主要包括序列号、确认、差错控制、流量控制和拥塞控制等。下面几小节将分别对这些机制进行描述和分析。序列号
进入数据传输阶段后，对每一个从TCP连接接收并需要向XP连接转发的数据报文都进行编号。XP特有的连接建立机制，保证了每一个连接都不可能接收到来自别的连接的数据，因此对于每一个新连接，序列号都从0开始编号，依次递增，且每个序列号标识一个数据报文而不是TCP中的一个字节。基于发送方主动请求的延迟确认
数据发送方每发送出一个数据报文后，必须将该数据报文放入发送窗口队列进行缓存，以备丢失时重传。因此接收方必须对其所收到的数据报文进行确认。一旦发送方收到接收方发回来的对某个数据报文的确认，就表明它已知道接收方已正确接收到了这个数据报文，因此可以将该数据报文从它的发送窗口队列中清除。
TCP协议中要求对每一个报文都进行确认，因为在TCP中需要利用确认来计算超时重传时间(RTO)，并利用确认的超时来判断网络是否拥塞。频繁的确认容易导致非对称网络中反向链路的ACK拥塞。
XP协议采用了一种新的基于发送方主动请求的延迟确认，可以根据传输信道的具体情况计算并使用不同的延迟值，从而解决了非对称网络中上行低速信道拥塞而下行高速信道利用率不高的问题。
具体实现方法为由GW2(局端加速代理)每发送n个数据块后向GW1(客户端加速代理)发出一个ACK请求，主动请求GW1(客户端加速代理)发送ACK。该ACK请求在下行的数据块中捎带，不需增加任何负载。由于XP协议中ACK的主要作用在于释放发送方的发送窗口队列，因此由GW2(局端加速代理)主动发出ACK请求使得GW2(局端加速代理)可以根据每条连接的带宽情况以及自己的缓冲空间利用情况等来灵活调整n的大小。另外GW1(客户端加速代理)只有在GW2(局端加速代理)需要它发送ACK的情况下才进行发送，从而可以有效避免上行链路的带宽拥塞。
上述n的取值需要根据上下行链路的标准化带宽比率(normalizedbandwidth ratio)k来确定。k定义为双向链路的带宽比除以数据包大小比所得的比值。例如，假定下行链路带宽为10Mb/s，下行数据包大小为1518字节，上行链路带宽为34Kb/s，上行ACK包大小为54字节，则k＝(10M/34K)/(1518/54)＝10.5。这就意味着如果在下行链路中每接收不到10.5个数据报文便在上行链路中发送1个ACK，就会导致上行链路带宽饱和而发生拥塞，并反过来影响下行链路的吞吐量。考虑到上行链路中的其它非ACK数据，n的取值还应该在k的基础上适当提高，例如在本例中可以将n的值取定为13。
GW1(客户端加速代理)只有在接收到一个带ACK请求的数据报文时，才向GW2(局端加速代理)发回一个ACK报文。GW2(局端加速代理)根据ACK中的序列号，判断它发送出去的哪些报文GW1(客户端加速代理)已经接收到，并将这些报文从它的发送窗口队列中清除。XP协议不仅实现了普通的累积ACK，而且实现了类似TCP中的SACK(选择性ACK)选项。
基于发送方主动请求的延迟确认算法存在一定的问题，即在一个连接中传输的最后几个报文可能得不到确认。例如，假设GW2(局端加速代理)每发送10个报文后发送一个ACK请求(即n＝10)，且总共发送了105个报文，则最后发出的5个报文不会收到确认。这个问题我们将在连接释放阶段进行解决。基于数据驱动的差错控制
数据发送方如果以某种方式判断出所发出去的数据报文对方没有正确收到，就应该重传该数据报文。
由于采用了延迟确认，因此类似TCP中以时间驱动(即根据ACK的超时)来重传数据的策略实现起来较为困难。为此XP中采取了基于数据驱动的差错控制机制。由于数据收发方之间只有一跳卫星链路，因此可认为数据报文在该链路上的传输是按顺序进行的，不会失序。如果接收方接收到的数据报文序列号之间有间隔，则可认定中间序列号的数据块是在传输过程中上丢失了，而不是因为错序而引起的。这时就可以立即发送NACK，主动请求发送方重传丢失的数据报文。由于在发现有数据丢失时便立即请求重传，因此可以最大限度缩短出错重传的等待时间，进而提高信道吞吐量。
XP处理下行数据出错重传的方法为：GW1(客户端加速代理)接收数据报文，如果其序列号与当前所期待的一致，则直接向Client转发。否则将其先缓存在接收队列，并检查其与接收队列中其它已经接收到的数据报文的序列号是否连续。如果不连续，则向GW2(局端加速代理)发送一个NACK，其中包含在当前接收数据报文之前连续空缺的一段数据报文的首尾序列号。当GW2(局端加速代理)接收到一个NACK后，将按其中指定的序列号范围从发送窗口队列中取出相应数据报文进行重传。
为了防止NACK或者重传的数据报文丢失，当GW1(客户端加速代理)每发送一个NACK时，还需要设置一个定时器。当定时器超时而该NACK所要求的数据报文还没有收到时，就重发该NACK，并重新设定超时。
基于数据驱动的差错控制需要根据连续数据流中下一个接收到的数据报文来判断在其之前的报文是否已经收到，因此当一个数据流中的最后一个或多个报文丢失时，该算法将会无能为力。为此XP在连接释放阶段采取了其它措施来保证数据传输的完全可靠。流量控制和拥塞控制
由于XP建立于UDP之上，而UDP是不可靠的且没有流量控制和拥塞控制。因此XP必须在UDP之上实施自己的流量控制和拥塞控制。
XP中的流量控制主要考虑当GW2(局端加速代理)的发送速度大于GW1(客户端加速代理)的处理速度时，必须对GW2(局端加速代理)的发送速度进行限制。由于GW2(局端加速代理)与GW1(客户端加速代理)之间只有一跳卫星链路，因此XP的拥塞控制只需要考虑当GW2(局端加速代理)从TCP连接接收数据的速率大于GW2(局端加速代理)与GW1(客户端加速代理)之间卫星链路的传输速率时，如何对从TCP接收数据进行限制。
XP中采用基于队列的滑动窗口机制来同时实现流量控制和拥塞控制。以GW2(局端加速代理)为例，它维持有一个发送窗口队列，用于缓存所有已发送但尚未被确认的数据报文。每发送一个报文，便将其加入队尾；每收到一个确认，便将其所确认的报文从队列中取出。为了进行流量控制和拥塞控制，必须为其确定一个最大队列长度，也就是最大窗口尺寸：w。当GW2(局端加速代理)从TCP连接接收到来自Server的数据时，将其打包成XP数据报文，通过XP连接向GW1(客户端加速代理)发送，同时加入发送窗口队列。如果发送窗口队列已满(队列长度等于w)，则置位TCP阻塞标志，不再从TCP连接接收数据。当GW2(局端加速代理)接收到来自GW1(客户端加速代理)的ACK并对发送窗口队列中的数据报文进行确认，从而导致发送窗口队列非满并有一定的空闲空间时，便重新复位TCP阻塞标志，可以继续从TCP连接接收数据。这样就限制了每个XP连接某一时间段最多只能发送固定数量的数据报文，达到了流量控制和拥塞控制的目的。
最大发送窗口尺寸w的取值由两个因素来确定。对于流量控制，为了使高速的发送方不至于淹没低速接收方，发送方的最大发送窗口需受制于接收方的UDP接收缓冲区。这通过在XP连接建立时，由GW1(客户端加速代理)在其发送的CONN_REQ中向GW2(局端加速代理)通报其UDP接收缓冲区大小来实现。设GW1(客户端加速代理)的UDP接收缓冲区大小为R字节，XP下行数据报文的长度为L字节，则GW2(局端加速代理)可根据下列公式计算其最大发送窗口尺寸的一个上限：w1＝R/L。
对于拥塞控制，发送方的最大发送窗口需受制于GW2(局端加速代理)与GW1(客户端加速代理)之间卫星网络的带宽时延乘积，以及当前已建立的连接数。设该带宽时延乘积为M，当前连接数为C，则GW2(局端加速代理)可根据下列公式计算其每个连接的最大发送窗口尺寸的另一个上限：w2＝(M/L)/C。需要注意的是在计算带宽时延乘积时，需要考虑延迟确认所带来的影响。由于一个信道中的连接数是动态变化的，因此w2的取值也是根据网络中连接的不断建立和释放动态变化的。这样既保证了多连接共享带宽的公平性，又可以在任意时刻获得最大吞吐量。
综合考虑这两个因素，则w应取上述两个上限中的最小值，即：w＝min(w1，w2)。
为了在卫星信道上取得最大吞吐量，应该将w设置为w2。这就要求将GW1(客户端加速代理)上的UDP接收缓冲区设置为至少等于中间卫星网络的带宽时延乘积。但这只是针对单个连接而言，如果多个连接共享带宽，则没必要对每个连接都进行这样的设置。连接释放
前文已经提到过的XP基于发送方主动请求的延迟确认和基于数据驱动的差错控制机制在一个数据流的结尾处均存在一些隐患，而这些隐患均可以通过采用正确的连接释放机制来彻底解决。XP采用了一种新的两阶段多次握手的连接释放机制来确保数据传输的可靠性。
可靠连接释放的前提是：连接的每一方都确信自己所发送出去的数据对方已全部收到，而且对方发过来的数据自己也已全部收到。下面以GW2(局端加速代理)主动开始释放连接为例对XP连接释放的可靠性进行分析。
当GW2(局端加速代理)接收到由Server端发来的TCP FIN时，说明GW2(局端加速代理)与Server之间的TCP连接进入了半释放状态，即GW2(局端加速代理)不再能从Server接收到数据，但还可以继续向Server发送数据。这时GW2(局端加速代理)便转入主动预释放状态(PRECLOSE_A)。它首先检查自己的发送窗口队列是否为空，是则向GW1(客户端加速代理)发送CLOSE报文，否则发送PRECLOSE报文。CLOSE和PRECLOSE数据头中均携带有本节点当前期望接收的下一个序列号，它们都同时具有ACK和NACK的作用。当GW1(客户端加速代理)收到PRECLOSE时，进入被动预关闭状态(PRECLOSE_P)。它首先根据其中的序列号对自己的发送窗口队列进行确认，并将发送窗口队列中GW2(局端加速代理)尚未接收到的数据报文全部发送至GW2(局端加速代理)。然后再根据自己的发送窗口队列是否为空向GW2(局端加速代理)发送CLOSE或PRECLOSE报文。当GW2(局端加速代理)收到PRECLOSE时，也做同样的工作。当任何一方收到CLOSE时，首先判断自己是否已发出过CLOSE，是则返回完全释放状态(CLOSED)，释放其两端的XP及TCP连接；否则继续执行上述收到PRECLOSE时的操作，并在发送CLOSE时判断是否已经收到过CLOSE，如果是则也返回完全释放状态(CLOSED)。如此反复一到多次，直到每一方都发出去了一个CLOSE(表明自己发出去的数据对方已全部收到)，并且也收到了一个CLOSE(表明对方发过来的数据自己也已全部收到)时，才可以安全释放XP连接和相关的TCP连接。为了消除因某些意外情况而出现的半连接，在XP连接建立进入数据传输阶段之后，每个GW都对其两端的TCP和XP连接的空闲时间进行定时。如果在一定的时间间隔内没有收到从这些连接发来的任何数据，则主动释放连接，返回完全释放状态(CLOSED)。
本发明提出并实现了一个基于分布式性能提升代理的卫星网络环境TCP(传输控制协议)加速协议：XP协议。它专门针对卫星网络长时延、高误码率和非对称信道等特点进行设计和优化，主要用于在一条端到端TCP连接中透明替代途经单跳段卫星网络的TCP协议。本文对XP协议及其在连接建立、数据传输和连接释放等阶段所采用的一些关键技术进行了描述和分析，其中主要包括：可靠高效的两路握手连接建立算法，基于发送方主动请求的延迟确认算法，基于窗口的流量控制和拥塞控制，和基于两阶段多路握手的连接释放算法。
Claims (10)
1、一种分布式的卫星网络TCP性能加速协议的方法，包括如下步骤：
1)当Client向Server发起TCP连接请求时，GW1客户端加速代理对其进行透明拦截，代理Server与Client建立一条TCP连接；
2)GW1客户端加速代理向GW2局端加速代理发起连接请求，双方建立一条XP加速加速连接；
3)GW2局端加速代理再向Server发起TCP连接请求，代理Client与Server建立一条TCP连接；
4)当Client向Server发送数据时，实际上是首先通过TCP发送至GW1客户端加速代理，GW1客户端加速代理将其转换成为XP后发送至GW2局端加速代理，再由GW2局端加速代将其转换成为TCP协议发送至Server；
5)Server通过TCP连接将数据发送给GW2局端加速代理，GW2局端加速代理将其转换成XP后，发送至GW1客户端加速代理；
6)GW1客户端加速代理收到GW2发送过来的XP数据后，首先将其转换为TCP协议数据，然后通过TCP连接将数据发送至Client。
2、根据权利要求1的分布式的卫星网络TCP性能加速协议的方法，其特征在于，连接建立的步骤如下：
1)GW1客户端加速代理中驻留有一个监听代理对象；当Client客户端发起一个到Server的TCP连接请求时，该连接被GW1客户端加速代理中的监听代理对象所截获，并首先在Client客户端和GW1客户端加速代理之间建立起一条TCP连接；然后GW1客户端加速代理创建一个新的连接代理对象来接管并全权负责与新连接相关的所有事务，新的连接代理对象进入XP加速协议连接准备状态，并生成一个全局唯一的UDP端口号用于在新连接上接收数据；
2)GW1客户端加速代理首先向GW2局端加速代理发送一个CONN_REQ，其中包括真正要建立TCP连接的Server端IP地址和端口号，GW1客户端加速代理准备从GW2接收该新连接数据的IP地址和UDP端口号，以及GW1客户端加速代理的UDP接收缓冲区大小；然后GW1客户端加速代理等待接收来自GW2局端加速代理的连接确认；如果超时未收到连接确认，则重发连接请求，直至达到限定的最高次数后放弃；
3)在GW2局端加速代理中也驻留有一个监听代理对象，在周知的UDP端口上接收来自客户端加速代理的XP连接请求；当它接收到来自客户端加速代理的一个CONN_REQ时，也创建一个新的连接代理对象来接管并全权负责与新连接相关的所有事务，该新的连接代理对象进入XP连接准备状态；它首先生成一个全局唯一的UDP端口号用于在新连接上接收数据，并生成一个全局唯一的标识符(ConnID)用来标识即将建立的XP连接；然后根据接收到的真正Server地址与Server端建立TCP连接；如果TCP连接建立失败，则向GW1客户端加速代理发回一个否定性的CONN_ACK，并放弃建立连接；否则向GW1客户端加速代理发回一个肯定性的CONN_ACK，其中包括GW2局端加速代理准备从GW1接收该新连接数据的IP地址和UDP端口号，以及新生成的连接标识符(ConnID)，然后转入连接建立状态(CONNSTAT_ESTABLISHED)；
4)当客户端加速代理上新的连接代理对象接收到来自GW2局端加速代理的第一个肯定性CONN_ACK后，也随即进入连接建立状态。
3、一种分布式的卫星网络TCP性能加速协议的协议状态转换方法，其步骤如下：
1)XP协议的建立首先从GW1客户端加速代理开始，当GW1客户端加速代理截获到来自Client客户机的TCP连接请求并与Client客户机建立TCP传输控制协议连接后，向GW2局端加速代理发送XP连接请求(CONN_REQ)，进入连接准备状态READY；
2)当GW2局端加速代理接收到来自GW1客户端加速代理的CONN_REQ后，也进入连接准备状态READY，然后试图与Server建立TCP连接；如果TCP连接建立失败，则向GW1客户端加速代理返回一个否定性的XP连接确认(CONN_ACK)，转入连接释放状态(CLOSED)；否则向GW1客户端加速代理发送肯定性的XP连接确认(CONN_ACK)，进入连接建立状态(ESTABLISHED)；
3)当GW1客户端加速代理接收到GW2局端加速代理发回来的CONN_ACK后，如果其中有否定性标志，则转入连接释放状态；否则进入连接建立状态(ESTABLISHED)；
4)数据传输结束后，双方通过两阶段多路握手机制来释放连接，经过预释放状态(PRECLOSE_A或PRECLOSE_P)最后返回至完全释放状态(CLOSED)；
5)在数据传输状态和预释放状态，如果空闲时间超过某个设定值，则返回完全释放状态。
4、一种分布式的卫星网络TCP性能加速协议的格式，其XP协议头格式，包括：
类型：占用一个字节长度，用于指示报文的类型；
保留字：占用一个字节长度，用于以后扩展；
连接标识：ConnID字段在建立连接时由GW2局端加速代理生成，用于在由GW2局端加速代理服务的全局范围内唯一标识一条XP连接；
序列号：占用4个字节长度，用于标识当前报文的序列号。
5、一种分布式的卫星网络TCP性能加速协议的格式，其XP协议上行数据包格式，包括：
类型：占用一个字节长度，其值为上行数据包类型；
保留字：占用一个字节长度，用于以后扩展；
连接标识：占用两个字节长度，用于唯一标识一条XP连接；
序列号：占用4个字节长度，用于标识当前报文的序列号；
数据长度：占用4个字节长度，用于指示该报文负载部分的长度；
数据负载：最大长度为512个字节。
6、一种分布式的卫星网络TCP性能加速协议的格式，其XP协议下行数据包格式，包括：
类型：占用一个字节长度，其值为下行数据包类型；
保留字：占用一个字节长度，用于以后扩展；
连接标识：占用两个字节长度，用于唯一标识一条XP连接；
序列号：占用4个字节长度，用于标识当前报文的序列号；
数据长度：占用4个字节长度，用于指示该报文负载部分的长度；
数据负载：最大长度为1448个字节。
7、一种分布式的卫星网络TCP性能加速协议的格式，其XP协议连接请求包格式，包括：
类型：占用一个字节长度，其值为连接请求包格式的类型；
保留字：占用一个字节长度，用于以后扩展；
连接标识：占用两个字节长度，用于唯一标识一条XP连接；
序列号：占用4个字节长度，用于标识当前报文的序列号；
接收端监听端口号：占用两个字节，用于监听来自客户机的连接请
求；
局端监听端口号：占用两个字节，是GW2局端加速代理用于监听来
自GW1客户端加速代理XP连接请求的端口号；
局端XP连接对应端口号：占用两个字节，该端口号对应于一个XP
连接，GW2通过该端口指定的套接字发送和接收数据；
接收缓冲区大小：占用两个字节，是指用于接收XP数据缓冲区的大小；
发出连接请求的客户机的IP地址：占用四个字节，对应于客户端局域网内发出TCP请求的客户机的IP地址；
TCP服务器的IP地址：占用四个字节，对应于客户机想要访问的TCP服务器的IP地址；
数据捎带：最大长度为512字节，为了加快XP连接建立过程，可以使用数据捎带，数据捎带内容是TCP服务器相关信息。
8、一种分布式的卫星网络TCP性能加速协议的格式，其XP协议连接应答包格式，包括：
类型：占用一个字节长度，其值为连接应答包格式类型；
保留字：占用一个字节长度，用于以后扩展；
连接标识：占用两个字节长度，用于唯一标识一条XP连接；
序列号：占用4个字节长度，用于标识当前报文的序列号；
接收网卡的IP地址：占用4个字节长度，该IP地址是用于接收与发送XP数据的网卡的IP地址；
接收端口号：占用两个字节长度，用于接收XP数据的端口号；
接收缓冲区大小：占用两个字节长度，使用接收XP数据缓冲区大小。
9、一种分布式的卫星网络TCP性能加速协议的格式，其XP协议SACK有选择相应包格式，包括：
类型：占用一个字节长度，其值为有选择相应类型；
保留字：占用一个字节长度，用于以后扩展；
连接标识：占用两个字节长度，用于唯一标识一条XP连接；
起始序列号：占用四个字节长度，对应于重传的XP数据包的起始序列号；
结束序列号：占用四个字节长度，对应于重传的XP数据包的结束序列号。
10、一种分布式的卫星网络TCP性能加速协议的格式，其XP协议NACK重传请求响应包格式，包括：
类型：占用一个字节长度，其值为重传请求响应类型；
保留字：占用一个字节长度，用于以后扩展；
连接标识：占用两个字节长度，用于唯一标识一条XP连接；
结束序列号：占用四个字节，标识已经接收到的对后一个XP数据包的序列号；期待接收的序列号：占用四个字节，标识准备接收的XP数据包序列号的大小。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 03147470 CN1266847C (zh) | 2003-07-14 | 2003-07-14 | 一种分布式的卫星网络tcp性能加速协议格式和方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 03147470 CN1266847C (zh) | 2003-07-14 | 2003-07-14 | 一种分布式的卫星网络tcp性能加速协议格式和方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1476181A true CN1476181A (zh) | 2004-02-18 |
| CN1266847C CN1266847C (zh) | 2006-07-26 |
Family
ID=34156151
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 03147470 Expired - Fee Related CN1266847C (zh) | 2003-07-14 | 2003-07-14 | 一种分布式的卫星网络tcp性能加速协议格式和方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN1266847C (zh) |
Cited By (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101854738A (zh) * | 2010-05-21 | 2010-10-06 | 南京邮电大学 | 一种用于卫星网络的传输控制协议方法 |
| WO2011020397A1 (zh) * | 2009-08-17 | 2011-02-24 | 成都市华为赛门铁克科技有限公司 | 网络代理实现方法及装置 |
| CN102055531A (zh) * | 2009-11-11 | 2011-05-11 | 上海摩波彼克半导体有限公司 | 无线感知网络中提高tcp传输性能的方法 |
| CN101133623B (zh) * | 2004-12-30 | 2011-11-16 | 茨特里克斯系统公司 | 用于提供客户端加速技术的系统和方法 |
| CN102694810A (zh) * | 2012-05-31 | 2012-09-26 | 航天恒星科技有限公司 | 一种卫星网络tcp地面加速方法 |
| CN102739569A (zh) * | 2011-04-01 | 2012-10-17 | 中国科学院空间科学与应用研究中心 | 一种用于卫星通信中的网关及其tcp性能增强的方法 |
| CN102801692A (zh) * | 2011-05-26 | 2012-11-28 | 中国科学院声学研究所 | 一种基于分裂连接的传输控制协议优化方法及系统 |
| CN102820915A (zh) * | 2012-08-01 | 2012-12-12 | 北京佳讯飞鸿电气股份有限公司 | 改善tcp传输性能的卫星链路系统及其使用方法 |
| CN101263670B (zh) * | 2005-07-29 | 2013-05-29 | Atc科技有限责任公司 | 使用不对称前向和返回链路频率再用的卫星通信装置和方法 |
| CN103220206A (zh) * | 2012-01-19 | 2013-07-24 | 阿里巴巴集团控股有限公司 | 一种消息发送方法、装置和一种消息接收方法、装置 |
| US8593954B2 (en) | 2008-07-16 | 2013-11-26 | Huawei Technologies Co., Ltd. | Method and apparatus for controlling congestion of wireless multi-hop network |
| CN104092707A (zh) * | 2014-07-31 | 2014-10-08 | 中国电子科技集团公司第五十四研究所 | 基于分块校验与确认的卫星网络tcp协议性能增强方法 |
| CN104243097A (zh) * | 2014-09-19 | 2014-12-24 | 东软集团股份有限公司 | 基于卫星网络的数据传输方法及系统 |
| CN104540040A (zh) * | 2015-01-21 | 2015-04-22 | 冯山泉 | 一种通过卫星传输ktv数据的方法及系统 |
| CN105490729A (zh) * | 2015-11-26 | 2016-04-13 | 中国航天空气动力技术研究院 | 一种基于卫星链路的一对多数据传输系统及方法 |
| WO2016119464A1 (zh) * | 2015-01-26 | 2016-08-04 | 中兴通讯股份有限公司 | 一种卫星网络环境下实现tcp传输的方法及相应的网关 |
| CN105897452A (zh) * | 2015-08-12 | 2016-08-24 | 乐视云计算有限公司 | 一种数据重传方法及装置 |
| CN109257418A (zh) * | 2018-08-22 | 2019-01-22 | 西安电子科技大学 | 一种基于移动可靠传输代理的分段可靠传输方法 |
| CN110290030A (zh) * | 2019-08-12 | 2019-09-27 | 北京字节跳动网络技术有限公司 | 网络状态检测方法、装置、电子设备及计算机可读介质 |
| CN110830472A (zh) * | 2019-11-07 | 2020-02-21 | 西北工业大学 | 基于tcp/ip协议的灵活数据传输协议的灵活数据传输方法 |
| CN111262845A (zh) * | 2020-01-13 | 2020-06-09 | 中科全维科技(苏州)有限公司 | 一种面向通信端的移动端通信框架、系统和方法 |
| CN114143382A (zh) * | 2021-11-30 | 2022-03-04 | 北京天融信网络安全技术有限公司 | 一种双边加速数据传输方法及系统 |
| CN114244822A (zh) * | 2021-12-17 | 2022-03-25 | 八维通科技有限公司 | 一种基于通信协议的消息传输系统及传输方法 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1946078B (zh) * | 2006-10-27 | 2010-08-11 | 清华大学 | 一种适用于卫星网络的高效交互传输方法 |
-
2003
- 2003-07-14 CN CN 03147470 patent/CN1266847C/zh not_active Expired - Fee Related
Cited By (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101133623B (zh) * | 2004-12-30 | 2011-11-16 | 茨特里克斯系统公司 | 用于提供客户端加速技术的系统和方法 |
| CN101263670B (zh) * | 2005-07-29 | 2013-05-29 | Atc科技有限责任公司 | 使用不对称前向和返回链路频率再用的卫星通信装置和方法 |
| US8593954B2 (en) | 2008-07-16 | 2013-11-26 | Huawei Technologies Co., Ltd. | Method and apparatus for controlling congestion of wireless multi-hop network |
| WO2011020397A1 (zh) * | 2009-08-17 | 2011-02-24 | 成都市华为赛门铁克科技有限公司 | 网络代理实现方法及装置 |
| US8694651B2 (en) | 2009-08-17 | 2014-04-08 | Chengdu Huawei Symantec Technologies Co., Ltd. | Method and system for implementing network proxy |
| CN102055531A (zh) * | 2009-11-11 | 2011-05-11 | 上海摩波彼克半导体有限公司 | 无线感知网络中提高tcp传输性能的方法 |
| CN102055531B (zh) * | 2009-11-11 | 2013-09-25 | 上海摩波彼克半导体有限公司 | 无线感知网络中提高tcp传输性能的方法 |
| CN101854738A (zh) * | 2010-05-21 | 2010-10-06 | 南京邮电大学 | 一种用于卫星网络的传输控制协议方法 |
| CN101854738B (zh) * | 2010-05-21 | 2012-10-24 | 南京邮电大学 | 一种用于卫星网络的传输控制协议方法 |
| CN102739569B (zh) * | 2011-04-01 | 2015-04-15 | 中国科学院空间科学与应用研究中心 | 一种用于卫星通信中的网关及其tcp性能增强的方法 |
| CN102739569A (zh) * | 2011-04-01 | 2012-10-17 | 中国科学院空间科学与应用研究中心 | 一种用于卫星通信中的网关及其tcp性能增强的方法 |
| CN102801692A (zh) * | 2011-05-26 | 2012-11-28 | 中国科学院声学研究所 | 一种基于分裂连接的传输控制协议优化方法及系统 |
| CN102801692B (zh) * | 2011-05-26 | 2016-05-18 | 中国科学院声学研究所 | 一种基于分裂连接的传输控制协议优化方法及系统 |
| CN103220206A (zh) * | 2012-01-19 | 2013-07-24 | 阿里巴巴集团控股有限公司 | 一种消息发送方法、装置和一种消息接收方法、装置 |
| CN103220206B (zh) * | 2012-01-19 | 2017-04-19 | 阿里巴巴集团控股有限公司 | 一种消息发送方法、装置和一种消息接收方法、装置 |
| CN102694810A (zh) * | 2012-05-31 | 2012-09-26 | 航天恒星科技有限公司 | 一种卫星网络tcp地面加速方法 |
| CN102694810B (zh) * | 2012-05-31 | 2014-10-08 | 航天恒星科技有限公司 | 一种卫星网络tcp地面加速方法 |
| CN102820915B (zh) * | 2012-08-01 | 2014-11-05 | 北京佳讯飞鸿电气股份有限公司 | 改善tcp传输性能的卫星链路系统及其使用方法 |
| CN102820915A (zh) * | 2012-08-01 | 2012-12-12 | 北京佳讯飞鸿电气股份有限公司 | 改善tcp传输性能的卫星链路系统及其使用方法 |
| CN104092707B (zh) * | 2014-07-31 | 2017-09-12 | 中国电子科技集团公司第五十四研究所 | 基于分块校验与确认的卫星网络tcp协议性能增强方法 |
| CN104092707A (zh) * | 2014-07-31 | 2014-10-08 | 中国电子科技集团公司第五十四研究所 | 基于分块校验与确认的卫星网络tcp协议性能增强方法 |
| CN104243097A (zh) * | 2014-09-19 | 2014-12-24 | 东软集团股份有限公司 | 基于卫星网络的数据传输方法及系统 |
| CN104540040A (zh) * | 2015-01-21 | 2015-04-22 | 冯山泉 | 一种通过卫星传输ktv数据的方法及系统 |
| WO2016119464A1 (zh) * | 2015-01-26 | 2016-08-04 | 中兴通讯股份有限公司 | 一种卫星网络环境下实现tcp传输的方法及相应的网关 |
| CN105897665A (zh) * | 2015-01-26 | 2016-08-24 | 中兴通讯股份有限公司 | 一种卫星网络环境下实现tcp传输的方法及相应的网关 |
| CN105897665B (zh) * | 2015-01-26 | 2020-01-14 | 中兴通讯股份有限公司 | 一种卫星网络环境下实现tcp传输的方法及相应的网关 |
| CN105897452A (zh) * | 2015-08-12 | 2016-08-24 | 乐视云计算有限公司 | 一种数据重传方法及装置 |
| CN105490729B (zh) * | 2015-11-26 | 2018-10-09 | 中国航天空气动力技术研究院 | 一种基于卫星链路的一对多数据传输系统及方法 |
| CN105490729A (zh) * | 2015-11-26 | 2016-04-13 | 中国航天空气动力技术研究院 | 一种基于卫星链路的一对多数据传输系统及方法 |
| CN109257418A (zh) * | 2018-08-22 | 2019-01-22 | 西安电子科技大学 | 一种基于移动可靠传输代理的分段可靠传输方法 |
| CN109257418B (zh) * | 2018-08-22 | 2021-07-13 | 西安电子科技大学 | 一种基于移动可靠传输代理的分段可靠传输方法 |
| CN110290030A (zh) * | 2019-08-12 | 2019-09-27 | 北京字节跳动网络技术有限公司 | 网络状态检测方法、装置、电子设备及计算机可读介质 |
| CN110830472A (zh) * | 2019-11-07 | 2020-02-21 | 西北工业大学 | 基于tcp/ip协议的灵活数据传输协议的灵活数据传输方法 |
| CN111262845A (zh) * | 2020-01-13 | 2020-06-09 | 中科全维科技(苏州)有限公司 | 一种面向通信端的移动端通信框架、系统和方法 |
| CN111262845B (zh) * | 2020-01-13 | 2022-05-17 | 中科全维科技(苏州)有限公司 | 一种面向通信端的移动端通信框架、系统和方法 |
| CN114143382A (zh) * | 2021-11-30 | 2022-03-04 | 北京天融信网络安全技术有限公司 | 一种双边加速数据传输方法及系统 |
| CN114244822A (zh) * | 2021-12-17 | 2022-03-25 | 八维通科技有限公司 | 一种基于通信协议的消息传输系统及传输方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1266847C (zh) | 2006-07-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1266847C (zh) | 一种分布式的卫星网络tcp性能加速协议格式和方法 | |
| CN1155901C (zh) | 补偿通信协议缺陷的拦截方法和系统 | |
| CN1227854C (zh) | 用于蜂窝电信的链路层确认和重发 | |
| CN102823202B (zh) | 用于通信网络中的拥塞处理的方法和网络组件 | |
| Allman et al. | Ongoing TCP research related to satellites | |
| DK2315383T3 (en) | Method and apparatus for submitting a status report | |
| CN1426647A (zh) | 无线网络系统和方法 | |
| US20040052234A1 (en) | Method and system for dispatching multiple TCP packets from communication systems | |
| CN1112016C (zh) | 通信方法和系统 | |
| US20030131079A1 (en) | Performance enhancing proxy techniques for internet protocol traffic | |
| CN1561615A (zh) | 采用重传定时器改善传输协议性能的方法 | |
| CN1728671A (zh) | 服务器设备及其控制方法和使用该服务器建立连接的方法 | |
| JP2000224261A (ja) | ネットワ―ク層プロトコルを直接サポ―トするデ―タリンク制御プロトコルおよび方法 | |
| CN1778079A (zh) | 用于协调tcp/ip网络与其他网络之间的流控制的方法和设备 | |
| EP1418709A4 (en) | SENDING DEVICE AND SENDING METHOD | |
| CN1636364A (zh) | 通过通用分组无线服务无线网络传输数据 | |
| JPWO2007052764A1 (ja) | セッション中継装置およびセッション中継方法 | |
| WO2002089425A1 (en) | Data communication method, data communication system and program | |
| Wang et al. | Use of TCP decoupling in improving TCP performance over wireless networks | |
| CN101162968A (zh) | 前向通用路由封装包的乱序调整方法 | |
| JP4953965B2 (ja) | 通信システム、通信装置およびパケット伝送方法 | |
| CN103905331A (zh) | 一种实时媒体数据传输方法、装置及系统 | |
| US8102768B2 (en) | Method and system for traffic flow control in a communication network | |
| Ding et al. | Delay performance of the new explicit loss notification TCP technique for wireless networks | |
| WO2009140862A1 (zh) | 用于网络或协作mimo系统中的基站及其harq方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| ASS | Succession or assignment of patent right |
Owner name: BEIJING DINGSOFT TECHNOLOGY CO., LTD. Free format text: FORMER OWNER: INST. OF COMPUTING TECHNOLOGY, CHINESE ACADEMY OF SCIENCES Effective date: 20110110 Owner name: BEIJING DONGFANGJIANYU INSTITUTE OF CONCRETE SCIEN |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 100080 NO. 6, KEXUEYUAN SOUTH ROAD, ZHONGGUANCUN, BEIJING TO: 100080 ROOM 1701, NO. 9, N.4TH RING WEST ROAD, HAIDIAN DISTRICT, BEIJING |
|
| TR01 | Transfer of patent right |
Effective date of registration: 20110110 Address after: 100080, room 9, No. 1701 West Fourth Ring Road, Haidian District, Beijing Co-patentee after: Beijing Dongfangjianyu Institute of Concrete Science & Technology Limited Compan Patentee after: Beijing Dingsoft Technology Co.,Ltd. Co-patentee after: Beijing Xinao Concrete Group Co.,Ltd. Address before: 100080 No. 6 South Road, Zhongguancun Academy of Sciences, Beijing Patentee before: Institute of Computing Technology, Chinese Academy of Sciences |
|
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20060726 Termination date: 20180714 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |