一种用于加速应用代理的核心级TCP连接粘合方法

摘要

本发明公开了一种加速应用代理的核心级TCP连接粘合方法，包括：代理服务器接收到与其建立起TCP连接的客户端发送的http请求报文后，建立与服务器的TCP连接，并向所述服务器转发所述http请求报文；所述服务器向代理服务器传送http响应头报文，并在所述http响应头报文传送至内核态的IP协议栈时，粘合模块检测所述http响应头报文是否符合预先配置的粘合条件，若符合，则进行TCP连接粘合。本发明所述方法增加TCP粘合技术适用的广度。

说明书

技术领域

本发明涉及网络安全技术领域，尤其涉及一种用于加速应用代理的核心级TCP连接粘合方法。

背景技术

应用级代理广泛应用于HTTP代理、HTTP缓存、基于应用的负载均衡、深度内容检测、网关病毒过滤等领域，扮演着当今重要的网络服务角色。统计显示当前互联网的安全问题越来越多的来自应用层，应用级代理在未来将扮演越来越重要的角色。

传统的应用级代理都采用应用层连接粘合代理，如图1所示，应用代理位于客户端和被访问的服务器之间。对于客户端来说代理扮演服务器的角色，对于服务器来说代理扮演客户端的角色。客户端首先和代理建立socket连接，然后代理再和服务器建立socket连接。连接建立完成后，代理透明的进行数据的双向传递，作为一个中间人协助客户端和服务器完成网络通信。

传统的应用代理的优势是保持了对现有网络的兼容性，并且可以在应用层实现复杂的协议处理。限制其大规模应用的核心问题是性能问题，表现为吐量小、通信延时长。原因在于对于每一个报文应用代理都会发生两次拷贝，首先是报文从客户端拷贝到应用代理，然后应用代理再拷贝给服务器。发生一次拷贝的同时伴随着一次内核态到用户态的上下文切换。内存拷贝特别是内核态/用户态之间的内存拷贝消耗大量的CPU资源，上下文切换同样会消耗大量的资源。这个过程同时明显的增加了通信延迟。

目前可用的应用代理加速方法，比如linux下的sendfile，只能用于把缓存的文件传递给服务器，可以避免内存拷贝、减少内核态/用户态的上下文切换。在HTTP缓存、基于文件扫描的病毒过滤比较有用。对于HTTP代理、基于应用的负载均衡、基于数据流的深度内容检测、基于数据流的病毒过滤，则完全无法发挥作用，并且和核心层的路由转发有相当大的性能差距。

现有技术中，为了解决上述问题采用了TCP粘合连接技术，该TCP粘合连接与应用级代理的最大不同在于客户端和服务器之间的连接在操作系统的核心层进行连接粘合。

其中，TCP粘合有三个关键问题需要解决，否则会导致通信异常：第一，必须要保证粘合之前客户端发送给代理的报文，完整的转发给服务器，同时保证服务器发送给代理的报文，完整的转发给客户端，因为TCP协议不会重传任何确认过的报文；第二，粘合模块实际上把两个TCP连接合并成一个，而TCP序号在连接建立时已经确定了，所以粘合模块需要对后续的报文做转换。第三，客户端和服务器操作系统不同，支持的TCP选项集合也不同，所以需要在TCP三次握手时协商TCP选项。

其中，粘合时机的选择是一个关键点，如图2所示，通常在应用代理获得HTTP请求头部即图中阶段2后就可以判定是否需要做粘合了，比如URL过滤、基于应用的负载均衡等。但是上述技术方案对于有些应用确不能适用，例如深度内容检测、病毒过滤等。

发明内容

本发明提供一种用于加速应用代理的核心级TCP连接粘合方法，用以解决现有技术中TCP粘合技术对于一些应用不适用导致其应用范围小的问题。

具体的，本发明提供的一种用于加速应用代理的核心级TCP连接粘合方法，包括：

代理服务器与客户端进行协商建立TCP连接；其中，在协商时，所述代理服务器通告客户端不支持时间戳和窗口扩大因子TCP选项，并记录交互报文的TCP序号、客户端支持的最大报文段长度信息MSS以及客户端是否支持选择确认TCP选项；

代理服务器接收到所述客户端发送的http请求报文时，与服务器进行协商建立TCP连接后，向所述服务器转发所述http请求报文；其中，在与服务器进行协商建立TCP连接时，记录交互报文的TCP序号，并基于所述代理服务器与客户端间的协商结果，调整所述代理服务器与服务器间的TCP选项，包括：修改TCP选项中的MSS为所述客户端支持的MSS，并剥离客户端不支持的TCP选项，包括时间戳、窗口扩大因子、选择确认选项；

