CN114465742B - 网络安全防护方法以及防护设备 - Google Patents

Abstract

本申请提供了一种网络安全防护方法以及防护设备，属于通信技术领域。在客户端与服务器之间交互首个会话的报文时，防护设备通过根据首个会话的报文中的应用层数据，识别应用层协议类型，根据应用层协议类型确定检测模式为代理模式，则采用代理模式对首个TCP会话的后续报文进行安全检测，从而突破首个TCP会话的报文只能采用流模式检测的技术瓶颈，保证首个TCP会话的报文也能通过代理模式检测，避免首个TCP会话的报文局限于流模式造成攻击漏检。

Description

网络安全防护方法以及防护设备

技术领域

本申请涉及通信技术领域，特别涉及一种网络安全防护方法以及防护设备。

背景技术

现代网络安全防护方案的基本原理是在客户端与受保护的服务器之间部署防护设备(如防火墙)，由防护设备对客户端与服务器之间交互的报文进行检测。

代理模式是防护设备的重要检测模式。代理模式的原理是防护设备代替服务器发送确认报文给客户端，并且防护设备代替客户端发送确认报文给服务器。在代理模式下，防护设备需要使用传输控制协议/互联网协议(transmission control protocol/internetprotocol，TCP/IP)协议栈负责报文的可靠发送。代理模式有助于检测出复杂的网络攻击，更能满足安全防护的需求，然而代理模式防护设备需要对大量数据报文进行缓存重组、以及支持完整的协议栈，因此需要消耗大量资源。

相关技术中，在客户端和服务器数量较大时，由于处理性能的限制，防护设备难以对每个客户端和服务器之间所有会话中交互的报文都采用代理模式进行检测。通常的做法是防护设备在客户端和服务器之间建立首个会话的过程中进行识别，并记录首个会话的IP地址、目的端口号、以及协议类型等信息，以确定是否需要以代理模式对同一客户端与同一服务器上的同一端口之间建立的后续会话进行检测。这种方案，防护设备实际上未对客户端和服务器之间建立首个会话中的报文进行安全检测，在这种方案中，如果客户端与服务器之间交互的首个会话中的报文存在攻击行为，则防护设备就会出现漏检问题。

发明内容

本申请实施例提供了一种网络安全防护方法以及防护设备，有助于避免首个会话中的报文存在攻击行为时出现漏检。所述技术方案如下。

第一方面，提供了一种网络安全防护方法，在该方法中，防护设备获取客户端设备与服务器之间首个TCP会话中的第一数据报文，所述首个TCP会话为客户端设备与服务器之间建立的第一个会话，所述防护设备部署于所述客户端设备与所述服务器之间；所述防护设备根据所述第一数据报文的应用层数据，识别所述第一数据报文的应用层协议类型；所述防护设备确定所述应用层协议类型对应的检测模式为代理模式；所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测。

第一方面提供了能够快速切换至代理模式的方案。在客户端与服务器之间交互首个会话的报文时，防护设备通过根据首个会话的报文中的应用层数据，识别应用层协议类型，根据应用层协议类型确定检测模式为代理模式，则采用代理模式对首个TCP会话的后续报文进行安全检测，从而突破首个TCP会话的报文只能采用流模式检测的技术瓶颈，保证首个TCP会话的报文也能通过代理模式检测，避免首个TCP会话的报文局限于流模式造成攻击漏检。

可选地，所述防护设备获取客户端设备与服务器之间首个TCP会话中的第一数据报文之前，所述方法还包括：所述防护设备获取所述客户端设备与所述服务器之间传输的第一握手报文，所述第一握手报文用于创建所述首个TCP会话，所述第一握手报文包括第一选项以及第二选项，所述第一选项为所述防护设备支持的选项，所述第二选项为所述防护设备不支持的选项；所述防护设备从所述第一握手报文删除所述第二选项，从而得到第二握手报文；所述防护设备向所述第一握手报文的目的设备发送所述第二握手报文。

通过上述可选方式，避免因客户端设备和服务器设备使用防护设备不支持的选项进行通信而造成的防护设备针对首条流切换到代理模式后，由于难以解析客户端或者服务器使用的选项造成报文传输失败，提高模式切换流程的可靠性和成功率。

可选地，所述首个TCP会话中的后续报文包括第二数据报文，所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测，包括：所述防护设备接收并缓存所述第二数据报文；所述防护设备根据所述第一选项生成针对所述第二数据报文的确认报文；所述防护设备向所述第二数据报文的源设备发送所述针对第二数据报文的确认报文，所述第二数据报文的源设备为所述客户端设备或者所述服务器。

通过上述可选方式，提供之前在流模式下已缓存数据报文的复杂情况下如何模式切换的实现方式，提升方案的可用性。

可选地，所述首个TCP会话中的后续报文包括第三数据报文，所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测，包括：所述防护设备发送并缓存所述第三数据报文；如果所述第三数据报文满足重传条件，所述防护设备根据所述第一选项向所述第三数据报文的目的设备重新发送所述第三数据报文，所述第三数据报文的目的设备为所述客户端设备或者所述服务器。

通过上述可选方式，提供之前在流模式下已发送数据报文的复杂情况下如何模式切换的实现方式，提升方案的可用性。

可选地，所述重传条件包括：所述防护设备未接收到针对数据报文的确认报文；或者，所述第一选项为选择性确认(selective acknowledgement，SACK)选项，所述重传条件包括：所述防护设备根据来自于数据报文的目的设备的SACK选项中的信息，确定数据报文发生丢包。

通过上述可选方式，有助于防护设备在代理模式下保证报文的传输可靠性。

可选地，所述第一握手报文为来自于所述客户端设备的同步序列编号(synchronize sequence numbers，SYN)报文，所述第一握手报文的目的设备为所述服务器；或者，所述第一握手报文为来自于所述服务器的同步序列编号确认(synchronizesequence numbers acknowledgement，SYN ACK)报文，所述第一握手报文的目的设备为所述客户端设备。

可选地，所述安全检测为防病毒(anti virus，AV)检测，所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测，包括：所述防护设备采用所述代理模式对所述首个TCP会话中的第四数据报文进行AV检测，所述第四数据报文为所述首个TCP会话中在所述第一数据报文之后传输的报文；所述方法还包括：如果所述防护设备对所述首个TCP会话中的第四数据报文进行AV检测的结果为不包含病毒，所述防护设备切换为流模式，并采用所述流模式针对所述首个TCP会话中所述第四数据报文之后传输的后续报文继续进行安全检测。

通过上述可选方式，由于防护设备通过AV检测结果发现客户端设备与服务器在首个会话交互的数据报文不包含病毒时，从代理模式切换为流模式，从而利用流模式加速针对首个会话后续的处理流程，降低设备的资源占用量，有助于提升检测性能。

可选地，所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测，包括：所述防护设备采用所述代理模式对所述首个TCP会话中的第五数据报文进行检测，所述第五数据报文为所述首个TCP会话中在所述第一数据报文之后传输的报文；所述方法还包括：如果所述第五数据报文的应用层数据指示所述客户端设备与所述服务器将要在所述TCP会话中进行加密通信，所述防护设备切换为流模式，并采用所述流模式针对所述首个TCP会话中所述第五数据报文之后传输的后续报文继续进行安全检测。

通过上述可选方式，由于防护设备发现客户端设备与服务器后续将要在首个会话加密通信时，从代理模式切换为流模式，有助于在防护设备不支持加解密功能导致无法利用代理模式对加密数据检测的场景下，及时切换回流模式，从而利用流模式加速首个会话后续的处理流程，降低设备的资源占用量，有助于提升检测性能。

第二方面，提供了一种防护设备，该防护设备具有实现上述第一方面或第一方面任一种可选方式的功能。该防护设备包括至少一个单元，至少一个单元用于实现上述第一方面或第一方面任一种可选方式所提供的方法。

在一些实施例中，防护设备中的单元通过软件实现，防护设备中的单元是程序模块。在另一些实施例中，防护设备中的单元通过硬件或固件实现。第二方面提供的防护设备的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。

第三方面，提供了一种防护设备，该防护设备包括处理器和通信接口，该处理器用于执行指令，使得该防护设备执行上述第一方面或第一方面任一种可选方式所提供的方法，所述通信接口用于接收或发送报文。第三方面提供的防护设备的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。

第四方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，该指令由处理器读取以使防护设备执行上述第一方面或第一方面任一种可选方式所提供的方法。

第五方面，提供了一种计算机程序产品，该计算机程序产品包括一个或多个计算机指令，当所述计算机程序指令被计算机加载并执行时，使得所述计算机执行上述第一方面或第一方面任一种可选方式所提供的方法。

第六方面，提供了一种芯片，当该芯片在防护设备上运行时，使得防护设备执行上述第一方面或第一方面任一种可选方式所提供的方法。

第七方面，提供了一种网络系统，该网络系统包括防护设备、客户端设备以及服务器，该防护设备用于执行上述第一方面或第一方面任一种可选方式所述的方法。

附图说明

图1是本申请实施例提供的一种流模式下报文交互的流程图；

图2是本申请实施例提供的一种代理模式下报文交互的流程图；

图3是本申请实施例提供的一种典型应用场景的示意图；

图4是本申请实施例提供的一种防护设备的结构示意图；

图5是本申请实施例提供的一种网络安全防护方法的流程图；

图6是本申请实施例提供的一种客户端与服务器之间三次握手的流程图；

图7是本申请实施例提供的一种防护设备在三次握手阶段的处理流程图；

图8是本申请实施例提供的一种防护设备的系统架构图；

图9是本申请实施例提供的一种防护设备的系统架构图；

图10是本申请实施例提供的一种防护设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

最早的防火墙，是在传统的路由器的基础上，增加访问控制列表(access controllists，ACL)对转发的数据包进行过滤实现的，称为包过滤防火墙。包过滤的基本原理是，对需要转发的数据包，防火墙先获取数据包的包头信息。包头信息例如互联网协议(internetprotocol，IP)地址、源端口、目的端口等网络层信息。然后，防火墙用包头信息和设定的规则(ACL中的表项)进行比较，防火墙根据比较的结果对数据包进行转发或者丢弃。

流模式(flow mode)在上述包过滤方式的基础上进一步结合了会话状态信息。参见附图1，附图1示出了流模式下报文交互的流程。在流模式下，防火墙对客户端和服务器发出的原始报文进行包过滤匹配，决定是丢弃报文还是转发报文。在流模式下，防火墙虽然会维护会话状态信息，但很少对报文进行修改，也很少主动生成报文发送给客户端和服务器。报文传输的可靠性，依赖客户端和服务器自身部署的传输控制协议(transmissioncontrol protocol，TCP)/IP协议栈保证。比如，客户端发送的数据报文，经过防火墙检测后，如果在发送给服务器的过程中意外丢失，则依赖客户端上TCP协议的重传机制，由客户端负责重新发送丢失的报文。

