UTM上的应用层安全功能很多，通过“对症下药”我们知道，检测是关键和难点。在实施多种应用层安全功能时，对数据进行全面的、精确的协议分析是确保高安全能力、高性能的前提条件。

    一般的协议类型识别方法是利用RFC规定的协议默认端口来判断协议的类型，然而这种方法的准确性并不高，因此需要通过增加对后续数据报文内容的分析来综合判断协议类型，同时在底层平台中设计相应的处理机制，以支持对协议类型的综合判断。在TCP/IP网络结构下，应用层的数据报文主要基于UDP和TCP两种传输层之上，下面进行关键技术讨论。

    1）UDP数据

    在平台的性能和实际应用中，对于没有上下文信息的数据，比如IP分片、IP数据和UDP数据等，采用优先级按照插件优先级的顺序进行调用，根据高优先级的插件的返回结果决定当前数据是否提交低优先级的插件处理。例如，如果存在两个不同的IP层数据处理插件IPP1、IPP2，分别赋予两个插件优先级1，2。当监控平台捕获网络数据包A的时候，平台首先调用优先级最高的插件IPP1，如果IPP1处理完成后返回PASS指令，则将当前数据包继续提交插件IPP2，如果IPP1处理完成后返回的指令是DROP，则抛弃当前的数据包，不再提交优先级较低的IPP2处理。这种方式可以有效地避免同一数据包的重复处理，可以有效地提高系统的整体性能。

    2）TCP数据

    针对有上下文连接信息的TCP数据，采用竞争连接控制权的方式来决定处理插件。相对于网络层的协议而言，应用层的协议没有统一的表示来表明协议的类型。

    目前，除了少数的协议（如：DNS和SMTP协议）可以通过TCP连接的目的端口判定以外，其他的协议均可以变换连接的端口，比如HTTP协议虽然在RFC规定默认情况下使用80端口，但在实际应用中，可以见到大量的网站采用其他端口，比如说1080、8080等。

    因此，对于应用层协议的判定，有必要通过对数据内容进行分析来进行协议识别。但是应用层协议种类繁多、内容复杂、并且更新很快，而通过平台统一完成应用层协议的识别既复杂又降低了平台的通用性和可扩展性，因此可将具体协议的识别交给进行相应协议处理的插件去完成，如图5所示，每个数据报文按自上而下的顺序依次传递给各插件进行处理。

    图5 插件的组织结构

    当底层平台捕获一个TCP连接的建立信息，平台将这个连接建立的信息提交所有的TCP协议处理插件进行处理，每个插件的处理过程如图2-8所示。所有的插件都必须对当前连接的内容进行处理，判定当前连接的类型是否是自己所能处理的协议。

    如果不是，则通过平台提供的函数DROP_ME通知平台放弃当前连接的处理权；如果插件识别出当前连接的协议和他所能处理的协议吻合，插件通过函数KEEP_ME通知平台宣称自己对于当前连接的处理控制权；而对于那些根据当前信息还不能进行有效判断的功能插件，则可以使用函数PEND_ME通知平台将自己挂在当前连接上等待进一步更多的数据到来再完成有效的判断。

    这样，通过不断到达的数据包驱动上述过程，可以找到当前连接的处理插件或者所有的插件均放弃对于当前连接的处理权。如果找到了当前连接的处理插件平台，则需要通知调用了PEND_ME的插件释放对于当前连接的控制并完成现场销毁。

    由于可能出现在同一TCP连接中包含多个应用层协议的问题，比如说使用SOCKS代理进行HTTP访问的TCP连接，连接的前一部分是SOCKS协议，而连接的后一个部分则为标准的HTTP协议，所以平台提供函数RESTORE_ME函数允许插件在完成协议分析以后将连接控制权交还给平台，使平台重新选择当前连接的处理插件。对于一个TCP连接，平台的状态转换也如图6所示。

    图6 插件的处理过程

    这种方法给出了一种协议类型识别及内容分析的实现机制，它使得底层平台具有良好的通用性和可扩展性。