CN101547210A - 一种tcp连接的处理方法和装置 - Google Patents

一种tcp连接的处理方法和装置 Download PDF

Info

Publication number
CN101547210A
CN101547210A CN200910137192A CN200910137192A CN101547210A CN 101547210 A CN101547210 A CN 101547210A CN 200910137192 A CN200910137192 A CN 200910137192A CN 200910137192 A CN200910137192 A CN 200910137192A CN 101547210 A CN101547210 A CN 101547210A
Authority
CN
China
Prior art keywords
message
state
tcp
syn
server
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.)
Pending
Application number
CN200910137192A
Other languages
English (en)
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.)
Fujian Star Net Communication Co Ltd
Original Assignee
Fujian Star Net Communication 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 Fujian Star Net Communication Co Ltd filed Critical Fujian Star Net Communication Co Ltd
Priority to CN200910137192A priority Critical patent/CN101547210A/zh
Publication of CN101547210A publication Critical patent/CN101547210A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Computer And Data Communications (AREA)

Abstract

本发明实施例涉及通信技术领域，尤其涉及一种TCP连接的处理方法和装置。在本发明实施例提供的技术方案采用SYN代理来建立TCP连接，从而保证到达服务器的连接都是合法的连接，能够有效防御SYN－FLOOD攻击，并且在TCP连接处于各状态时，根据预设的各状态下能够接收的合法报文确定接收到的报文是否合法，从而防止其他可能存在的入侵行为。

Description

