monkeysocks的目標是爲開發以及測試提供一個穩定的環境。它使用socks代理,將錄製網絡流量並本地保存,並在測試時將其重放。html
首先對公司一個項目進行了代理,測試結果:從開始啓動到完成,只有4.7M的網絡流量,本地空間開銷不是問題。mysql
今天把jsocks修改了下,將build工具換成了maven,並獨立成了項目https://github.com/code4craft/jsocks。後來算是把record和replay功能作完了,開始研究各類協議replay的可能性。git
replay時候,如何知道哪一個請求對應響應包是個大問題。開始的方式是把request報文的md5做爲key,response做爲value。github
後來使用wiredshark結合程序日誌來進行分析。sql
TCP協議棧大概是這樣子: 瀏覽器
下面是wiredshark抓包的截圖,從ea開始纔是應用層協議的內容。cookie
實現replay後,拿HTTP協議作了測試,本身用程序寫了個URLConnection,卻是可以實現replay,可是換到瀏覽器裏就很難了,由於cookie老是會有些不同(如今基本上全部站點都會寫cookie吧)。若是不對應用層協議自己進行分析,那麼進行包的僞造就很難了。網絡
https協議對於重放攻擊作了處理,每次的請求包都不同,也沒法replay成功,暫時略過。架構
後來對於測試中得重點協議--mysql的協議,進行了研究。框架
這是一個有狀態的協議,狀態轉移圖以下:
詳細介紹http://dev.mysql.com/doc/internals/en/client-server-protocol.html,有點hold不住的感受啊!
看了Authentication部分,會由server端發送一個隨機數,來避免重放攻擊。這個東西啓發了我,由於主動權通常都是在server端,而咱們要對client進行欺騙,難度就小了不少。
後來決定把架構解耦了,fake server單獨做爲一個模塊,能夠單獨啓動成TCP server,也能夠加入到jsocks裏。最後架構是這樣子:
fake servers的實現一定是個大坑,不過能把經常使用協議都瞭解一遍,自己也頗有意思不是麼?
實現fake servers的TCP框架。
研究並實現經常使用協議的fake server。
肯定持久化以及報文對應的策略。