随着网络、应用的复杂性增长，简单的网络层信息检查的包过滤技术已经不能满足安全防范的需要。以AV检测场景为例，防病毒功能要求获得完整传输的文件，才能检测出一些高级的病毒。而TCP传输机制要求，在客户端发送一定的数据后(部分文件)，需要服务器产生应答，客户端收到应答之后才会继续发送后续数据。而服务器只有收到来自客户端的数据，服务器才会进行应答。因此，防火墙采用流模式时，只能将数据报文发送出去。服务器收到防火墙发来的数据报文并产生应答后，客户端才会发送后续数据报文。等到数据报文发送完，防火墙才能开始对提取的文件(防火墙进行缓存拷贝)进行病毒检查。此时，即使防火墙发现有病毒，也不能进行阻断。因为，几乎所有数据报文已经发送到服务器，病毒的实际有效部分已经发送，攻击已经形成，显然对服务器的防护效果不佳。为了实现阻断病毒的目的，一些研究引入了代理模式(proxy mode)。

参见附图2，附图2示出了代理模式下报文交互的流程。代理模式下，防火墙扮演模拟服务器的角色，由防火墙代替服务器和客户端进行交互。并且，防火墙扮演模拟客户端的角色，由防火墙代替客户端和服务器交互。例如，在病毒检测场景中，防火墙代替服务器发送确认(acknowledgement，ACK)报文给客户端，使客户端在确认报文的触发下继续发送后续数据报文。在防火墙和客户端交互数据报文的过程中，数据报文并没有被发送给服务器；等到防火墙从客户端获得所有的数据报文，从而获得完整的文件内容，防火墙开始进行病毒检查。如果防火墙发现病毒，则防火墙将含病毒文件完整删除，确保病毒不会发送到服务器；或者，防火墙不删除附件，而是通过增加提示信息的方式告知用户，附件存在病毒；对于没有发现病毒的文件，则由防火墙代替客户端发送给服务器。

从代理模式的原理可见，由于代理模式下防火墙通过主动向数据报文的源端(如客户端)回复确认报文，使得源端在确认报文的触发下继续发送后续的数据报文，因此，防火墙能够收到更多的数据报文，从而获得更多的数据进行检测。显然，代理模式有助于检测出复杂的网络攻击，提高安全检测的精确性。此外，由于代理模式下，防火墙对完整的文件内容检测，确认文件安全后，才会将文件转发给数据报文的目的端(如服务器)，避免虽然检测出文件包含病毒、但包含病毒的文件已经被转发给目的端的情况，显然更能阻断病毒的传播，提升安全防护的有效性。

在代理模式下，防护设备需要对大量数据报文进行缓存重组、以及支持完整的协议栈，因此需要消耗大量资源。由于硬件资源限制、性能等方面的考虑，防火墙难以对所有会话都默认采用代理模式处理。考虑到实际应用场景下现网流量的复杂性(非标准端口)以及用户配置的灵活性(基于应用层的配置)，防火墙根据首个会话中的SYN报文无法判定是否需要采用代理模式，而是需要在进行一定数据报文交互后，才能确定是否需要使用代理模式处理。因此以防火墙为例的防护设备会采用流模式对首个会话中的报文进行协议识别，根据识别结果判断是否需要采用代理模式。如果需要采用代理模式进行检测，则服务器根据SYN报文记录服务器的IP地址、端口号等以形成识别表。当该客户端后续尝试与该服务器的同一端口号再次建立会话时，如果服务器的IP地址、端口号存在于识别表中，则防护设备再采用代理模式对后续建立的会话中的报文进行检测。

在研究过程中发现，采用上述方案存在诸多缺陷。由于首个会话中的流(如服务器向客户端传输的首条流以及客户端向服务器传输的首条流)没有采用代理模式处理，对于依赖代理模式检测的复杂业务，如加密套接字(security socket layer，SSL)解密等特性，如果首个会话中的流(如服务器向客户端传输的首条流以及客户端向服务器传输的首条流)中存在攻击行为，防火墙将无法检测出攻击行为，从而导致攻击漏过，严重影响网络安全性。

有鉴于此，本申请实施例提供了能够快速切换至代理模式的方案。防火墙或者其他防护设备通过实施本技术方案，能够根据应用层对安全检测的需求，采用代理模式检测首条流，从而突破首条流只能采用流模式检测的技术瓶颈，避免首条流局限于流模式造成攻击漏检。

相对于首条流默认采用流模式的方案而言，本技术方案能确保所有流量，即使是非标准端口的首条流，也获得充分的安全检测，不漏过威胁，充分提升安全防护效果。相对于默认采用代理模式的方案而言，本技术方案极大减少了代理类会话的数量，降低了设备的资源消耗，提升了设备的整体处理能力。

下面，从系统运行环境、硬件装置、软件装置、方法流程等多个角度，对本技术方案进行详细介绍。

以下结合附图3介绍本申请实施例提供的系统运行环境。

请参考图3，图3是本申请实施例提供的一种典型应用场景10的示意图。应用场景10包括客户端设备11、服务器12以及防护设备13。下面对客户端设备11、服务器12以及防护设备13分别进行描述。

(1)客户端设备11

客户端设备11为TCP会话中发起访问的设备。客户端设备11包括但不限于个人计算机、移动电话、服务器12、笔记本电脑、IP电话、摄像头、平板电脑、可穿戴设备等。例如，客户端设备11为企业内部员工的办公设备。

在一些实施例中，客户端设备11安装了邮箱客户端、文件传输客户端等应用程序，客户端设备11通过应用程序产生应用层数据，基于应用层协议与服务器12交互应用层数据，从而触发下述方法实施例。在一个示例性场景中，客户端设备11在运行邮箱客户端的过程中，基于SMTP协议与服务器12传输邮件。在另一个示例性场景中，客户端设备11在运行文件传输客户端的过程中，基于文件传输协议(file transfer protocol，FTP)协议与服务器12传输文件。

在一些实施例中，系统架构10中包含大量客户端设备11，为了简明起见，图3以一个客户端设备11的情况为例进行说明。

(2)服务器12

服务器12为TCP会话中提供服务的设备。例如，服务器12为邮件服务器12，邮件服务器12基于SMTP协议为客户端提供邮件传输服务。又如，服务器12为文件服务器12，文件服务器12基于FTP协议为客户端提供文件传输服务。又如，服务器12为网站服务器。

上述客户端设备11和服务器12之间的文件传输可能是双向的，既可能是客户端设备11向服务器12发送文件，也可能是服务器12向客户端设备11发送文件。

(3)防护设备13

防护设备13部署于客户端设备11与服务器12之间。防护设备13与客户端设备11与服务器12分别通过网络相连。防护设备13用于对网络中传输的报文进行安全检测，安全检测包括而不限于IPS检测、AV检测等。防护设备13包括而不限于防火墙、入侵检测系统(intrusion detection system，IDS)类设备、IPS类设备。防护设备13例如为网络中直路部署的网络检测设备。

防护设备13支持的多种检测模式构成了检测模式集合。检测模式集合包括至少一种检测模式。例如，检测模式集合中包括包过滤模式、流模式或代理模式等等。

以下，以防护设备13支持的检测模式集合包括流模式以及代理模式为例，对防护设备13内部的逻辑功能架构进行介绍。

请参考附图3，防护设备13包括上层业务模块130、流模式处理模块131、代理模式处理模块132以及TCP/IP协议栈模块133。

(a)上层业务模块130

上层业务模块130例如通过防护设备13的应用程序实现。上层业务模块130用于处理应用层的业务。在本申请的一些实施例中，上层业务模块130用于根据应用层数据进行协议识别，以便根据识别出的协议类型确定采用哪种检测模式检测报文。

(b)流模式处理模块131

流模式处理模块131负责流模式下对TCP会话中报文的处理任务。例如，流模式处理模块131用于在流模式下接收来自客户端设备11或者服务器12的数据报文、缓存收到的数据报文、向客户端设备11或者服务器12转发数据报文、接收来自客户端设备11或者服务器12的确认报文、向客户端设备11或者服务器12转发确认报文。流模式处理模块131内部的具体构成可参考附图8相关的介绍。

(c)代理模式处理模块132

代理模式处理模块132负责代理模式下对TCP会话中报文的处理任务。在一些实施例中，代理模式处理模块132和TCP/IP协议栈模块133分离设置。图3以代理模式处理模块132与TCP/IP协议栈模块133分离设置为例进行说明。在另一些实施例中，代理模式处理模块132和TCP/IP协议栈模块133集成为同一个模块。

(d)TCP/IP协议栈模块133

TCP/IP协议栈模块133用于基于TCP/IP协议传输报文，从而确保报文的传输可靠性。TCP/IP协议栈模块133内部的具体构成可参考附图8或附图9相关的介绍。在一些实施例中，TCP/IP协议栈模块133采用软件实现。在另一些实施例中，TCP/IP协议栈模块133采用硬件实现，或者采用软件硬件相结合的方式实现。例如，防护设备13配置有加速器，加速器为专用于处理TCP/IP协议栈相关处理步骤的硬件，TCP/IP协议栈模块133通过加速器实现，从而将TCP/IP协议栈卸载至加速器上，减少中央处理器(central processing unit，CPU)的负载。

TCP/IP协议栈模块133确保传输可靠性主要通过回复确认以及重传机制实现。具体地，TCP/IP协议栈模块133在接收数据报文后，TCP/IP协议栈模块133会向数据报文的源端返回确认报文。TCP/IP协议栈模块133在发送数据报文后，如果数据报文满足重传条件，TCP/IP协议栈模块133会向数据报文的目的端重新发送数据报文。

在一些实施例中，重传条件包括未接收到针对数据报文的确认报文。比如，TCP/IP协议栈模块133将数据报文发送给对端后，如果超过预设时长未收到数据报文对应的确认报文，则满足重传条件，TCP/IP协议栈模块133会自动重传数据报文。

在另一些实施例中，重传条件包括根据对端(客户端设备11或者服务器12)发来的确认报文中选择性确认(selective acknowledgement，SACK)选项中的信息，确定数据报文发生丢包。这种重传条件适用于TCP/IP协议栈模块133支持SACK选项的情况。具体地，TCP/IP协议栈模块133向对端发出数据报文后，TCP/IP协议栈模块133接收来自对端的确认报文，TCP/IP协议栈模块133根据确认报文中SACK选项中的范围以及记录的最大序列号(sequence number，Seq)号，确定数据报文丢失，则TCP/IP协议栈模块133重传数据报文。例如，防护设备13发送了Seq号分别为1，2，3，4的四个报文。由于网络原因造成Seq号为1的报文丢包，Seq号分别为2，3，4的三个报文成功传输到对端。当对端收到Seq号分别为2，3，4的三个报文时，对端在确认报文中通过SACK选项通知防护设备13，Seq号分别为2，3，4的三个报文都收到了，只有Seq号为1的报文没收到，则Seq号为1的报文满足重传条件，防护设备13重传Seq号为1的报文。

