一种保持安全套接层会话持续性的方法及设备

摘要

本发明提供了一种保持安全套接层会话持续性的方法及设备。所述方法包括：A.本地负载均衡SLB设备接收第一客户端发送的携带有第一会话标识的SSL连接恢复请求，所述第一会话标识中包含有第一服务器的设备标识；B.SLB设备从所述SSL连接恢复请求中获取第一服务器的设备标识，并根据预存的服务器的设备标识和服务器地址之间的第一对应关系，确定第一服务器的设备标识对应的第一服务器的地址，并将所述SSL连接恢复请求发送至第一服务器；C.第一服务器根据所述SSL连接恢复请求，恢复本服务器与第一客户端之间的SSL连接。按照本发明，可以减少对SLB设备内存资源的占用，减轻SLB设备的工作负担。

说明书

技术领域

本发明涉及数据通信技术领域，具体涉及一种保持安全套接层会话持续性的方法及设备。

背景技术

安全套接层(SSL，Security Socket Layer)协议在传输控制协议(TCP)层之上建立了一条加密连接，可以保证通讯双方传输数据的私密性。SSL协议的通讯过程分为两个阶段：

一、握手阶段：SSL的客户端与服务器端通过SSL握手协议协商密钥等会话参数，建立SSL连接；

二、数据传输阶段：SSL客户端与服务器端使用协商出来的密钥对通讯数据进行加密，并传送给对方；对方接收后会使用协商处出来的密钥解密，得到通讯数据。

由于建立SSL连接的握手过程涉及较多的复杂计算，所以SSL协议提供了一种会话恢复机制，以快速恢复会话。通常情况下，使用会话恢复的次数要远远多于新建连接的次数。会话恢复机制的流程如下：

(1)在进行第一次通讯时，客户端与服务器端执行完整的握手过程，协商出会话密钥，具体包含以下特殊的处理步骤：

客户端首先发送一个新建SSL连接请求报文(ClientHello报文)，该报文中的会话标识(session_id)字段为0，表示自己没有缓存的会话参数，请求建立新的会话连接；

SSL服务器会为新建立的SSL连接分配一个会话ID，并针对ClientHello报文返回一个响应报文(ServerHello)。该报文中有一个session_id字段，用于记录服务器端为本次会话所分配的会话标识(ID)。根据SSL协议规定，会话ID是一个32字节的随机数，其构造完全由实现者自行定义。

在客户端与服务器端交互完ClientHello和ServerHello后，双方就可以进一步协商会话参数，建立SSL会话连接，这一过程较复杂、耗时较多，在此介绍从略。

(2)在完成一次数据传送任务后，可以由客户端或者服务器端发起断开SSL连接的操作，但通讯双方仍可以在本地保留刚才使用过的会话参数。

(3)当再次发起与服务器端的连接请求时，客户端可以继续使用仍在本地保存的会话，在ClientHello报文中使用该会话的会话ID来填充session_id字段，发起SSL连接恢复请求。服务器端接收到该SSL连接恢复请求后，在本地的会话缓存中查找与该session_id相对应的会话记录：如果找到了，服务器根据本地保存的该session_id的会话参数进行会话恢复，通讯双方通过一个简单的验证过程，就可以恢复会话的使用了，从而避免了再次建立SSL连接所消耗的大量时间；如果会话ID无效，表明在服务器已不存在指定的会话记录了，服务器就会分配一个新的会话ID，并将该会话ID放入ServerHello报文中返回，之后，通讯双方执行新的完整的会话协商过程以建立SSL连接。

负载均衡(LB，Load Balance)是通过LB设备根据后台服务器的负载情况，将客户端发来的请求均衡地分发给服务器进行处理，从而使得整个系统的计算资源得到充分的利用。SLB(Site Load Balance)是指本地设备的负载均衡，即LB设备和服务器处在同一个局域网中。SLB有网络地址转换(NAT，Network Address Translation)模式和直接路由(DR，Direct-Routing)模式两种工作模式。

如图1所示，NAT模式中，SLB设备对外提供一个可访问的IP地址IP0。后台服务器有各自的IP地址IP1～IP3。SLB设备对IP报文的处理过程如下：

(1)SLB设备接收来自客户端的目的地址为IP0的IP报文。

(2)SLB设备根据负载均衡算法，确定哪台服务器适合处理此报文，比如是服务器1。

(3)SLB设备将来自客户端的IP报文的目的地址改写为IP1，并通过路由转发出去。

(4)服务器1接收到目的IP为IP1的报文，对其进行处理，生成响应报文，该响应报文的目的IP为客户端的IP地址，而源IP为本机的IP1。

(5)在服务器1上设置路由的默认网关为SLB设备。这样，服务器1根据路由将响应报文转发给SLB设备。

(6)SLB设备对IP报文的源IP地址进行转换，改写为IP0。

(7)SLB设备将经过源地址转换过的IP报文转发给客户端。

