原文:抓包工具
抓包工具：顾名思义、耳熟能详。tcpdump、wireshark、sniffsmart、httpwatch（还算有点良心）。。。
但当其只是当为工具使用时，又贵为可惜。因工作需要，再度涉及该领域。
可随想云随风去，江河大变。某某文公司镜像工具，价比天高。某某调公司主打产品，爱理不理。
脑中闪过一句 码农何苦为难码农。
下班后闭关修炼3周，输出类似功能，自己动手丰衣足食。感谢libpcap，感谢gnu。下面把一些心得与君共享。
- 起步
网上有很多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，和目标一致，可以交差了。