最近一两年间，研究网络流量分析的各种流派，都殊途同归到“全流量”这个方向。你也全流量我也全流量，但究竟什么是全流量，大家不是语焉不详就是讳莫如深。更有甚者，拿开源IDS引擎来直接充当全流量，就像“人工智能”一样，兀自念了一个咒语，就能鸡犬升天。让人不能不感慨，一个IDS的时代结束了，这个时代的人还活着——这是一件很残酷、却很常见的事。
流量，顾名思义，即流淌于网络中的各种数据。全，则是全部的意思。放在一起，望文生义来说就是网络中全部的数据。用小学生的视角去看，与“全”对应的就是“部分”。使用过众多流量分析工具的各位都知晓，大部分工具输入的就是全部网络流量，那这个被大家集体鄙视的“部分”又从何而来？
PART1
全从何来
我们不妨直接去看故事的结尾，安全管理和维护人员，最常遇到的用户对网络的反馈。
反馈1：今天我电脑被勒索了，是不是从网络来的，你花钱买的安全设备为什么没防住，明天就开除你！
反馈2：昨天下午四点钟，这网络慢死了，你告诉我为什么？我花了这么多钱买带宽，买设备，以后不能这样了！
不切身走到一线，很难体会网络安全和维护工程师，此时面对一堆安全设备告警和网管软件流量曲线的无奈感。用户对网络的要求究竟是什么，问题又到底出在哪里？
PART2
全流量何以可能
2.空间维度
在传统分层结构的网络架构中，由于出口网关、骨干路由器、核心交换机和汇聚交换机等设备的存在，要提取网络中的流量，在物理结构上相对容易。在网络出口镜像或者分光，可以解决南北向数据提取的问题，在核心交换机的镜像功能则可以解决绝大部分的东西向流量采集。
随着5G和云网络技术的普及，一切都发生了根本性改变。绝大多数的政企网络已经完成或正在经历从单一园区网，向移动化、多分支化和云化的迈进。一个总部、多个云、众多分支和移动办公的普及，已经变成了网络管理人员所要面临的常态。单点镜像分光能解决的问题，已经退化到了只能解决为数很少的骨干网节点，其他位置已经失去了基本的存在可能。在这种网络结构下，多分支多点逐跳采集、云南北向采集、云东西向采集和移动端数据采集，就成了当前全流量采集首先要面对的基础问题。
3.成本维度
以我们多年研究网络原始流量的经验来看，一个经验丰富的数据分析师，在配有较为强大的数据分析工具前提下，一天能处理的原始数据量达到1TB就是极限。换句话说，1Gb链路一天产生的流量，如果要做到同步分析，需要10个有经验的分析师才能在滞后一天完成。与看起来高昂的存储成本相比，这才是全流量所要面对的最大成本——你会被淹死在数据的海洋里！
PART3
三个境界
铺陈许多，现在就来解剖一个全流量系统的逻辑模块，来阐述全流量系统的境界差异。从逻辑结构上，可以将任意一个全流量系统拆分为采集、预处理、在线分析、数据包存储、离线分析五个部分，通过一张图来展示如下。
与传统的单点分层网络结构相比，云化多分支的网络结构有了比较大的变化，整个云化分支网络的六大采集点包括：总部网络出口、分支网络出口、数据中心出口、云网络南北向出口、云东西向流量和移动用户接入数据。要实现真正的“全流量”采集，就需要覆盖到以上的所有采集点，这种情况下，需要各种实体和虚拟化探针的加持才能完成。
采集后的流量需要先进入预处理引擎，预处理引擎再根据规则丢弃一些流量。丢弃多少流量，丢弃哪些流量，取决于在线分析引擎的实际输入需求，也取决于预处理引擎的分析能力。预处理引擎对性能要求高，一般采用ASIC、FPGA、DPU/SmartNIC和DPDK/eBPF等技术架构简单过滤方式，比如：根据IP地址、端口丢弃包，剩下的部分流量穿透到在线分析引擎。
在线分析引擎接收预处理引擎给到的流量，并根据分析目标的不同将所有流量生成不同种类的摘要，然后将生成的摘要作为索引送到数据包存储引擎。后续再根据索引做分析，每个索引种类会对应不同的全流量设备。常见的摘要类型包括：告警、会话、文件和元数据。IDS、IPS、WAF、SoC等产品对应的索引是告警；NPM、流分析、溯源、威胁情报和DDoS等产品则使用会话作为处理依据和索引；防病毒、APT、内容审计类的全流量分析，则更多依赖的是还原的文件。元数据本质上是更高一个维度的索引储备，在生成的那一刻只是代表未来可能会要求被快速提供，并不即刻就对应一个结果。例如：HTTP协议的UserAgent字段元数据，经常会被用来事后追溯一种特殊的HTTP客户端，用于离线分析，但是在生成提取的时候并没有确切的结果。
数据包存储是全流量分析的重要组成部分，与传统的数据分析不同的是，全流量数据存储需要存储原始数据报文。1Gb带宽的实时流量，每天就会产生10TB的原始数据包。面对海量数据的存储，对数据库的选择、数据的区分、索引的创建、内存的分配、文件格式、缓存以及中间表都有更高的要求。最终所有的数据组成大的存储矩阵，为了方便提取，优秀的索引管理也就尤为重要。
离线分析引擎的主要针对已经存储好数据包内容和索引进行分析和处理，需要有丰富的进一步深度解码数据包、报表和分析模型创建能力。为了保障分析的准确性，离线分析引擎可以根据原始数据进一步更新索引表内容，例如以一个新解析的元数据类型重构索引，同时还需要具备文件还原、数据重放、场景回滚等能力。离线分析引擎还需要提供对外接口，用于和其它产品或数据库对接，常见的比如Hadoop原始文件接口、Kafka消息接口等。
要量化的评价一个全流量系统基础能力，可以有三个参数，或说是全流量的三个境界：
境界一：输入全部（C0=1）：拥有俯视一个已完成云化和多分支化的网络的能力，在任何时刻都可以按需完成对其中云化多分支六大采集点的流量采集和回传，是全流量的第一个目标。能采集的流量和要害节点总流量的比例，就是评价系统能力的第一个参数C0。C0的取值范围为[0,1]，越接近1，说明采集输入的能力越强。
境界二：分析全部（C1=1）：任何品类的在线分析引擎，在物理硬件限制下都有两个确定参数：生成摘要的种类和最大处理能力。基于摘要的种类和处理能力，可以反推预处理引擎需要基于哪些规则，来丢弃不处理的流量。被预处理引擎保留不丢弃的流量和输入预处理引擎的总流量的比例，是评价系统能力的第二个参数C1。C1的取值范围为[0,1]，越接近1，说明在线分析引擎的性能越强劲，需要预处理引擎干预的越少。
境界三：记录全部（C2=1）：基于在线分析引擎建立的摘要，指令数据包存储引擎来保存哪些原始数据包。同时，这个记录的能力受限于存储管理模块的性能和硬件设备的写入瓶颈。所有记录的原始数据，都必须是基于摘要可回溯的。实际存储的原始数据包流量和发送到在线分析引擎的流量比例，是评价系统能力的第三个参数C2。C2的取值范围为[0,1]，越接近1，说明记录和回溯原始数据的能力越强。
PART4
未来到哪里去
在上一章里提到的C0值，理论上C0=1最佳，但是要在现网中实现园区出口、企业出口、政府出口、云南北向出口、云东西向流量等等点位的采集，面临着极大的挑战。当离散的采集点过多时，探针成本问题、专线成本问题、数据分析问题会接踵而至。
探针成本的问题，不仅来自于部署探针点位的多少，更在于各类数据分析产品的探针无法通用，导致探针存在重叠部署。探针采集到的全量数据回传至总部，需要大量的网络带宽，所以带宽成本也高居不下。假设预算充足，以上问题均已得到有效解决，但是从海量的数据中提取有价值的信息堪比大海捞针。因此，所有流量采集点部署全部的检测能力并全部回传，从来都是一个永远不可完成的任务。
从上一章可以得出，用户的实际场景需求决定了预处理的需求，也决定了C1值的大小。因此流量预处理的判断精度要实现三层到应用层的转变，仅仅依靠IP、端口等方式进行筛选难以完成此重任。举例说明：例如用户使用的是WAF产品，在预处理过程中则可以丢弃所有非Web访问，但是有大量非80/443端口的Web流量，不能用依据端口的规则进行丢弃，要细化到应用级别。再例如用户使用的是APT产品，需要在已知流量中寻找异常，丢弃是不允许的，比如有未知协议使用53端口，如果依据端口规则直接丢弃，则会失去对异常流量的判断能力。如果面对海量的数据输入时，可以通过增加硬件，集群化部署来缓解预处理引擎的压力，拥有云原生的横向扩展能力，而不是简单地使用ASIC、FPGA等应用层处理能力低下的快速筛选。
全流量分析产品的在线分析引擎，首先要保证强大的处理性能，其次是保证数据分析的全量。在线分析引擎要基于会话或是元数据创建索引，同时又兼容文件、告警等多种交叉索引方式，真正实现C2=1。在线分析引擎每多一种索引，就增加一个网络分析的维度，同时也加大一次引擎的性能消耗，如何在索引和性能之间取得更好的折中是在线分析的最大难题之一。简单如Netflow，复杂如几千种元数据的实时采集建模。索引的选取，直接决定了最终的产品类型，交叉索引则产生更有戏剧性的结果，比如最近颇为流行的APT分析产品。在实时展示方面，要设置丰富的筛选条件，支持多级的数据检索能力，同时保障元数据快速的检索能力。
在线分析引擎的传统硬件部署方式，虽然可以解决流量吞吐问题，但是灵活性较差。为了更好地适应网络的发展，其一定要具备云原生的弹性扩展能力。在公有云、私有云以及混合云市场蒸蒸日上的大环境下，和在线分析引擎本身一样，探针和数据库也需要具备云原生弹性扩展能力。
经过在线分析引擎输出的数据随时有可能会被用户读取，如果采用随机存储的方式，那么对于用户读取数据来说，会变得相当困难。
【举例说明：以开头的故事为例，运维人员想要快速查询“昨天下午14:00-14:30之间，A分支至总部的视频会议时延超过300ms的会话有哪些”。】
面对这样的多纬度分组聚合查询，需要有很多方面的优化，比如：
对采集的数据进行时序存储，并采用固定块大小，固定文件个数，轮询覆盖最老文件，减少硬盘存储碎片。
通过内存进行原始数据压缩，减少硬盘存储文件的数量，达到存储性能提升的目的，并且使用内存进行数据压缩，并不会消耗太多性能，毕竟压缩文件是内存的强项。
将元数据与原始数据包的分级存储，元数据存在SSD上面，原始数据包存在机械硬盘上面。以此保证索引信息的快速查询，又不会因为原始数据包过多，造成用户硬盘存储成本的增加。
对海量的数据处理，对大表建立索引是必行的，建立索引要考虑到具体情况，例如针对大表的分组、排序等字段，都要建立相应索引，一般还可以建立复合索引。
如果是对云南北向出口或是云东西向的流量进行存储时，为了减少中间链路的传输压力，原始数据的存储将会放到云端，因此，数据包存储引擎也必须支持云化的弹性部署。
除了存储方式的优化，该部分还要具备原始数据包的回放能力，被回放的数据一般会用于对接第三方的安全产品。数据回放可以复原当时网络的真实情况，方便运维人员对故障或是安全事件的分析。
所谓大隐隐于市，异常的通信内容隐蔽伪装在常用协议中，是很多恶意应用的常用手段。离线分析引擎需要对已经识别的协议，根据协议、目标去向、域名、URL、DNS请求、用户身份、地理位置、UA等元数据，建立数据仓库，然后再根据它们的波动、差分、排序等统计规律寻找异常变化，最后对锁定的异常变化会话数据进行深度的原始数据分析，就会到很多问题的答案。
通常情况下，被在线分析引擎确定为未知的协议数据有三种：小众协议、已知协议数据的漏识别以及广泛使用的非正常协议。在离线引擎中，可以利用同目标其他识别结果的交叉校验，排除大量已知协议数据情况，然后再结合交叉地理位置、使用频度等情况，剩余的小众协议和广泛使用的非正常协议就会快速的浮出水面。值得一提的是，两种协议分别是APT类未知威胁发现和黑产类未知威胁发现的重点分析目标。
PART5
选择需要慧眼
在现实中，并不存在一个“完美”的全流量系统。前述C0、C1、C2和索引的选择，可以用于评价一个全流量系统的目标和现实水平。
从采集完整度讲，C0=1是理想目标，但其面临的是六大离散的采集点的复杂度，成本和管理复杂度都是大问题，C0值需要根据具体任务目标灵活设定。例如：只是监控和保护服务器，C0=0.15就是可以接受的选择，而如果目标是全网态势感知，监控全部分支内外通信，则C0必须大于0.8以上，否则从数据样本就已满盘皆输。困扰大部分全流量系统的是在线分析引擎的性能，而C1决定的预处理引擎，可以极大消减输入的数据数量。C1的取值某种程度上体现出对在线分析引擎能力的信心，但是依据任务不同，的确有很多的流量是可以不用注入在线分析引擎。例如：对WAF来说，非HTTP/HTTPS的流量就是无谓的性能浪费。C2越大，则意味着原始痕迹越多，离线分析引擎进行再贴标签和回滚问题的几率越大。
诚然，世界上并没有绝对完美的全流量产品，但是全流量产品的种类会越来越丰富，与用户网络的结合度也会越来越高。自己定义的目标，决定了全流量产品选择的优劣。大多数人都是又懒又蠢的，只要稍微用点心，稍微努力点，就能比大多数人做得更好一点。为了不和又蠢又懒的人为伍，大家在定义自己想要的全流量系统时，可以问自己四个问题：