一种TCP连接的处理方法和装置
技术领域
本发明涉及通信技术领域，尤其涉及一种TCP(Transmission ControlProtocol，传输控制协议)连接的处理方法和装置。
背景技术
通信协议要么是面向连接(Connection-Oriented)的，要么是无连接(Connectionless Protocols)的。这依赖于信息发送方是否需要与接收方联系并通过联系来维持一个对话(面向连接的)，还是没有任何预先联系就发送消息(无连接的)，并希望接收方能顺序接收所有内容。这两种方法对应着网络上实现通信的两种途径。
在面向连接的方法中，网络负责顺序发送报文并且以一种可靠的方法检测丢失和冲突。这种方法被“可靠的”传输协议使用。
在无连接的方法中，网络只需要将报文分组发送到接收点，检错与流控由发送方和接收方处理。这种方法被称作“最佳工作(best-effort)”或“无应答(unacknowledged)”的传输协议使用。
状态检测(stateful inspection)的思想基于“连接”的概念。连接必然是有序的，通信双方的连接状态也是有一定顺序进行变化的，就象打电话，一定要先拨号对方电话才能振铃，不可能没人拨铃就响了，那样的话一定是哪出了故障。状态检测就是事先确定好连接的合法过程模式，如果数据交互过程符合这个模式，则说明数据是合法正确的，否则就是非法数据，应该被丢弃。
TCP协议是一个面向连接协议，在真正的通信前，必须按一定协议先建立连接，连接建立好后才能通信，通信结束后释放连接。
TCP连接建立过程称为三次握手(Three-way Handshake)，包括以下步骤：
步骤一，客户端发送一个包含SYN(Synchronize，同步)标志的TCP报文(被称为SYN报文)，SYN报文会指明客户端使用的端口以及TCP连接的初始序号；
步骤二，服务器在收到客户端的SYN报文后，将返回一个带SYN和ACK(Acknowledgement，确认)标志的报文(被称为SYNACK报文)给客户端，表示客户端的请求被接受，同时TCP序号被加一；
步骤三，客户端在接收到SYNACK报文后再发送一个带ACK标志的报文(被称为ACK报文)给服务器，同样TCP序列号被加一。
服务器收到该ACK报文后就可认为连接已经成功建立；在正常断开时，一方会发送带FIN(请求关闭TCP连接)标志的报文(被称为FIN报文)到对方，表示本方已经不会再发送数据了，但还可以接收数据，对方接收后还可以发数据，发完后也会发送带FIN标志的报文，双方进入断开状态，经过一段时间后连接彻底删除。在异常情况会发送RST(请求重置TCP连接)标志的包来执行异常断开，不论是在连接开始还是通信和断开过程。
由此可见，第一，TCP的连接过程是一个有序过程，新连接一定是通过SYN包来开始的，防火墙只有收到了SYN报文才会建立一个TCP连接记录；如果防火墙收到一个不是SYN的TCP报文，但找不到该TCP报文对应的连接记录，那么就可以断定该报文一定是非法的，可以将其扔掉；其二，数据通信过程是有方向性的，一定是客户端发送SYN报文，服务器发SYNACK报文，反之则为非法。所以，TCP状态检测就是当TCP连接处于某种特定状态时，只允许来自特定方向的特定类型的报文。
SYN Flood(洪水)是当前最流行的DoS(Denial of Service，拒绝服务攻击)与DDoS(Distributed Denial of Service，分布式拒绝服务攻击)的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽(CPU(Central Processing Unit，中央处理器)满负荷或内存不足)的攻击方式。
问题就出在TCP连接的三次握手中，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYNACK应答报文后是无法收到客户端的ACK报文的，则第三次握手无法完成，这种情况下服务器端一般会重试(即再次发送SYNACK给客户端)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟)。由于每个TCP连接都要占用服务器一定的存储资源和计算资源，一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的未完成三次握手(也称“半连接”)的TCP连接列表而消耗非常多的资源，数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYNACK的重试。实际上如果服务器的TCP/IP(Internet Protocol，因特网协议)栈不够强大，最后的结果往往是堆栈溢出崩溃。即使服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小)，此时从正常客户的角度看来，服务器失去响应，这种情况我们称作：服务器端受到了SYN Flood攻击。
SYN代理安装在保护服务器的防火墙上。SYN代理收到客户端的SYN报文后，自己构造一个SYNACK报文回复给客户端，同时缓存客户端的SYN报文，建立并维护TCP连接记录，当客户端返回ACK报文，也就意味着客户端的连接请求不是SYN-FLOOD攻击，SYN代理于是把之前缓存的客户端SYN报文发给服务器，代替客户端和服务器建立TCP连接，这个过程中SYN代理要给客户端发送SYNACK报文一个，给服务器发送SYN和ACK报文各一个，SYN代理和服务器连接建立后，客户端与服务器通信的后续报文，SYN代理都要修改序列号或确认号，因为SYN代理回复客户端的SYNACK报文的序列号基本不可能等于服务器发送的SYNACK包的序列号，所以需要调整。SYN代理可以保证到达服务器的连接都是合法的连接，当SYN-FLOOD发生时，服务器并不会受到冲击，而是由SYN代理承受。但是，SYN代理在桥接起客户端和服务器的连接后，不具备后续阶段的TCP状态检测能力，给其他类型的入侵行为留下可利用的机会。
发明内容
本发明实施例提供一种TCP连接的处理方法和装置，用以保证到达服务器的连接都是合法的连接，并能够进行TCP状态检测，防止入侵行为。
为了解决上述问题，本发明实施例提供了一种TCP连接的处理方法，包括：
在传输控制协议TCP连接的当前状态为NONE状态或CLOSE状态时，若接收到客户端发送的第一同步SYN报文，则以服务器的名义回复第一同步确认SYNACK报文给所述客户端，并令TCP连接进入SYN_ACKED状态；
在所述TCP连接的当前状态为SYN_ACKED状态时，若接收到所述客户端发送的用以确认所述第一SYNACK报文的第一确认ACK报文，则以所述客户端的名义向所述服务器发送第二SYN报文，并令所述TCP连接进入SYN_FWED状态；
在所述TCP连接的当前状态为SYN_FWED状态时，若接收到所述服务器发送的第二SYNACK报文，则向所述服务器发送确认所述第二SYNACK报文的第二ACK报文，并令所述TCP连接进入已连接状态；
在接收到报文时，根据所述接收到的报文以及所述TCP连接的当前状态确定接收到的报文是否合法。
本发明实施例还提供了一种TCP连接的处理装置，包括：
接收模块，用于接收客户端或服务器发送的报文；
同步SYN代理模块，用于在传输控制协议TCP连接的当前状态为NONE状态或CLOSE状态时，若所述接收模块接收到客户端发送的第一同步SYN报文，则以服务器的名义回复第一同步确认SYNACK报文给所述客户端，并令TCP连接进入SYN_ACKED状态；在所述TCP连接的当前状态为SYN_ACKED状态时，若所述接收模块接收到所述客户端发送的用以确认所述第一SYNACK报文的第一确认ACK报文，则以所述客户端的名义向所述服务器发送第二SYN报文，并令所述TCP连接进入SYN_FWED状态；在所述TCP连接的当前状态为SYN_FWED状态时，若所述接收模块接收到所述服务器发送的第二SYNACK报文，则向所述服务器发送确认所述第二SYNACK报文的第二ACK报文，并令所述TCP连接进入已连接状态；
状态检测模块，用于在所述接收模块接收到报文时，根据所述接收到的报文以及所述TCP连接的当前状态确定接收到的报文是否合法。
本发明实施例的有益效果在于：
本发明实施例提供的技术方案采用SYN代理来建立TCP连接，从而保证到达服务器的连接都是合法的连接，能够有效防御SYN-FLOOD攻击，并且在TCP连接处于各状态时，根据预设的各状态下能够接收的合法报文确定接收到的报文是否合法，从而防止其他可能存在的入侵行为。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例中的SYN代理方案在TCP建立阶段的处理流程图；
图2为实施例一中的TCP状态检测方法的流程图；
图3为图2中的sFW流程的流程图；
图4为图2中的sCL流程的流程图；
图5为图2中的sES流程的流程图；
图6为图2中的默认流程的流程图；
图7为实施例二中的TCP连接的处理装置的框图。
具体实施方式
本发明实施例中，由位于客户端和服务器之间的防火墙来实现SYN代理，该SYN代理方案在TCP建立阶段的处理流程如图1所示，包括以下步骤：
步骤S101，接收客户端发送的第一SYN报文，以服务器的名义回复第一SYNACK报文给客户端，令TCP连接进入SYN_ACKED状态；
该SYN_ACKED状态即防火墙已响应客户端的TCP连接建立请求的状态。
步骤S102，接收客户端发送的用以确认第一SYNACK报文的第一ACK报文，并以客户端的名义向服务器发送第二SYN报文，令TCP连接进入SYN_FWED状态；
该SYN_FWED状态即防火墙已向服务器发出TCP连接建立请求的状态。
在SYN_FWED状态下，防火墙可以缓存客户端所发送的报文中的用户数据。
可以看出，防火墙并未在接收到第一SYN报文后就立刻转发，而是在接收客户端发送的用以确认第一SYNACK报文的第一ACK报文后，才以客户端的名义向服务器发送第二SYN报文，这是由于如果客户端回复了第一ACK报文，防火墙和客户端之间的三次握手完成，成功建立连接，这就可以确定该次连接不是SYN-FLOOD攻击，可以向服务器发起TCP连接了。
步骤S103，接收服务器发送的第二SYNACK报文，并向服务器发送确认第二SYNACK报文的第二ACK报文，令TCP连接进入已连接(ESTABLISHED)状态。
该ESTABLISHED状态表示客户端和服务器之间的TCP连接已建立。
在步骤S103结束后，则客户端与服务器之间的TCP连接建立完成，客户端与服务器之间可以进行通信。
为了防止可能存在的入侵行为，本发明实施例对TCP连接的各个状态下接收到的报文进行监控，根据接收到的报文以及TCP连接的当前状态确定接收到的报文是否合法，以确保接收到的报文是合法的。在本发明实施例的具体实现中，可以根据接收到的报文以及TCP连接的当前状态确定TCP连接的新状态，并根据该新状态确定接收到的报文是否合法。
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行详细描述。
实施例一
在本实施例中，采用TCP状态转换表来实现状态的监控，预设TCP状态转换表，TCP状态转换表用于标识在TCP连接的当前状态下，接收到来自各种来源的各种类型的报文时转换得到的TCP连接的新状态，该来源可以为客户端或服务器；在接收到报文时，根据TCP连接的当前状态和接收到的报文的来源以及类型查询TCP状态转换表，确定TCP连接的新状态，并根据该新状态确定接收到的报文是否合法。
该TCP状态转换表中的各TCP状态定义如下：
表1
 
