抓包工具

抓包工具：顧名思義、耳熟能詳。tcpdump、wireshark、sniffsmart、httpwatch（還算有點良心）。。。

但當其只是當為工具使用時，又貴為可惜。因工作需要，再度涉及該領域。

可隨想雲隨風去，江河大變。某某文公司映象工具，價比天高。某某調公司主打產品，愛理不理。

腦中閃過一句 碼農何苦為難碼農。

下班後閉關修煉3周，輸出類似功能，自己動手豐衣足食。感謝libpcap，感謝gnu。下面把一些心得與君共享。

1. 起步

網上有很多libpcap的起步教程，這裡就不幾大主要函式的功能在此進行羅列，

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