所述服务器向代理服务器传送http响应头报文，并在所述http响应头报文传送至内核态的IP协议栈时，通过粘合模块检测所述http响应头报文是否符合预先配置的粘合条件，若符合，则进行TCP连接粘合。

进一步的，本发明所述方法中，所述客户端与代理服务器进行协商建立TCP连接具体为：

所述客户端向代理服务器发送syn报文，所述代理服务器记录所述syn报文中TCP选项中客户端支持的最大报文长度MSS，记录交互报文的TCP序号、客户端支持的TCP选项，包括时间戳、窗口扩大因子、选择确认；

所述代理服务器发送syn-ack报文给客户端；其中，在发送所述syn-ack报文过程中，通过粘合模块剥离时间戳和窗口扩大因子TCP选项；

所述客户端向所述代理服务器反馈ack消息，完成客户端到代理服务器TCP连接的建立。

进一步的，本发明所述方法中，所述代理服务器与服务器进行协商建立TCP连接具体为：

所述代理服务器向服务器发送syn报文，其中，在发送syn报文过程中，根据客户端和代理服务器协商的结果，通过粘合模块调整TCP选项，具体包括：调整TCP选项中MSS为所述客户端支持的MSS，并剥离客户端不支持的TCP选项，包括时间戳、窗口扩大因子、选择确认选项。

所述服务器接收到所述syn报文后，向所述代理服务器反馈syn-ack报文；

所述代理服务器向服务器反馈ack消息，完成代理服务器到服务器TCP连接的建立。

进一步的，本发明所述方法中，在进行TCP连接粘合后还包括：所述粘合模块通知应用层释放已建立的TCP连接对应的资源。

本发明所述方法中，在代理服务器与客户端进行协商建立TCP连接时，记录的交互报文的TCP序号包括：客户端到代理服务器的syn报文的序号和代理服务器到客户端的syn-ack报文的序号；

在代理服务器与服务器进行协商建立TCP连接时，记录的交互报文的TCP序号包括：代理服务器到服务器的syn报文的序号和服务器到代理服务器的syn-ack报文的序号。

进一步的，本发明所述方法中，在进行TCP连接粘合后还包括：所述粘合模块建立TCP序列号和确认号的映射逻辑，所述映射逻辑包括：

服务器接收报文的新序列号＝现有服务器接收报文的序列号-客户端到代理服务器的syn报文的序列号+代理服务器到服务器的syn报文的序列号；

服务器接收报文的新确认号＝现有服务器接收报文的确认号+服务器到代服务器的syn-ack报文的序列号-代理服务器到客户端的syn-ack报文的序列号；

客户端接收报文的新序列号＝现有客户端接收报文的序列号-服务器到代理服务器的syn-ack报文的序列号+代理服务器到客户端的syn-ack报文的序列号；

客户端接收报文的新确认号＝现有客户端接收报文的确认号+客户端到代理服务器的syn报文的序列号-代理服务器到服务器的syn报文的序列号。

本发明所述方法中，在进行TCP连接粘合后，所述服务器和客户端均对发送的报文重算报文校验和。

在进行TCP连接粘合后，所述服务器和客户端间交互的报文直接通过IP层发送至对端。

所述粘合模块检测所述http响应头报文是否符合预先配置的粘合条件具体为：所述粘合模块对所述http响应头报文进行协议分析，获取报文解析项，并检测所述报文解析项是否满足预先配置的粘合条件；其中，所述报文解析项包括下述中的一项或多项：文件大小、文件类型和是否是http片断。

进一步的，所述粘合模块检测出所述http响应头报文不符合预先配置的粘合条件时，直接将所述http响应头报文向上层TCP协议栈发送。

与现有技术相比，本发明有益效果如下：

首先，本发明提供的方法增加TCP粘合技术适用的广度，比如深度内容检测、病毒过滤；

其次，本发明所述方法使得一个会话只有TCP三次握手和客户端的HTTP请求需要应用代理参与，后续所有的报文直接在IP层路由转发，避免了数据包从核心空间到用户空间的拷贝，和多次socket系统调用导致的上下文切换，显著提高了转发的性能，并且大大降低了通信延迟。把应用代理的性能提升至和路由转发相当的程度，使之可以应用于大规模的网络系统中。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术中应用层连接粘合代理的原理图；

图2为现有技术中http协议处理流程图；

图3为本发明中http协议处理流程图；

图4为本发明提供的一种加速应用代理的核心级TCP连接粘合方法流程图；

