CN101841468B - 数据流报文发送控制方法及装置 - Google Patents

数据流报文发送控制方法及装置 Download PDF

Info

Publication number
CN101841468B
CN101841468B CN2010101268599A CN201010126859A CN101841468B CN 101841468 B CN101841468 B CN 101841468B CN 2010101268599 A CN2010101268599 A CN 2010101268599A CN 201010126859 A CN201010126859 A CN 201010126859A CN 101841468 B CN101841468 B CN 101841468B
Authority
CN
China
Prior art keywords
message
receiving terminal
rise
sequence
rate
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
Application number
CN2010101268599A
Other languages
English (en)
Other versions
CN101841468A (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.)
Beijing Zhigu Tech Co Ltd
Original Assignee
Beijing Star Net Ruijie Networks Co Ltd
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 Beijing Star Net Ruijie Networks Co Ltd filed Critical Beijing Star Net Ruijie Networks Co Ltd
Priority to CN2010101268599A priority Critical patent/CN101841468B/zh
Publication of CN101841468A publication Critical patent/CN101841468A/zh
Application granted granted Critical
Publication of CN101841468B publication Critical patent/CN101841468B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种数据流报文发送控制方法及装置,该方法包括:当判断出接收到的数据报文的报文序列号大于接收端的接收缓冲上限时,判断接收端的接收缓冲上限的增长速率是否大于等于发送端报文序列号增长速率;若接收端的接收缓冲上限的增长速率大于等于发送端报文序列号增长速率,转发所述数据报文至接收端;否则丢弃所述数据报文。该方法有效的避免了合法报文被丢弃和拦截的问题,提高了报文转发效率,节约了系统资源。

Description

