iOS,Android網絡抓包教程之tcpdump
現在的移動端應用幾乎都會通過網絡請求來和服務器交互,通過抓包來診斷和網絡相關的bug是程序員的重要技能之一。抓包的手段有很多:針對http和https可以使用Charles設置代理來做,對于更廣泛的協議可以使用tcpdump或者wireshark。wireshark提供GUI,方便做深入全面的數據分析。tcpdump則輸出原始的包內容,好處是快速高效,之前寫過一篇簡單的微信紅包圖片的破解教程,就是用tcpdump來操作的。這篇文章主要介紹tcpdump的基本使用方法,閱讀目標是能基本掌握并運用tcpdump解決網絡相關的問題。閱讀前提是對TCP/IP有初步的了解。
1.啟動tcpdump
1.1 iOS上啟動tcpdump
iOS設備上啟動tcpdump比較方便。apple在mac上有個叫rvictrl的程序,可以通過iOS設備的udid創建一個虛擬網卡,然后通過這個虛擬網卡監聽設備上所有的網絡流量。步驟如下:
獲取itunes獲取設備udid
![]()
打開終端(terminal),創建虛擬網卡
在終端輸入rvictl -s udid,創建虛擬網卡。
![]()
啟動tcpdump監控流量
在終端繼續輸入sudo tcpdump -i rvi0 -AAl,啟動tcpdump監控。
![]()
2.1 Android上啟動tcpdump
Android設備沒辦法通過rvictl創建虛擬網卡,但是可以把tcpdump的可執行文件上傳到android設備上,然后通過mac遠程登錄android設備運行tcpdump,前提是這臺android設備必須已經root過。步驟如下:
下載android版本的tcpdump
從這個鏈接可以下載到專門為android系統編譯的tcpdump版本。
通過adb將tcpdump上傳到android設備
通過adb push將tcpdump文件上傳到特定的目錄,這里我們選擇/sdcard/data目錄。
![]()
在android設備上運行tcpdump
通過adb shell登陸設備,并執行tcpdump,最后一步執行./tcpdump即可。
![]()
2. 分析tcpdump輸出
經過上面的步驟成功運行tcpdump之后,接下來就可以分析輸出的網絡包內容了,iOS設備和Android設備的輸出是一致的。我們先來解析下幾個基本的格式:
![]()
圖中紅色方框內的部分是一個ip包的詳細記錄,類似的紀錄還有好幾條。這里我們著重分析第一條的各部分字段含義。
14:37:41.615018 很簡單,是該包接收到的時間。
17.143.164.37.5223 是發送方的ip地址及端口號(5223是端口號)。
10.29.44.140.58036 是我iphone的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,然后怎么在網絡上穩定可靠的傳輸,要有個基本的印象。下面我們再看下tcpdump更多的功能,這些功能都是基于對tcp/ip協議的理解,遇到不理解的建議多google下相關的技術概念。
3. tcpdump知識拓展
再繼續深入tcpdump之前,先貼上一張tcp header格式圖,常看常新。
![]()
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 Reduced)為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,我可以將就下。我們在使用tcpdump的時候會經常看到這幾個flag,[S],[P],[R],[F],[.]。其他幾個都好理解,[.]特殊點,是個占位符,沒有其他flag被設置的時候就顯示這個占位符,一般表示ack。
3.2 tcpdump 更多使用參數
這部分我們來看下tcpdump常用的一些命令參數。文章最開始部分的tcpdump命令是這樣的:sudo tcpdump -i rvi0 -AAl。 -i rvi0 -AAl都是屬于參數部分。常見的有這些:
- -i, 要監聽的網卡名稱,-i rvi0監聽虛擬網卡。不設置的時候默認監聽所有網卡流量。
- -A, 用ASCII碼展示所截取的流量,一般用于網頁或者app里http請求。-AA可以獲取更多的信息。
- -X,用ASCII碼和hex來展示包的內容,和上面的-A比較像。-XX可以展示更多的信息(比如link layer的header)。
- -n,不解析hostname,tcpdump會優先暫時主機的名字。-nn則不展示主機名和端口名(比如443端口會被展示成https)。
- -s,截取的包字節長度,默認情況下tcpdump會展示96字節的長度,要獲取完整的長度可以用-s0或者-s1600。
- -c,只截取指定數目的包,然后退出。
- -v,展示更多的有用信息,還可以用-vv -vvv增加信息的展示量。
- src,指明ip包的發送方地址。
- dst,指明ip包的接收方地址。
- port,指明tcp包發送方或者接收方的端口號。
- and,or,not,操作法,字面意思。
上面幾個是我個人比較常用的,更多的參數可以參考這個詳細文檔。有興趣的可以分析下面幾個例子練習下:
tcpdump ‘tcp[13] & 16!=0’
tcpdump src port 80 and tcp
tcpdump -vv src baidu and not dst port 23
tcpdump -nnvvS src 192.0.1.100 and dst port 443
4. 用tcpdump分析http完整請求
說了這么多,我們再來實戰下,看一個完整的http請求流程。 下面截圖里的流量是我監聽的 知乎App點贊之后發送的一個https請求。我之前先分析過server的ip地址了,tcpdump命令是:
sudo tcpdump -i rvi0 -AAl src 60.28.215.123 or dst 60.28.215.123
![]()
圖中列出了6個前面的packet,10.29.44.240是我iphone的ip地址,60.28.215.123是知乎server的ip地址,紅色方框內是iphone發出的packet,白色方框內是server發出的packet。packet1是iphone三次握手的第一個syn包,packet2是server ack+syn的包,packet3是iphone ack的包。這3個packet之后tcp的三次握手就完成了。
packet4是iphone發出的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比較簡單,iphone發送個FIN+ACK的包就斷開連接了,server直接發送了一個RST包后也斷開連接了。
這篇教程到這里就結束了,建議大家自己多練習下,遇到不懂的參數或關鍵字多google。最好能系統的學習下tcp/ip協議