附图4是本申请实施例提供的防护设备的结构示意图。可选地，具有附图4所示结构的防护设备是附图3、附图8或附图9中的防护设备13。

防护设备200包括至少一个处理器201、通信总线202、存储器203以及至少一个通信接口204。

处理器201例如是通用中央处理器(central processing unit，CPU)、网络处理器(network processer，NP)、图形处理器(graphics processing unit，GPU)、神经网络处理器(neural-network processing units，NPU)、数据处理单元(data processing unit，DPU)、微处理器或者一个或多个用于实现本申请方案的集成电路。例如，处理器201包括专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。PLD例如是复杂可编程逻辑器件(complexprogrammable logic device，CPLD)、现场可编程逻辑门阵列(field-programmable gatearray，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合。

在一些实施例中，处理器201用于支持防护设备200执行附图5所示方法500中S520、S530以及S540。在一些实施例中，处理器201还用于支持防护设备200执行附图7所示方法700中S720以及S750。

通信总线202用于在上述组件之间传送信息。通信总线202可以分为地址总线、数据总线、控制总线等。为便于表示，附图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器203例如是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其它类型的静态存储设备，又如是随机存取存储器(random access memory，RAM)或者可存储信息和指令的其它类型的动态存储设备，又如是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compactdisc read-only memory，CD-ROM)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器203例如是独立存在，并通过通信总线202与处理器201相连接。存储器203也可以和处理器201集成在一起。

在一些实施例中，存储器203用于支持防护设备200缓存收到的报文、缓存已发送的报文。例如，结合附图8或附图9来看，存储器203包括接收报文队列13111、接收报文队列13121、发送报文队列13312或者发送报文队列13322中的至少一项。

通信接口204使用任何收发器一类的装置，用于与其它设备或通信网络通信。例如，结合附图3所示的部署场景来看，通信接口204用于与客户端设备11或者服务器12通信。通信接口204包括有线通信接口，还可以包括无线通信接口。其中，有线通信接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线通信接口可以为无线局域网(wireless local area networks，WLAN)接口，蜂窝网络通信接口或其组合等。

在一些实施例中，通信接口204用于支持防护设备200执行附图5所示方法500中S510。在一些实施例中，通信接口204还用于支持防护设备200执行附图7所示方法700中S730以及S780。

在具体实现中，作为一种实施例，处理器201可以包括一个或多个CPU，如附图4中所示的CPU0和CPU1。

在具体实现中，作为一种实施例，防护设备200可以包括多个处理器，如附图4中所示的处理器201和处理器205。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(如计算机程序指令)的处理核。

在具体实现中，作为一种实施例，防护设备200还可以包括输出设备和输入设备。输出设备和处理器201通信，可以以多种方式来显示信息。例如，输出设备可以是液晶显示器(liquid crystal display，LCD)、发光二级管(light emitting diode，LED)显示设备、阴极射线管(cathode ray tube，CRT)显示设备或投影仪(projector)等。输入设备和处理器201通信，可以以多种方式接收用户的输入。例如，输入设备可以是鼠标、键盘、触摸屏设备或传感设备等。

在一些实施例中，存储器203用于存储执行本申请方案的程序代码210，处理器201可以执行存储器203中存储的程序代码210。也即是，防护设备200可以通过处理器201以及存储器203中的程序代码210，来实现附图5所示方法500或附图7所示方法700。

本申请实施例的防护设备200可对应于附图5所示方法500或附图7所示方法700中的防护设备，并且，该防护设备200中的处理器201、通信接口204等可以实现附图5所示方法500或附图7所示方法700中的防护设备所具有的功能和/或所实施的各种步骤和方法。为了简洁，在此不再赘述。

下面结合附图5对本申请实施例提供的网络安全防护方法进行介绍。

附图5是本申请实施例提供的网络安全防护方法500的流程图。方法500包括步骤S510至步骤S540。

可选地，方法500中涉及的客户端设备、服务器以及防护设备的网络部署场景如附图3所示。方法500中涉及的客户端设备为附图3中的客户端设备11，方法500中服务器为系统架构10中的服务器12，方法500中防护设备为附图3中的防护设备13。

可选地，方法500中防护设备具备附图4所示的结构。

步骤S510、防护设备获取客户端与服务器之间首个TCP会话中的第一数据报文。

首个会话为客户端与服务器之间建立的第一个会话。在一些实施例中，首个会话为预定时间段内客户端与服务器之间建立的第一个会话。其中，预定时间段的起始时间点为防火墙的上线时间点。在一些实施例中，首个会话是指防护设备上线后经过防护设备访问特定服务器上特定服务的第一个会话。首条流是指首个会话的报文流。例如，首条流为首个会话中客户端向服务器发送的流，又如，首条流为首个会话中服务器向客户端发送的流。在一个示例性场景中，防火墙开机后，第一次经过防火墙访问IP地址为10.10.10.10、端口80的流为首条流；第一次经过防火墙访问IP地址为10.10.10.10、端口8080的流为首条流；第一次经过防火墙访问IP地址为20.20.20.20、端口80的流为首条流。

本实施例中为了区分不同的数据报文，用“第一数据报文”、“第二数据报文”描述不同的数据报文。

第一数据报文是防护设备在第一模式下接收并缓存的报文。第一数据报文包括客户端设备与服务器之间交互的内容。在一些实施例中，第一数据报文的源设备是客户端设备，第一数据报文的目的设备是服务器。例如，第一数据报文是客户端设备根据来自于服务器的数据报文生成的报文，第一数据报文包括客户端设备需要反馈给服务器的应答内容。在另一些实施例中，第一数据报文的源设备是服务器，第一数据报文的目的设备是客户端设备。例如，第一数据报文是服务器根据来自于客户端设备的数据报文生成的报文，第一数据报文包括服务器需要反馈给客户端设备的应答内容。

步骤S520、防护设备根据第一数据报文的应用层数据，识别第一数据报文的应用层协议类型。

应用层协议为客户端设备上的应用与服务器上的应用相互传递报文时使用的协议。应用层协议的类型包括很多种。例如，应用层协议为电子邮件传输协议。比如说，应用层协议为SMTP协议、邮局协议版本3(post office protocol 3，POP3)、交互式数据消息访问协议第四个版本(internet message access protocol 4，IMAP4)协议等。又如，应用层协议为文件传输协议。比如说，应用层协议为FTP协议。当然，应用层协议可选地为隶属于TCP/IP协议簇的其他协议，本实施例对应用层协议的具体类型不做限定。

在一些实施例中，防护设备根据应用层数据以及应用层协议对应的关键字，识别应用层协议类型。

应用层协议对应的关键字例如为应用层协议规定的数据报文所需包含的关键字。应用层协议对应的关键字例如通过应用层协议相关的标准或草案指定。在一些实施例中，应用层协议对应的关键字为应用层协议中登录命令携带的关键字。登录命令用于请求登录至服务器。下面，结合SMTP协议以及FTP协议这两类协议，对关键字以及利用关键字识别应用层协议类型的方式举例说明。

例如，应用层协议为SMTP协议，SMTP协议中登录命令包括HELO(hello，问候)命令。SMTP协议对应的关键字例如为HELO命令携带的关键字。HELO命令携带的关键字为HELO。其中，HELO命令的格式可简化表示为“HELO xxxx”。“HELO xxxx”中“xxxx”是HELO命令包含的参数，该参数的含义通常是SMTP客户端的域名。那么，如果防护设备收到的应用层数据包括HELO，防护设备即可识别出应用层协议的类型是SMTP协议。当然，HELO命令仅是对SMTP协议中登录命令的举例说明，HELO仅是对SMTP协议对应的关键字的举例说明，HELO命令可替代为SMTP协议中其他登录命令，如EHLO(extended hello)命令等，SMTP协议对应的关键字可替代为其他登录命令中的关键字，本实施例对识别SMTP协议时采用的关键字不做限定。

又如，应用层协议为FTP协议，FTP协议中登录命令包括USER命令。FTP协议对应的关键字例如为USER命令携带的关键字。具体地，USER命令携带的关键字为USER。USER命令可简化表示为“USER xxx”。“USER xxx”中“xxxx”是USER命令包含的参数，该参数的含义通常是用户名。那么，如果防护设备收到的应用层数据包括USER，防护设备即可识别出应用层协议的类型是FTP协议。当然，USER命令仅是对FTP协议中登录命令的举例说明，USER仅是对FTP协议对应的关键字的举例说明，USER命令可替代为FTP协议中其他登录命令，如pass命令、pavs命令等，FTP协议对应的关键字可替代为其他登录命令中的关键字，如pass、pavs等，本实施例对识别FTP协议时采用的关键字不做限定。

步骤S530、防护设备确定应用层协议类型对应的检测模式为代理模式。

在一些实施例中，防护设备保存应用层协议类型与检测模式之间的对应关系。防护设备根据应用层协议类型与检测模式之间的对应关系，确定第一数据报文的应用层协议类型对应的检测模式为代理模式。

例如，应用层协议类型与检测模式之间的对应关系包括SMTP协议与代理模式之间的对应关系。防护设备识别出应用层协议类型为SMTP协议后，防护设备根据SMTP协议与代理模式之间的对应关系，确定第一数据报文的应用层协议类型对应代理模式，则防护设备切换为代理模式，采用代理模式对首个TCP会话中基于SMTP协议传输的邮件进行防病毒检测。

又如，应用层协议类型与检测模式之间的对应关系包括FTP协议与流模式之间的对应关系。防护设备识别出应用层协议类型为FTP协议后，防护设备根据FTP协议与流模式之间的对应关系，确定第一数据报文的应用层协议类型对应流模式，则防护设备继续使用流模式对首个TCP会话后续报文进行安全检测。

步骤S540、防护设备采用代理模式对首个TCP会话中的后续报文进行安全检测。

本实施例提供的方法，在客户端与服务器之间交互首个会话的报文时，防护设备通过根据首个会话的报文中的应用层数据，识别应用层协议类型。如果根据应用层协议类型确定检测模式为代理模式，则防护设备采用代理模式对首个TCP会话的后续报文进行安全检测。从而能够在首个TCP会话处理过程中快速切换至代理模式，突破了首个TCP会话的报文只能采用流模式检测的技术瓶颈，保证首个TCP会话的报文也能通过代理模式检测，避免首个TCP会话的报文局限于流模式造成攻击漏检，因此提升了防护效果。

下面通过实例一和实例二这两个实例，对步骤S520中防护设备如何利用协议对应的关键字识别协议类型举例说明。

实例一、客户端与服务器基于SMTP协议交互。

客户端设备与服务器建立首个TCP会话后，服务器向客户端设备发送欢迎信息。防护设备接收到来自于服务器的欢迎信息后，防护设备将欢迎信息转发到客户端设备。客户端设备收到欢迎信息后，发送的应用层数据包括“HELO xxxx”。防护设备收到应用层数据之后，发现应用层数据包括“HELO”，则识别出首个TCP会话运行了SMTP协议。