NONE(sNO)： TCP连接处于无连接状态
SYN_ACKED(sSA)： 防火墙已经接收到客户端的第一SYN报文，且已经以服务器的名义向客户端回复了第一SYNACK报文                 
SYN_FWED(sSF)： 防火墙已经接收到客户端用以确认第一SYNACK的第一ACK报文，且防火墙已经以客户端的名义向服务器发出第二SYN报文。TCP连接进入SYN_FWED状态。                    
ESTABLISHED(sES)： 防火墙已经接收到服务器响应的第二SYNACK报文，防火墙已经响应一个ACK报文给服务器，该ACK报文中可以附带所缓存的全部客户端用户数据。                        
FIN_WAIT(sFW)： FIN报文通过防火墙
 
CLOSE_WAIT(sCW)： ACK报文通过防火墙，TCP连接之前状态为FIN_WAIT
LAST_ACK(sLA)： FIN报文通过防火墙，TCP连接之前状态为FIN_WAIT或CLOSE_WAIT                                     
TIME_WAIT(sTW)： ACK报文通过防火墙，TCP连接之前状态为LAST_ACK
CLOSE(sCL)： TCP连接重置
INVALID(sIV)： 非法报文，或者防火墙不支持TCP通讯双方同时发起连接请求
具体的TCP状态转换表如表2、表3所示，其中：
输入：①TCP连接当前状态，②报文的类型
输出：TCP连接新状态
表2示出了来源为客户端时的状态装换表：
表2
Figure A200910137192D00121
表3示出了来源为服务器时的状态装换表：
表3
Figure A200910137192D00122
TCP状态转换表的详细解说如下：
A、防火墙接收到来自客户端的第一SYN报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表4所示：
表4
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sSA： 初始化一个新连接，防火墙以服务器名义响应第一SYNACK给客户端                                          
sSA -> sSA： 防火墙认为接收到客户端重发的第一SYN，再次响应第一SYNACK                                       
 
sSF -> sIV： 防火墙认为可能是重发的SYN迟到，丢弃
sES -> sIV： 防火墙认为该第一SYN为非法报文。
sFW -> sIV： 同上
sCW -> sIV： 同上
sLA -> sIV： 同上
sTW -> sSA： TCP连接重打开
sCL -> sSA： 同上
B、防火墙接收到来自客户端的第一SYNACK报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表5所示：
表5
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 来自连接发起方的SYNACK总视为非法，不允许TCP通讯双方都发出连接请求                                         
sSA -> sIV： 同上
sSF -> sIV： 同上
sES -> sIV： 同上
sFW -> sIV： 同上
sCW -> sIV： 同上
sLA -> sIV： 同上
sTW -> sIV： 同上
sCL -> sIV： 同上
C、防火墙接收到来自客户端的第一FIN报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表6所示：
表6
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 延迟太久，防火墙已删除连接记录，视为非法
sSA -> sCL： 客户端在与防火墙三次握手完成之前提出连接关闭请求，防火墙响应RST                                                 
sSF -> sCL： 同上
sES -> sFW： 客户端发起关闭连接请求
sFW -> sLA： 通讯双方都发过FIN，尚欠最后一个ACK完成连接关闭，也可能是重传的FIN                                         
sCW -> sLA： 同上
sLA -> sLA： 重传的FIN，TCP连接状态保持不变
sTW -> sTW： 同上
sCL -> sCL： 同上
D、防火墙接收到来自客户端的第一ACK报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表7所示：
表7
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 不允许ACK建立连接
sSA -> sSF： 防火墙与客户端三次握手完成，防火墙代替客户端向服务器发出SYN报文，发起连接请求                               
sSF -> sSF： 防火墙等待服务器响应连接请求过程中，收到客户端ACK报文，若报文携带用户数据，则缓存报文用户数据；若属于重发报文，则向服务器重发SYN报文                           
sES -> sES： 三次握手完成后的通讯，TCP连接维持连接建立状态
sFW -> sCW： 响应关闭连接请求的ACK.
sCW -> sCW： 连接一端的数据尚未传输完
sLA -> sTW： 关闭TCP连接的最后一个ACK收到
sTW -> sTW： 最后一个ACK重传，TCP连接状态维持不变
sCL -> sCL： 同上
E、防火墙接收到来自客户端的第一RST报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表8所示：
表8
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 不允许ACK建立连接
sSA -> sCL： 防火墙与客户端三次握手未完成，客户端发出重置请求，防火墙删除TCP连接记录                                     
sSF -> sCL： 防火墙等待服务器响应连接请求过程中，客户端发出重置请求，防火墙修改RST报文的acknum(AcknowledgementNumber，确认编号)为0，发送给服务器                  
sES -> sCL： 连接重置
sFW -> sCL： 同上
sCW -> sCL： 同上
sLA -> sCL： 同上
sTW -> sCL： RST重传，TCP连接状态维持不变
sCL -> sCL： 同上
F、防火墙接收到来自服务器的第二SYN报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表9所示：
表9
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 不可能发生的情况
sSA -> sIV： 同上
 
sSF -> sIV： 不支持客户端和服务器双方都发起连接请求
sES -> sIV： 服务器不可能发起连接请求
sFW -> sIV： 同上
sCW -> sIV： 同上
sLA -> sIV： 同上
sTW -> sIV： 服务器不会重打开已关闭连接
sCL -> sCL： 同上
G、防火墙接收到来自服务器的第二SYNACK报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表10所示：
表10
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 不可能发生的情况
sSA -> sIV： 同上
sSF -> sES： 防火墙收到服务器的SYNACK，响应以一个包含所缓存客户端用户数据的ACK。防火墙与服务器三次握手完成。   
sES -> sES： 可能是重传的SYNACK迟到
sFW -> sIV： 非法报文：已经过了sES状态的TCP连接收到的SYNACK报文视为非法。                                
sCW -> sIV： 同上
sLA -> sIV： 同上
sTW -> sIV： 同上
sCL -> sCL： 同上
H、防火墙接收到来自服务器的第二FIN报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表11所示：
表11
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 不可能发生的情况
sSA -> sIV： 同上
sSF -> sIV： 同上
sES -> sFW： 服务器发起连接关闭请求
sFW -> sLA： 通讯双方都已发出FIN
sCW -> sLA： 同上
sLA -> sLA： 重传的FIN.
sTW -> sTW： 同上
sCL -> sCL： 同上
I、防火墙接收到来自服务器的第二ACK报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表12所示：
表12
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 不可能发生的情况
sSA -> sIV： 同上
sSF -> sCL： 防火墙响应RST给服务器。对客户端等待超时后重发的报文响应RST                                            
sES -> sES： 三次握手完成后双方的数据交互
sFW -> sCW： 响应关闭连接请求的ACK.
sCW -> sCW： 连接一端尚未完成数据传输
sLA -> sTW： 收到完成关闭连接的最后一个ACK
sTW -> sTW： 重传的最后一个ACK
sCL -> sCL： 同上
J、防火墙接收到来自服务器的第二RST报文时的TCP状态转换情况以及防火墙的相应操作或状态说明如表13所示：
表13
 
