SNMP与RMON
基于 SNMP的流量信息采集的核心思想是在每个网络节点上存放一个管理信息库 (Manage— ment Information Base，MIB)，并由节点上的代理 Agent负责维护 ，管理站中的网络管理系统 (Network Management System，NMS)通过应用层协议对这些信息库进行统一管理。 基于SNMP的流量分析就是通过SNMP协议访问设备获取MIB库中的端口流量信息，典型工具有MRTG。
- 缺点：
- 在大型的网络中，轮询会产生巨大的网络管理通信量，因而导致通信拥挤情况的发生
- MRTG的功能比较单一，其收集到的流量信息仅是简单的端口出、入流量统计信息，不能深入分析包的类型、流向等信息。
远程网络监控 (Remote Network Monitoring， RMON)是为了解决 SNMP协议在日益扩大的分布式网络中的局限性所提出的。但这种方式受网络设备资源限制，一般不能获取RMON MIB的所有数据，大多数只收集统计量、历史、告警、事件等四个组的信息。
sFlow
sFlow采用数据流随机采样技术， 可提供完整的第二层到第四层，甚至全网络范围内的流量信息，可以适应超大网络流量（10Gbit/s 左右）环境下的流量分析，让用户详细、实时地分析网络传输流的性能、 趋势和存在的问题。sFlow 使用两种独立的采样方法来获取数据：针对交换数据流基于数据包统计的采样方法和针对网络接口统计
数据基于时间的采样方法。
工作原理：sFlow 监 控 系 统 包 括 sFlow 代 理 、sFlow 数 据 采 集 器 或 sFlow 分 析 器 。sFlow 代理通常为硬件芯片 ， 内嵌到路由器或交换机中，通过统计采样技术获取流量信息形成 sFlow 数据包， 并立即发送给 sFlow 分析器进行流量分析。
-
优点：
- 成本低廉
- 能在没有消耗额外资源的环境监测万兆网络，不会带来新的网络冲突
-
缺点：
-
随机采样，我们需要的是精准流量的统计 ，所以直接否定
-
只有少数厂商部分型号的交换机支持
-
Netflow
NetFlow被用于网络设备对数据交换进行加速 ，并可同步实现对高速转发的IP数据流进行测量和统计。NetFlow的收集器负责解析来自采集器的数据报文 ，依据模板进行处理 ，提取出流记录信息 ，然后存储到数据库中，数据收集的过程比较简单 ，关键是收集器必须有模板 ，所以采集器在发送 NetFlow报文前 ，需要先将模板发送给收集器 ，使收集器能够依据模板正确处理 NetFlow报文中的流信息 。捕获到原始网络流量后，提取相应信息按自定义模板封装成 NetFlow报文 ，以UDP包的形式不断发送给收集器。
NetFlow数据采集系统
- 优点：根据模板采集，如果模板的7个关键域(SIp，DIp，SPort，DPort等)都匹配，则视为一个流，对原始记录进行自动汇聚后输出统计结果。 然后存储到数据库中，为进一步流量分析提供数据支持
- 缺点：
- 对于大规模的系统，需要配置多个采集器
- 只能实时处理10Gbit/s 主干网络信道的流量（参考论文）
- 采集器调用pcap库抓包，然后Pcap_thread线程调用系统库函数从数据链路层进行抓包，需要用户态和内核态的切换
NetStream
NetStream与NetFlow类似，是一种对网络中的业务流量进行统计和分析的技术。NetStream技术基于“流”提供报文统计功能，可以对网络设备的每个端口上出入方向的流量进行采样，对采样到的报文依据报文中的关键值（比如源IP地址、目的IP地址、源端口号、目的端口号等）对网络中的流量进行分类统计，还可以对统计到的数据进行过滤和聚合。当然也可以定制特定的模板，根据模板对网络中的流量进行分类统计。
- 优点：NetStream就像NetFlow一样，基于七个条件定义了一个流，因此具有相同7元组信息的数据包被标记为一个流。
- 缺点：
- 对数据包进行采样
- NetStream功能是需要交换机预留缓存空间存储NetStream流
Ntopng
Ntopng是Ntop的替代版本，去掉了一些拖沓冗长的功能，同时新增了网络流量实时监控功能，并将各个功能进行重新梳理和整合，使整个流量展示更加智能化和合理化。Ntopng使用Redis键值服务按时间序列存储统计信息，通过这种方式实现了流量状态实时展示。
- 优点：
- 以图形的方式动态展示流量状态
- 实时监控网络数据并实时汇总
- 以矩阵图的方式显示IP流量
- 支持历史流量数据分析
- 方案更成熟，网络相关指标更全面
- 缺点：
- 在高速网络环境(基于libpcap，阶级局限性，PF_RING-ZC下10G+，参考文章)下有丢包的现象
- 不能满足实时性要求，因为以RRD格式存储磁盘持久流量统计信息，做查询时，需要先做ETL处理，再加载到数据仓库中，对外提供查询服务，不能满足实时查询的要求
- 查询效率低下，响应速度慢
- ntopng部分核心组件闭源
Ntopng架构
Ntopng底层使用Libpcap和PF_RING来抓包，对数据包进行处理。相比于Libpcap，PF_RING是技术的革新，他提出的核心解决方案便是减少报文在传输过程中的拷贝次数。
以上技术的小结：
以上技术，SNMP和RMON不能采集到IP信息；sFlow和NetStream都是采用随机采样，不能够精确分析；NetFlow和Ntopng都基于libpcap，在高速网络环境下容易丢包。
libpcap的流程：数据包通过路径为网卡硬中断→软中断→内核协议栈→系统调用→socket→->libpcap接口→用户应用程序，在这个传输过程中sk_buff结构的多次拷贝，且涉及到用户态和内核态的反复切换，所以在高速率下使用libpcap抓包丢包严重也不用感到奇怪了。
PF_RING：最新技术是PF_RING-ZC，传统的数据包捕获方式（libpcap）会进行两次数据包拷贝，PF_RING从采用mmap()将环形缓冲区映射至用户空间，实现了只有一次拷贝。而PF_RING-ZC更是将PF_RING的一次拷贝也省去，达到了零拷贝的目的。(参考自DPDK，PF_RING对比)
但PF_RING-ZC有一个缺点：应用可以在某个时间打开DMA ring（注意，现在的网卡可以具有多个RX / TX队列，从而就可以在每个队列上同时运行一个应用程序），换而言之，用户态的多个应用需要彼此沟通才能分发数据包。
DPDK
PF_RING-ZC和DPDK均可以实现数据包的零拷贝，两者均旁路了内核，但是实现原理略有不同。PF_RING-ZC通过ZC驱动（也在应用层）接管数据包，DPDK基于UIO实现。
除此之外，DPDK还有以下优势：
- 支持轮询收包的网卡驱动
- 绑定CPU：允许轮询进程绑定CPU利用全部资源收一个队列的包，避免被调度和加锁
- 大页内存：快速命中充分利用TLB
- NUMA架构下限制使用远端内存
- 内存对齐
- DPDK开源免费
关于DPDK具体的介绍见这篇文章，DPDK在某些基准测试中比PF_RING快1-2％（参考自ntop官网，PF_RING-ZC VS DPDK）
网友评论