在上述负载均衡的实现过程中，SLB设备对客户端和服务器之间的报文在进行地址转换处理之后再转发，因此称为NAT模式。

SLB的另一种工作模式为直接路由(DR，Direct-Routing)模式，如图2所示。SLB设备和后台服务器一起构成了一个虚拟服务，对外提供可访问的IP地址IP0。其中，SLB设备上配置真实的IP地址IP0，以及与IP0相对应的MAC地址MAC0；服务器1～服务器3上只配置虚拟的IP服务地址IP0，即服务器1～服务器3可以接收目的地址为IP0的IP报文，但并不响应外界对IP0发出的地址解析协议(ARP，Address Resolution Protocol)请求。各服务器有自己的MAC地址MAC1～MAC3。如图2所示，服务器和SLB设备都连接在同一台交换设备上。该交换设备是一台三层交换设备，既可以进行二层交换，又可以进行三层的路由转发。DR模式下的负载均衡处理过程如下：

(1)客户端发送目的地址为IP0的IP报文。

(2)交换设备收到上述IP报文后，会发出ARP请求，寻找IP0对应的MAC地址。

(3)此时在服务器网段内，各服务器不响应上述ARP请求，只有SLB设备会返回自己的应答，报告IP0对应的MAC地址为MAC0。交换设备学习到此ARP表项：IP0<->MAC0后，在后续的报文转发过程中就可以不再重复发送ARP请求了。

(4)交换设备给IP报文加上目的MAC地址MAC0后，就将报文转发给SLB设备。

(5)SLB设备根据服务器的负载状况，决定由哪台服务器处理此IP报文，比如是服务器1。

(6)SLB设备将IP报文的目的MAC地址改写为服务器1的MAC地址MAC1，然后SLB设备将报文发送给交换设备，交换设备根据目的MAC地址将报文转发给服务器1。

(7)服务器1接收目的IP为IP0的报文，对其进行处理。处理完后生成响应报文，响应报文的目的IP为客户端的IP，源IP为虚拟服务地址IP0。

(8)在服务器上，配置默认网关为交换设备。这样，服务器1返回的响应报文就发送给了交换设备，由交换设备根据路由直接转发给了客户端。

上述流程中，服务器1返回的响应报文没有经过SLB设备，而是通过交换设备直接路由到客户端，因此，被称为DR模式。

以下说明TCP报文和SSL报文的负载均衡的特点：

在通常的客户端/服务器(C/S)应用中，客户端通过TCP连接发送请求，而服务器通过同一条TCP连接来返回响应。当客户端和服务器端完成一次通讯任务后，才会断开TCP连接。在对TCP报文进行均衡处理时，通常要求保持TCP连接的持续性，即将一条TCP连接分配到同一服务器上处理：在TCP连接活动期间，要求SLB设备能将来自同一个客户端同一条TCP连接上的所有报文都发送给同一台服务器进行处理，这样才能保证服务器处理业务的正确性。由于一条TCP连接可以被五元组(目的IP，目的端口号，源IP，源端口号，协议号)唯一标识。在TCP报文在经由IP层转发被分片时，还可以根据IP报头中的报文ID来判断IP报文属于哪条TCP连接，从而可以根据TCP连接与服务器之间的对应关系，将同一TCP连接上的报文发送给同一台服务器。

SSL报文承载于TCP报文之中，TCP报文又承载于IP报文之中。SSL协议以一个TCP服务的形式对外提供，使用固定的TCP服务端口。用户也可以自行配置SSL服务所使用的端口号。通过在SLB设备上配置说明SSL服务使用的TCP端口号，从而SLB设备根据TCP报文的目的端口号就可以识别出一个TCP/IP报文是否为SSL报文。在对SSL报文进行负载均衡处理时，SLB设备需要分析SSL报文，了解会话过程，之后才能做出如何分发报文的判断。SSL记录头是明文的，接收者可以直接对其进行分析。SSL握手协议报文一般是明文的，因为之前尚未协商出通讯密钥。在数据传输阶段，记录层的负载一般是加密的，无法直接进行分析。

在对SSL报文进行负载均衡处理时，同样需要保持SSL报文的持续性。对SSL会话来说，保持会话的持续性要求SLB设备将属于同一SSL会话的报文转发到同一台服务器上。属于同一SSL会话的通讯过程包括新建立连接的通讯、以及通过SSL会话恢复而建立连接的通讯，这两个通讯过程使用同一组会话密钥参数。在服务器群组中，一个会话的参数只保存在其中的一台服务器上，所以要求SLB设备不但能将新建SSL连接持续性地分发给同一台服务器，还要能将会话恢复建立的SSL连接分发给保存有原来会话参数的服务器。否则，就会造成会话恢复失败而重新建立连接，这将大大降低系统建立SSL连接的效率。

现有技术中，可以采用TCP代理的方法实现SSL报文的负载均衡：

