編輯:關於Android編程
WireShark是一個非常准確和穩定的tcp抓包工具,但看其40多m的安裝包就可以想象其功能的強大,借助其功能強大的表達式篩選器,可以迅速的篩選出來我們所需要報文和記錄,最近我就通過WireShark推斷網絡性能問題的故障點,收獲頗豐。
最近客戶提出app端load慢,尤其是在網絡不好的地方,得好幾分鐘才能加載出數據,於是打算用抓包軟件WireShark 看看http請求就用用了多長時間才傳回來的,首先我用火狐浏覽器訪問了一下一個GET接口,監聽結果如下
(我本機的端口是61281,但是抓包軟件又抓出一個61282的端口,應該不是我的火狐浏覽器的結果,下文忽略61282端口的消息)
從抓包結果來看,本次HTTP請求大體分為以下步驟
三次握手-->發送GET請求--->收到服務器返回json--->獲取浏覽器favicon.ico--->KEEP-ALIVE--->四次揮手
在介紹每個步驟的返回值之前,先介紹一下WireShark這個軟件的簡單用法
首先是我的過濾器設置:ip.addr == 122.248.245.191 含義是僅保留源ip地址和目標主機ip地址至少有一個為122.248.245.191,也就是項目服務器的地址,這樣就可以篩選出所有的本機和122.248.245.191的收發報文
如果更改過濾器描述,比如ip.dst==122.248.245.191 andip.src==192.168.1.109(192.168.1.109是本機的ip)就可以查看所有從本機發往服務器的報文,如果把兩個ip對換一下,就可以查看所有服務器發給本機的報文
如果寫成ip.addr == 122.248.245.191 and tcp.srcport==61281(其中61281是本機的對外端口)就是查找所有源ip的端口為61281的報文,換句話說就是只顯示本機發給服務器的報文,不同的條件可以用and連接,靈活處理。
再來說一下報文裡面的基本信息
(一)、ACK,FIN,PSH這三個是TCP請求的標志,本身並不是一個數,而是和另外五個這樣的標志組成了一個長度為1字節(8位)的標志,用於標示出當前請求報文的類型,可以在WireShark 底下的FLAGS目錄下查看,如果某一位設置為1則為Set,置0為Not set,一般我們只看置1的位,其中Acknowledgement = ACK,FIN = Fin,Push = Psh
(二)、seq,ack的含義,其中seq是Sequence number的簡寫,即序列號。Ack是 Acknowledge number的簡寫,即應答碼,用這兩個數字可以觀察相鄰的幾條報文的順序。
好了現在我們可以開始按照步驟逐一分析了
第一階段:三次握手
(本機ip是192.168.1.109:61281,服務器ip是:122.248.245.191:7033)
首先來回顧一下三次握手的過程
下面這幅圖標示出了三次握手的報文
這裡面的第三條因為端口不是火狐的端口號,所以是另一次三次握手
從這裡面我們可以看出完全符合標准TCP三次握手的流程,第二次握手的ack為第一次的seq+1
三次握手耗時102.605103-102.354383 = 0.2572秒,看起來很快,說明三次握手上沒有浪費很多時間
第二階段:發送GET請求並接收返回json
從這裡可以看出,服務器發送三波數據,每個報文的長度為都為1514,然後返回了一個200 OK來結束發送,其中在第二次發送完畢之後客戶端發送了一個數據接收確認報文,在200 OK之後,客戶端有發送了一個數據接收確認報文
從這裡可以看出整個服務器向客戶端發送數據的耗時:103.862232-102.858066 = 1.004166
那麼從三次握手成功到成功客戶端成功收到json的時間是103.862232-102.354383 = 1.507849
那麼我們可以算出來服務器的響應時間是1.507849-1.004166(數據回傳)-0.2572(三次握手)= 0.246483秒
可以看出,無論是網絡還是服務器,都是相當快。
本部分的幾個報文都已經粘貼在本文的最底部,有興趣可以看看
第三階段:請求favicon.ico
從圖中可以看出,一共請求了兩次圖片,每次請求都沒有成功(因為服務器根本就沒有這個圖)每次請求大約1秒左右的時間,其中第一次105.605757-104.393820 = 1.211937,第二次106.025472-105.608105= 0.417367,第二次比第一次時間用的短好多。
第四階段:KEEP-ALIVE
這個KEEP-ALIVE的請求是由火狐浏覽器發出的,我估計目的在於減少三次握手建立和銷毀連接的開銷,並且每隔10秒左右就發出一個KEEP-ALIVE請求,總共發送了6次,服務器應答了5次,總共保活的時間是158.373788-115.817623=42.556165秒,看來火狐浏覽器對http優化的很好,同時我們也知道了用火狐在大約1分鐘內是不會重建http連接的
第五階段:四次揮手
首先我們來回顧一下四次揮手的過程下面我們來看一下四次揮手的報文
從這裡抓取的報文可以看出,這裡和標准的TCP四次揮手是一致的,而且從抓包結果來看,這次揮手是由服務器先發起的,估計是服務器受不了客戶端沒完沒了的保活請求,要釋放一下連接。從數據來看,整個四次揮手耗時,166.387505-166.162996 = 0.224509
ok了從這裡可以看出,整個http請求過程一氣呵成,速度極快,幾乎用了不到兩秒就完成了全部數據的請求,至於UI繪制以毫秒計數,所以可以看出在代碼層面無論服務器還是客戶端都沒什麼性能上的問題,不過剛剛的測試是使用電腦浏覽器通過寬帶網絡進行http請求,沒有考慮到超時重傳和丟包的情況,也沒有模擬手機在wifi或者無線網絡下的情況,下文將著重考慮網絡條件不好的時候丟包情況。
附:http回傳數據的幾條報文
No. Time Source Destination Protocol Length Info 3632 102.858066 122.248.245.191 192.168.1.109 TCP 60 7033 → 61281 [ACK] Seq=1 Ack=413 Win=19200 Len=0 Frame 3632: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 1, Ack: 413, Len: 0 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 0] Sequence number: 1 (relative sequence number) Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0x6f29 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] No. Time Source Destination Protocol Length Info 3675 103.861417 122.248.245.191 192.168.1.109 TCP 1514 [TCP segment of a reassembled PDU] Frame 3675: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 1, Ack: 413, Len: 1460 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 1460] Sequence number: 1 (relative sequence number) [Next sequence number: 1461 (relative sequence number)] Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0xdba5 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] TCP segment data (1460 bytes) No. Time Source Destination Protocol Length Info 3676 103.861630 122.248.245.191 192.168.1.109 TCP 1514 [TCP segment of a reassembled PDU] Frame 3676: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 1461, Ack: 413, Len: 1460 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 1460] Sequence number: 1461 (relative sequence number) [Next sequence number: 2921 (relative sequence number)] Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0xb2fa [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] [Reassembled PDU in frame: 3679] TCP segment data (1460 bytes) No. Time Source Destination Protocol Length Info 3677 103.861655 192.168.1.109 122.248.245.191 TCP 54 61281 → 7033 [ACK] Seq=413 Ack=2921 Win=65700 Len=0 Frame 3677: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface 0 Ethernet II, Src: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c), Dst: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2) Internet Protocol Version 4, Src: 192.168.1.109, Dst: 122.248.245.191 Transmission Control Protocol, Src Port: 61281 (61281), Dst Port: 7033 (7033), Seq: 413, Ack: 2921, Len: 0 Source Port: 61281 Destination Port: 7033 [Stream index: 29] [TCP Segment Len: 0] Sequence number: 413 (relative sequence number) Acknowledgment number: 2921 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 16425 [Calculated window size: 65700] [Window size scaling factor: 4] Checksum: 0x23e3 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] No. Time Source Destination Protocol Length Info 3678 103.861773 122.248.245.191 192.168.1.109 TCP 1514 [TCP segment of a reassembled PDU] Frame 3678: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 2921, Ack: 413, Len: 1460 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 1460] Sequence number: 2921 (relative sequence number) [Next sequence number: 4381 (relative sequence number)] Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0x6d9d [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] [Reassembled PDU in frame: 3679] TCP segment data (1460 bytes) No. Time Source Destination Protocol Length Info 3679 103.862209 122.248.245.191 192.168.1.109 HTTP 288 HTTP/1.1 200 OK (application/json) Frame 3679: 288 bytes on wire (2304 bits), 288 bytes captured (2304 bits) on interface 0 Ethernet II, Src: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2), Dst: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c) Internet Protocol Version 4, Src: 122.248.245.191, Dst: 192.168.1.109 Transmission Control Protocol, Src Port: 7033 (7033), Dst Port: 61281 (61281), Seq: 4381, Ack: 413, Len: 234 Source Port: 7033 Destination Port: 61281 [Stream index: 29] [TCP Segment Len: 234] Sequence number: 4381 (relative sequence number) [Next sequence number: 4615 (relative sequence number)] Acknowledgment number: 413 (relative ack number) Header Length: 20 bytes Flags: 0x018 (PSH, ACK) Window size value: 75 [Calculated window size: 19200] [Window size scaling factor: 256] Checksum: 0x46b6 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis] TCP segment data (234 bytes) [4 Reassembled TCP Segments (4614 bytes): #3675(1460), #3676(1460), #3678(1460), #3679(234)] Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Content-Encoding: gzip\r\n Content-Type: application/json;charset=UTF-8\r\n Date: Wed, 11 May 2016 05:37:22 GMT\r\n Server: nginx\r\n Vary: Accept-Encoding\r\n Content-Length: 4404\r\n Connection: keep-alive\r\n \r\n [HTTP response 1/3] [Time since request: 1.256983000 seconds] [Request in frame: 3615] [Next request in frame: 3705] [Next response in frame: 3779] Content-encoded entity body (gzip): 4404 bytes -> 17029 bytes JavaScript Object Notation: application/json No. Time Source Destination Protocol Length Info 3680 103.862232 192.168.1.109 122.248.245.191 TCP 54 61281 → 7033 [ACK] Seq=413 Ack=4615 Win=65700 Len=0 Frame 3680: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface 0 Ethernet II, Src: WistronI_a3:c8:2c (3c:97:0e:a3:c8:2c), Dst: ChengduV_08:d6:c2 (ec:6c:9f:08:d6:c2) Internet Protocol Version 4, Src: 192.168.1.109, Dst: 122.248.245.191 Transmission Control Protocol, Src Port: 61281 (61281), Dst Port: 7033 (7033), Seq: 413, Ack: 4615, Len: 0 Source Port: 61281 Destination Port: 7033 [Stream index: 29] [TCP Segment Len: 0] Sequence number: 413 (relative sequence number) Acknowledgment number: 4615 (relative ack number) Header Length: 20 bytes Flags: 0x010 (ACK) Window size value: 16425 [Calculated window size: 65700] [Window size scaling factor: 4] Checksum: 0x1d45 [validation disabled] Urgent pointer: 0 [SEQ/ACK analysis]
安卓使用ES文件浏覽器看電腦上的共享媒體文件。手機多大多很難大過電腦,有時手機都裝不下一步藍光的高清電影,可是我們要看,那怎麼辦?現在小編教你使用ES浏覽器
在API21中Google就發布了Camera2類來取代Camera類,那麼這個Camera2類到底改變了那些地方呢,我們來看官方的說法:Camera2 APISuppo
有時候我們添加的一些資源,如圖片和一些沒用的代碼,以及在添加第三方庫的時候我們只需要使用其中的一部分功能和一部分資源,那麼這個時候如果靠我們手工去怕是非常難做的,尤其是
上一篇我們講了多渠道打包 其中我們用到了簽名文件在eclipse時.keystore在Android Studio中就是.jks文件了,那麼這個文件怎麼生成呢?這篇文章