网络流量处理中的协议解析:流量处理模型

这里所说的网络流量处理，包括常说的IDS，IPS，NTA, NDR，XDR，DPI，网络行为审计，防火墙之类需要在数据包层面对流量进行判断审计之类的操作。如果只需要简单的处理比如流量统计，那只需要++就行了。如果要做更准确深入的分析判断，就得需要对这些数据解码。从IP TCP 一直到应用层如SMTP。要针对SMTP的协议内容作出判断分析审计，就需要解析SMTP协议。

IDS，IPS等流量处理引擎各有不同的侧重点，所以对协议解析的要求也各不相同，但大概来说，完整，准确，详细地提取出协议中的字段，比如邮件的标题，收件人，发件人是更好的。解析提取的实现方式也各有各的办法，但解析部分的实现方式会受到流量处理模型的影响。这里把协议解析的实现建立在通常的处理模型之上。所以先简单描述一下这个处理模型。可能有其他处理模型，那这里讨论的协议解析方式有可能不适用。通常，流量处理模型分为以下几个部分,每抓到一个数据包，就会逐个功能调用一遍，也就是数据包会逐次经过每个模块，每个模块被数据包触发。

抓包

从系统中获取到数据包。性能之类这里不关心。这里只关心获取到的数据包是网络层的，它是零散的单个的ip包，它不会为协议解析提供什么方便，除非你只基于单个包解析。这部分虽然实现了从无到有的数据包获取，解决了根本关键问题。但它只提供了一个简单的视角：一个个的数据包，随机的，混乱的，毫无顺序的，甚至是被破坏了的和错误的数据包。

解码

这个解码仅限于TCP/IP的头解码，还没到我们要说的应用层协议解析。因为上一个抓包功能提供的数据包仅仅是原始数据，也就是一个buff，并没有结构信息。为此，需要解析TCP/IP。至少得知道源目的IP端口五元祖等信息。

流表

有了数据包的TCP/IP信息，流表把单个的数据包按照链接进行分类，属于同一链接的数据包都关联到同一个链接节点上。这个节点上可以保存本链接的相关信息。比如每条链接有多少个数据包。流表就是一个可以用五元祖来确定唯一节点的hash表。每随机到来一个包，就根据这个包的IP端口五元祖来找到对应的hash节点，这个节点上会记录着此链接相关的数据，比如数据包统计。总不能把A链接的数据包算到B链接的头上，如果这样，那A B链接所在的手机会有流量统计错误，不止协议解析会出错，连钱就会出错。数据包经过流表的处理后，就具备了链接这个视角。

协议识别

协议识别可以判断一条链接是什么协议。是邮件还是网页还是。这个功能内部很复杂，但它对外输出很简单：就是在一条链接上打一个标签。因为有了流表的支持，它不需要在每个数据包上标记协议类型，它只需要在流表的链接节点上标记即可。协议解析也依赖这个标记，只有标记了是SMTP，才能开始按照SMTP协议来解析。否则无从下手。不过实际情况协议解析和协议识别可能并非完全的先后关系，协议识别也可能依赖协议解析之后的内容进行判断。比如：识别出是HTTP协议，进入HTTP解析，提取出HTTP头的URI字段。URI字段内容再次进入协议识别模块，进一步判断出这条链接是基于HTTP协议的聊天应用。不过这里先不关注这些内容，我们只关注协议解析过程。

现在，已经得到了协议解析所需要的基本条件。这条链接可以进入协议解析模块开始解析了。如果是SMTP协议，就在这条流上按照SMTP协议规范解析。如果是POP协议，就按照POP协议规范解析…