SLB设备和服务器群组按照NAT模式组网，SLB设备作为TCP代理。首先客户端通过TCP的三次握手与SLB设备建立起TCP连接1。随后，SLB设备接收SSL握手报文并进行分析，对新建连接进行负载均衡处理，确定由哪台服务器负责处理。随后，SLB设备通过TCP三次握手与所确定的后台服务器建立起新的TCP连接2，在本地保存TCP连接1和TCP连接2之间的映射关系，转发这两个TCP连接之间的报文，实现客户端与服务器之间的通讯。但是，TCP代理方式效率不高，存在以下问题：

(1)SLB设备成为通讯的瓶颈，负责转发所有的通讯报文。

(2)要通过TCP连接收发应用层的报文，需要SLB设备在接收报文时完成对TCP分片报文的重组；在通过IP层发送时，又要对TCP报文进行分片。

为了提高传输效率，SLB设备最好能对接收到的TCP报文直接转发出去。但是TCP连接1跟TCP连接2是不同的，两者TCP报头中的序列号是不一样的，现有技术又提出一种“TCP粘连”技术，通过SLB设备对收到的TCP报文转换其中的序列号，以提高转发效率，如图3所示，可以采用以下步骤：

步骤1～3，客户端通过TCP的三次握手与SLB设备建立起TCP连接1，客户端的初始序列号为X，SLB设备的初始序列号为Y；

步骤4～8，SLB设备接收ClientHello报文(新建SSL连接请求)后，选择服务器1，并通过三次握手与服务器1建立起TCP连接2。为了提高处理效率，SLB设备向服务器1发送的TCP连接建立(SYN)使用的初始序列号与客户端发来的SYN报文中的一样(X)，服务器返回的初始序列号为Z。

这样以后SLB设备只需要保存TCP连接1与连接2之间初始序列号的差值：Z-Y，在以后的收发的报文中：对于来自TCP连接1的报文，将客户端的确认号(ACK)加上这个差值再直接转发到TCP连接2；对于来自TCP连接2的报文，将服务器1的序列号(SN)减去这个差值再直接转发到TCP连接1即可。

为了保持SSL报文的持续性，现有技术采用以下方法对报文进行分析转发：

(1)当收到的ClientHello报文中的会话ID为0时，SLB设备判断出这是一个新建SSL连接请求，于是根据负载均衡算法将此新建连接请求分配给任何一台合适的服务器，如服务器1去处理。

(2)SLB设备接收并分析服务器1返回的ServerHello报文，从中提取会话ID，在本地保存一条映射表项：SSL会话ID<->服务器1

(3)随后SLB设备使用保持TCP连接持续性的方法(具体的可以通过保存TCP连接与服务器之间的对应关系，根据该对应关系确定对应的服务器)，，以及前述的序列号转换方法，将客户端的报文持续发送到服务器1。

(4)在客户端与服务器1完成一次会话后，SSL连接和TCP连接就断开了，TCP连接与服务器之间的对应关系也相应地被删除。

(5)当客户端要再次与服务器端建立SSL连接时，会重新发送一个ClientHello报文，其中的会话ID为原来的会话ID，表示请求恢复SSL连接。

(6)SLB设备截获上述ClientHello报文，获得要恢复使用的会话ID，查询本地保存的SSL会话ID映射表：如果找到了，就将该报文转发给原来的服务器进行处理；否则重新分配一个服务器进行处理。

从以上所述可以看出，现有技术方案在实现保持SSL会话的持续性时，需要维护会话ID和服务器之间的对应关系，这存在以下缺点：

1)SLB设备需要分析ServerHello报文，从中获取会话ID，而对ServerHello报文的分析需要占用SLB设备的处理器资源，增加SLB设备的工作负担；

2)由于后台服务器有多个，每个服务器在工作期间通常会分配多个会话ID，因此，会话ID的数量通常都远远大于服务器的数量。SLB设备需要在内存中保存每个会话ID和服务器之间的对应关系，显然，保存该对应关系会占用较多的内存资源；并且，在每新建一个SSL会话时，都要向该对应关系中增加新的内容，因此，维护该对应关系也将增加SLB设备的工作负担。同时，为了避免内存耗尽，SLB设备不得不对该对应关系进行老化，对其中长时间未访问的会话ID进行删除，老化工作必然又会增加LB设备的工作负担。

发明内容

本发明所要解决的技术问题是提供一种保持SSL会话持续性的方法及设备，减少对SLB设备内存资源的占用，减轻SLB设备的工作负担。

为解决上述技术问题，本发明提供方案如下：

一种保持安全套接层SSL会话持续性的方法，包括：

A，本地负载均衡SLB设备接收第一客户端发送的携带有第一会话标识的SSL连接恢复请求，所述第一会话标识中包含有第一服务器的设备标识；

B，SLB设备从所述SSL连接恢复请求中获取第一服务器的设备标识，并根据预存的服务器的设备标识和服务器地址之间的第一对应关系，确定第一服务器的设备标识对应的第一服务器的地址，并将所述SSL连接恢复请求发送至第一服务器；

