抓包工具详解及示例

常见 抓包工具：主要有tcpdump、wireshark、sniffsmart、httpwatch等，本文将对抓包工具详解及示例进行展示：

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，和目标一致，可以交差了。

参考：http://www.cnblogs.com/zacard-orc/p/3775399.html