图5为本发明实施例提供的一种加速应用代理的核心级TCP连接粘合方法的流程图；

图6为本发明中客户端、代理服务器和服务器间报文流向图。

具体实施方式

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

为了解决现有技术中存在的技术问题，本发明提供一种加速应用代理的核心级TCP连接粘合方法，该方法增加了TCP粘合技术适用的广度，比如深度内容检测、病毒过滤等。

通过图2可知，现有技术中对于TCP连接粘合的时机都是建立在客户端与代理服务器三次握手后，客户端向代理服务器发送http请求报文时，然而若在此时进行TCP连接粘合处理，对于像内容过滤和病毒过滤这样的应用确不能适用，因为，对于像内容过滤和病毒过滤这样的应用需要在得到http响应头部时，才可以完全获取粘合需要的信息，例如响应文件的大小，是否是http片断，文件类型等等。

本发明所述方法就是基于粘合所需信息的获取时刻作为粘合时机的判断基准，改变了传统的在TCP连接粘合时机，将粘合时机选取在获得http响应头部时，具体如图3所示。

然而，对于上述粘合时机的选取还存在一些问题，因为http数据紧跟着http响应头部到达代理服务器，甚至有可能http响应头部和http数据在同一个IP报文里面。这就导致在应用层通知IP层做粘合的时候，后续的http数据可能已经到达TCP的协议栈，并且协议栈很可能已经发送了ACK报文。在这种TCP协议栈缓存了http数据的情况下，很难保证报文的完整性。

为了解决这个问题，本发明所述方法提出在内核态的IP协议栈收到http响应头部的时候(到达TCP协议栈之前)，做粘合的决策。从图3可以看出，这个报文之前的所有报文都已经发送给了通信的另外一端，TCP协议栈没有缓存任何报文。本发明所述方法在内核态(IP层)做http响应头部的协议分析，获取文件大小、文件类型、是否是http片断等，进而做粘合的判断。如果符合粘合条件，那么从http响应头部这个报文开始，就开始做粘合了，不再向TCP协议栈传送这个报文。从而巧妙的避开了TCP协议栈缓存报文的问题，并且相对于传统的实现，大大拓展了粘合技术的应用范围。

其中，所述的粘合条件可以根据具体情况进行灵活设置，下面通过两个示例来说明哪些情况下符合粘合条件：

示例一：对于深度内容检测

某些实现可以做到对文本的内容检测，那么其他的文件类型content-type就可以做粘合；某些实现可能做的更深入，比如可以对office文件做检测。那么除了文本、office文件之外其他的可以粘合。

示例二：网关防病毒

由于病毒匹配是CPU密集型的工作，一般的网关防病毒产品性能较弱，相对于交换、路由设备可能差一个量级。

为了提高网关防病毒产品的可用性，产品的开发人员可以选择性的扫描部分流量。比如扫描感染病毒可能性最大的文件(exe、图片、脚本等)。其他的文件类型就可以粘合了。

对于基于文件查杀的产品，由于设备的内存受限，不可能还原任意大小的文件。所以在文件大小Content-Length域超过阀值的时候，可以设置粘合条件。

具体的，本发明提供的一种加速应用代理的核心级TCP连接粘合方法，如图4所示，具体包括以下步骤：

步骤S401、代理服务器与客户端进行协商建立TCP连接。

其中，在协商时，所述代理服务器通告客户端不支持时间戳和窗口扩大因子TCP选项，并记录交互报文的TCP序号、客户端支持的最大报文段长度信息MSS以及客户端是否支持选择确认TCP选项。

步骤S402、代理服务器接收到客户端发送的http请求报文后，与服务器进行协商建立TCP连接，并向所述服务器转发所述http请求报文。

其中，在与服务器进行协商建立TCP连接时，记录交互报文的TCP序号，并基于所述代理服务器与客户端间的协商结果，调整所述代理服务器与服务器间的TCP选项，包括：修改TCP选项中的MSS为所述客户端支持的MSS，并剥离客户端不支持的TCP选项，包括时间戳、窗口扩大因子、选择确认选项。

步骤S403、服务器向代理服务器传送http响应头报文，并在所述http响应头报文传送至内核态的IP协议栈时，通过粘合模块检测所述http响应头报文是否符合预先配置的粘合条件，若符合，执行步骤S404；否则，执行步骤S405。

步骤S404、粘合模块进行TCP连接粘合。

步骤S405、粘合模块直接将http响应头报文向上层TCP协议栈发送。