C，第一服务器根据所述SSL连接恢复请求，恢复本服务器与第一客户端之间的SSL连接。

较佳的，上述方法中，所述第一对应关系是根据各服务器预先配置的设备标识和地址，在SLB设备上手工配置并保存的；或者是SLB设备根据接收到的各服务器的地址以及本SLB设备为各服务器所分配的设备标识，自动建立并保存的。

较佳的，上述方法中，所述步骤A之前还包括：

SLB设备接收第一客户端发送的新建SSL连接请求，根据预定的负载均衡算法从服务器群组中选择出第一服务器，并将所述新建SSL连接请求发送至第一服务器；

第一服务器根据所述新建SSL连接请求，建立本服务器与第一客户端之间的第一SSL连接，为第一SSL连接分配包含有自身设备标识的第一会话标识，并向第一客户端返回携带有所述第一会话标识的第一响应报文。

较佳的，上述方法中，SLB设备和服务器群组中的各服务器都连接到同一个交换设备，SLB设备和服务器群组中的各服务器之间都建立有控制通道；

所述新建SSL连接请求是通过第一客户端与SLB设备之间的第一TCP连接发送的；在选择出第一服务器之后，SLB设备进一步通过所述控制通道将第一TCP连接的状态信息和所述新建SSL连接请求发送给第一服务器；

第一服务器进一步接收并维护第一TCP连接的状态信息，并根据第一TCP连接的状态信息，设置所述第一响应报文中的对应信息，并将所述第一响应报文通过所述交换设备发送至第一客户端。

较佳的，上述方法中，在选择出第一服务器之后，SLB设备进一步保存第一TCP连接与第一服务器之间的第二对应关系，并根据第二对应关系，将后续来自所述第一TCP连接的所有报文都转发至第一服务器。

6.如权利要求5所述的方法，其特征在于，

所述SSL连接恢复请求是通过第一客户端与SLB设备之间的第二TCP连接发送的；在确定第一服务器的设备标识对应的第一服务器的地址之后，SLB设备进一步通过所述控制通道将第二TCP连接的状态信息和所述SSL连接恢复请求发送至第一服务器；

第一服务器进一步接收并维护第二TCP连接的状态信息，生成所述SSL连接恢复请求的第二响应报文，并根据第二TCP连接的状态信息，设置第二响应报文中的对应信息，并将所述第二响应报文通过所述交换设备发送至第一客户端。

较佳的，上述方法中，在确定第一服务器的设备标识对应的第一服务器的地址之后，SLB设备进一步保存第二TCP连接与第一服务器之间的第三对应关系，并根据第三对应关系，将后续来自所述第二TCP连接的所有报文都转发至第一服务器。

本发明还提供了一种本地负载均衡SLB设备，包括：

接收单元，用于接收第一客户端发送的携带有第一会话标识的SSL连接恢复请求，所述第一会话标识中包含有第一服务器的设备标识；

服务器选择单元，用于从所述SSL连接恢复请求中获取第一服务器的设备标识，并根据预存的服务器的设备标识和服务器地址之间的第一对应关系，确定第一服务器的设备标识对应的第一服务器的地址；

转发单元，用于根据所述服务器选择单元确定的第一服务器的地址，将所述SSL连接恢复请求发送至第一服务器。

较佳的，上述的SLB设备还包括：

第一对应关系保存单元，用于接收并保存外部输入的所述第一对应关系；或者用于根据本SLB设备接收到的各服务器的地址以及本SLB设备为各服务器所分配的设备标识，建立并保存所述第一对应关系。

较佳的，上述的SLB设备中，

所述接收单元，还用于接收第一客户端发送的新建SSL连接请求；

所述服务器选择单元，还用于在接收到所述新建SSL连接请求后，根据预定的负载均衡算法从服务器群组中选择出第一服务器；

所述转发单元，还用于将所述新建SSL连接请求发送至所述服务器选择单元选择出的第一服务器。

较佳的，上述的SLB设备中，

所述接收单元，进一步用于建立与第一客户端之间的第一TCP连接，通过第一TCP连接接收所述新建SSL连接请求；

所述转发单元，进一步用于通过本SLB设备和第一服务器之间的控制通道，将所述新建SSL连接请求和第一TCP连接的状态信息发送给第一服务器；以及在所述服务器选择单元选择出第一服务器之后，进一步保存第一TCP连接与第一服务器之间的第二对应关系，并根据第二对应关系，将后续来自所述第一TCP连接的所有报文都转发至第一服务器。

较佳的，上述的SLB设备中，

所述接收单元，进一步用于建立与第一客户端之间的第二TCP连接，通过第二TCP连接接收所述SSL连接恢复请求；

所述转发单元，进一步用于通过本SLB设备和第一服务器之间的控制通道，将所述SSL连接恢复请求和第二TCP连接的状态信息发送给第一服务器；以及在所述服务器选择单元确定出第一服务器的设备标识对应的第一服务器的地址之后，进一步保存第二TCP连接与第一服务器之间的第三对应关系，并根据第三对应关系，将后续来自所述第二TCP连接的所有报文都转发至第一服务器。