TCP状态转换情况 防火墙的相应操作或状态说明
sNO -> sIV： 不可能发生的情况
sSA -> sIV： 同上
sSF -> sCL： 服务器拒绝连接请求
sES -> sCL： 连接重置
sFW -> sCL： 同上
sCW -> sCL： 同上
sLA -> sCL： 同上
sTW -> sTW： RST重传，TCP连接状态维持不变
sCL -> sCL： 同上
由于在本实施例中，在TCP建立过程中采用了SYN代理，因此与现有的TCP通信过程相比，增加了SYN_ACKED状态、SYN_FWED状态这两个状态，下面将上述TCP状态转换表以及TCP状态转换情况以及防火墙的相应操作或状态说明的对应表中与SYN_ACKED状态、SYN_FWED状态相关的状态转换以及操作进行详细说明。
由TCP状态转换表可知，SYN_ACKED状态下能够接收的合法报文包括：第一SYN报文、第一ACK报文；以及客户端发送的第一FIN报文、客户端发送的第一RST报文。
在TCP连接的当前状态为SYN_ACKED状态时，若接收到上述SYN_ACKED状态下能够接收的合法报文之外的报文，则认为是非法报文并丢弃。若接收到合法报文，则对应如下处理：
1、若接收到所述第一SYN报文，则令所述TCP连接保持所述SYN_ACKED状态，并以服务器的名义重发第一SYNACK报文给所述客户端。
2、若接收到所述第一FIN报文，则令所述TCP连接进入CLOSE状态，并响应RST报文给所述客户端。
3、若接收到所述第一RST报文，则令所述TCP连接进入CLOSE状态，并删除TCP连接记录。
4、若接收到所述第一SYNACK报文的第一确认ACK报文，则以所述客户端的名义向所述服务器发送第二SYN报文，并令所述TCP连接进入SYN_FWED状态。
由TCP状态转换表可知，SYN_FWED状态下能够接收的合法报文包括：第一ACK报文、第二SYNACK报文、第一FIN报文、第一RST报文、第二ACK报文、第二RST报文。
在TCP连接的当前状态为SYN_FWED状态时，若接收到上述SYNFWED状态下能够接收的合法报文之外的报文，则认为是非法报文并丢弃。若接收到合法报文，则对应如下处理：
1、若接收到所述第一ACK报文，则令所述TCP连接保持所述SYNFWED状态，当所述第一ACK报文携带用户数据时，缓存所述用户数据；当所述第一ACK报文未携带用户数据时，则向所述服务器重发所述二SYN报文。
2、若接收到所述第一FIN报文，则令所述TCP连接进入CLOSE状态，并响应RST报文给所述客户端。
3、若接收到所述第二ACK报文，则令所述TCP连接进入CLOSE状态，并响应RST报文给所述服务器，对客户端等待超时后重发的报文响应RST报文。
4、若接收到所述第二RST报文，则令所述TCP连接进入CLOSE状态，并丢弃所述第二RST报文。
5、若接收到所述第一RST报文，则令所述TCP连接进入CLOSE状态，并修改第一RST报文的acknum为0，发给服务器。
6、若接收到第二SYNACK报文，则向所述服务器发送确认所述第二SYNACK报文的第二ACK报文，并令所述TCP连接进入ESTABLISHED状态。
在具体实现时，只要预设了某个TCP状态下能够接收的合法报文，则在接收到报文时，就可以获知该报文是否合法了。
本实施例中的TCP状态检测方法可以如图2所示，包括以下步骤：
步骤S201，接收网络报文；
该网络报文可能来自客户端或者服务器。
步骤S202，判断TCP连接记录是否存在，若是，进行步骤S203，否则进行步骤S207；
步骤S203，将TCP连接当前的状态、报文的来源、报文的类型输入TCP状态转换表，确定TCP连接的新状态；
步骤S204，判断该确定出的新状态是否sSA，若是，则进行步骤S205，否则，进行步骤S206；
步骤S205，构造第一SYNACK报文，发送给客户端，建立连接记录，令TCP连接的新状态为sSA，返回步骤S201；
步骤S206，丢弃接收到的报文，返回步骤S201；
步骤S207，将TCP连接当前的状态、报文的来源、报文的类型输入TCP状态转换表，获得TCP连接的新状态；
步骤S208，判断该确定出的新状态是否sFW，若是，进行sFW流程，否则进行步骤S209；
步骤S209，判断该确定出的新状态是否sCL，若是，进行sCL流程，否则进行步骤S210；
步骤S210，判断该确定出的新状态是否sSA，若是，重发第一SYNACK给客户端，返回步骤S201，否则进行步骤S211；
步骤S211，判断该确定出的新状态是否sIV，若是，丢弃接收到的报文，返回步骤S201，否则进行步骤S212；
步骤S212，判断该确定出的新状态是否sES，若是，进行sES流程，否则进行默认流程。
在上述流程中，步骤S208至步骤S212没有一定的先后顺序。
上述sFW流程如图3所示，包括以下步骤：
步骤S301，判断TCP连接的当前状态是否为sFW，若是，进行步骤S302，否则进行步骤S305；
步骤S302，判断接收到的报文是否携带用户数据，若是，进行步骤S303，否则进行步骤S304；
步骤S303，缓存报文携带的用户数据，结束；
步骤S304，向服务器重发第一SYN报文，结束；
步骤S305，向服务器发送首个第一SYN报文。
由状态转换表可知，若TCP连接的当前状态与确定出的新状态都是sFW，则该接收到的报文为第一ACK报文，因此，也可以直接判断该报文是否为第一ACK报文并根据判断结果进行后续步骤。
上述sCL流程如图4所示，包括以下步骤：
步骤S401，判断TCP连接的当前状态是否为sSA，若是，进行步骤S402，否则，进行步骤S405；
步骤S402，判断接收到的报文是否为RST，若是，进行步骤S403，否则，进行步骤S404；
步骤S403，丢弃接收到的报文，结束；
步骤S404，反馈RST给该报文的发送方，结束；
步骤S405，判断TCP连接的当前状态是否为sFW，若是，进行步骤S402，否则进行步骤S406；
步骤S406，进行默认流程。
上述sES流程如图5所示，包括以下步骤：
步骤S501，判断TCP连接的当前状态是否为sFW，若是，进行步骤S502，否则进行默认流程，结束；
步骤S502，判断是否存在被缓存的客户端的用户数据，若是，进行步骤S503，否则，进行步骤S504；
步骤S503，构造响应第二SYNACK的第二ACK报文，以缓存的客户端的用户数据作为报文的用户数据，进行步骤S505；
步骤S504，构造响应第二SYNACK的第二ACK报文，报文的用户数据字节数为0；
步骤S505，发送第二ACK给服务器，结束。
上述默认流程如图6所示，包括以下步骤：
步骤S601，判断接收到的报文是否来自服务器，若是，进行步骤S602，否则，进行步骤S603；
步骤S602，调整报文的seqNum(Sequence Number，序列编号)，进行步骤S604；
步骤S603，调整报文的AckNum；
步骤S604，发送调整后的报文给目的端。
该目的端可能为客户端或服务器，若接收到的报文为客户端发送给服务器，则目的端为服务器；若接收到的报文为服务器发送给客户端，则目的端为客户端。
进行上述默认流程的原因是：防火墙构造的发给客户端的第一SYNACK报文的SeqNum(以下称F_SEQ)与服务器响应连接请求的第二SYNACK报文的SeqNum(以下称S_SEQ)存在值差；连接建立完成后，来自服务器的报文的SeqNum(以下称SA_SEQ)要改成SA_SEQ+F_SEQ-S_SEQ，才会被客户端接受；同理，来自客户端报文的AckNum(以下成CA_ACK)要改成CA_ACK-(F_SEQ-S_SEQ)，才会被服务器接受。
本发明实施例将SYN代理与状态检测进行结合，能够检测TCP连接建立完成以后报文交互所引起的连接状态变换的合法性，进一步消除被其他入侵攻击利用的安全隐患。并且，相比于SYN代理和TCP状态检测独立实现的方案，本发明实施例在实现时代码量少，执行效率高，可以在条件更苛刻(例如：系统指令空间小，内存小)的环境下实现。
另外，由于SYN代理存在以下缺点：
1)SYN代理缓存客户端的SYN报文，与客户端三次握手完成连接建立后，SYN代理要代替客户端与服务器建立连接，SYN代理发给服务器的SYN报文即之前缓存的来自客户端的SYN报文。当遭受SYN-FLOOD攻击时，运行SYN代理的防火墙的有限系统内存会因为需要缓存大量的SYN报文而被迅速耗尽。
2)SYN代理与客户端三次握手完成连接建立后，才开始与服务器建立连接。而在客户端看来，它与服务器的连接已经建立了，于是客户端开始发送数据给服务器。SYN代理与服务器连接建立完成之前，必须缓存客户端发送来的所有报文，并在收到服务器的SYNACK报文后，把所缓存的全部客户端ACK报文，逐条顺序发送给服务器。因此SYN代理必须为每个TCP连接预留了足够大的内存空间，当系统内存资源有限时，无法支持足够多的TCP连接数。
因此，本实施例还对SYN代理作了一些改进，本实施例中客户端、服务器和防火墙三方参与的一次TCP连接建立，数据传输，及TCP连接关闭的过程与现有技术的区别点具体如下：
1、本发明不缓存客户端的第一SYN报文，而仅缓存客户端的第一SYN报文的TCP选项，如window-scale，sack-permit，MSS等，与客户端三次握手建立连接后，把客户端完成三次握手的第一ACK报文添加上缓存的TCP选项，改造成第二SYN报文，发给服务器。当遭受SYN-FLOOD攻击时，本实施例中的防火墙的有限的系统内存不至于因为需要缓存大量的SYN报文而被迅速耗尽。
2、本实施例中将响应给客户端的第一SYNACK报文的WINDOW(TCP报文的WINDOW选项域表示该报文的发送方的接收缓存区的大小)域置为1(即通知对方，本方的接收缓冲区只能容纳一个字节)，这就保证了在防火墙与客户端三次握手完成连接建立后，至与服务器建立连接之前的这段时间，客户端最多只会发来数据总量只有一个字节的报文，客户端和防火墙三次握手建立连接后，仅发来一条含有一个字节用户数据的报文。本发明不缓存整条报文，而只缓存报文中的用户数据。采用本实施例，在防火墙等待与和服务器建立连接的过程中，需要预留的缓存空间也仅为1字节，进一步节省了防火墙系统内存。而服务器在接收到包含用户数据的报文后，返回响应报文，该响应报文中携带服务器的窗口大小，防火墙修改SeqNum后把该响应报文转给客户端，客户端后续根据服务器的窗口大小发送数据报文。
3、本实施例中响应服务器第二SYNACK的第二ACK报文直接基于第二SYNACK改造，并附带上所缓存的客户端用户数据内容。在收到服务器的第二SYNACK之前收到的所有客户端第一ACK报文可以合并为一条报文，作为对服务器SYNACK的确认报文发送，提高了传输效率。
可见，本实施例与通常SYN代理的主要差别在于内存开销小，特别适用于系统内存资源有限的防火墙，并提高了安全性。
实施例二
本实施例中的TCP连接的处理装置，如图7所示，包括：
接收模块701，用于接收客户端或服务器发送的报文；
SYN代理模块702，用于在传输控制协议TCP连接的当前状态为NONE状态或CLOSE状态时，若所述接收模块接收到客户端发送的第一同步SYN报文，则以服务器的名义回复第一同步确认SYNACK报文给所述客户端，并令TCP连接进入SYN_ACKED状态；在所述TCP连接的当前状态为SYN_ACKED状态时，若所述接收模块接收到所述客户端发送的用以确认所述第一SYNACK报文的第一确认ACK报文，则以所述客户端的名义向所述服务器发送第二SYN报文，并令所述TCP连接进入SYN_FWED状态；在所述TCP连接的当前状态为SYN_FWED状态时，若所述接收模块接收到所述服务器发送的第二SYNACK报文，则向所述服务器发送确认所述第二SYNACK报文的第二ACK报文，并令所述TCP连接进入ESTABLISHED状态；
状态检测模块703，用于在所述接收模块接收到报文时，根据所述接收到的报文以及所述TCP连接的当前状态确定接收到的报文是否合法。
进一步地，该装置可以包括存储模块，用于保存预设的TCP状态转换表，所述TCP状态转换表用于标识在TCP连接的当前状态下，接收到来自各种来源的各种类型的报文时转换得到的TCP连接的新状态，所述来源为客户端或服务器；
在包括存储模块的情况下，所述状态检测模块，用于在所述接收模块接收到报文时，根据所述TCP连接的当前状态和接收到的报文的来源以及类型查询所述TCP状态转换表，确定所述TCP连接的新状态，并根据所述新状态确定接收到的报文是否合法。
进一步地，该装置可以包括处理模块，用于在所述状态检测模块确定所述接收模块接收到的报文合法时，根据所述接收模块接收到的报文进行相应处理；在所述状态检测模块确定所述接收模块接收到的报文不合法时，丢弃所述接收模块接收到的报文。
综上所述，本发明实施例提供的技术方案采用SYN代理来建立TCP连接，从而保证到达服务器的连接都是合法的连接，能够有效防御SYN-FLOOD攻击，并且在TCP连接处于各状态时，根据预设的各状态下能够接收的合法报文确定接收到的报文是否合法，从而防止其他可能存在的入侵行为。
本领域普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。
上述提到的存储介质可以是只读存储器，磁盘或光盘等。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1、一种TCP连接的处理方法，其特征在于，包括：
在传输控制协议TCP连接的当前状态为NONE状态或CLOSE状态时，若接收到客户端发送的第一同步SYN报文，则以服务器的名义回复第一同步确认SYNACK报文给所述客户端，并令TCP连接进入SYN_ACKED状态；
在所述TCP连接的当前状态为SYN_ACKED状态时，若接收到所述客户端发送的用以确认所述第一SYNACK报文的第一确认ACK报文，则以所述客户端的名义向所述服务器发送第二SYN报文，并令所述TCP连接进入SYN_FWED状态；
在所述TCP连接的当前状态为SYN_FWED状态时，若接收到所述服务器发送的第二SYNACK报文，则向所述服务器发送确认所述第二SYNACK报文的第二ACK报文，并令所述TCP连接进入已连接状态；
在接收到报文时，根据所述接收到的报文以及所述TCP连接的当前状态确定接收到的报文是否合法。
2、根据权利要求1所述的方法，其特征在于，所述根据所述接收到的报文以及所述TCP连接的当前状态确定接收到的报文是否合法的方法为：根据所述接收到的报文以及所述TCP连接的当前状态确定所述TCP连接的新状态，并根据所述新状态确定接收到的报文是否合法。
3、根据权利要求2所述的方法，其特征在于，预设TCP状态转换表，所述TCP状态转换表用于标识在TCP连接的当前状态下，接收到来自各种来源的各种类型的报文时转换得到的TCP连接的新状态，所述来源为客户端或服务器；
所述根据所述接收到的报文以及所述TCP连接的当前状态确定所述TCP连接的新状态的方法为：根据所述TCP连接的当前状态和接收到的报文的来源以及类型查询所述TCP状态转换表，确定所述TCP连接的新状态。
4、根据权利要求1至3中任一权利要求所述的方法，其特征在于，所述SYN_ACKED状态下能够接收的合法报文包括：所述第一SYN报文、所述第一ACK报文；以及所述客户端发送的第一FIN报文、所述客户端发送的第一RST报文。
5、根据权利要求1至3中任一权利要求所述的方法，其特征在于，所述SYN_FWED状态下能够接收的合法报文包括：
所述第一ACK报文、所述第二SYNACK报文、所述第一FIN报文、第一RST报文；
所述服务器发送的第二ACK报文、第二RST报文。
6、根据权利要求1所述的方法，其特征在于，所述接收客户端发送的第一SYN报文后，缓存所述第一SYN报文的TCP选项；
所述接收所述客户端发送的用以确认所述第一SYNACK报文的第一ACK报文后，在所述第一ACK报文上添加所述TCP选项得到所述第二SYN报文。
7、根据权利要求1所述的方法，其特征在于，将所述第一SYNACK报文中的WINDOW域置为1。
8、一种TCP连接的处理装置，其特征在于，包括：
接收模块，用于接收客户端或服务器发送的报文；
同步SYN代理模块，用于在传输控制协议TCP连接的当前状态为NONE状态或CLOSE状态时，若所述接收模块接收到客户端发送的第一同步SYN报文，则以服务器的名义回复第一同步确认SYNACK报文给所述客户端，并令TCP连接进入SYN_ACKED状态；在所述TCP连接的当前状态为SYN_ACKED状态时，若所述接收模块接收到所述客户端发送的用以确认所述第一SYNACK报文的第一确认ACK报文，则以所述客户端的名义向所述服务器发送第二SYN报文，并令所述TCP连接进入SYN_FWED状态；在所述TCP连接的当前状态为SYN_FWED状态时，若所述接收模块接收到所述服务器发送的第二SYNACK报文，则向所述服务器发送确认所述第二SYNACK报文的第二ACK报文，并令所述TCP连接进入已连接状态；
状态检测模块，用于在所述接收模块接收到报文时，根据所述接收到的报文以及所述TCP连接的当前状态确定接收到的报文是否合法。
9、根据权利要求8所述的装置，其特征在于，包括：
存储模块，用于保存预设的TCP状态转换表，所述TCP状态转换表用于标识在TCP连接的当前状态下，接收到来自各种来源的各种类型的报文时转换得到的TCP连接的新状态，所述来源为客户端或服务器；
所述状态检测模块，用于在所述接收模块接收到报文时，根据所述TCP连接的当前状态和接收到的报文的来源以及类型查询所述TCP状态转换表，确定所述TCP连接的新状态，并根据所述新状态确定接收到的报文是否合法。
10、根据权利要求8或9所述的装置，其特征在于，包括：
处理模块，用于在所述状态检测模块确定所述接收模块接收到的报文合法时，根据所述接收模块接收到的报文进行相应处理；在所述状态检测模块确定所述接收模块接收到的报文不合法时，丢弃所述接收模块接收到的报文。
CN200910137192A 2009-05-14 2009-05-14 一种tcp连接的处理方法和装置 Pending CN101547210A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN200910137192A CN101547210A (zh) 2009-05-14 2009-05-14 一种tcp连接的处理方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200910137192A CN101547210A (zh) 2009-05-14 2009-05-14 一种tcp连接的处理方法和装置