数据流报文发送控制方法及装置
技术领域
本发明涉及互联网技术领域,尤指一种用于在线数据流检查过滤的数据流报文发送控制方法及装置。
背景技术
在互联网中的在线数据流传输过程中,防火墙跟踪完整的数据交互过程,在一定的上下文环境中,审核数据交互过程中双方每个往来报文的合法性,根据规则允许或阻止报文通过。防火墙可以通过流记录来记录数据交互过程中的上下文环境。
传输控制协议(Transmission Control Protocol,TCP协议)是一种通过设置报文序列号来保证传送的数据流报文的数据包的有序性的、可靠的面向连接的数据流协议。TCP协议中,防火墙通过“窗口”(window)的概念来进行流量控制,实现数据流报文的过滤功能。“窗口”就是接收端所能提供的缓冲区大小。即当发送端发送数据的速度很快而接收端接收速度很慢的情况下,为了保证数据不丢失,需要进行流量控制,来协调好通信双方的工作节奏。
例如:TCP报文的一次数据交互过程一般是以SYN报文开始的,防火墙收到该报文后创建一个流记录,然后,接收端会返回SYNACK响应报文,符合该交互过程的报文是合法报文,否则为非法报文,从而决定报文的取舍。同时,TCP协议中利用接收窗口来告诉发送端能为它所发送的数据提供多大的缓冲区。利用窗口大小和接收到的报文序列号计算出接收端最大可接收的数据序列号,来控制数据流量。现有的TCP报文序列号检查算法包含如下规则:
1)每条报文的报文序列号(Sequence number)与该报文的数据长度(n)之和不允许超过接收端当前的接收缓冲上限,即:
Seq < = max pktssentbyDst , seenbyFireWALL { Ack + max ( win , 1 ) }
其中,接收端当前接收缓冲的上限为当前已经通过防火墙的所有接收端接收报文的确认序列号与接收窗口的长度之和的最大值。防火墙根据接收端接收到报文后的响应报文得到确认序列号,接收窗口的长度为设定值,并随着确认序列号的更新而移动。
例如:Max(win,1)表示:如果某条报文的window域值是0,则该报文窗口大小取值为1。
也就是说通过防火墙发往接收端的每条报文必须满足:报文序列号不大于当前已经通过防护墙的所有“接收报文的确认序列号与窗口大小之和”的最大值。
2)每条报文的序列号(Sequence number)与报文数据长度(n)之和的下限保证接收端已经收到的报文不应被重发,即:
Seq + n > = max pktssentbySrc , seenbyFireWAL { Seq + n } - max pktssentbyDst , seenbyFirewall { max ( win , 1 ) }
防火墙每接收到一条报文,计算报文序列号与报文的用户数据长度之和,并记录计算得到的所有和值中的最大值。同时,防火墙每接收到一条报文,记录所声明窗口的最大值。
通过防火墙发往接收端的每条报文必须满足:报文序列号与数据长度之和≥当前已经通过防火墙的所有“发送端报文的序列号与数据长度之和”的最大值与当前已经通过防火墙的所有接收端报文窗口最大值之差。
3)确认序列号(Acknowledgement number)的上限只允许响应报文确认已经接收到的数据,即:
Ack < = max pktssentbyDst , seenbyfireWALL { Seq + n }
通过防火墙的每条报文必须满足:确认序列号不大于所有“当前已经通过防火墙的接收端报文的序列号与数据长度之和”的最大值。
4)确认序列号(Ack number)的下限最大限度避免延迟的响应报文被错误阻挡。即
Ack > = max pktssentbyDst , seenbyFireWAL { Seq + n } - MAXACKWINDOW
其中,MAXACKWINDOW一般取值为66000。通常TCP协议报文的报头的WINDOW域占16位,二进制中的16位能表示的最大值是65535。因此,MAXACKWINDOW取值为66000时几乎等同于对报文的下限不做设置。
防火墙根据上述TCP序列号检查算法对通过的报文进行合法性检测,通过检测通讯双方当前已通过防火墙的所有报文的确认序列号与接收窗口之和的最大值、报文序列号与报文数据长度之和的最大值、当前已经通过防火墙的报文所声明的窗口的最大值,确定出当前接收到报文是否是符合转发规则的合法报文。
上述方式,当发送端不顾接收端声明的接收窗口大小,而持续、高速、大量地发送报文,对报文接收端进行攻击时,能够有效的起到防止攻击的作用,避免过度消耗接收端的带宽。当然也会导致防火墙频繁检测报文是是否落在窗口内,从而消耗系统的计算资源。
但上述方式,由于其第1)条规则过于严格,当接收端未来得及及时回复响应报文时,发送端已经开始发送下一条报文时,由于报文确认序列号尚未得到及时更新,从而会导致接收端发送的下一条报文在第1)条检测规则时被检测为不合法,从而防火墙会将该合法的报文丢弃。具体举例分析如下:
(1)防火墙收到接收端(B端)的响应报文P_B1,确认序列号为ACK_B1,则防火墙计算其确认序列号与接收窗口长度之和(ACK_B1+WIN_B1),并与之前计算的到的该接收端的所有确认序列号与接收窗口长度之和比较得到一个最大值,并将流记录中的确认序列号与接收窗口长度之和的最大值更新为新得到ACK_B1+WIN_B1。
(2)然后,防火墙接收到来自发送端(A端)的报文P_A1,其报文序列号为SEQ_A1。假设ACK_B1<SEQ_A1<ACK_B1+WIN_B1,则说明该报文的报文序列号满足上述第1)条规则,落在接收端的接收缓冲窗口内。
且如果该报文数据长度为N_A1,其对应的响应报文的确认序列号为ACK_A1,假设N_A1和ACK_A1满足第2)、3)、4)条规则,则该报文能够通过防火墙。
(3)B端接收到报文P_A1后,发送确认其已收到报文P_A1的响应报文P_B2,P_B2的确认序列号一定是SEQ_A1+N_A1。此处假设响应报文P_B2的窗口长度为WIN_B2。
(4)如果防火墙在接收到响应报文P_B2之前,又收到来自A端的报文P_A2,其报文序列号为SEQ_A1+N_A1,其报文数据长度为N_A2。
此时防火墙由于没有接收到响应报文P_B2,因此其缓冲上限未更新,仍为ACK_B1+WIN_B1,假设SEQ_A1+N_A1>ACK_B1+WIN_B1,即报文序列号大于了接收端的缓冲上限,则报文P_A2的报文序列号不符合第1)条规则,防火墙将会丢弃该报文。
如果防火墙在接收到响应报文P_B2之后,才接收到报文P_A2,则此时由于根据新接收到的确认报文得到的缓冲上限SEQ_A1+N_A1+WIN_B2大于原来的缓冲上限ACK_B1+WIN_B1,防火墙的缓冲上限已经更新为SEQ_A1+N_A1+WIN_B2,则接收到的报文P_A2,其报文序列号SEQ_A1+N_A1小于更新后的缓冲上限SEQ_A1+N_A1+WIN_B2,则P_A2是合法的,可以通过防火墙发往接收端。
可见,报文P_A2被丢弃的原因是防火墙没有及时收到接收端的响应报文,更新接收缓冲上限,从而导致该合法的报文被丢弃。
发明内容
本发明提供一种数据流报文发送控制方法及装置,用以解决现有技术中存在数据流报文发送控制过程中控制策略过于严格导致合法报文被丢弃的问题。
一种数据流报文发送控制方法,包括:
当判断出接收到的数据报文的报文序列号大于接收端的接收缓冲上限时,判断接收端的接收缓冲上限的增长速率是否大于等于发送端报文序列号增长速率;
若接收端的接收缓冲上限的增长速率大于等于发送端报文序列号增长速率,转发所述数据报文至接收端;否则丢弃所述数据报文。
一种数据流报文发送控制装置,包括:
第一判断模块,用于判断出接收到的数据报文的报文序列号是否大于接收端的接收缓冲上限;
第二判断模块,用于当第一判断模块判断出接收到的数据报文的报文序列号超过接收端的接收缓冲上限时,判断接收端的接收缓冲上限的增长速率是否大于等于发送端报文序列号增长速率;
执行模块,用于若第二判断模块判断出接收端的接收缓冲上限的增长速率大于等于发送端报文序列号增长速率,转发所述数据报文至接收端;否则丢弃所述数据报文。
一种网络设备,包括:上述的数据流报文发送控制装置。
本发明有益效果如下:
本发明提供的数据流报文发送控制方法及装置,通过当判断出接收到的数据报文的报文序列号大于接收端的接收缓冲上限时,判断接收端的接收缓冲上限的增长速率是否大于等于发送端报文序列号增长速率;若接收端的接收缓冲上限的增长速率大于等于发送端报文序列号增长速率,转发所述数据报文至接收端;否则丢弃所述数据报文。该方法当接收到的数据报文的报文序列号超过接收端的接收缓冲上限时,不直接进行过滤,进一步判断接收缓冲上限的增长速率与发送端报文序列号增长速率的大小关系,再决定是否丢弃报文,有效的避免了合法报文被丢弃和拦截的问题,减少合法报文被误拦截的发生概率,提高了报文转发效率,节约了系统资源。
附图说明
图1为本发明实施例一中数据流报文发送控制方法的流程图;
图2为本发明实施例二中数据流报文发送控制方法示例的流程图;
图3为本发明实施例中数据流报文发送控制装置的结构示意图。
具体实施方式
本申请实施例提供一种数据流报文发送控制方法,防火墙在对报文进行合法性检测时,改变原有检测标准过于严格的做法,在报文序列号超过接收端接收缓冲上限时,进一步检测报文序列号的增长速率和接收端的响应报文确认序列号的增长速率,从而避免防火墙没有及时接收到确认序列号没有及时更新缓冲上限时,导致的合法报文被丢弃的问题。
实施例一
本申请实施例一提供的数据流报文发送控制方法,其流程如图1所示,执行步骤如下:
步骤S101:防火墙接收发送端发送的数据报文。
防火墙每接收到发送端发送的一条数据报文,均会在该数据报文所属的流记录中记录其报文序列号和数据长度。
步骤S102:判断接收到的数据报文的序列号是否超过(即大于)接收端的缓冲上限。
防火墙接收到发送端发送的数据报文后,首先根据该报文的序列号按照现有技术中的第1)条规则判断其序列号是否超过了接收端的缓冲上限。其中,接收端的接收缓冲上限根据接收端的接收缓冲窗口的长度和已确认接收到的数据报文所对应的响应报文的确认序列号确定,即接收缓冲窗口随着接收到的数据报文所对应的响应报文的确认序列号的更新,向前移动。因此,判断的过程具体包括:
计算接收端接收到数据报文后返回的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和。
确定得到的数据报文的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和的最大值,作为接收端的接收缓冲上限。
比较接收到的数据报文的报文序列号与确定出的接收缓冲上限的大小。即比较接收到的数据报文的报文序列号是否大于确定出的接收缓冲上限,大于时,确定接收到的数据报文的序列号是否超过了接收端的缓冲上限。
若是接收到的数据报文的报文序列号超过确定出的接收缓冲上限,执行步骤S103,若否,执行步骤S106。
步骤S103:确定接收端的接收缓冲上限的增长速率和发送端的报文序列号增长速率。
防火墙根据发送端发送的数据报文的发送时间,计算数据报文的报文序列号增长速率,具体包括:
接收到发送端发送的数据报文时,记录数据报文的发送时间。
选取从最新接收到的数据报文发送时间开始,之前的设定时间长度范围内的一个发送报文。可以选择和最新接收到的数据报文相邻的上一个数据报文,也可以选择和最新接收到的数据报文间隔至少一个数据报文的数据报文。由于防火墙只会在流记录中记录一段时间内的数据报文的信息,因此,设定的时间长度范围一般不超过防火墙所记录数据报文的时间段的范围。
根据选取的发送报文的发送时间和报文序列号,以及最新接收到的数据报文的报文序列号和发送时间,计算发送端发送数据报文的报文序列号的增长速率。
防火墙根据接收端返回的响应报文的返回时间,计算响应报文的确认序列号增长速率,得到接收端的接收缓冲上限增长速率,具体包括:
接收到接收端返回的响应报文时,记录响应报文的返回时间。
选取从最新接收到的响应报文返回时间开始,之前的设定时间长度范围内的一个响应报文。可以选择和最新接收到的响应报文相邻的上一个数据报文,也可以选择和最新接收到的响应报文间隔至少一个响应报文的响应报文。由于防火墙只会在流记录中记录一段时间内的响应报文的信息,因此,设定的时间长度范围一般不超过防火墙所记录响应报文的时间段的范围。
根据选取的响应报文的返回时间点和确认序列号,以及最新接收到的响应报文的确认序列号和返回时间点,计算接收端的响应报文的确认序列号的增长速率,得到接收端缓冲上限的增长速率。
步骤S104:比较得到的接收缓冲上限的增长速率和报文序列号增长速率的大小。
若接收端的接收缓冲上限增长速率大于等于发送端的报文序列号增长速率,则执行步骤S106;否则,执行步骤S105。
步骤S105:丢弃接收到的数据报文。
步骤S106:将接收到的数据报文转发给对应的接收端。
当然,较佳的,在将数据报文发送给接收端之前,需要判断报文是否符合现有的第2)、3)、4)条规则。此为现有协议中已有的做法,此处不再赘述。
较佳的,防火墙将接收到的数据报文发送给接收端,还包括:
步骤S107:接收接收端返回的响应报文,发送给发送端。
将接收到的数据报文发送给接收端之后,防火墙还会将接收端返回的响应报文,转发给发送端。
同时,防火墙还会根据接收到的响应报文的确认序列号和接收端的接收缓冲窗口的长度实时更新接收端的接收缓冲上限。其中,响应报文的确认序列号等于数据报文的报文序列号与数据报文的报文数据长度之和。
也就是说,防火墙每接收到接收端返回的一条响应报文,均会记录报文的确认序列号和接收缓冲窗口的长度值,并计算确认序列号与接收缓冲窗口的长度值之和,如果计算得到的和值超过原来的接收缓冲上限,则更新接收端的接收缓冲上限为计算得到的和值。从而实现确定得到的数据报文的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和的最大值,作为接收端的接收缓冲上限这一目的。
实施例二
本申请实施例二提供一种数据流报文发送控制的具体实现过程示例,其流程如图2所示,执行步骤如下:
步骤S201:防火墙接收到接收端返回的响应报文P_B1。
防火墙收到接收端(B端)的响应报文P_B1,防火墙将响应报文P_B1转发给发送端,同时记录该响应报文的确认序列号和接收端的接收缓冲窗口的长度。例如:该响应报文的确认序列号为ACK_B1,则防火墙计算其确认序列号与接收窗口长度之和(ACK_B1+WIN_B1)。
然后,防火墙将计算得到的和与之前计算的到的该接收端的所有确认序列号与接收窗口长度之和比较得到一个最大值,并将流记录中的确认序列号与接收窗口长度之和的最大值更新为新得到ACK_B1+WIN_B1。
步骤S202:防火墙接收发送端发送的数据报文P_A1。
然后,防火墙接收到来自发送端(A端)的报文P_A1,并记录其报文序列号为SEQ_A1。
步骤S203:判断出接收到的数据报文P_A1的序列号未超过接收端的缓冲上限。
假设ACK_B1<SEQ_A1<ACK_B1+WIN_B1,则说明该报文的报文序列号满足上述第1)条规则,落在接收端的接收缓冲窗口内,即接收到的数据报文P_A1的序列号没有超过接收端的缓冲上限。
且如果该报文数据长度为N_A1,其对应的响应报文的确认序列号为ACK_A1,假设N_A1和ACK_A1满足现有技术中的第2)、3)、4)条规则,则该报文能够通过防火墙。
步骤S204:防火墙等待接收端返回响应报文P_B2。
接收端(B端)接收到报文P_A1后,应该发送确认其已收到报文P_A1的响应报文P_B2,P_B2的确认序列号一定是SEQ_A1+N_A1。此处假设响应报文P_B2的窗口长度为WIN_B2。
步骤S205:防火墙接收发送端发送的数据报文P_A2。
如果防火墙在接收到响应报文P_B2之前,又收到来自A端的报文P_A2,并记录其报文序列号为SEQ_A1+N_A1,其报文数据长度为N_A2。
步骤S206:判断出接收到的数据报文P_A2的序列号超过了接收端的缓冲上限。
此时防火墙由于没有接收到响应报文P_B2,因此其缓冲上限未更新,仍为ACK_B1+WIN_B1,假设报文序列号SEQ_A1+N_A1>ACK_B1+WIN_B1,则报文P_A2的报文序列号不符合第1)条规则,即接收到的数据报文P_A2的序列号超过了接收端的缓冲上限。
步骤S207:确定接收端的接收缓冲上限的增长速率(RECV_MAX_RATE)和发送端的报文序列号增长速率(SEND_MAX_RATE)。
例如:防火墙根据记录的数据报文的发送时间,计算数据报文P_A1和P_A2的报文序列号之差和发送时间之差,并用报文序列号之差除以发送时间之差,得到发送端的报文序列号增长速率V1。
当然也可以选择数据报文P_A2和此前一段时间范围内的一个数据报文进行计算。
同时,防火墙根据记录的响应报文的返回时间,计算响应报文P_B1和此前一段时间范围内的一个响应报文的确认序列号之差和返回时间之差,并用确认序列号之差除以返回时间之差,得到接收端的响应报文确认序列号的增长速率,作为接收端的接收缓冲上限的增长速率V2。
防火墙也可以在每次接收到数据报文时计算发送端的报文序列号增长速率,在每次接收到响应报文时计算接收端的接收缓冲上限的增长速率,并保存在流记录中记录,当需要时直接调用即可。
步骤S208:比较得到的接收缓冲上限的增长速率和报文序列号增长速率的大小。
若接收端的接收缓冲上限增长速率大于等于发送端的报文序列号增长速率,则执行步骤S210;否则,执行步骤S209。
例如:上述计算的到的V2大于等于V1,则执行步骤S210;否则,执行步骤S209。
步骤S209:丢弃接收到的数据报文。
步骤S210:将接收到的数据报文转发给对应的接收端。
上述计算的到的V2大于等于V1时,数据报文P_A2不会被认为是非法报文而丢弃,而是会发送给接收端。
原有的TCP协议的报文序列号检查算法以“报文序列号不超过接收端接收缓冲上限”为唯一标准,对报文进行过滤,本申请则放宽过滤标准,在报文序列号超过接收端接收缓冲上限,且接收端接收缓冲上限增长速率小于发送端报文序列号增长速率时,才进行拦截和丢弃,使得当接收端来不及告知防火墙其接收缓冲上限已经增长,防火墙可以根据所记录的接收端接收缓冲上限增长速率,判断出其接收缓冲上限“极有可能”已经增长,于是转发当前的发送端报文。
当接收端出于某种原因,接收窗口不再移动,与现有算法相比,本改进方案会导致误放行几条接收端不愿接收的数据报文,直到接收端接收缓冲上限增长速率小于发送端报文序列号增长速率时为止。接收端可以并丢弃这几条报文,其操作开销不大,对系统性能不会有影响。而且一般只有接收端操作系统出现致命故障,比如磁盘空间满等,才会导致接收端在接收过程中接收窗口停止移动,属于小概率事件。因此,本申请以可能存在的极微小的代价获得了更高的报文转发速率,减少了合法报文被拦截的可能性。
根据本申请实施例提供的上述数据流报文发送控制方法,可以构建一种数据流报文发送控制装置,如图3所示,包括:第一判断模块10、第二判断模块20和执行模块30。
第一判断模块10,用于判断出接收到的数据报文的报文序列号是否大于接收端的接收缓冲上限。
较佳的,第一判断模块10,具体包括:第一计算单元101、第一确定单元102和第一比较单元103。
第一计算单元101,用于计算接收端接收到数据报文后返回的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和。
第一确定单元102,用于确定得到的数据报文的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和的最大值,作为接收端的接收缓冲上限。
第一比较单元103,用于比较接收到的数据报文的报文序列号是否大于确定出的接收缓冲上限。
第二判断模块20,用于当第一判断模块10判断出接收到的数据报文的报文序列号超过接收端的接收缓冲上限时,判断接收端的接收缓冲上限的增长速率是否大于等于发送端报文序列号增长速率。
较佳的,第二判断模块20,具体包括:第二计算单元201、第二确定单元202和第二比较单元203。
第二计算单元201,用于根据接收端返回的响应报文的返回时间,计算响应报文的确认序列号增长速率,得到接收端的接收缓冲上限增长速率。
较佳的,第二计算单元201,具体包括:第一记录子单元2011、第一选取子单元2012和第一计算子单元2013。
第一记录子单元2011,用于接收到接收端返回的响应报文时,记录响应报文的返回时间。
第一选取子单元2012,用于选取从最新接收到的响应报文返回时间开始,之前的设定时间长度范围内的一个响应报文。
第一计算子单元2013,用于根据选取的响应报文的返回时间点和确认序列号,以及最新接收到的响应报文的确认序列号和返回时间点,计算接收端的响应报文的确认序列号的增长速率,得到接收端缓冲上限的增长速率。
第二确定单元202,用于根据发送端发送的数据报文的发送时间,计算数据报文的报文序列号增长速率。
较佳的,第二确定单元202,具体包括:第二记录子单元2021、第二选取子单元2022和第二计算子单元2023。
第二记录子单元2021,用于接收到发送端发送的数据报文时,记录数据报文的发送时间。
第二选取子单元2022,用于选取从最新接收到的数据报文发送时间开始,之前的设定时间长度范围内的一个发送报文。
第二计算子单元2023,用于根据选取的发送报文的发送时间和报文序列号,以及最新接收到的数据报文的报文序列号和发送时间,计算发送端发送数据报文的报文序列号的增长速率。
第二比较单元203,用于比较计算的到的接收端接收缓冲上限增长速率大于等于报文序列号增长速率。
执行模块30,用于若第二判断模块20判断出接收端的接收缓冲上限的增长速率大于等于发送端报文序列号增长速率,转发接收到的数据报文至接收端;否则丢弃所述数据报文。
同时,执行模块30也会在第一判断模块10判断出接收到的数据报文的报文序列号小于等于接收端的接收缓冲上限时,转发接收到的数据报文至接收端。
上述数据流报文发送控制装置,还包括:更新模块40,用于根据接收到的响应报文的确认序列号和接收端的接收缓冲窗口的长度,实时更新接收端的接收缓冲上限。
该数据流报文发送控制装置,可以设置在网络防火墙或其他网络设备中,实现对经过网络防火墙或其他网络设备的数据流报文的合法性检测。适用于网络防火墙、网络防毒、网络入侵检测/防御、以及敏感字眼拦截、网址过滤等在线数据流内容过滤过程。
本申请实施例提供的上述数据流报文发送控制方法及装置,在检测到发送短发送的报文序列号大于接收端的接收缓冲上限时,进一步判断接收端的接收缓冲上限的增长速率是否大于等于接收端发送数据报文的报文序列号增长速率,若是的话,说明接收端有足够的处理能力处理发送端的发送的数据报文,只是个别的报文响应回复不及时,因此,将不会丢弃接收端的数据报文,而是将其发送给接收端。从而避免了现有报文检测过滤标准过于单一和严格,导致TCP协议通讯过程中合法报文被误认为非法的问题;该方式有效的减少合法报文被误拦截的发生概率,实现了支持更高的TCP协议报文转发速率。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (13)