本发明还提供了一种服务器，包括：

接收单元，用于接收SLB设备转发的来自第一客户端的SSL连接恢复请求；

SSL处理单元，用于根据所述SSL连接恢复请求，恢复本服务器与第一客户端之间的SSL连接。

较佳的，上述服务器中，所述接收单元，还用于接收SLB设备转发的来自第一客户端的新建SSL连接请求；

所述SSL处理单元，还用于根据所述新建SSL连接请求，建立本服务器与第一客户端之间的第一SSL连接，为第一SSL连接分配包含有自身设备标识的第一会话标识，并生成携带有所述第一会话标识的第一响应报文；

所述服务器还包括：

发送单元，用于将所述第一响应报文发送给第一客户端。

较佳的，上述服务器中，所述接收单元，进一步用于通过本服务器与SLB设备之间的控制通道，接收所述新建SSL连接请求和第一TCP连接的状态信息，所述第一TCP连接是第一客户端与SLB设备之间发送所述新建SSL连接请求的TCP连接；

所述发送单元，进一步用于维护所述第一TCP连接的状态信息，并根据第一TCP连接的状态信息，设置所述第一响应报文中的对应信息；

所述SSL处理单元，还用于处理SLB设备转发的来自所述第一TCP连接的报文。

较佳的，上述服务器中，所述接收单元，进一步用于通过本服务器与SLB设备之间的控制通道，接收所述SSL连接恢复请求和第二TCP连接的状态信息，所述第二TCP连接是第一客户端与SLB设备之间发送所述SSL连接恢复请求的TCP连接；

所述SSL处理单元，还用于生成所述SSL连接恢复请求的第二响应报文，以及用于处理SLB设备转发的来自所述第二TCP连接的报文；

所述发送单元，进一步用于维护所述第二TCP连接的状态信息，并根据第二TCP连接的状态信息，设置所述第二响应报文中的对应信息。

从以上所述可以看出，本发明提供的保持SSL会话持续性的方法及设备，具有以下有益效果：

1)SLB设备不需要分析ServerHello报文，从而可以减轻SLB设备的工作负担。

2)SLB设备也无需保持SSL会话的会话ID和服务器之间的对应关系，而只需保存较为简单的设备ID与服务器之间的对应关系。由于负载均衡系统中的服务器的数量稳定且有限，因此，保存设备ID与服务器之间的对应关系通常只需要较小的内存空间。本发明所保存的对应关系不需要老化操作，并且由于该对应关系具有很好的稳定性，在服务器群组不发生变化的情况下，无需维护操作。因此，本发明可以节约SLB设备的内存资源，减轻SLB设备的工作负担。

3)最后，由于本发明中SLB设备无需截获并分析ServerHello报文，因此可以在采用DR模式的SSL报文负载均衡的情况下保持SSL会话的持续性，而DR模式的负载均衡通常能够达到较高的报文转发性能，因此，本发明可以在保持SSL会话持续性的同时达到较高的报文转发性能。

附图说明

图1为现有技术的NAT模式的负载均衡系统的示意图；

图2为现有技术的DR模式的负载均衡系统的示意图；

图3为现有技术的SLB设备对TCP报文序列号的转换示意图；

图4为TCP迁移技术的应用环境示意图；

图5为TCP迁移技术对应用层报文的处理示意图；

图6为本发明实施例所述保持SSL会话持续性的方法流程图；

图7为本发明实施例所述SLB设备的结构示意图；

图8为本发明实施例所述服务器的结构示意图。

具体实施方式

本发明的主要思想是：通过在SSL会话的会话ID中携带服务器设备ID的信息，在SLB设备上配置服务器的设备ID和服务器地址之间的对应关系，从而在后续的SSL会话恢复时SLB设备根据会话ID中的设备ID就可以选择对应的服务器进行SSL会话恢复。虽然服务器群组可能分配很多个会话ID，但服务器群组中所包括的服务器的数目是固定的且有限的，因此，相对于现有技术，保存服务器的设备ID和服务器地址之间的对应关系只需要很小的内存资源且无需老化等维护操作，从而可以节约内存资源和减轻SLB设备工作负担。以下通过附图结合具体实施例对本发明作进一步说明。

根据背景技术中的分析，现有技术在实现保持SSL会话的持续性时，需要通过SLB设备分析ServerHello报文，提取其中的会话ID。由于DR模式的SSL报文的负载均衡中，服务器返回的ServerHello报文被发送到默认网关交换设备上，由交换设备直接路由到客户端，因此，SLB设备不能截获ServerHello报文，从而现有技术无法在DR模式下保持SSL会话的持续性。