Publications (1)

Publication Number Publication Date
CN101547210A true CN101547210A (zh) 2009-09-30

Family

ID=41194093

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200910137192A Pending CN101547210A (zh) 2009-05-14 2009-05-14 一种tcp连接的处理方法和装置

Country Status (1)

Country Link
CN (1) CN101547210A (zh)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101771695A (zh) * 2010-01-07 2010-07-07 福建星网锐捷网络有限公司 Tcp连接的处理方法、系统及syn代理设备
CN102025746A (zh) * 2010-12-21 2011-04-20 北京星网锐捷网络技术有限公司 一种tcp连接的建立方法、装置及网络设备
CN102065017A (zh) * 2010-12-31 2011-05-18 成都市华为赛门铁克科技有限公司 一种报文处理方法及装置
WO2011079743A1 (zh) * 2009-12-30 2011-07-07 深圳市同洲电子股份有限公司 一种数据发送方法和相关设备
CN103248605A (zh) * 2012-02-02 2013-08-14 哈尔滨安天科技股份有限公司 一种基于ipv6的tcp流汇聚方法及系统
WO2014037760A1 (zh) * 2012-09-04 2014-03-13 柏思科技有限公司 增加数据流传输的方法和系统
CN104184749A (zh) * 2014-09-15 2014-12-03 上海斐讯数据通信技术有限公司 一种sdn网络访问方法及系统
CN104219215A (zh) * 2013-06-05 2014-12-17 深圳市腾讯计算机系统有限公司 一种tcp连接的建立方法、装置、终端、服务器及系统
CN106254433A (zh) * 2016-07-28 2016-12-21 杭州迪普科技有限公司 一种建立tcp通信连接的方法及装置
CN106487817A (zh) * 2016-12-28 2017-03-08 北京奇艺世纪科技有限公司 一种tcp连接的关闭方法及装置
WO2018023988A1 (zh) * 2016-07-30 2018-02-08 华为技术有限公司 一种网络报文处理方法、装置及网络服务器
CN108924200A (zh) * 2018-06-21 2018-11-30 国家电网有限公司 一种报文处理方法及装置
CN109361784A (zh) * 2018-12-07 2019-02-19 成都知道创宇信息技术有限公司 一种在四层代理网络环境下获取客户端真实ip的方法
CN110839017A (zh) * 2019-10-21 2020-02-25 腾讯科技（深圳）有限公司 代理ip地址识别方法、装置、电子设备及存储介质
CN111431871A (zh) * 2020-03-10 2020-07-17 杭州迪普科技股份有限公司 Tcp半透明代理的处理方法和装置
CN111800499A (zh) * 2020-06-30 2020-10-20 北京百度网讯科技有限公司 一种数据传输方法、装置及电子设备
CN112104744A (zh) * 2020-03-30 2020-12-18 厦门网宿有限公司 流量代理方法、服务器及存储介质
CN113037873A (zh) * 2021-05-24 2021-06-25 广东睿江云计算股份有限公司 一种优化tcp传输的方法
CN113472795A (zh) * 2021-07-05 2021-10-01 南京云利来软件科技有限公司 一种截断的tcp流拼接方法
CN114285771A (zh) * 2021-12-30 2022-04-05 阿里巴巴（中国）有限公司 一种tcp连接的连接状态追踪方法及装置
CN114979237A (zh) * 2022-05-16 2022-08-30 咪咕文化科技有限公司 一种长连接验证方法、装置、设备及可读存储介质
CN117579233A (zh) * 2024-01-15 2024-02-20 杭州优云科技股份有限公司 一种报文重传方法及装置