下面根据图5～图6给出本发明一个较佳的实施例，并结合对实施例的描述，进一步给出本发明的技术细节，使其能够更好地说明本发明提供的方法的具体实现过程。

如图5所示，为本发明实施例提供的一种加速应用代理的核心级TCP连接粘合方法，包括：

第一阶段：客户端和代理服务器三次握手，建立TCP连接：

步骤S501、客户端向代理服务器发送syn报文。

步骤S502、代理服务器接收到syn报文后向客户端反馈syn-ack报文。

该步骤中，为了适应后续的TCP连接粘合过程，在该建立TCP连接过程中，还要对常见的TCP选项进行协商和转换，具体为：

代理服务器接收到syn报文后，记录双向交互报文的TCP序号，包括客户端到代理服务器的syn报文的序号和代理服务器到客户端的syn-ack报文的序号、记录客户端支持的最大报文长度MSS，以及客户端支持的TCP选项，包括：时间戳、窗口扩大因子和选择确认选项。其中，如果客户端不支持选择确认，则在代理服务器向服务器端发送syn报文时需要剥离syn报文里面的选择确认选项；如果支持选择确认选项，则不做处理。

然后，代理服务器在向客户端反馈syn-ack报文过程中，通过粘合模块剥离时间戳和窗口扩大因子选项，即关闭TCP选项中时间戳和窗口扩大因子选项。

步骤S503、客户端向代理服务器发送ack报文，至此建立起TCP连接。

第二阶段：

步骤S504、客户端向代理服务器发送http请求报文。

第三阶段：代理服务器和服务器三次握手，建立TCP连接：

步骤S505、代理服务器向服务器发送syn报文。

该步骤中，为了适应后续的TCP连接粘合过程，所述代理服务器向服务器发送syn报文时，记录交互报文的TCP序号，并基于所述代理服务器与客户端间的协商结果，调整所述代理服务器与服务器间的TCP选项，包括：修改TCP选项中的MSS为所述客户端支持的MSS，并剥离客户端不支持的TCP选项，包括时间戳、窗口扩大因子；若客户端不支持选择确认选项，则此时也剥离选择确认选项。

步骤S506、服务器向代理服务器反馈syn-ack报文。

步骤S507、代理服务器向服务器发送ack报文，至此建立起TCP连接。

第四阶段：

步骤S508、代理服务器向服务器转发客户端发送的http请求报文。

第五阶段：

步骤S509、服务器接收到http请求报文后向代理服务器传送http响应头部报文，并在该http响应头报文传送至内核态的IP协议栈时，通过粘合模块对该http响应头部报文进行协议分析，获取报文解析项，粘合模块检测报文解析项是否符合预先配置的粘合条件，若符合，粘合模块对当前的TCP连接进行粘合；否则，直接将所述http响应头报文向上层TCP协议栈发送。

其中，报文解析项包括：文件大小、文件类型、是否是http片断等。

该步骤中，在进行TCP连接粘合后，后续报文不再经过应用代理转发，直接在核心层路由转发。而应用层分配的包括socket描述符、存储资源等资源，已经不需要了，此时，粘合模块需要通知应用层释放建立TCP连接对应的资源。

需要说明的是，由于被粘合的两个TCP连接(包括客户端到代理服务器和代理服务器到服务器)使用完全不同的序列号空间，因此必须有一种机制将两个连接上传送的报文的序列号进行互相的转换——映射，所以在TCP连接粘合后，粘合模块还需要建立TCP序列号映射逻辑，用来适应TCP粘合后的报文传送；进一步的，目前所见的TCP协议栈都支持选择确认(SACK)选项，TCP连接粘合后选择确认的确认号同样需要调整。

如图6所示，为本发明中客户端、代理服务器和服务器间报文流向图，图中出现了四个独立的序列号空间：C2P_SEQ、P2S_SEQ、S2P_SEQ、P2C_SEQ(TCP是全双工的通信协议，反方向的处理是对称的)。这里提到的四个序列空间分别表示某一个方向上的通信序列，包括SYN、Data以及ACK报文等。TCP的任何一个方向上的通信都是有序的，因此我们定义序列空间为：该方向上发起的第一个SYN报文的序列号作为该序列空间的起始号码。通常粘合的过程中报文的长度不会被修改，因此序列号映射仅仅需要固定的偏移。进而，本发明中，序列号和确认号映射逻辑如下：

服务器接收报文的新序列号＝现有服务器接收报文的序列号-C2P_SEQ+P2S_SEQ；

服务器接收报文的新确认号＝现有服务器接收报文的确认号+S2P_SEQ-P2C_SEQ；

