抓包工具

抓包工具:顾名思义、耳熟能详。tcpdump、wireshark、sniffsmart、httpwatch(还算有点良心)。。。

但当其只是当为工具使用时,又贵为可惜。因工作需要,再度涉及该领域。

可随想云随风去,江河大变。某某文公司镜像工具,价比天高。某某调公司主打产品,爱理不理。

脑中闪过一句 码农何苦为难码农。

下班后闭关修炼3周,输出类似功能,自己动手丰衣足食。感谢libpcap,感谢gnu。下面把一些心得与君共享。

  1. 起步

网上有很多libpcap的起步教程,这里就不几大主要函数的功能在此进行罗列,

2,解析HTTP包的坑

准备一张ASCII的表,转备一张EXCEL,提升你的分析速度。自认是高手的还可以备一份《密码学理论》。

先举例TELNET包,直接上图,不废话。蓝色为二层帧,橙色为三层包,绿色为四层包。四层包大坑在于包长会变。

072147318646423

OSI的4~7层感觉有些酱油。直接跳7层进行展示

072147396144589

http报文最恶心的在于OD/0A太多,列的意义无法固定,导致头不能固定,BODY不能固定。博主没太好的方法,统统扔给HBASE去玩。这里抛砖,望高手提供解决方案。

072147470834541

3,计算成本留给谁?

几乎所有抓包工具只输出一条单向记录,如果部署100台,每台每天产生1GB报文(算少的),那么把它们串成大闸蟹的活谁来干?

答案A: 每台服务器自己算

答案B: 交给后台SQL或NOSQL。

答案C:Hbase+Mapreduce。

======

答案A:很有意思,分散计算压力,同时训练你的算法实践能力应用。

答案B:训练你的sql能力,如oracle的connect by,但几乎坐等宕机。

答案C:训练你的MR能力。但槽点不少,从100-》1-》100^N。坐等硬盘和网络兹兹。

4,串包的烦恼

选B/C的下面就不要看了。大家都知道三次握手,但实际情况比这恶心多了。话说1来2去,2来1去,1来1去,0来1去,1去0来。

之前笔者也停留在理论阶段,在你用调试多种网站场景后发现,网络资源大多数浪费在这些seq和ack上。

串包看似简单,但实际操作起来还得应付各种N来N去的SHAKE场景。下图是比较理想的场景。

072148019743757

这个是F5不放的场景,其他的我就不贴了。

072148107087223

这是我想串成的场景。

072148198021944

怎么办?好在libpcap是一家良心的组织,包的分解几乎都是在阻塞形式下给出,这就给我们的程序设计提供的清晰的蓝天。

随即祭出码农3宝:红黑、指针、绕开FOR。

虾兵蟹将,三个皮匠,百试百灵。

开始为了程序的可读性:没用3宝前,1 CORE CPU高峰情况下就要30%~60%。3宝后,CPU立即压到了5%以下。欣喜!~

5、时差的计算

http在所有报文结束都会有一个结束FIN动作,这动作在httpwatch中不被记录耗时,这个动作差不多就是两个MSL。所以这个耗时的计算我们要绕开,但HTTP何时才算正常传输完毕,这个是个头大是活儿。所以只能靠捕捉纯握手来进行判断,还要提前一个串联维度。当然这个维度至于提前多少,还要看具体场景进行分析。

072148488955922

6,说说回城卷轴

计算好的报文是珍贵的信息资源,但发回服务器的过程未必一帆风顺。服务器的设计就不多说了,要抗高负载就这么1、2个模型。从程序设计的便利度上看,临时存放在mq中是一个好选择。

虽然mq有初始大小限制,但对于程序的健壮性而言,不可谓是一个好的避风港。传回的过程在加上一个超时、非阻塞、自动重连、fork等特色。基本上你的程序就变成”周泰”

7,效果

贴两张效果图。服务显示BODY RESPONSE完毕约203 MS。实际终端侧纯报文213MS,加上IE渲染40~50ms。OK,和目标一致,可以交差了。

072151284117690 072151342394943 072151408333796

2 收藏 1 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • wsq   2014/06/11

    试试在网卡驱动层直接做这个事情,会更有趣。open your mind.

跳到底部
返回顶部