在NAT模式中，来自客户端和服务器的报文都经由SLB设备转发，SLB设备成为报文转发的瓶颈。而在DR模式中，服务器返回的报文不通过SLB设备，而是通过交换设备直接传送给了客户端。在一般情况下，进行二、三层报文转发的交换设备可以实现较高的转发性能。所以相对而言，DR模式的报文转发性能较高。本发明无需分析ServerHello报文，可以在DR模式下保持SSL会话的持续性，同时达到较好的报文转发性能。为了更好的理解本实施例，这里首先对TCP迁移技术进行简单介绍。

TCP迁移技术的系统的组网如图4所示，TCP迁移技术包括：

1、准备阶段：

如图4所示，SLB设备与服务器群组按照DR模式组网。整个群组对外公开的服务地址为IP0。在LB上配置真实的IP地址IP0和IP_0；各服务器除了配置一个虚拟服务地址IP0以外，还配置一个真实的IP地址，如IP1～IP3，用于内部通讯。SLB设备与群组内各服务器之间建立起一条控制通道(如图4中的虚线双向箭头所示)，比如一条一直不断开的TCP常连接，用于SLB设备与各服务器之间传递控制信息。

2、对应用层报文的负载均衡处理

如图5所示，通讯过程如下：

步骤1～3，通过三次握手，客户端与SLB设备之间建立起了TCP连接。

步骤4，客户端向服务器端发送应用层服务请求报文；SLB设备分析应用层服务请求报文，根据负载情况，确定一个合适的服务器来处理此请求，比如是服务器1。

步骤5，通过控制通道，SLB设备将与客户端建立的TCP连接的状态信息同步给服务器1。同步的信息包括：TCP连接的源IP、源端口号、目的IP、目的端口号、收发双方当前的TCP序列号，以及应用层请求报文。服务器1建立新的TCP控制块，按照SLB设备同步过来的状态信息进行设置。并且由服务器上的应用层模块处理应用层请求报文。处理完应用层请求报文后，服务器向客户端返回应答报文。由于采用DR模式，此报文将通过交换设备直接转发给客户端，不经过SLB设备。

后续由客户端发送来的应用层报文，由于目的IP为IP0，故仍会到达SLB设备。SLB设备采用保持TCP连接持续性的方法，将后续报文转发给了服务器1。而服务器1的后续报文仍然通过交换设备转发给了客户端。

上述这种通过同步TCP连接的状态，实现TCP连接被转移到另一台设备上去处理的方法，被称为“TCP迁移”。

本实施例以基于DR模式的TCP迁移技术为例进行说明。根据SSL协议，会话ID是一个32字节的随机数，ID值的构造可以由实现者自行定义。因此，本实施例中在会话ID中携带服务器的设备ID，该设备ID是服务器群组中唯一标识该服务器的标识。例如，在会话ID的32个字节中选择出特定字节部分(如第1个字节)用于保存设备ID，服务器在为SSL会话分配会话ID时，该特定字节部分的内容为服务器自身的设备ID，其它字节内容可以由服务器自行分配。

如图6所示，本实施例所述保持SSL会话持续性的方法包括以下步骤：

步骤601，通过TCP三次握手，客户端与SLB设备之间建立起了第一TCP连接。

步骤602，客户端通过第一TCP连接发送新建SSL连接请求(ClientHello报文)，该报文中的会话ID为0。

步骤603，SLB设备分析ClientHello报文，根据会话ID为0，判断出这是一个新建SSL连接请求。SLB设备根据预定的负载均衡算法，选择出一个合适的服务器来处理此请求，比如是服务器1，同时，SLB设备在本地保存第一TCP连接和服务器1之间的对应关系。

本步骤中，可以利用现有技术中已有的负载均衡算法，选择服务器处理新建SSL连接请求。

步骤604，通过控制通道，SLB设备将ClientHello报文和第一TCP连接的状态信息同步给服务器1。所述状态信息包括：第一TCP连接的源IP、源端口号、目的IP、目的端口号、收发双方当前的TCP序列号。这里，第一TCP连接的源IP是SLB设备的IP地址，源端口号是SLB设备对应于该第一TCP连接的端口号，目的IP是客户端的IP地址，目的端口号是客户端对应于该第一TCP连接的目的端口。

步骤605，服务器1建立新的TCP控制块，按照SLB设备同步过来的第一TCP连接的状态信息设置该TCP控制块，通过TCP控制块维护第一TCP连接的状态信息，从而将第一TCP连接的端点从SLB设备迁移到服务器1，即服务器替代SLB设备作为第一TCP连接中对应于客户端的端点，对第一TCP连接上的来自客户端的报文进行处理并返回响应报文。对于其中的ClientHello报文，由服务器1上的SSL模块来处理。