1.一种数据流报文发送控制方法,其特征在于,包括:
当判断出接收到的数据报文的报文序列号大于接收端的接收缓冲上限时,判断接收端的接收缓冲上限的增长速率是否大于等于发送端报文序列号增长速率;
若接收端的接收缓冲上限的增长速率大于等于发送端报文序列号增长速率,转发所述数据报文至接收端;否则丢弃所述数据报文。
2.如权利要求1所述的方法,其特征在于,判断接收到的数据报文的报文序列号是否大于接收端的接收缓冲上限的步骤,具体包括:
计算接收端接收到数据报文后返回的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和;
确定得到的数据报文的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和的最大值,作为接收端的接收缓冲上限;
比较接收到的数据报文的报文序列号是否大于确定出的接收缓冲上限。
3.如权利要求1所述的方法,其特征在于,所述判断接收端的接收缓冲上限的增长速率是否大于等于发送端报文序列号增长速率,具体包括:
根据接收端返回的响应报文的返回时间,计算响应报文的确认序列号增长速率,得到接收端的接收缓冲上限增长速率;
根据发送端发送的数据报文的发送时间,计算数据报文的报文序列号增长速率;
比较计算得到的接收端接收缓冲上限增长速率是否大于等于报文序列号增长速率。
4.如权利要求3所述的方法,其特征在于,计算响应报文的确认序列号增长速率,得到接收缓冲上限的增长速率的步骤,具体包括:
接收到接收端返回的响应报文时,记录响应报文的返回时间;
选取从最新接收到的响应报文返回时间开始,之前的设定时间长度范围内的一个响应报文;
根据选取的响应报文的返回时间点和确认序列号,以及最新接收到的响应报文的确认序列号和返回时间点,计算接收端的响应报文的确认序列号的增长速率,得到接收端缓冲上限的增长速率。
5.如权利要求3所述的方法,其特征在于,根据发送端发送的数据报文的发送时间,计算数据报文的报文序列号增长速率,具体包括:
接收到发送端发送的数据报文时,记录数据报文的发送时间;
选取从最新接收到的数据报文发送时间开始,之前的设定时间长度范围内接收到的一个数据报文;
根据选取的数据报文的发送时间和报文序列号,以及最新接收到的数据报文的报文序列号和发送时间,计算发送端发送数据报文的报文序列号的增长速率。
6.如权利要求1-5任一所述的方法,其特征在于,转发所述数据报文至接收端之后,还包括:
接收接收端返回的所述数据报文的响应报文;
根据接收到的响应报文的确认序列号和接收端的接收缓冲窗口的长度,实时更新所述接收端的接收缓冲上限。
7.一种数据流报文发送控制装置,其特征在于,包括:
第一判断模块,用于判断出接收到的数据报文的报文序列号是否大于接收端的接收缓冲上限;
第二判断模块,用于当第一判断模块判断出接收到的数据报文的报文序列号超过接收端的接收缓冲上限时,判断接收端的接收缓冲上限的增长速率是否大于等于发送端报文序列号增长速率;
执行模块,用于若第二判断模块判断出接收端的接收缓冲上限的增长速率大于等于发送端报文序列号增长速率,转发所述数据报文至接收端;否则丢弃所述数据报文。
8.如权利要求7所述的装置,其特征在于,所述第一判断模块,具体包括:
第一计算单元,用于计算接收端接收到数据报文后返回的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和;
第一确定单元,用于确定得到的数据报文的响应报文的确认序列号和接收端的接收缓冲窗口的长度之和的最大值,作为接收端的接收缓冲上限;
第一比较单元,用于比较接收到的数据报文的报文序列号是否大于确定出的接收缓冲上限。
9.如权利要求7所述的装置,其特征在于,所述第二判断模块,具体包括:
第二计算单元,用于根据接收端返回的响应报文的返回时间,计算响应报文的确认序列号增长速率,得到接收端的接收缓冲上限增长速率;
第二确定单元,用于根据发送端发送的数据报文的发送时间,计算数据报文的报文序列号增长速率;
第二比较单元,用于比较计算得到的接收端接收缓冲上限增长速率是否大于等于报文序列号增长速率。
10.如权利要求9所述的装置,其特征在于,所述第二计算单元,具体包括:
第一记录子单元,用于接收到接收端返回的响应报文时,记录响应报文的返回时间;
第一选取子单元,用于选取从最新接收到的响应报文返回时间开始,之前的设定时间长度范围内的一个响应报文;
第一计算子单元,用于根据选取的响应报文的返回时间点和确认序列号,以及最新接收到的响应报文的确认序列号和返回时间点,计算接收端的响应报文的确认序列号的增长速率,得到接收端缓冲上限的增长速率。
11.如权利要求9所述的装置,其特征在于,所述第二确定单元,具体包括:
第二记录子单元,用于接收到发送端发送的数据报文时,记录数据报文的发送时间;
第二选取子单元,用于选取从最新接收到的数据报文发送时间开始,之前的设定时间长度范围内接收到的一个数据报文;
第二计算子单元,用于根据选取的数据报文的发送时间和报文序列号,以及最新接收到的数据报文的报文序列号和发送时间,计算发送端发送数据报文的报文序列号的增长速率。
12.如权利要求7-11任一所述的装置,其特征在于,还包括:
更新模块,用于根据接收到的响应报文的确认序列号和接收端的接收缓冲窗口的长度,实时更新所述接收端的接收缓冲上限。
13.一种网络设备,其特征在于,包括:如权利要求8-11任一所述的数据流报文发送控制装置。
CN2010101268599A 2010-03-16 2010-03-16 数据流报文发送控制方法及装置 Active CN101841468B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN2010101268599A CN101841468B (zh) 2010-03-16 2010-03-16 数据流报文发送控制方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2010101268599A CN101841468B (zh) 2010-03-16 2010-03-16 数据流报文发送控制方法及装置