例如，客户端发送的应用层数据如以下所示。

220dshnayder.fscinternet.com ESMTP postfix

HELO localhost

MAIL FROM:<test>

RCPT TO:<test@dshnayder.fscinternet.com>

data

From:"test"<ttest>

To:<test@dshnayder.fscinternet.com>

Subject:open object tag-exploit.html

Content-Type:text/html；charset＝"iso-8859-1

其中，“220dshnayder.fscinternet.com ESMTP postfix”为欢迎信息，“HELOlocalhost”为HELO命令。

实例二、客户端与服务器基于FTP协议交互。

客户端设备与服务器建立首个TCP会话后，服务器向客户端设备发送欢迎信息。防护设备接收到来自于服务器的欢迎信息后，防护设备将欢迎信息转发到客户端设备。客户端设备收到欢迎信息后，发送的应用层数据包括“USER xxx”。防护设备收到应用层数据之后，发现应用层数据包括“USER”，则识别出首个TCP会话运行了FTP协议。

例如，客户端发送的应用层数据如以下所示。

220redhat_52.test FTP server(Version wu-2.4.2-academ[BETA-18](1)MonAug 3 19:17:20EDT 1998)ready.

USER anonymous

331Guest login ok，send your complete e-mail address as password.

PASS hi@blahblah.net

230Guest login ok，access restrictions apply.

MKD/incoming

550/incoming:Permission denied.

CND/incoming

250CWD command successful.

其中，“220redhat_52.test FTP server(Version wu-2.4.2-academ[BETA-18](1)Mon Aug3 19:17:20EDT 1998)ready”为欢迎信息，“USER anonymous”为USER命令。这一USER命令表示匿名登录FTP服务器。

以上实例一和实例二以SMTP协议、FTP协议这两种应用层协议为例进行说明。本实施例的应用范围并不仅限于这几种协议。本实施例能够应用于各种基于协议类型、应用层数据等需要若干报文交互后才能确定是否需要采用代理模式检测的流量的处理场景。

防护设备如何获得应用层协议类型与检测模式之间的对应关系包括多种实现方式。在一些实施例中，防护设备根据用户的配置操作，确定应用层协议类型与检测模式之间的对应关系。例如，用户配置了对基于SMTP协议传输的流量进行AV检测。由于AV检测通常情况下要求使用代理模式，则防护设备确定SMTP协议与代理模式对应。

在一些实施例中，防护设备在检测首个会话中的流量的过程中，用户对配置进行修改，使得应用层协议类型与检测模式之间的对应关系发生更新。在这一场景下，防护设备根据更新后的应用层协议类型与检测模式之间的对应关系，确定首个会话的应用层协议类型对应的检测模式为代理模式，则防护设备针对首个会话切换为代理模式，从而实现用户配置的实时生效，保障首条流及时地采用代理模式检测。例如，用户通过对配置进行修改，将原来配置为使用流模式检测的流量修改为需要使用代理模式检测。防护设备在检测首个会话的报文的过程中，当检测到配置修改后，将针对首个会话的报文的检测模式切换为代理模式。

在一些实施例中，防护设备针对首个会话从流模式切换至代理模式之后，防护设备还针对首个会话从代理模式切换回流模式，从而在首个TCP会话中多次切换检测模式。例如，按照时间先后顺序的角度描述，在首个TCP会话建立之后，防护设备首先采用流模式检测首个TCP会话中的数据报文。之后，防护设备通过执行步骤S510至步骤S530，从流模式切换为代理模式，采用代理模式检测首个TCP会话中后续的数据报文。之后，防护设备在一些场景下从代理模式重新切换为流模式，采用流模式检测首个TCP会话中后续的数据报文，直至首个TCP会话结束。下面，针对首个会话采用流模式→代理模式→流模式的一些实现方式进行举例说明，具体参见以下实现方式一和实现方式二。

实现方式一、防护设备根据AV检测结果，确定从代理模式重新切换回流模式。

例如，防护设备在采用代理模式对首个TCP会话中的报文进行安全检测的过程中，防护设备接收到了第四数据报文。防护设备采用代理模式对第四数据报文的应用层数据进行AV检测，从而得到AV检测结果。如果AV检测结果为不包含病毒，防护设备切换为流模式，并采用流模式针对首个TCP会话中第四数据报文之后传输的后续报文继续进行安全检测。其中，第四数据报文为首个TCP会话中在第一数据报文之后传输的报文。例如，在客户端与服务器首个会话中基于SMTP协议交互的场景下，防护设备在转发客户端与服务器之间的邮件时，防护设备采用代理模式对邮件的内容(包含邮件附件)进行AV检测，如果邮件的AV检测结果为邮件不包含病毒，或者说邮件是安全的，则防护设备从代理模式切换为流模式。

实现方式二、防护设备通过识别出客户端和服务器要开始加密通信，确定从代理模式重新切换回流模式。

例如，防护设备在采用代理模式对首个TCP会话中的报文进行检测的过程中，防护设备接收到了第五数据报文。防护设备采用代理模式对第五数据报文进行安全检测。如果第五数据报文的应用层数据指示客户端设备与服务器将要在TCP会话中进行加密通信，防护设备切换为流模式，并采用流模式针对首个TCP会话中第五数据报文之后传输的后续报文继续进行安全检测。其中，第五数据报文为首个TCP会话中在第一数据报文之后传输的报文。在一些实施例中，防护设备预先保存加密通信命令的关键字，如果第五数据报文的应用层数据包括加密通信命令的关键字，则确定客户端设备与服务器将要加密通信。其中，加密通信命令例如为starttls命令。

在一个示例性应用场景中，防护设备采用上述方法500对基于SMTP协议的邮件进行安全检测，服务器具体为邮箱服务器，客户端设备安装有SMTP客户端。在SMTP客户端与邮箱服务器建立会话后，防护设备首先采用流模式检测会话中的数据报文。之后，在SMTP客户端与邮箱服务器在会话中交互的过程中，防护设备通过SMTP客户端与邮箱服务器之间交互的数据报文，发现会话对应的应用层协议是SMTP协议，则防护设备从流模式切换为代理模式。防护设备采用代理模式检测SMTP客户端与邮箱服务器在会话中后续交互的数据报文。具体地，SMTP客户端发送的邮件数据，均由防护设备进行ACK，使得SMTP客户端将整个邮件(包括附件)完整发送到防护设备上。防护设备对邮件数据进行防病毒检测，防护设备确认邮件数据不包括病毒，则通过自身TCP/IP协议栈代替SMTP客户端将邮件数据发送给服务器。防护设备通过在代理模式下进行一次或多次检测，确定SMTP客户端与服务器之间传输的邮件安全，则防护设备再从代理模式切换为流模式，从而加速后续的处理流程。

以上提供的方法中，防护设备通过基于数据报文交互结果，在首个会话中的数据报文交互阶段进行不同检测模式之间的自适应切换，能够实现按需进行模式选择，避免单一采用流模式造成威胁漏过，并避免单一采用代理模式造成大量不必要的资源占用，因此提升了防护效果。

下面介绍防护设备在三次握手阶段的处理流程。

为了便于理解，下面先对TCP协议中三次握手的原理进行介绍。

参见附图6，附图6是客户端与服务器之间三次握手的流程图。在附图6所示的流程中，客户端为TCP会话的发起方，服务器为TCP会话的接受方。客户端与服务器的交互主要包括会话建立、数据传输以及会话关闭这三个阶段。附图6未示出数据传输的具体流程。

会话建立是通过三次握手(three-way handshake)实现的。当客户端与服务器需要使用TCP协议传输数据时，客户端使用SYN报文发起TCP会话来建立协商，称为三次握手。三次握手涉及SYN报文、同步序列编号确认(synchronize sequence numbersacknowledgement，SYN ACK)报文以及ACK报文这三种报文的交互过程。具体地，三次握手包括以下步骤一至步骤三。

步骤一、客户端向服务器发送SYN报文。SYN报文包括建立TCP会话需要用到的选项。选项例如为最大报文段长度(maximum segment size，MSS)、SACK、数据缓冲区大小(TCP窗口)等。

其中，SYN报文中的Seq号为客户端初始序列号(inital sequence number，ISN)。SYN报文中的ISN为客户端随机产生的一个值。SYN报文中的ISN可简化表示为ISN(c)。ISN(c)中“c”的含义是客户端(client)。

步骤二、服务器接收SYN报文，服务器向客户端发送SYN ACK报文。SYN ACK报文包括服务器支持的选项。服务器通过发送SYN ACK报文，从而通知客户端已经收到了客户端的SYN报文，并将支持的选项告诉给客户端。

其中，SYN ACK报文中的Seq号为ISN。SYN ACK报文中的ISN为服务器随机产生的一个值。SYN ACK报文中的ISN可简化表示为ISN(s)。ISN(c)中“s”的含义是服务器(server)。SYN ACK报文中的ACK号为ISN(c)+1。

步骤三、客户端接收SYN ACK报文，客户端向服务器发送ACK报文，从而完成三次握手。其中，ACK报文中的Seq号为ISN(c)+1。ACK报文中的ACK号为ISN(s)+1。

当客户端与服务器握手完成后，客户端与服务器在数据传输阶段交互数据报文时，客户端与服务器会使用握手协商出的报文序列号(Seq)、MSS，按序分段发送数据。其中，客户端与服务器每次发送的数据量的最大值为对方通告的窗口大小。接收方通过ACK报文确认收到的数据报文，同时更新自己可以接收到的最大数据长度。此外，TCP协议还需要使用一系列定时器、拥塞算法，来处理网络中的异常丢包，以及发送过快造成的丢包。

以上介绍了三次握手的基本原理。可选地，由于版本限制或者性能限制等因素，在有些情况下防护设备的协议栈可能只能支持部分选项，而不能支持所有选项。如果客户端设备和服务器恰好使用防护设备协议栈不支持的选项进行会话协商，则可能会造成防护设备采用代理模式进行检测时出现检测失败。在这种情况下，本申请实施例提供了一种改进的报文处理方式，防护设备在三次握手阶段对交互报文进行处理，从而避免因协议栈不支持因素引入的检测故障。下面对本申请实施例提供的防护设备在三次握手阶段的处理流程进行介绍。

防护设备在三次握手阶段的处理流程包括以下步骤S501至步骤S503。

以下介绍的步骤S501至步骤S503，和上述步骤S510至步骤S540之间的关系是，步骤S501至步骤S503、步骤S510至步骤S540分别针对同一个TCP会话的不同阶段。步骤S501至步骤S503应用在触发TCP会话建立的三次握手阶段。步骤S510至步骤S540应用在TCP会话建立之后的数据传输阶段。从时间先后顺序的角度而言，防护设备先在三次握手阶段执行步骤S501至步骤S503。当TCP会话建立，客户端设备与服务器交互数据报文的过程中，防护设备执行上述步骤S510至步骤S540。