步骤606，服务器1上的SSL模块处理完ClientHello报文后，为新建立的SSL连接分配一个包含服务器1自身设备ID的会话ID，并生成ServerHello报文，该报文中携带有所分配的会话ID；并根据TCP控制块中的第一TCP连接的状态信息设置ServerHello报文的TCP头和IP头中的对应信息：具体包括设置TCP序列号、源/目的IP地址、源/目的端口号，其中，ServerHello报文的目的IP是客户端的IP地址，目的端口号是客户端对应于第一TCP连接的端口号，源IP是SLB设备的IP地址(即整个系统的虚拟服务IP地址，对应于图4中的IP0)，源端口号是SLB设备对应于第一TCP连接的端口号，TCP序列号为收发双方当前的序列号；由于采用DR模式，该ServerHello报文被发送到服务器1的默认网关(交换设备)，再由交换设备根据路由将该报文直接转发给客户端，不经过SLB设备。

在所述新建SSL连接请求之后，后续由客户端发送来的SSL协议报文，由于目的IP地址为SLB设备的IP地址，故仍会到达SLB设备。SLB设备采用保持TCP连接持续性的方法，对于后续来自第一TCP连接上接收到的所有报文，转发到第一TCP连接对应的服务器1，具体的可以是将该报文的目的MAC地址改写为服务器1的MAC地址，然后将该报文发送给交换设备，交换设备根据目的MAC地址将报文转发给服务器1。而服务器1的后续的SSL协议报文则仍然通过交换设备直接路由至客户端。在客户端与服务器端交互完ClientHello和ServerHello后，双方就可以进一步协商会话参数，建立SSL会话连接。

在客户端与服务器端完成一次SSL会话后，SSL连接和TCP连接就断开了，SLB设备同时会删除先前保存的第一TCP连接与服务器1之间的对应关系。

步骤607，当客户端想要再次与服务器端建立SSL连接时，需要再通过TCP的三次握手与SLB设备建立起第二TCP连接，并通过该第二TCP连接重新发送一个SSL连接恢复请求(ClientHello报文)，其中的会话ID为先前分配的会话ID。

步骤608，SLB设备在本地保存有服务器设备ID和服务器地址之间的对应关系表，所述服务器地址是服务器的MAC地址；SLB设备接收到上述SSL连接恢复请求后，获得要恢复使用的SSL连接的会话ID，根据该会话ID中包含的设备ID，查询本地保存的对应关系表：如果找到了与该设备ID对应的服务器地址，如服务器1的MAC地址，则通过控制通道，SLB设备将ClientHello报文和第二TCP连接的状态信息同步给服务器1，该状态信息包括：第二TCP连接的源IP、源端口号、目的IP、目的端口号、收发双方当前的TCP序列号，并且在本地保存第二TCP连接和服务器1之间的对应关系，然后进入步骤609；如果没找到对应的服务器，则重新分配一个服务器进行处理，接下来的流程同上述步骤603～步骤606。

这里，SLB设备上保存的服务器设备ID和服务器地址之间的所述对应关系，可以按照以下方式建立：

(1)如果SLB设备与服务器之间彼此独立，可以预先在每个服务器处分别配置该服务器地址和设备ID，然后在SLB设备上手工配置并保存系统中所有的服务器设备ID与服务器地址之间的对应关系；

(2)如果SLB设备与服务器之间构成集群，则可以通过私有的集群协议，服务器在加入集群时，向SLB设备报告自己的地址；SLB设备接收各服务器的地址，为各服务器分配设备ID，并同时保存该服务器设备ID与服务器地址之间的对应关系。

步骤609，服务器1建立新的TCP控制块，按照SLB设备同步过来的状态信息进行设置，并由服务器上的SSL模块来处理SSL连接恢复请求，在这里应该进行会话恢复的处理：在本地会话缓存中查找与其中会话ID相对应的会话参数，并根据找到的会话参数进行会话恢复，恢复SSL会话。

在所述SSL连接恢复请求之后，SLB设备根据本地保存第二TCP连接和服务器1之间的对应关系，将后续来自所述第二TCP连接的所有报文都转发至服务器1。

本实施例在DR模式下保持了SSL报文的持续性。与现有技术相比，本实施例不需要分析ServerHello报文，从而可以减轻SLB设备的工作负担；本实施例无需保持SSL会话的会话ID和服务器之间的对应关系，而只需保存较为简单的设备ID与服务器之间的对应关系。由于负载均衡系统中的服务器的数量稳定且有限，因此，保存设备ID与服务器之间的对应关系通常只需要较小的内存空间。该对应关系不需要老化操作，并且，该对应关系具有很好的稳定性，在服务器群组不发生变化的情况下，无需变动。最后，由于在DR模式中，服务器返回的报文不通过SLB设备，而是通过交换设备直接传送给了客户端。而通常进行二、三层报文转发的交换设备可以实现较高的转发性能。本实施例可以获得较高的报文转发性能。

基于上述保持SSL会话持续性的方法，本实施例还相应提供了一种本地负载均衡SLB设备和服务器。

本实施例所述SLB设备，包括：

接收单元，用于接收第一客户端发送的携带有第一会话标识的SSL连接恢复请求，所述第一会话标识中包含有第一服务器的设备标识；