Cited By (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011079743A1 (zh) * 2009-12-30 2011-07-07 深圳市同洲电子股份有限公司 一种数据发送方法和相关设备
CN101771695A (zh) * 2010-01-07 2010-07-07 福建星网锐捷网络有限公司 Tcp连接的处理方法、系统及syn代理设备
CN102025746B (zh) * 2010-12-21 2013-04-17 北京星网锐捷网络技术有限公司 一种tcp连接的建立方法、装置及网络设备
CN102025746A (zh) * 2010-12-21 2011-04-20 北京星网锐捷网络技术有限公司 一种tcp连接的建立方法、装置及网络设备
CN102065017B (zh) * 2010-12-31 2013-08-28 华为数字技术（成都）有限公司 一种报文处理方法及装置
CN102065017A (zh) * 2010-12-31 2011-05-18 成都市华为赛门铁克科技有限公司 一种报文处理方法及装置
CN103248605A (zh) * 2012-02-02 2013-08-14 哈尔滨安天科技股份有限公司 一种基于ipv6的tcp流汇聚方法及系统
CN103248605B (zh) * 2012-02-02 2016-12-14 哈尔滨安天科技股份有限公司 一种基于ipv6的tcp流汇聚方法及系统
GB2519491B (en) * 2012-09-04 2021-01-06 Pismo Labs Technology Ltd Method and system for increasing data flow transmission
WO2014037760A1 (zh) * 2012-09-04 2014-03-13 柏思科技有限公司 增加数据流传输的方法和系统
GB2519491A (en) * 2012-09-04 2015-04-22 Pismo Labs Technology Ltd Method and system for increasing data flow transmission
US9967193B2 (en) 2012-09-04 2018-05-08 Pismo Labs Technology Limited Method and system for increasing data flow transmission
CN104219215B (zh) * 2013-06-05 2019-02-26 深圳市腾讯计算机系统有限公司 一种tcp连接的建立方法、装置、终端、服务器及系统
CN104219215A (zh) * 2013-06-05 2014-12-17 深圳市腾讯计算机系统有限公司 一种tcp连接的建立方法、装置、终端、服务器及系统
CN104184749A (zh) * 2014-09-15 2014-12-03 上海斐讯数据通信技术有限公司 一种sdn网络访问方法及系统
CN104184749B (zh) * 2014-09-15 2019-07-19 上海斐讯数据通信技术有限公司 一种sdn网络访问方法及系统
CN106254433A (zh) * 2016-07-28 2016-12-21 杭州迪普科技有限公司 一种建立tcp通信连接的方法及装置
CN106254433B (zh) * 2016-07-28 2020-11-06 杭州迪普科技股份有限公司 一种建立tcp通信连接的方法及装置
US11218570B2 (en) 2016-07-30 2022-01-04 Huawei Technologies Co., Ltd. Network packet processing method and apparatus and network server
WO2018023988A1 (zh) * 2016-07-30 2018-02-08 华为技术有限公司 一种网络报文处理方法、装置及网络服务器
CN113259415B (zh) * 2016-07-30 2023-03-10 华为技术有限公司 一种网络报文处理方法、装置及网络服务器
US11689646B2 (en) 2016-07-30 2023-06-27 Huawei Technologies Co., Ltd. Network packet processing method and apparatus and network server
CN113259415A (zh) * 2016-07-30 2021-08-13 华为技术有限公司 一种网络报文处理方法、装置及网络服务器
CN106487817A (zh) * 2016-12-28 2017-03-08 北京奇艺世纪科技有限公司 一种tcp连接的关闭方法及装置
CN108924200A (zh) * 2018-06-21 2018-11-30 国家电网有限公司 一种报文处理方法及装置
CN109361784B (zh) * 2018-12-07 2021-09-21 成都知道创宇信息技术有限公司 一种在四层代理网络环境下获取客户端真实ip的方法
CN109361784A (zh) * 2018-12-07 2019-02-19 成都知道创宇信息技术有限公司 一种在四层代理网络环境下获取客户端真实ip的方法
CN110839017B (zh) * 2019-10-21 2022-02-08 腾讯科技（深圳）有限公司 代理ip地址识别方法、装置、电子设备及存储介质
CN110839017A (zh) * 2019-10-21 2020-02-25 腾讯科技（深圳）有限公司 代理ip地址识别方法、装置、电子设备及存储介质
CN111431871B (zh) * 2020-03-10 2022-11-25 杭州迪普科技股份有限公司 Tcp半透明代理的处理方法和装置
CN111431871A (zh) * 2020-03-10 2020-07-17 杭州迪普科技股份有限公司 Tcp半透明代理的处理方法和装置
CN112104744A (zh) * 2020-03-30 2020-12-18 厦门网宿有限公司 流量代理方法、服务器及存储介质
CN111800499A (zh) * 2020-06-30 2020-10-20 北京百度网讯科技有限公司 一种数据传输方法、装置及电子设备
CN111800499B (zh) * 2020-06-30 2022-04-15 北京百度网讯科技有限公司 一种数据传输方法、装置及电子设备
CN113037873A (zh) * 2021-05-24 2021-06-25 广东睿江云计算股份有限公司 一种优化tcp传输的方法
CN113472795A (zh) * 2021-07-05 2021-10-01 南京云利来软件科技有限公司 一种截断的tcp流拼接方法
CN114285771A (zh) * 2021-12-30 2022-04-05 阿里巴巴（中国）有限公司 一种tcp连接的连接状态追踪方法及装置
CN114285771B (zh) * 2021-12-30 2024-02-06 阿里巴巴（中国）有限公司 一种tcp连接的连接状态追踪方法及装置
CN114979237A (zh) * 2022-05-16 2022-08-30 咪咕文化科技有限公司 一种长连接验证方法、装置、设备及可读存储介质
CN114979237B (zh) * 2022-05-16 2024-05-24 咪咕文化科技有限公司 一种长连接验证方法、装置、设备及可读存储介质
CN117579233A (zh) * 2024-01-15 2024-02-20 杭州优云科技股份有限公司 一种报文重传方法及装置
CN117579233B (zh) * 2024-01-15 2024-04-23 杭州优云科技股份有限公司 一种报文重传方法及装置

Similar Documents

Publication Publication Date Title
CN101547210A (zh) 一种tcp连接的处理方法和装置
EP3352431B1 (en) Network load balance processing system, method, and apparatus
US7672223B2 (en) Method and apparatus for replicating a transport layer protocol stream
CN1251446C (zh) 一种防御网络传输控制协议同步报文泛滥攻击的方法
CN101924771B (zh) 一种用于加速应用代理的核心级tcp连接粘合方法
US8583831B2 (en) Thin client discovery
JP6858749B2 (ja) 負荷平衡システムにおいて接続を確立するデバイス及び方法
JP4465639B2 (ja) プロキシ・サーバ、通信システム、通信方法及びプログラム
US20060031518A1 (en) Method and apparatus for transparent negotiations
EP1175066A2 (en) Method and system for providing connection handling
JP2006164252A (ja) ウェブサービス環境用の信頼できるメッセージング内の接続生存性の検証および維持
CN102025746B (zh) 一种tcp连接的建立方法、装置及网络设备
CN101296223B (zh) 一种实现防火墙芯片参与syn代理的方法
US11700321B2 (en) Transparent proxy conversion of transmission control protocol (TCP) fast open connection
US11349934B2 (en) Opportunistic transmission control protocol (TCP) connection establishment
JP2006166018A (ja) ネットワーク電話システム及びこのネットワーク電話システムの主装置及び電話端末
KR20160102348A (ko) Ｔｃｐ 핸드셰이크를 수행하기 위한 장치 및 방법
CN111314447B (zh) 代理服务器及其处理访问请求的方法
JP3648211B2 (ja) パケット中継プログラム、パケット中継装置および記録媒体
KR102412225B1 (ko) 메시지 서버 및 이를 포함하는 메시지 처리 장치
CN110602225A (zh) 一种适用于工控环境的linux系统高效收发包方法
CN111049754B (zh) 数据通信方法、装置、设备和计算机可读存储介质
JP6407114B2 (ja) 通信システム、通信方法、通信ノード装置、及びプログラム
CN114124489B (zh) 防止流量攻击的方法、清洗装置、设备和介质
US11683327B2 (en) Demand management of sender of network traffic flow

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C12 Rejection of a patent application after its publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20090930