步骤S501、防护设备获取客户端设备与服务器之间传输的第一握手报文。

第一握手报文用于创建TCP会话。第一握手报文为TCP协议中的三次握手报文。具体地，第一握手报文为SYN报文或者SYN ACK报文中的至少一种。第一握手报文包括TCP头，TCP头包括长度可变的选项(option)字段。选项字段的内容为选项的具体信息。选项包括而不限于SACK选项、MSS选项、窗口扩大选项、时间戳选项等。

在第一握手报文为SYN报文的情况下，第一握手报文的源设备为客户端设备。步骤S501包括：防护设备接收来自于客户端设备的SYN报文。

在第一握手报文为SYN ACK报文的情况下，第一握手报文的源设备为服务器。步骤S501包括：防护设备接收来自于服务器的SYN ACK报文。

步骤S502、防护设备从第一握手报文删除第二选项，从而得到第二握手报文。

以第一握手报文包括第一选项和第二选项为例，防护设备分别判断第一选项和第二选项是否是防护设备的TCP/IP协议栈支持的选项；防护设备确定第一选项是防护设备的TCP/IP协议栈支持的选项，则防护设备保留第一选项。防护设备确定第二选项是防护设备的TCP/IP协议栈不支持的选项，则防护设备删除第二选项。防护设备处理得到的第二握手报文包括第一选项且不包括第二选项。

步骤S503、防护设备向第一握手报文的目的设备发送第二握手报文。

在第一握手报文为SYN报文的情况下，第一握手报文的目的设备为服务器。第二握手报文为删除选项后的SYN报文。步骤S503包括：防护设备向服务器发送删除选项后的SYN报文。

在第一握手报文为SYN ACK报文的情况下，第一握手报文的目的设备为客户端设备。第二握手报文为删除选项后的SYN ACK报文。步骤S503包括：防护设备向客户端设备发送删除选项后的SYN ACK报文。

以上通过步骤S501至步骤S503介绍了防护设备在三次握手阶段删除选项相关的流程，以下介绍基于上述删除选项的流程进行三次握手的完整流程。

请参考附图7，本申请实施例在三次握手阶段包括附图7所示的流程700。流程700包括以下步骤S710至步骤S780。其中，步骤S710和步骤S720中的SYN报文、步骤S740和步骤S750中的SYN ACK报文均是对第一握手报文的举例说明，步骤S720和步骤S730中删除选项后的SYN报文、步骤S750和步骤S760中删除选项后的SYN ACK报文均是对第二握手报文的举例说明。

步骤S710、客户端设备生成并发送SYN报文。

步骤S720、防护设备接收来自客户端的SYN报文。防护设备解析SYN报文，从SYN报文中提取客户端的MSS、窗口、时间戳、SACK等选项。防护设备根据防护设备本地的TCP/IP协议栈支持的选项，从SYN报文中删除本地的TCP/IP协议栈不支持的选项，保留SYN报文中本地的TCP/IP协议栈支持的选项，得到删除选项后的SYN报文。

步骤S730、防护设备向服务器发送删除选项后的SYN报文。

步骤S740、服务器接收删除选项后的SYN报文，生成并发送SYN ACK报文。

步骤S750、防护设备接收来自服务器的SYN ACK报文。与步骤S720同理地，防护设备解析SYN ACK报文，从SYN ACK报文提取服务器的MSS、窗口、时间戳、SACK等选项。防护设备根据防护设备本地的TCP/IP协议栈支持的选项，从SYN ACK报文中删除不支持的选项，保留SYN ACK报文中本地的TCP/IP协议栈支持的选项，得到删除选项后的SYN ACK报文。

步骤S760、防护设备向客户端发送删除选项后的SYN ACK报文。

步骤S770、客户端接收删除选项后的SYN ACK报文，生成并发送ACK报文。

步骤S780、防护设备接收来自于客户端的ACK报文，防护设备将客户端的ACK报文转发给服务器，从而完成客户端和服务器会话建立。

以上介绍了本实施例提供的三次握手流程，以下介绍基于该三次握手流程切换至代理模式的流程。

以下介绍的模式切换的流程是对上述方法500中步骤S540的举例说明。以上介绍的三次握手流程与以下介绍的模式切换流程之间的主要关联在于，由于三次握手流程中防护设备删除了不支持的选项，能够确保采用代理模式检测首条流的过程中报文交互涉及的选项是防护设备自身的TCP/IP协议栈支持的选项，避免针对首条流切换至代理模式后由于防护设备难以解析客户端或者服务器使用的选项造成报文传输失败，提高针对首条流检测的可靠性和成功率。下面，对达到这种效果的原理进行介绍。

在TCP协议中，TCP会话中使用哪些选项来传输数据报文是通过三次握手报文进行协商的。具体而言，收发两端(客户端和服务器)在三次握手阶段中，会在三次握手报文中添加自身支持的选项，将三次握手报文发给对端，从而通知对端自身支持哪些选项。收发两端收到对端发来的三次握手报文后，如果三次握手报文中携带某个选项，而且自身也支持这个选项，收发两端会将该选项作为协商出的选项。当会话建立后时，收发两端会启动协商出的选项传输数据。

而通过本实施例提供的三次握手流程，由于防护设备从三次握手报文中删除了不支持的选项，将删除选项后的三次握手报文转发给客户端设备或者服务器，因此，传递到客户端设备以及服务器上的三次握手报文中不包括防护设备不支持的选项。换句话说，传递到客户端设备以及服务器上的三次握手报文中的选项都是防护设备支持的选项。因此，客户端设备和服务器协商出的每个选项都会是防护设备支持的选项，避免出现客户端设备和服务器协商出的选项包含防护设备不支持的选项的情况。那么，当首个会话建立后，客户端和服务器在首个会话中交互的报文中的选项都是防护设备支持的选项。

因此，在本实施例提供的针对首个会话进行检测的流程中，在客户端和服务器交互首个会话的报文的过程中，如果防护设备决定要切换针对首个会话的检测模式，由于防护设备切换为代理模式后继续收到的首个会话中的报文中的选项是防护设备支持的选项，因此防护设备能够通过自身支持的选项采用切换后的模式处理首个会话中继续收到的报文，确保在首个会话过程中成功地进入代理模式，使得首个会话中后续报文能通过代理模式检测。

具体地，防护设备通过在初始的三次握手阶段，根据防护设备的TCP/IP协议栈的能力，对客户端设备和服务器的握手进行干涉，确保客户端设备和服务器协商出的选项防护设备本地TCP/IP协议栈都可以支持。因此，后续一旦在首个会话中切换为代理模式，客户端设备和服务器使用协商的选项进行报文交互时，防护设备自身的TCP/IP协议栈能够利用支持的选项代替服务器与客户端设备交互，防护设备自身的TCP/IP协议栈能够利用支持的选项代替客户端设备与服务器交互，从而成功执行采用代理模式进行检测的任务，而不会出现错误。比如，如果防护设备上的TCP/IP协议栈不支持SACK选项，而客户端设备和服务器支持SACK选项，如果客户端设备和服务器在三次握手阶段协商使用SACK选项，当防护设备在首个会话中切换为代理模式后，防护设备会因为难以解析SACK选项，造成首个会话中的报文传输故障，导致业务不通。而防护设备通过删除握手报文中的SACK选项，使得客户端设备和服务器在三次握手阶段不会协商使用SACK选项，因此防护设备在首个会话中切换为代理模式后继续收到的报文不包括SACK选项，避免由于防护设备难以解析SACK选项造成的传输故障。

下面，以防护设备在流模式与代理模式之间进行模式切换为例，对防护设备在首个会话中进行模式切换的具体过程举例说明，详见下述场景一和场景二。

场景一、流模式切换为代理模式

在场景一下，防护设备之前在流模式下可能已经缓存了首个会话中的一些数据报文。比如，防护设备在流模式下，为了进行流重组而缓存一个窗口内接收的数据报文。又如，防护设备在流模式下缓存了一些已经转发给对端，而对端尚未返回确认报文的数据报文。对于这些之前已经缓存的数据报文，防护设备通过执行以下介绍的方案，从而在达到删除选项带来的效果的基础上，进一步加速模式切换的处理过程，减少模式切换的处理时延。

以下，通过方面(1)和方面(2)这两个方面，描述场景一涉及的具体实现方式。

方面(1)防护设备如何处理之前在流模式下缓存的已接收的数据报文。

防护设备在针对首个TCP会话从流模式切换为代理模式的过程中，对于之前在流模式下缓存的已接收的数据报文，防护设备会通过自身TCP/IP协议栈进行ACK处理。具体而言，针对之前在流模式下缓存的客户端设备发来的数据报文，防护设备会通过TCP/IP协议栈主动生成确认报文发送给客户端设备，从而扮演模拟的服务器的角色来应答客户端设备；针对之前在流模式下缓存的服务器发来的数据报文，防护设备会通过TCP/IP协议栈主动生成确认报文发送给服务器，从而扮演模拟的客户端设备的角色来应答服务器。

例如，防护设备在三次握手阶段保留了第一选项(防护设备支持的选项)，删除了第二选项(防护设备不支持的选项)。以上方法500中，防护设备在流模式下接收并缓存了首个TCP会话中的第二数据报文。防护设备确定将要切换为代理模式以检测首个TCP会话之后，防护设备根据第一选项生成针对首个TCP会话中的第二数据报文的确认报文；防护设备向第二数据报文的源设备发送针对第二数据报文的确认报文。

在一些实施例中，第二数据报文是客户端发往服务器的报文。具体地，防护设备在采用流模式检测首个TCP会话的数据报文的过程中，客户端发送第二数据报文；防护设备接收并缓存来自于客户端的第二数据报文；防护设备确定将要切换为代理模式以检测首个TCP会话之后，防护设备向客户端发送针对第二数据报文的确认报文。

在另一些实施例中，第二数据报文是服务器发往客户端的报文。具体地，防护设备在采用流模式检测首个TCP会话的数据报文的过程中，服务器发送第二数据报文；防护设备接收并缓存来自于服务器的第二数据报文；防护设备确定将要切换为代理模式以检测首个TCP会话之后，防护设备向服务器发送针对第二数据报文的确认报文。

方面(2)防护设备如何处理之前在流模式下已经转发给对端、而没有收到对端的确认报文的数据报文。

防护设备在针对首个TCP会话从流模式切换为代理模式的过程中，对于之前在流模式下已经转发给对端，而没有收到对端的确认报文的数据报文，防护设备会通过自身TCP/IP协议栈负责这些数据报文的传输可靠性。具体地，针对之前在流模式下已经转发给服务器、且还没有收到确认报文的数据报文，防护设备会扮演模拟客户端的角色，当发生丢包时向服务器重传数据报文，从而确保数据报文抵达服务器；针对之前在流模式下已经转发给客户端、且还没有收到确认报文的数据报文，防护设备会扮演模拟服务器的角色，当发生丢包时向客户端重传数据报文，从而确保数据报文抵达客户端。