Publications (2)

Publication Number Publication Date
CN101841468A CN101841468A (zh) 2010-09-22
CN101841468B true CN101841468B (zh) 2011-11-16

Family

ID=42744602

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2010101268599A Active CN101841468B (zh) 2010-03-16 2010-03-16 数据流报文发送控制方法及装置

Country Status (1)

Country Link
CN (1) CN101841468B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103138904A (zh) * 2011-11-30 2013-06-05 鼎桥通信技术有限公司 报文处理方法、装置及系统
CN106789700B (zh) * 2016-12-23 2020-11-03 京信通信系统(中国)有限公司 一种流量整形方法及网络设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1251446C (zh) * 2002-07-18 2006-04-12 华为技术有限公司 一种防御网络传输控制协议同步报文泛滥攻击的方法
US20080075072A1 (en) * 2006-09-25 2008-03-27 Sercomm Corporation WLAN packet control protocol for video streaming
KR101375918B1 (ko) * 2007-12-12 2014-03-18 삼성전자주식회사 이동 통신 시스템에서 패킷 재정렬 방법 및 장치
CN101409611B (zh) * 2008-11-21 2011-05-18 北京佳讯飞鸿电气股份有限公司 一种ip调度的通信方法
CN101494652B (zh) * 2009-02-27 2012-01-11 中国电子科技集团公司第五十四研究所 一种卫星通信系统中增强tcp协议性能的方法

