流量分流脚本（2）（3）

2017/04/21
第二个版本修改的部分。
1）原来的查到流是遍历数组，这次换一种方式，就用哈希吧。
这里有一个关键的问题，那就是，怎么样把两个不同的流hash到同一个位置。
上面这个问题，最开始的时候没有考虑到，结果导致结果成为了单项流。不过就这样吧，就当单向流来处理。（目前来说）
2）更新了数据流的结构，
原来是只有stream一个结构，包含了报文和流。
这次是报文和流分开。分为Message和Flow这两个。
不过，总觉得多此一举了。（我也不清楚）
3）单向流数据结果

单向流

4）有一点需要注意，必须吧VNC那部分的流量屏蔽掉，那部分的方差太大了。导致整个图像不清晰。

调整像素后

5）现在这种状况其实是好事
就是的却能看到出来这些像素点都分布开了。
但是，我现在要试试，就是标记下，HTTP的到底在哪。
简单的利用端口进行标记：

标记后的

蓝色的为https、黄色的为http。
不过，也有一个比较尴尬的问题那就是，本身这个数据集就不太好，本身掺杂的流量类型就不多。
这样就导致无法直接关联了。
可能数据集太小了，我试试那个大的。
6）数据集大的就容易出现各种情况
比如刚才这个莫名其妙就崩溃了，现在也没找到原因，这就很尴尬，
这部分原因就是有些报文时ip的分片包，不知道现在的这些流量还会不会有这种问题。
还有一个问题就是原来说的，tcp重组？！需不需要我来处理？！
Tcp充足就是到来的包的顺序不是一个接一个的，需要为上层把数据的顺序排好。
（这些细碎的内容我觉得，还是需要好好的理解下。）
（就是从小的地方做起）
还是需要优化下这个程序结构。
不过，我的确感觉应该将这个程序结构好好改一下。
现在1个G的文件跑的时间太久了。

252-0315_

仔细看看，是不是有特征呢？！

各个方向

（上面是我把各个方向，就是S2C、C2S方向单独单独进行了标记）

感觉，还是有一部分的内容重叠在了左下角。
这个里面的流尴尬的地方，就是这是单向流，最起码双倍了结果。
（就是这里面很多流是重复的。）
7）包长很长
这部分，怎么处理。
如果是就找最大MSS来进行分的话，分出来的包，包长均值和方差肯定会不同的。
（就是不能直接做这部分的操作）

---

（3）
本版本仅仅修改了读取的文件，加入了计时功能。

---

不过，我真的觉得，应该好好的把这部分的程序结构好好组织一下。

---