抓包工具：顧名思義、耳熟能詳。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去玩。這里拋磚，望高手提供解決方案。
幾乎所有抓包工具只輸出一條單向記錄，如果部署100台，每台每天產生1GB報文（算少的），那么把它們串成大閘蟹的活誰來干？
答案A： 每台服務器自己算
答案B： 交給后台SQL或NOSQL。
答案C：Hbase+Mapreduce。
======
答案A：很有意思，分散計算壓力，同時訓練你的算法實踐能力應用。
答案B：訓練你的sql能力，如oracle的connect by，但幾乎坐等宕機。
答案C：訓練你的MR能力。但槽點不少，從100-》1-》100^N。坐等硬盤和網絡茲茲。
選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，和目標一致，可以交差了。