例如，防护设备在三次握手阶段保留了第一选项(防护设备支持的选项)，删除了第二选项(防护设备不支持的选项)，以上方法500中，防护设备在流模式下发送了首个TCP会话中的第三数据报文，并缓存第三数据报文。防护设备确定将要切换为代理模式之后，如果第三数据报文满足重传条件，防护设备根据第一选项向第三数据报文的目的设备重新发送第三数据报文。

在一些实施例中，第三数据报文是客户端发往服务器的报文。具体地，防护设备在采用流模式检测首个TCP会话的数据报文的过程中，客户端发送第三数据报文；防护设备接收第三数据报文，对第三数据报文进行安全检测后，向服务器转发第三数据报文；防护设备确定将要切换为代理模式之后，如果第三数据报文满足重传条件，防护设备向服务器重新发送第三数据报文。

在一些实施例中，第三数据报文是服务器发往客户端的报文。具体地，防护设备在采用流模式检测首个TCP会话的数据报文的过程中，服务器发送第三数据报文；防护设备接收第三数据报文，对第三数据报文进行安全检测后，向客户端转发第三数据报文；防护设备确定将要切换为代理模式之后，如果第三数据报文满足重传条件，防护设备向客户端重新发送第三数据报文。

从以上方面(1)和方面(2)可见，在流模式切换为代理模式的场景下，防护设备根据握手阶段协商出的选项(第一选项)，对之前在流模式下缓存的报文进行ACK处理以及负责可靠性传输，使得防护设备之前在流模式下缓存的首个会话中数据报文也能够快速走代理模式处理，从而缩短了流模式切换到代理模式所需耗费的时间。

请参考附图8，防护设备通过提供附图8中的功能模块来支持上述处理流程。

防护设备的TCP控制层中包括流模式处理模块1311、TCP/IP协议栈模块1331、流模式处理模块1312以及TCP/IP协议栈模块1332。其中，附图3中的流模式处理模块131包括附图8中的流模式处理模块1311以及流模式处理模块1312。附图3中的TCP/IP协议栈模块133包括附图8中的TCP/IP协议栈模块1331以及TCP/IP协议栈模块1332。

流模式处理模块1311用于处理流模式下与客户端设备11的交互。流模式处理模块1311包括接收报文队列13111以及已发送报文队列13112。接收报文队列13111用于缓存流模式下接收到的来自客户端设备11的数据报文。在一些实施例中，接收报文队列13111具体用于缓存一个窗口内收到的客户端设备11的数据报文。接收报文队列13111缓存的数据报文用于进行TCP层的流重组。已发送报文队列13112用于缓存流模式下已经向客户端设备11发送的数据报文。在一些实施例中，已发送报文队列13112具体用于缓存已发送、且仍未收到客户端设备11的确认报文的数据报文。

流模式处理模块1312用于处理流模式下与服务器12的交互。流模式处理模块1312包括接收报文队列13121以及已发送报文队列13122。接收报文队列13121用于缓存流模式下接收到的来自服务器12的数据报文。在一些实施例中，接收报文队列13121具体用于缓存一个窗口内收到的服务器12的数据报文。接收报文队列13121缓存的数据报文用于进行TCP层的流重组。已发送报文队列13122用于缓存流模式下已经向服务器12发送的数据报文。在一些实施例中，已发送报文队列13122具体用于缓存已发送、且仍未收到服务器12的确认报文的数据报文。

TCP/IP协议栈模块1331为用于与客户端设备11交互的TCP/IP协议栈模块。

TCP/IP协议栈模块1331包括接收报文队列13311以及发送报文队列13312。接收报文队列13311用于缓存代理模式下接收到的来自客户端设备11的数据报文。发送报文队列13312用于缓存代理模式下向客户端设备11发送的数据报文。在一些实施例中，发送报文队列13312具体用于缓存代理模式下已经向客户端设备11发送、且仍未收到确认报文的数据报文。

TCP/IP协议栈模块1332为与服务器12交互的TCP/IP协议栈模块。TCP/IP协议栈模块1332包括接收报文队列13321以及发送报文队列13322。接收报文队列13321用于缓存代理模式下接收到的来自服务器12的数据报文。发送报文队列13322用于缓存代理模式下向服务器12发送的数据报文。在一些实施例中，发送报文队列13322具体用于缓存代理模式下已经向服务器12发送、且仍未收到确认报文的数据报文。

下面介绍防护设备如何通过图3或者图8示出的各个模块实现从流模式切换为代理模式的处理流程。

请参考图3和图8，上层业务模块130判断需要进入代理模式处理，则上层业务模块130向TCP控制层下发指令从而通知TCP控制层要转换为代理模式。TCP控制层接收到上层业务模块130发来的指令后，执行以下步骤S530a至步骤S530d。

步骤S530a、TCP控制层根据流模式处理模块131记录的TCP三次握手协商信息，通过TCP/IP协议栈模块133快速建立会话对。其中，会话对包括代理服务器会话以及代理客户端会话。代理服务器会话负责和真实的客户端交互。代理客户端会话负责和真实的服务器交互。其中，协商信息包括三次握手处理时协商出的选项(如第一选项)。

步骤S530b、TCP控制层将从流模式处理模块131缓存的数据报文送入TCP/IP协议栈模块133。TCP/IP协议栈模块133对从流模式处理模块131送入的报文进行ACK处理，从而应答真实客户端或者真实服务器。

具体地，请参考图8，流模式处理模块1311中的接收报文队列13111缓存了来自客户端设备11的数据报文。TCP控制层将接收报文队列13111缓存的数据报文送入TCP/IP协议栈模块1331的接收报文队列13311。TCP/IP协议栈模块1331针对流模式处理模块1311送入的报文进行ACK处理，从而应答客户端设备11。

流模式处理模块1312中的接收报文队列13121缓存了来自服务器12的数据报文。TCP控制层将接收报文队列13121缓存的数据报文送入TCP/IP协议栈模块1332的接收报文队列13321。TCP/IP协议栈模块1332针对流模式处理模块1312送入的报文进行ACK处理，从而应答服务器12。

步骤S530c、TCP控制层将流模式处理模块131已经转发，尚未收到ACK的报文加入TCP/IP协议栈模块/代理模式处理模块中的发送报文队列。具体地，流模式处理模块1311以及TCP/IP协议栈模块1331都负责处理和客户端设备11的交互，流模式处理模块1312以及TCP/IP协议栈模块1332都负责处理和服务器12的交互。在流模式切换为代理模式的过程中，TCP控制层会将流模式处理模块1311中已发送报文队列13112中缓存的报文加入TCP/IP协议栈模块1331中发送报文队列13312。TCP控制层会将流模式处理模块1312中已发送报文队列13122中缓存的报文加入TCP/IP协议栈模块1332中发送报文队列13322。

比如，上层业务模块130根据客户端设备11发送的数据报文判定需要采用代理模式，TCP控制层将客户端设备11后续发来的数据报文送入TCP/IP协议栈模块1331之后，TCP控制层需要将流模式处理模块1311已经转发给客户端设备11的数据报文，送入TCP/IP协议栈模块1331，通过TCP/IP协议栈模块1331实现代理客户端的功能，由TCP/IP协议栈模块1331负责丢包、超时引起的重传操作。

步骤S530d、TCP控制层清理流模式使用的资源，进入代理模式处理TCP会话后续报文。

例如，TCP控制层释放流模式处理模块1311中接收报文队列13111以及已发送报文队列13112、流模式处理模块1312中接收报文队列13121以及已发送报文队列13122占用的缓存空间。

以上提供的系统架构中，通过定制化的TCP/IP协议栈，不仅实现基于数据报文交互结果，在数据报文交互阶段从流模式自适应地切换到代理模式，还支持已经在流模式下缓存数据报文的复杂情况，提升方案的可用性。

场景二、代理模式切换为流模式

防护设备在采用代理模式处理的过程中，防护设备的TCP/IP协议栈模块内部、防护设备的上层业务模块都会缓存有一定数量的数据报文。代理模式切换为流模式理想的时间点是防护设备的TCP/IP协议栈模块内部以及上层业务模块都没有任何缓存数据报文。在这种理想的时间点进行模式切换时，防护设备建立流模式处理相关的资源、状态等，释放TCP/IP协议栈相关资源，即可完成模式切换。但是，通常情况下，并不能满足这一理想状态；这是由于，TCP/IP协议栈模块中的两种缓存(接收报文队列以及发送报文队列)通常是非空的。比如，当防护设备决定要切换到代理模式时，TCP/IP协议栈模块中的发送报文队列可能已经缓存了一些已经发送、等待对端确认的报文，TCP/IP协议栈模块中的接收报文队列可能已经缓存了一些TCP/IP协议栈模块已经确认、等待上层业务处理的报文。对于这些之前在代理模式下缓存的数据报文，防护设备通过执行以下介绍的方案，从而在达到删除选项带来的效果的基础上，进一步保证这些数据报文的传输可靠性。

以下，通过方面(a)和方面(b)这两个方面，描述场景二涉及的具体实现方式。以下描述的实现方式能够应用在防护设备针对首个会话，从流模式切换为代理模式之后再重新切换回流模式的场景。

方面(a)防护设备如何处理之前在代理模式下缓存的已发送的数据报文。

防护设备在针对首个TCP会话从代理模式切换为流模式的过程中，对于之前在代理模式下已发送的首个TCP会话的数据报文，防护设备会通过自身TCP/IP协议栈负责这些数据报文的传输可靠性。具体地，防护设备会继续等待对端对这些数据报文的确认报文。当防护设备收到对端针对这些数据报文的确认报文之后，防护设备再从缓存中删除这些数据报文。如果防护设备通过超时未收到确认报文、SACK选项或者其他方式，发现这些数据报文丢包，则防护设备执行重传。

例如，防护设备在三次握手阶段保留了第一选项(防护设备支持的选项)，删除了第二选项(防护设备不支持的选项)，以上方法500中，防护设备在代理模式下已发送首个TCP会话中的第六数据报文。防护设备确定针对首个TCP会话切换回流模式之后，如果第六数据报文满足重传条件，防护设备根据第一选项向第六数据报文的目的设备重新发送第六数据报文。

在一些实施例中，第六数据报文是首个TCP会话中客户端发往服务器的报文。具体地，防护设备在采用代理模式检测首个TCP会话的数据报文的过程中，客户端发送第六数据报文；防护设备接收第六数据报文，防护设备对第六数据报文根据第一选项执行解析后，向客户端设备发送确认报文，此外，防护设备对第六数据报文进行安全检测。如果第六数据报文检测通过，防护设备向服务器发送第六数据报文。防护设备确定将要切换为流模式之后，如果第六数据报文满足重传条件，防护设备根据第一选项向服务器重新发送第六数据报文。

