我们把 GitHub 上的流量分析工具都装了一遍

参赛选手

我们找了 GitHub 上和 sFlow、NetFlow、IPFIX 有关、星数靠前的项目。有的是完整产品，有的只是采集器，有的已经归档。星数是 GitHub 页面上的数字。

第一项：从下载到第一张图

这是我们最在意的一项。网工下午三点接到“出口跑满了，看看是谁”，没有人想先学 Kafka。下面是各家从零到能看图的步骤，按官方文档最短路径数：

traffic66 第一次启动后用 admin / traffic66 登录，登录后先改一个自己的密码。Windows 上双击 traffic66.exe 就自动打开浏览器。想先看效果，traffic66 demo 会造一个模拟公司网络，带一天历史数据和一次完整的攻击过程。

顺带一提，Windows。表里的项目基本只跑在 Linux 或 Docker 上。traffic66 的 Windows、Linux、macOS 是同一份代码编出来的原生程序，不用 WSL，也不用 Docker。很多中小单位的网管机就是一台 Windows。

第二项：数字能不能和设备计数器对上

流量工具最常被问的问题：图上说出口 800M，Zabbix 里 SNMP 取的是 600M，到底信哪个？

流量数字本来就是估算值：采样到的包乘以采样率。traffic66 专门做了一页接口对账，把每个接口的流量估算和设备自己的计数器（sFlow 计数器或 SNMP）画在同一张图上，算出偏差和采样本身的统计误差。偏差超出误差范围，会直接写出最可能的原因：有接口没开采样、同一份流量在两个口各采了一次、导出包在路上丢了，或者采样率还没收到。

为了让数字对得上，后台还做了几件不显眼的事：用设备实际生效的采样率；采样率没到之前先扣住记录，不按 1:1 乱算；补偿导出时丢掉的包；把长流按持续时间摊到每一分钟；给 NetFlow 字节数补上以太网开销，因为接口计数器是算它的。

对手们在这件事上做到哪一步：

接口计数器在别家要么不读，要么是另一张图，摆在那里让你自己比。把“对不上的原因”写成结论的，我们没找到第二家。

第三项：打开就有结论，不用先学查询语言

概览页回答“现在多少、谁在用、和昨天比怎么样”。每个地址、端口、应用、国家都能点：只看它、排除它、看它的流记录、看它的详情页。整个界面的设计目标是让人尽量不用打字。

同一件事，对手们的界面：

第四项：攻击能不能在采样数据里找到

采样数据做安全检测是出了名的难：1:4096 的采样下，一次扫描可能只剩几个包。traffic66 的检测规则按采样后的数据重新校过阈值，演示环境里的整条攻击链都能找出来：内网扫描、端口扫描、暴力破解、横向移动、向陌生地址的大量上传，再加上威胁情报命中。同时，一天的正常流量里除了互联网上的扫描器敲网站，不出别的误报。

这一项要说实话：

所以安全这一项，我们和 ntopng 是同一档。我们的优势在于：这些检测在一个程序里、不用额外配置，而且专门针对采样数据调过。

还有一个顺手的功能：traffic66 a.pcap b.pcapng 直接分析抓包文件，和实时数据分开存放，Ctrl+C 退出时自动删除导入的数据。ntopng 也能读 pcap，这一项算打平。

总成绩单

把上面几项和后面要说的弱项放在一张表里。实心是做到了，半个是部分做到或要付费、要另装，空心是没有。

前八行里，traffic66 每一行都是实心；八行全实心的，表里只有这一列。后三行是我们的短板，下一节细说。

别人做得更好的地方

选工具之前，请认真看这一节。

怎么选

我们有把握的是三件事：装得快、看得懂、数字对得上。其他几项，欢迎来 GitHub 提 issue，把差距一项一项缩小。