流量分流脚本（4）

2017/04/21
我得怎么把这个程序的机构进行更新下。现在的流量已经不行了，就是里面掺杂了太多的那种巨型帧，
包括252上捕捉的，还有241上自己运行的。
（这部分，后续在进行出来，就是后续重新捕捉新的包的时候。）

---

程序功能构想
1）Tcp握手
最后生成的流结果，Tcp握手部分应该直接就去除掉。
2）Tcp释放
这部分没必要非得就清楚掉，可以进行保留。
3）对于不完整的流
一些没有开始握手信息的流，必须进行去除。
也就是这部分流不与考虑。
这就需要有一个过滤器，刚刚看了看dpkt部分的源码，发现这部分的内容并没有怎么写，估计这部分功能应该是没有实现。
看来我需要自己写了。
当然这部分，一旦写了，肯定会增加一部分的处理时间。
4）只分析TCP流
包括上面的，现在可以把前两个握手的包都去掉。
*后续的话，有时候是实时分类的话，可以直接就把分类好的，进行处理，而不是仍然占据着内存。
5）哈希表
本来想，如果可以将双向流，两种不同的东西，都hash到同一个位置，就最好了。
然后自己想的是，分别对字符串两边进行hash，（因为，反向的流，字符串中间对称过来，就是正向的了。）
然后两个数值直接相加，但我突然觉可能会导致冲突。就没敢使用。
如果是能够证明，不会出错，那么就是非常好了。
也不用那么多乱七八糟的判断了，简直神器了。

---

目前的哈希表还是把两个都HASH了进行，数组大小为1000，处理一个G的文件，时间控制在3分钟左右，还可以接受。

---

程序结构构想
1）为了加快速度，可以在处理数据包的时候，使用多线程。
过滤包的部分可以用多线程实现。
如果是使用过多线程的话，怎么协调各个流的关系？！
操作一个数据的时候肯定要将其加锁。
开始想边读取文件，边进行报文处理，但如果是仅仅将流量报文读取到列表中，只需12秒。
（多线程的思路，还不算是太完整，目前还没有加入，后续在说吧。）

---

这个版本，对于分流的部分已经完成了，但是关键的是，处理大文件的时候。
跟第三个版本的相比，同样处理这个文件，第三个版本要用4分钟，这个版本用3分钟。
而且，同流双向的在一起。
（修改后，速度还是算可以。）
版本4

0315_

测试0315_，8000多个流（此流为从包含握手信息开始的）
版本3

Version3

共5W多个流，不同方向的放在不同位置。这次还算速度快的。
而且包括不握手的。

---

这部分的流统计，可能是不可信的，必须后期增加这部分的可信度。

---

一些判断的时候，有些流很短，可能根本没有S2C方向的东西。
所以必须吧这个问题考虑到，不然计算方差的时候就会出错。

计算空数组的时候

---

通过一个过滤器，发现如果使用了过滤器最后的时间增加了。
主要那部分的过滤器的确需要一部分时间。
增加的时间不到1S，还是可以接受的。

增加过滤器

主要增加了之后，后续的处理，就不用那么麻烦的判断了。
对于一些大文件，最后分配到hash表的基本就满了，而比较小文件最后的内存大小就变了。
另外，就是那个有些流没什么用的。
所以说，实质上这个分流的部分还是不够完善