在另一些实施例中，第六数据报文是首个TCP会话中服务器发往客户端的报文。具体地，防护设备在采用代理模式检测首个TCP会话的数据报文的过程中，服务器发送第六数据报文；防护设备接收第六数据报文，防护设备对第六数据报文根据第一选项执行解析后，向服务器发送确认报文，此外，防护设备对第六数据报文进行安全检测。如果第六数据报文检测通过，防护设备向客户端发送第六数据报文。防护设备确定将要切换为流模式之后，如果第六数据报文满足重传条件，防护设备根据第一选项向客户端重新发送第六数据报文。

方面(b)防护设备如何处理之前在代理模式下缓存的已接收的数据报文。

防护设备在针对首个TCP会话从代理模式切换为流模式的过程中，对于之前在代理模式下已接收并回复确认的首个TCP会话中数据报文，防护设备会先根据这些数据报文安全检测，再通过自身TCP/IP协议栈模块将检测处理后的数据报文进行可靠性发送。其中，可靠性发送是指TCP/IP协议栈基于TCP重传机制向TCP会话的对端(客户端或者服务器)发送数据报文。

例如，防护设备在三次握手阶段保留了第一选项(防护设备支持的选项)，删除了第二选项(防护设备不支持的选项)。以上方法500中，防护设备在代理模式下已接收首个TCP会话中的第七数据报文，并且防护设备已对第七数据报文根据第一选项执行解析后向第七数据报文的源设备发送针对第七数据报文的确认报文。防护设备确定将要切换为流模式之后，防护设备对第七数据报文执行检测处理，得到第八数据报文；防护设备根据第一选项向第七数据报文的目的设备发送第八数据报文。

在一些实施例中，第七数据报文是首个TCP会话中客户端发往服务器的报文。具体地，防护设备在采用代理模式检测首个TCP会话的数据报文的过程中，客户端发送第七数据报文；防护设备接收第七数据报文，防护设备对第七数据报文根据第一选项执行解析后，向客户端设备发送针对第七数据报文的确认报文。防护设备确定将要切换为流模式之后，防护设备对第七数据报文执行检测处理，得到第八数据报文；防护设备根据第一选项向服务器发送第八数据报文。此外，如果第八数据报文满足重传条件，防护设备根据第一选项向服务器重新发送第八数据报文。

在另一些实施例中，第七数据报文是首个TCP会话中服务器发往客户端的报文。具体地，防护设备在采用代理模式检测首个TCP会话的数据报文的过程中，服务器发送第七数据报文；防护设备接收第七数据报文，防护设备对第七数据报文根据第一选项执行解析后，向服务器发送针对第七数据报文的确认报文。防护设备确定将要切换为流模式之后，防护设备对第七数据报文执行检测处理，得到第八数据报文；防护设备根据第一选项向客户端发送第八数据报文。此外，如果第八数据报文满足重传条件，防护设备根据第一选项向客户端重新发送第八数据报文。

下面结合附图9，介绍防护设备如何通过附图9所示的各个模块实现代理模式切换至流模式的处理流程。

请参考附图9，防护设备从代理模式切换为流模式的步骤包括以下步骤S530a’至步骤S530i’。

步骤S530a’、TCP控制层停止新报文的入协议栈操作。具体地，上层业务模块130确定切换为流模式之后，如果TCP控制层新接收到来自客户端设备11的数据报文，TCP控制层停止将数据报文添加至TCP/IP协议栈模块1331的接收报文队列13111；如果TCP控制层新接收到来自服务器12的数据报文，TCP控制层停止将数据报文添加至TCP/IP协议栈模块1332的接收报文队列13321。

步骤S530b’、TCP控制层丢弃TCP/IP协议栈模块1331的接收报文队列13111中乱序的数据报文，以及TCP/IP协议栈模块1332的接收报文队列13321中乱序的数据报文。

具体地，由于TCP/IP协议栈模块不会对乱序的数据报文回复确认报文，因此乱序的数据报文是能够安全丢弃的。其中，乱序的数据报文是指数据报文的Seq号不连续。例如，TCP/IP协议栈模块1331的接收报文队列13111缓存有Seq号分别是1-5的数据报文以及Seq号分别是8-10的数据报文，但是TCP/IP协议栈模块1331的接收报文队列13111中没有Seq号分别是6-7的数据报文，那么Seq号分别是8-10的数据报文即为乱序的数据报文，TCP控制层在执行步骤S530b时，丢弃Seq号分别是8-10的数据报文。

步骤S530c’、TCP控制层将TCP/IP协议栈模块1331的接收报文队列13111中的数据报文以及TCP/IP协议栈模块1332的接收报文队列13321中的数据报文提交给上层业务模块130处理，并清空TCP/IP协议栈模块1331的接收报文队列13111以及TCP/IP协议栈模块1332的接收报文队列13321。

步骤S530d’、上层业务模块130将处理后的数据报文发给TCP控制层，之后上层业务模块130清空缓存。TCP控制层将处理后的数据报文交给对端TCP/IP协议栈模块中的发送报文队列。

具体地，如果数据报文来自于TCP/IP协议栈模块1331的接收报文队列13111，TCP控制层会将数据报文发送给TCP/IP协议栈模块1332中的发送报文队列13322，由TCP/IP协议栈模块1332中的发送报文队列13322向服务器12发送数据报文。如果数据报文来自于TCP/IP协议栈模块1332的接收报文队列13321，TCP控制层会将数据报文发送给TCP/IP协议栈模块1331中的发送报文队列13312，由TCP/IP协议栈模块1331中的发送报文队列13312向客户端发送数据报文。

步骤S530e’、针对处于发送报文队列的数据报文，防护设备通过TCP/IP协议栈模块对数据报文进行可靠性发送，并记录TCP/IP协议栈模块已发送的数据报文的最大Seq号。其中，已发送的数据报文的最大Seq号例如是初始序列号(ISN)的基础上按照已发送的数据长度进行递增得到的值。例如，客户端的初始序列号，即ISN(c)是1000，防护设备已经为客户端转发了2000字节的数据，那么最大Seq号就是3001，其中SYN报文占1字节。

步骤S530f’、防护设备接收到来自客户端或者服务器的后续数据报文后，按照流模式处理后续数据报文。

防护设备接收到来自客户端或者服务器的确认报文时，对确认报文的处理步骤包括以下步骤S530g’或步骤S530h’。具体地，如果防护设备不支持SACK选项，防护设备在三次握手阶段从握手报文中删除SACK选项，并按照以下步骤S530g’处理确认报文。如果防护设备支持SACK选项，防护设备在三次握手阶段保留握手报文中的SACK选项，并按照以下步骤S530h’处理确认报文。

步骤S530g’、如果防护设备不支持SACK选项，对于确认报文，防护设备判断确认报文的ACK号。如果确认报文的ACK号小于或等于记录的最大Seq号，防护设备将确认报文送TCP/IP协议栈模块。如果确认报文的ACK号大于记录的最大Seq号，防护设备跳转至步骤S530i，按照流模式处理确认报文。

其中，将确认报文送TCP/IP协议栈模块与按照流模式处理确认报文是两种不同的动作。

如果防护设备按照流模式处理确认报文，防护设备会将确认报文转发给对端。例如，如果确认报文来自于服务器，防护设备会将确认报文转发给客户端。如果确认报文来自于客户端，防护设备会将确认报文转发给服务器。

如果防护设备将确认报文送TCP/IP协议栈模块，防护设备不会将确认报文转发给对端，而是通过TCP/IP协议栈模块处理确认报文。比如，如果确认报文来自于服务器，防护设备不会将确认报文转发给客户端，而是通过TCP/IP协议栈模块充当模拟的服务器处理确认报文。

步骤S530h’、如果防护设备支持SACK选项，防护设备根据SACK选项中的范围以及记录的最大Seq号按TCP协议进行处理。如果确认报文是针对TCP/IP协议栈发送的数据报文的确认报文，则防护设备将确认报文送TCP/IP协议栈处理；如果确认报文是针对流模式下转发的数据报文的确认报文，则防护设备按照流模式处理确认报文，从而交给对端设备处理确认报文。进一步地，如果SACK选项同时确认了TCP/IP协议栈发送的数据和流模式下转发的数据，防护设备拆分确认报文分别送TCP/IP协议栈处理以及按照流模式处理。

例如，源端先后依次发送了7个报文，分别是报文1、报文2、报文3、报文4、报文5、报文6和报文7。其中，报文4丢失，报文1、报文2、报文3、报文5、报文6以及报文7成功传输到了目的端。如果源端和目的端在三次握手时协商使用SACK选项，目的端能够利用SACK选项指明丢失的报文是报文4。具体地，目的端返回的确认报文包括ACK号以及SACK选项。ACK号用于指示报文1、报文2至报文3已经收到，SACK选项中的序号用于指示报文5、报文6至报文7已经收到。因此，发送方根据ACK号以及SACK选项中的序号，能够知道报文4丢了。结合防护设备从代理模式切换为流模式的场景，例如，防护设备在代理模式下接收到报文1、报文2、报文3、报文4以及报文5，防护设备通过自身的TCP/IP协议栈发送报文1、报文2、报文3、报文4以及报文5。防护设备确定要切换到流模式之后，后续接收到了报文6和报文7。防护设备按照流模式转发了报文6和报文7。如果防护设备、客户端、服务器均使用SACK选项，防护设备接收到确认报文时会对确认报文拆分，针对确认报文中报文1、报文2、报文3、报文4以及报文5对应的内容，防护设备会通过自身的TCP/IP协议栈处理，比如如果报文4丢失了，防护设备会通过自身的TCP/IP协议栈重传报文4。针对确认报文中报文6以及报文7对应的内容，防护设备会通过流模式通知源端处理。

步骤S530i’、如果TCP/IP协议栈模块中针对当前TCP会话的发送报文队列缓存的数据报文都已经发送完毕，且防护设备已经接收到这些数据报文的确认报文，防护设备删除TCP/IP协议栈模块相关资源。对于TCP会话后续的所有报文，防护设备会按照流模式处理。

以上提供的系统架构中，通过定制化的TCP/IP协议栈，不仅实现基于数据报文交互结果，在数据报文交互阶段从代理模式自适应地切换为流模式，还支持已经在代理模式下缓存数据报文的复杂情况，提升方案的可用性。

附图10示出了防护设备的一种可能的结构示意图。

附图10所示的防护设备800例如实现附图5所示方法500中防护设备的功能。在一些实施例中，附图10所示的防护设备800还用于实现附图7所示方法700中防护设备的功能。

在一些实施例中，附图10所示的防护设备800为附图3、附图8或附图9中的防护设备13。例如，附图10所示的防护设备800中的处理单元802通过附图8或附图9中的流模式处理模块1311、TCP/IP协议栈模块1331、流模式处理模块1312、TCP/IP协议栈模块1332中的至少一项实现。

