❶ 如何用Fiddler對android應用進行抓包
1.場景還原之Fliddler
Fiddler是一款抓包神器，近日，由於項目中要嵌入H5頁面，公司又沒專門的UI設計師，所以你懂得，這個任務就要給我嘍！可憐的我並沒有藝術細胞，所以我想到求助抓包神器---Fliddler.話說Fliddler非常強大，是程序猿必備工具，好吧，今天我就跟大家分享一下如何使用Fliddler對Android應用進行抓包處理。
2.Fliddler以及手機端的配置工作
1.老套路，官網下載Fliddler：https://www.telerik.com/download/fiddler/fiddler4;
2.next到底安裝Fliddler;
3.打開Fliddler進行如下配置，如圖：
①點擊Tools-->Telerik Fliddler Options
②配置Https
③配置connections:
ok，你的PC端的Fliddler環境就搭好了。
4.手機端的配置（主要配置IP以及埠號，必須保證PC端與移動端在同一個網段中）
①打開手機的設置頁面：
②長按已連接的WiFI位置：（警告：此wifi必須是你電腦發出的，可以下載360wifi供應熱點，讓手機連接，這個非常重要，不然前功盡棄）
③查詢PC端ip:
那麼本地Ip：192.168.0.107，埠號為剛在Fliddler手動設置的8888（個人喜歡設置）
④點擊手機端的修改網路，然後點擊高級設置，如圖，保證參數一致：
好了，點擊連接，然後打開手機瀏覽器，在網址欄輸入：http://192.168.0.107:8888，安裝Fiddler證書
安裝完成後開始抓包吧！
3.Fiddler抓包處理流程
這里我以"開眼」App為例：
1.打開app,照常瀏覽界面，然後你的Fliddler會出現：
2.點擊圖片按鈕，在右下邊點擊TextView,j就會顯示你瀏覽手機的當前圖片：
你的移動端：
Fliddler端：
3.點擊左邊的額json,再點擊右下邊的json,然後會出現你手機端的數據：
你的移動端：
Fliddler顯示：
❷ 如何在 Android 手機上實現抓包
千鋒扣丁學堂Android開發為您解答：
tcpmp是最快捷方便的抓包方式，還可以加深對網路協議的理解。android下可以通過如下方式抓包：
1 Android上啟動tcpmp
Android設備可以把tcpmp的可執行文件上傳到android設備上，然後通過mac遠程登錄android設備運行tcpmp，前提是這台android設備必須已經root過。步驟如下：
下載android版本的tcpmp為android系統編譯的tcpmp版本。
通過adb將tcpmp上傳到android設備
通過adb push將tcpmp文件上傳到特定的目錄，這里我們選擇/sdcard/data目錄。
在android設備上運行tcpmp
通過adb shell登陸設備，並執行tcpmp，最後一步執行./tcpmp即可。
2. 分析tcpmp輸出
經過上面的步驟成功運行tcpmp之後，接下來就可以分析輸出的網路包內容了，iOS設備和Android設備的輸出是一致的。我們先來解析下幾個基本的格式：
圖中紅色方框內的部分是一個ip包的詳細記錄，類似的紀錄還有好幾條。這里我們著重分析第一條的各部分欄位含義。
14:37:41.615018 很簡單，是該包接收到的時間。
17.143.164.37.5223 是發送方的ip地址及埠號(5223是埠號)。
10.29.44.140.58036 是我android的ip地址及埠號。
Flags [P.]
是tcp包header部分的第14個位元組的P位。這個位元組所包含的幾個flag很重要，後面我會單獨詳細講解。這里P位表示接受方需要馬上將包push到應用層。
seq 1:54
tcp包的seq號，1是起始值，54結束值。tcp之所以被認為是流，是因為tcp包所攜帶的每一個位元組都有標號(seq號)。1:54表明總共有54個位元組被接受，其中一個位元組是三次握手階段所使用，所以一共發送的長度是53位元組。
ack 101 tcp包的ack號，ack 101表明seq號為100的位元組已被確認收到，下一個期望接收的seq號從101開始。
win 255 win表示的是tcp包發送方，作為接受方還可以接受的位元組數。這里win
255表明ip為17.143.164.37的主機還可以接受255個位元組。
options [nop,nop,…] options[…]表示的是該tcp包的options區域，nop是no
opertion的縮寫，沒什麼實際用途，主要是用做padding，因為options區域按協議規定必須是4位元組的倍數。
options[… TS val 2381386761] ts
val這個值是tcp包的時間戳，不過這個時間戳和設備的系統時間沒啥關系，剛開始是隨機值，後面隨著系統時鍾自增長。這個時間戳主要用處是seq序列號越界從0重新開始後，可以確認包的順序。
options[… ecr 427050796] ts ecr這個值主要用來計算RTT。比如A發送一個tcp包給B，A會在包里帶上TS
val，B收到之後在ack包里再把這個值原樣返回，A收到B的ack包之後再根據本地時鍾就可以計算出RTT了。這個值只在ack包里有效，非ack包ecr的值就為0.
length 53 這個length是應用層傳過來的數據大小，不包括tcp的header。這個值和我們上面分析的seq 1:54是一致的。
以上就是一個基本的tcp包結構，大家可以按照上面的分析再把其他幾個包理解下。我們在做應用的時候面對的更多是http協議，但對一個http請求是怎麼通過tcp/ip分解成一個個的packet，然後怎麼在網路上穩定可靠的傳輸，要有個基本的印象。下面我們再看下tcpmp更多的功能，這些功能都是基於對tcp/ip協議的理解，遇到不理解的建議多google下相關的技術概念。
3. tcpmp知識拓展
再繼續深入tcpmp之前，先貼上一張tcp header格式圖，常看常新。
[https://github.com/music4kid/music4kid.github.io/blob/master/images/tcpheader.png?raw=true](https://github.com/music4kid/music4kid.github.io/blob/master/images/tcpheader.png?raw=true)"
width="1056">
3.1 TCP Flags(tcp header第十四個位元組)
我們再仔細看下上面提到的flags概念，flags位於tcp
header的第十四個位元組，包含8個比特位，也就是上圖的CWR到FIN。這8個比特位都有特定的功能用途，分別是：CWR，ECE，URG，ACK，PSH，RST，SYN，FIN。
CWR ，ECE 兩個flag是用來配合做congestion
control的，一般情況下和應用層關系不大。發送方的包ECE(ECN-Echo)為0的時候表示出現了congestion，接收方回的包里CWR(Congestion
Window Reced)為1表明收到congestion信息並做了處理。我們重點看其他六個flag。
URG
URG代表Urgent，表明包的優先順序高，需要優先傳送對方並處理。像我們平時使用terminal的時候經常ctrl+c來結束某個任務，這種命令產生的網路數據包就需要urgent。
ACK
也就是我們所熟悉的ack包，用來告訴對方上一個數據包已經成功收到。不過一般不會為了ack單獨發送一個包，都是在下一個要發送的packet里設置ack位，這屬於tcp的優化機制，參見delayed
ack。
PSH Push我們上面解釋過，接收方接收到P位的flag包需要馬上將包交給應用層處理，一般我們在http
request的最後一個包里都能看到P位被設置。
RST Reset位，表明packet的發送方馬上就要斷開當前連接了。在http請求結束的時候一般可以看到一個數據包設置了RST位。
SYN
SYN位在發送建立連接請求的時候會設置，我們所熟悉的tcp三次握手就是syn和ack位的配合：syn->syn+ack->ack。
FIN
Finish位設置了就表示發送方沒有更多的數據要發送了，之後就要單向關閉連接了，接收方一般會回一個ack包。接收方再同理發送一個FIN就可以雙向關閉連接了。
這8個flag首字母分別是：C E U A P R S F。初看難以記憶，我腦洞了下，把它們組合成 supr
cafe，當然少了super少了個e，我可以將就下。我們在使用tcpmp的時候會經常看到這幾個flag，[S],[P],[R],[F],[.]。其他幾個都好理解，[.]特殊點，是個佔位符，沒有其他flag被設置的時候就顯示這個佔位符，一般表示ack。
3.2 tcpmp 更多使用參數
這部分我們來看下tcpmp常用的一些命令參數。文章最開始部分的tcpmp命令是這樣的：sudo tcpmp -i rvi0 -AAl。
-i rvi0 -AAl都是屬於參數部分。常見的有這些：
-i, 要監聽的網卡名稱，-i rvi0監聽虛擬網卡。不設置的時候默認監聽所有網卡流量。
-A, 用ASCII碼展示所截取的流量，一般用於網頁或者app里http請求。-AA可以獲取更多的信息。
-X，用ASCII碼和hex來展示包的內容，和上面的-A比較像。-XX可以展示更多的信息(比如link layer的header)。
-n，不解析hostname,tcpmp會優先暫時主機的名字。-nn則不展示主機名和埠名(比如443埠會被展示成https)。
-s，截取的包位元組長度，默認情況下tcpmp會展示96位元組的長度，要獲取完整的長度可以用-s0或者-s1600。
-c，只截取指定數目的包，然後退出。
-v，展示更多的有用信息，還可以用-vv -vvv增加信息的展示量。
src，指明ip包的發送方地址。
dst，指明ip包的接收方地址。
port，指明tcp包發送方或者接收方的埠號。
and,or,not,操作法，字面意思。
上面幾個是我個人比較常用的，更多的參數可以參考這個詳細文檔。有興趣的可以分析下面幾個例子練習下：
tcpmp 『tcp[13] & 16!=0』
tcpmp src port 80 and tcp
tcpmp -vv src and not dst port 23
tcpmp -nnvvS src 192.0.1.100 and dst port 443
4. 用tcpmp分析http完整請求
說了這么多，我們再來實戰下，看一個完整的http請求流程。sudo tcpmp -i rvi0 -AAl src 60.28.215.123 or
dst 60.28.215.123
列出了6個前面的packet，10.29.44.240是我android的ip地址，60.28.215.123是知乎server的ip地址，紅色方框內是android發出的packet，白色方框內是server發出的packet。packet1是android三次握手的第一個syn包，packet2是server
ack+syn的包，packet3是android ack的包。這3個packet之後tcp的三次握手就完成了。
packet4是android發出的http
request。長度只有240個位元組，所以一個packet就發過去了，當然還設置了flags的P位，request需要馬上被應用層處理。包裡面出現了spdy，點贊。
packet5是server ack剛收到的包，長度位0，所以這僅僅是一個ack包。
packet6是server返回http的response了，1388個位元組。packet5和packet6都ack了seq為241的包，當然是為了增加ack的成功率。
中間還有好幾個packet就不仔細分析了，最後再看下請求完成的最後幾個包：
最後兩個packet比較簡單，android發送個FIN+ACK的包就斷開連接了，server直接發送了一個RST包後也斷開連接了。