Also Published As

Publication number Publication date
CN101841468A (zh) 2010-09-22

Similar Documents

Publication Publication Date Title
JP4719270B2 (ja) データユニット中継装置およびその制御方法
KR101746629B1 (ko) 통신 장치 및 통신 방법
EP1424799B1 (en) System and method for detecting lost messages transmitted between modules in a communication device
CN101232445B (zh) 通信终端、拥塞控制方法
EP0973294A3 (en) Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems
EP2175582B2 (en) A method for triggering status report of automatic repeat request
EP0969623A3 (en) Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems
EP0969622A3 (en) Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems
WO2010100837A1 (ja) 通信レート制御方法、送信装置および通信システム
US20060161983A1 (en) Inline intrusion detection
JP2010532639A5 (zh)
CN102694631B (zh) 一种用于控制数据传输的方法和装置
CN109981385B (zh) 一种实现丢包检测的方法、装置和系统
CN104486243A (zh) 数据传输方法、设备及系统
CN101977358A (zh) 一种数据短信的传输方法、装置及设备
CN102104552B (zh) 基于明确拥塞通知机制的报文控制方法及设备
CN102655509A (zh) 一种网络攻击识别方法及装置
CN102158389A (zh) 异步的数据传输方法、装置及系统
CN101841468B (zh) 数据流报文发送控制方法及装置
CN104283716A (zh) 数据传输方法、设备及系统
CN101141393B (zh) 通信终端、通信控制方法
Thubert IPv6 over low-power wireless personal area network (6LoWPAN) selective fragment recovery
EP1898586A1 (en) Protection for data transmission network systems against SYN flood denial of service attacks
KR101479948B1 (ko) 엠투엠 플랫폼과 엠투엠 디바이스 간의 트래픽 관리 방법
US9565009B2 (en) Communication apparatus and communication method

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 Z-GOOD TECHNOLOGY SERVICE CO., LTD.