请参考附图10，防护设备800包括获取单元801和处理单元802。可选地，防护设备800还包括发送单元和存储单元。防护设备800中的各个单元全部或部分地通过软件、硬件、固件或者其任意组合来实现。防护设备800中的各个单元分别用于执行上述方法500或方法700中防护设备的相应功能。具体地，获取单元801用于支持防护设备800执行S510。处理单元802用于支持防护设备800执行S520、S530以及S540。在一些实施例中，处理单元802还用于支持防护设备800执行S720以及S750。发送单元用于支持防护设备800执行S730以及S780。存储单元用于支持防护设备800缓存数据报文。

本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可选地有另外的划分方式。

在一些实施例中，防护设备800中各个单元集成在一个单元中。例如，防护设备800中各个单元集成在同一个芯片上。该芯片包括处理电路和与该处理电路内部连接通信的输入接口以及输出接口。处理单元802通过芯片中的处理电路实现。获取单元801通过芯片中的输入接口实现。发送单元通过芯片中的输出接口实现。例如，该芯片通过一个或多个现场可编程门阵列(field－programmable gate array，FPGA)、可编程逻辑器件(programmablelogic device，PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其它适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合实现。

在另一些实施例中，防护设备800各个单元单独物理存在。在另一些实施例中，防护设备800一部分单元单独物理存在，另一部分单元集成在一个单元中。例如，在一些实施例中，防护设备800中获取单元801和发送单元集成为同一个硬件(如通信接口)。在一些实施例中，不同单元的集成采用硬件的形式实现，即，不同单元对应于同一个硬件。又如，不同单元的集成采用软件单元的形式实现。

在防护设备800中通过硬件实现的情况下，防护设备800中处理单元802例如通过附图4所示的防护设备200中的处理器201实现。防护设备800中获取单元801、发送单元例如通过附图4所示的防护设备200中的通信接口204实现。防护设备800中存储单元例如通过附图4所示的防护设备200中的存储器203实现。

在防护设备800中通过软件实现的情况下，防护设备800中各个单元例如为防护设备200中的处理器201读取存储器203中存储的程序代码210后生成的软件。例如，防护设备800为虚拟化设备。虚拟化设备包括而不限于虚拟机、容器、Pod中的至少一种。在一些实施例中，防护设备800以虚拟机的形式，部署在硬件设备(如物理服务器)上。例如，基于通用的物理服务器结合网络功能虚拟化(network functions virtualization，NFV)技术来实现防护设备800。采用虚拟机的方式实现时，防护设备800例如为虚拟主机、虚拟路由器或虚拟交换机。本领域技术人员通过阅读本申请即可结合NFV技术在通用物理服务器上虚拟出防护设备800。在另一些实施例中，防护设备800以容器(例如docker容器)的形式，部署在硬件设备上。例如，防护设备800执行上述方法实施例的流程被封装在镜像文件中，硬件设备通过运行镜像文件来创建防护设备800。在另一些实施例中，防护设备800以Pod的形式，部署在硬件设备上。Pod包括多个容器，每个容器用于实现防护设备800中的一个或多个单元。

本领域普通技术人员可以意识到，结合本文中所公开的实施例中描述的各方法步骤和单元，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参见前述方法实施例中的对应过程，在此不再赘述。

本申请中术语“第一”、“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。例如，在不脱离各种示例的范围的情况下，第一数据报文可以被称为第二数据报文，并且类似地，第二数据报文可以被称为第一数据报文。第一数据报文和第二数据报文都可以是数据报文，并且在某些情况下，可以是单独且不同的数据报文。

本申请中术语“至少一个”的含义是指一个或多个。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机程序指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机程序指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，DVD)、或者半导体介质(例如固态硬盘)等。前述的存储介质包括：U盘、移动硬盘、只读存储器(read-onlymemory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (15)

1.一种网络安全防护方法，其特征在于，所述方法包括：

防护设备获取客户端设备与服务器之间首个传输控制协议TCP会话中的第一数据报文，首个TCP会话为客户端设备与服务器之间建立的第一个会话，所述防护设备部署于所述客户端设备与所述服务器之间；

所述防护设备根据所述第一数据报文的应用层数据，识别所述第一数据报文的应用层协议类型；

所述防护设备确定所述应用层协议类型对应的检测模式为代理模式；

所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测。

2.根据权利要求1所述的方法，其特征在于，所述防护设备获取客户端设备与服务器之间首个传输控制协议TCP会话中的第一数据报文之前，所述方法还包括：

所述防护设备获取所述客户端设备与所述服务器之间传输的第一握手报文，所述第一握手报文用于创建所述首个TCP会话，所述第一握手报文包括第一选项以及第二选项，所述第一选项为所述防护设备支持的选项，所述第二选项为所述防护设备不支持的选项；

所述防护设备从所述第一握手报文删除所述第二选项，从而得到第二握手报文；

所述防护设备向所述第一握手报文的目的设备发送所述第二握手报文。

3.根据权利要求2所述的方法，其特征在于，所述首个TCP会话中的后续报文包括第二数据报文，所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测，包括：

所述防护设备接收并缓存所述第二数据报文；

所述防护设备根据所述第一选项生成针对所述第二数据报文的确认报文；

所述防护设备向所述第二数据报文的源设备发送针对所述第二数据报文的确认报文，所述第二数据报文的源设备为所述客户端设备或者所述服务器。

4.根据权利要求2所述的方法，其特征在于，所述首个TCP会话中的后续报文包括第三数据报文，所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测，包括：

所述防护设备发送并缓存所述第三数据报文；

如果所述第三数据报文满足重传条件，所述防护设备根据所述第一选项向所述第三数据报文的目的设备重新发送所述第三数据报文，所述第三数据报文的目的设备为所述客户端设备或者所述服务器。

5.根据权利要求4所述的方法，其特征在于，所述重传条件包括：所述防护设备未接收到针对数据报文的确认报文；或者，

所述第一选项为选择性确认SACK选项，所述重传条件包括：所述防护设备根据来自于数据报文的目的设备的SACK选项中的信息，确定数据报文发生丢包。

6.根据权利要求2至5中任一项所述的方法，其特征在于，所述第一握手报文为来自于所述客户端设备的同步序列编号SYN报文，所述第一握手报文的目的设备为所述服务器；或者，

所述第一握手报文为来自于所述服务器的同步序列编号确认SYN ACK报文，所述第一握手报文的目的设备为所述客户端设备。

7.根据权利要求1所述的方法，其特征在于，所述安全检测为防病毒AV检测，所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测，包括：

所述防护设备采用所述代理模式对所述首个TCP会话中的第四数据报文进行AV检测，所述第四数据报文为所述首个TCP会话中在所述第一数据报文之后传输的报文；

所述方法还包括：

如果所述防护设备对所述首个TCP会话中的第四数据报文进行AV检测的结果为不包含病毒，所述防护设备切换为流模式，并采用所述流模式针对所述首个TCP会话中所述第四数据报文之后传输的后续报文继续进行安全检测。

8.根据权利要求1所述的方法，其特征在于，所述防护设备采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测，包括：

所述防护设备采用所述代理模式对所述首个TCP会话中的第五数据报文进行检测，所述第五数据报文为所述首个TCP会话中在所述第一数据报文之后传输的报文；

所述方法还包括：

如果所述第五数据报文的应用层数据指示所述客户端设备与所述服务器将要在所述TCP会话中进行加密通信，所述防护设备切换为流模式，并采用所述流模式针对所述首个TCP会话中所述第五数据报文之后传输的后续报文继续进行安全检测。

9.一种防护设备，其特征在于，所述防护设备包括：

获取单元，用于获取客户端设备与服务器之间首个传输控制协议TCP会话中的第一数据报文，首个TCP会话为客户端设备与服务器之间建立的第一个的会话，所述防护设备部署于所述客户端设备与所述服务器之间；

处理单元，用于根据所述第一数据报文的应用层数据，识别所述第一数据报文的应用层协议类型；

所述处理单元，还用于确定所述应用层协议类型对应的检测模式为代理模式；

所述处理单元，还用于采用所述代理模式对所述首个TCP会话中的后续报文进行安全检测。

10.根据权利要求9所述的防护设备，其特征在于，

所述获取单元，还用于获取所述客户端设备与所述服务器之间传输的第一握手报文，所述第一握手报文用于创建所述首个TCP会话，所述第一握手报文包括第一选项以及第二选项，所述第一选项为所述防护设备支持的选项，所述第二选项为所述防护设备不支持的选项；

所述处理单元，还用于从所述第一握手报文删除所述第二选项，从而得到第二握手报文；

所述防护设备还包括发送单元，所述发送单元用于向所述第一握手报文的目的设备发送所述第二握手报文。

11.根据权利要求10所述的防护设备，其特征在于，所述首个TCP会话中的后续报文包括第二数据报文；

所述防护设备还包括接收单元和存储单元，所述接收单元用于接收所述第二数据报文，所述存储单元用于缓存所述第二数据报文；

所述处理单元，用于根据所述第一选项生成针对所述第二数据报文的确认报文；

所述发送单元，用于向所述第二数据报文的源设备发送针对所述第二数据报文的确认报文，所述第二数据报文的源设备为所述客户端设备或者所述服务器。

12.根据权利要求10所述的防护设备，其特征在于，所述首个TCP会话中的后续报文包括第三数据报文，所述发送单元，用于发送所述第三数据报文；

所述防护设备还包括存储单元，所述存储单元，用于缓存所述第三数据报文；

所述发送单元，还用于如果所述第三数据报文满足重传条件，根据所述第一选项向所述第三数据报文的目的设备重新发送所述第三数据报文，所述第三数据报文的目的设备为所述客户端设备或者所述服务器。

13.根据权利要求9所述的防护设备，其特征在于，所述安全检测为防病毒AV检测，所述处理单元，用于采用所述代理模式对所述首个TCP会话中的第四数据报文进行AV检测，所述第四数据报文为所述首个TCP会话中在所述第一数据报文之后传输的报文；

所述处理单元，还用于如果对所述首个TCP会话中的第四数据报文进行AV检测的结果为不包含病毒，切换为流模式，并采用所述流模式针对所述首个TCP会话中所述第四数据报文之后传输的后续报文继续进行安全检测。

14.根据权利要求9所述的防护设备，其特征在于，

所述处理单元，用于采用所述代理模式对所述首个TCP会话中的第五数据报文进行检测，所述第五数据报文为所述首个TCP会话中在所述第一数据报文之后传输的报文；

所述处理单元，还用于如果所述第五数据报文的应用层数据指示所述客户端设备与所述服务器将要在所述TCP会话中进行加密通信，切换为流模式，并采用所述流模式针对所述首个TCP会话中所述第五数据报文之后传输的后续报文继续进行安全检测。

15.一种防护设备，其特征在于，所述防护设备包括处理器和通信接口，所述处理器用于执行程序代码，使得所述防护设备执行如权利要求1至权利要求8中任一项所述的方法，所述通信接口用于接收或发送报文。

Images