抓包工具

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

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

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

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

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

 

  1. 起步

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

    /*

* 回调函数

* ========

* arg pcap_loop外传参数

* pcap_pkthdr结构,该结构位于真正的物理帧前面,用于消除不同链路层支持的差异

* packet结构,指向所捕获报文的物理帧。

* void processPacket(u_char *arg, const struct pcap_pkthdr *pkthdr, const u_char *packet)

*/

  

/* Opening the device for sniffing

* =======

* 打开一个设备,官方建议1.0以后使用pcap_create()和pcap_activate()

* 1-设备名称,2-每次捕捉的最大字节数,3-混杂模式, 4-捕捉间隔(毫秒),5-存放的报错信息

* 混杂模式:混杂模式就是接收所有经过网卡的数据包,包括不是发给本机的包

*/

pcap_t *descr=pcap_open_live(device, MAXBYTE2CAPTURE, 1,1024, errbuf);

  

 

/* Loop forever & call processPacket() for every received packet

* =============

* 循环收报

* 1-设备名称,2-循环次数[-1无限],3,自定义回调,4,类同pthread_create的外传参数

*

* pcap_next

* ============

* pcap_next() returns a u_char pointer to the packet that is described by this structure

*

*

* void got_packet(u_char *args, const struct pcap_pkthdr *header,const u_char *packet);

* =====

* 1-外传参数,2,pcap-header。3, points to the first byte of a chunk of data containing the entire packet

*/

pcap_loop(descr, -1, processPacket, (u_char *)&count);

  

 2,解析HTTP包的坑

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

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

 

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

 

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

 

 

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场景。下图是比较理想的场景。

 

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

    

这是我想串成的场景。

    

    

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

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

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

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

 

 5,时差的计算

 

 

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

 

6,说说回城卷轴

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

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

 

7,效果

 

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

 

 

 

 

 

 

 

 

posted @ 2014-06-07 21:55  RichardParker  阅读(11960)  评论(35编辑  收藏  举报