抓包工具

    抓包工具：顧名思義、耳熟能詳。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，和目標一致，能夠交差了。