抓包工具

    抓包工具：顾名思义、耳熟能详。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，说说回城卷轴

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

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

 

7，效果

 

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