Free format text: FORMER OWNER: BEIJING XINGWANG RUIJIE NETWORK TECHNOLOGIES CO., LTD.

Effective date: 20140813

C41 Transfer of patent application or patent right or utility model
COR Change of bibliographic data

Free format text: CORRECT: ADDRESS; FROM: 100036 HAIDIAN, BEIJING TO: 100085 HAIDIAN, BEIJING

TR01 Transfer of patent right

Effective date of registration: 20140813

Address after: 100085 Beijing city Haidian District No. 33 Xiaoying Road 1 1F06 room

Patentee after: BEIJING ZHIGU TECHNOLOGY SERVICES CO., LTD.

Address before: 100036 Beijing Haidian District City 33 Fuxing Road Cuiwei East 1106

Patentee before: Beijing Xingwang Ruijie Network Technologies Co., Ltd.

EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20100922

Assignee: Beijing Xingwang Ruijie Network Technologies Co., Ltd.

Assignor: BEIJING ZHIGU TECHNOLOGY SERVICES CO., LTD.

Contract record no.: 2014990000854

Denomination of invention: Data stream message transmission control method and device

Granted publication date: 20111116

License type: Common License

Record date: 20141105

LICC Enforcement, change and cancellation of record of contracts on the licence for exploitation of a patent or utility model