客户端接收报文的新序列号＝现有客户端接收报文的序列号-S2P_SEQ+P2C_SEQ；

客户端接收报文的新确认号＝现有客户端接收报文的确认号+C2P_SEQ-P2S_SEQ；

完成这样映射的计算量非常小，因此在进行报文转换的时候，避免了复杂的序号操作。

进一步的，TCP的校验和覆盖了整个TCP报文段：TCP头部和TCP数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。如果校验和错误收端会把TCP报文丢弃。很明显在调整过序列号、确认号、选择确认的确认号后，TCP的校验和一定需要重算，校验和可以只做部分数据的重算，效率会很高。

在进行TCP粘合后，执行第六阶段，即服务器直接向客户端发送http数据，客户端在接收到http数据后向服务器反馈接收响应消息。

为了更清楚的表述本发明，下面对上述图5中客户端与代理服务器以及代理服务器与服务器间建立TCP连接过程中对TCP选项的协商机制进行说明，具体如下：

TCP选项的协商是一件比较困难的事，因为选项协商是TCP三次握手时发生的。当客户端和应用代理连接建立完成后，客户端和应用代理的TCP选项协商也完成了。之后应用代理和服务器协商TCP选项的时候，客户端和应用代理协商完成的选项已经不可改变。所以TCP选项只能单向传递。比较安全的做法是让代理服务器支持相对较小的TCP选项集合，只把客户端的选项传递给服务器，而避免服务器的选项向客户端传递。

首先，对于TimeStamps时间戳，时间戳选项使发送方在每个报文段中放置一个时间戳值。接收方在确认中返回这个数值，从而允许发送方为每一个收到的ACK计算RTT。目前许多实现为每一个窗口只计算一个RTT，对于包含8个报文段的窗口而言这是正确的。然而，较大的窗口大小则需要进行更好的RTT计算。

这个选项是为了计算RTT，只是一个辅助的功能。处理这个选项简单的办法就是关闭本地协议栈tcp_timestamps功能。这样客户端和服务器都认为对方不支持该选项，协商的问题就解决了。

其次，对于MSS(Maximum Segment Size)最大报文段

最大报文段长度(MSS)表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。我们已经见过MSS都是1460，通常这个选项并不需要做转换。有一种常见情形客户端会通告服务器，它的MSS小于1460。就是支持IPSEC的客户端和远端通信时，IPSEC协议包含的ESP协议(IP协议号为50)会在标准的IP头后面添加ESP头部并且在数据包后面添加ESP尾。为了使整个报文的长度不大于1464，会为ESP保留一段长度，所以会通告服务器MSS小于1460。这种情况下需要把客户端的MSS传递到服务器。

具体的做法就是在客户端和应用代理进行协商时，记录客户端的MSS。代理服务器发起一个TCP三次握手连接时，修改SYN报文的MSS，使之和客户端的MSS相同。

第三，对于Windows Scale窗口扩大因子

窗口扩大选项使TCP的窗口定义从16位增加为32位。这并不是通过修改TCP首部来实现的，TCP首部仍然使用16位，而是通过定义一个选项实现对16位的扩大操作(scaling operation)来完成的。于是TCP在内部将实际的窗口大小维持为32位的值。

通常16位的窗口已经可以满足大多数的需求，所以这个选项可以简单处理。类似时间戳，把本地协议栈的窗口扩大因子选项关闭即可。

第四，对于选择确认(SACK)

选择确认(Selective ACK选择性ACK)SACK是针对TCP协议中的累积确认协议(Cumulative Acknowledgement)提出的。接收方有选择地在SACK确认信息中告知发送方已经正确接收到的部分数据包，而发送方根据SACK就可以只重发出错包，这就避免了不必要的数据重传。当通讯需要更有效率的进行时，通信的双方需要尽早地检测到任何丢失的分组，就发送端而言，可以根据获得的SACK的信息判断哪些分组未被确认，从而可以请求重新传输丢失的分组。目前仍未见不支持SACK的协议栈，所以这个选项无需做处理。

本发明提供的方法增加TCP粘合技术适用的广度，比如深度内容检测、病毒过滤；并且由于本发明所述方法使得一个会话只有TCP三次握手和客户端的HTTP请求需要应用代理参与，后续所有的报文直接在IP层路由转发，避免了数据包从核心空间到用户空间的拷贝，和多次socket系统调用导致的上下文切换，显著提高了转发的性能，并且大大降低了通信延迟。把应用代理的性能提升至和路由转发相当的程度，使之可以应用于大规模的网络系统中。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。