服务器选择单元，用于从所述SSL连接恢复请求中获取第一服务器的设备标识，并根据预存的服务器的设备标识和服务器地址之间的第一对应关系，确定第一服务器的设备标识对应的第一服务器的地址；

转发单元，用于根据所述服务器选择单元确定的第一服务器的地址，将所述SSL连接恢复请求发送至第一服务器。

这里，SLB设备还可以包括有第一对应关系保存单元，用于接收并保存外部输入的所述第一对应关系；或者用于根据本SLB设备接收到的各服务器的地址以及本SLB设备为各服务器所分配的设备标识，建立并保存所述第一对应关系。

这里，SLB设备也可以接收新建SSL连接请求，并为客户端分配合适的服务器，此时，所述接收单元，还用于接收第一客户端发送的新建SSL连接请求；所述服务器选择单元，还用于在接收到所述新建SSL连接请求后，根据预定的负载均衡算法从服务器群组中选择出第一服务器；所述转发单元，还用于将所述新建SSL连接请求发送至所述服务器选择单元选择出的第一服务器。

这里，所述接收单元，还可以进一步用于建立与第一客户端之间的第一TCP连接，通过第一TCP连接接收所述新建SSL连接请求；所述转发单元，进一步用于通过本SLB设备和第一服务器之间的控制通道，将所述新建SSL连接请求和第一TCP连接的状态信息发送给第一服务器；以及在所述服务器选择单元选择出第一服务器之后，进一步保存第一TCP连接与第一服务器之间的第二对应关系，并根据第二对应关系，将后续来自所述第一TCP连接的所有报文都转发至第一服务器。这里，所述后续是指在接收到所述新建SSL连接请求之后。

这里，所述接收单元，还可以进一步用于建立与第一客户端之间的第二TCP连接，通过第二TCP连接接收所述SSL连接恢复请求；所述转发单元，还可以进一步用于通过本SLB设备和第一服务器之间的控制通道，将所述SSL连接恢复请求和第二TCP连接的状态信息发送给第一服务器；以及在所述服务器选择单元确定出第一服务器的设备标识对应的第一服务器的地址之后，进一步保存第二TCP连接与第一服务器之间的第三对应关系，并根据第三对应关系，将后续来自所述第二TCP连接的所有报文都转发至第一服务器，这里，所述后续是指在接收到所述SSL连接恢复请求之后。

本实施例所述的服务器，包括：

接收单元，用于接收SLB设备转发的来自第一客户端的SSL连接恢复请求；

SSL处理单元，用于根据所述SSL连接恢复请求，恢复本服务器与第一客户端之间的SSL连接。

这里，服务器还可以接收新建SSL连接请求，并为新建的SSL会话分配会话ID，此时，所述接收单元，还用于接收SLB设备转发的来自第一客户端的新建SSL连接请求；所述SSL处理单元，还用于根据所述新建SSL连接请求，建立本服务器与第一客户端之间的第一SSL连接，为第一SSL连接分配包含有自身设备标识的第一会话标识，并生成携带有所述第一会话标识的第一响应报文；所述服务器还包括：

发送单元，用于将所述第一响应报文发送给第一客户端。

这里，所述接收单元，还可以进一步用于通过本服务器与SLB设备之间的控制通道，接收所述新建SSL连接请求和第一TCP连接的状态信息，所述第一TCP连接是第一客户端与SLB设备之间发送所述新建SSL连接请求的TCP连接；所述发送单元，进一步用于维护所述第一TCP连接的状态信息，并根据第一TCP连接的状态信息，设置所述第一响应报文中的对应信息；所述SSL处理单元，还用于处理SLB设备转发的来自所述第一TCP连接的报文。

这里，所述接收单元，还可以进一步用于通过本服务器与SLB设备之间的控制通道，接收所述SSL连接恢复请求和第二TCP连接的状态信息，所述第二TCP连接是第一客户端与SLB设备之间发送所述SSL连接恢复请求的TCP连接；所述SSL处理单元，还用于生成所述SSL连接恢复请求的第二响应报文，以及用于处理SLB设备转发的来自所述第二TCP连接的报文；所述发送单元，进一步用于维护所述第二TCP连接的状态信息，并根据第二TCP连接的状态信息，设置所述第二响应报文中的对应信息。

从以上所述可以看出，通过在SLB设备处保存服务器设备ID与服务器地址之间的对应关系，根据SSL连接恢复请求中的设备ID来选择对应的服务器来处理SSL报文，从而保持了SSL会话的持续性。显然，在SLB设备与服务器群组按照NAT模式组网的情况下，本发明也完全可以适用。

本发明所述保持SSL会话持续性的方法及设备，并不仅仅限于说明书和实施方式中所列运用，它完全可以被适用于各种适合本发明之领域，对于熟悉本领域的人员而言可容易地实现另外的优点和进行修改，因此在不背离权利要求及等同范围所限定的一般概念的精神和范围的情况下，本发明并不限于特定的细节、代表性的设备和这里示出与描述的图示示例。