轉自： http://blog.csdn.net/fenglibing/article/details/6298189
考慮以下這個非常常見的WEB開發部署場景：
在開發環境下，如果要調試APPSERV1向APPSERV2的接口調用，我們通常可以直接用IDE跟代碼，或者用wireshark抓包進行觀察。完成 接口調用的監控是一件容易的事情。
但如果場景發生在測試環境中，要監控SERV1與SERV2之間的通信就麻煩得多。我能夠想到的可能的手段是：爲這個請求單獨寫一個測試用例，直接執行觀 察。或者在APPSERV1上也裝上tshark或者wireshark，用UI的，還得再通過X11的x-forwarding轉發。總之，不管是哪種 方法，之前都介於複雜性和較低的可操作性，被我們拒絕了。
其實我們很多人都知道在所有的Linux distro上，都會自帶tcpdump。不少人也知道tcpdump是個強大的網絡監測工具，但很少人把tcpdump用來監測。其主要原因，我想還是 因爲tcpdump強大得有點讓人望而生畏。
最近研究了下，覺得非常handy，只要在要監控的主機(APPSERV1)上運行以下命令，即可監控APPSERV1與APPSERV2之間的通信：
# tcpdump –A -n -i eth1 –s0 'host 10.20.156.9 and tcp port 9003 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
參數簡單介紹(其實man page上都有，覺得不夠詳細的，自己RTFM吧)：
-A 顯示抓取的包的內容
-n 不要作DNS反向解析。否則的話，軟件會試圖去查詢這個IP的域名(或者主機名)。通常，關閉這一項可以提高速度。(插一句，反查在我看來相當可惡，沒必 要又拖累速度。但幾乎所有GNU的那些東西，如ping, traceroute，默認都會打開，真不瞭解那些開發是怎麼想的。)
-i 後面必須指出發生接口調用通信的接口設備名稱
-s 這個參數用來告訴tcpdump是否要對抓取的包進行truncate。這個參數費了我不少力氣，因爲不同版本的tcpdump，對這項的默認值是不一致 的。4.1.0及以後的版本，默認值都是65535字節。但我們測試環境裏的tcpdump版本是3.9.4，這項值只有96字節。所以一開始在我本機運 行得好好的同一條命令，在測試環境下總是得到閹割的數據，非常鬱悶，後來還是跑到tcpdump的郵件組裏面問了後，纔要到答案的。這裏配置0，表示不作 truncate。
host：指出APPSERV2的地址，也可以是域名
tcp port：指出接口服務監聽的端口，一般都配在antx.properties中
(((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)：這個不用細究了，說的簡單點，就是告訴tcpdump忽略掉tcp包中的SYN和FIN，只留下攜帶數據，對我們有意義的ACK包。
執行情況(有測試環境的截圖爲證)：
整個調用過程盡在眼底，一覽無遺。
下面再來講講用tcpdump的不足。
1. 權限問題。要從接口抓取包，自然也不是隨隨便便哪個用戶都可以做的，需要root權限。這個可以考慮用SUID或者SGID解決。
2. tcpdump只限於http接口的調用。因爲被監測的數據流是ASCII編碼的，所以對於序列化的hessian和dubbo接口，可能獲取不到有意義 的數據。
========================================================================
PS:這裏談的是對外部應用提供的URL式的接口進行的，通常情況下我們也可以直接輸入這個URL的地址進行訪問，不過通過這樣的監控方式不僅可以監控被調用方，也可以監控調用方，看調用方有沒有將被調用方需要的參數傳過去，以及被調用方的返回結果。
PS：我們也可以結合FIDDER，就可以看到調用方在調用接口時，傳遞的參數是否正確。