在幾年前在專項測試組，專項老大帶着我一起做一個應用的app的專項性能測試，給應用的耗流量地方進行排查， 好幾年了，現在我把他整理出來，看看還是很溫故以前的點點滴滴
1. 【專項】【流量】客戶端分片傳輸策略可以優化，把HTTP Header和較小的Content合並在一個包來發
過濾條件：tcp.stream eq 28
先發了長度241的包，內容是純Http Header
再分片發送長度504的包，內容是Content
*【期望結果】
http header + content < MTU（1400左右）的時候，直接合並在一起用一個包發送，不拆包
可節省56字節的TCP header和一次來回（2G網絡下性能提升一倍）
“TCP segment of a reassembled PDU”是什么意思，其實主機響應一個查詢或者命令時如果要回應很多數據（信息）而這些數據超出了TCP的最大MSS時，主機會通過發送多個數據包來傳送這些數據（注意：這些包並未被分片）。對wireshark來說這些對相應同一個查詢命令的數據包被標記了“TCP segment of a reassembled PDU”
2. *【前提條件】eventlog.beacon.qq.com通訊頻繁，建議keep-alive
版本：外網版本
環境：聯通2G
*【實際結果】
黑線表示與163.177.67.189之間的http通信
所屬部門/業務： 無線業務系統，公共框架服務->LB_V2->lb_深圳_聯通_蛇口高科DC3樓組
紅點表示與163.177.67.189斷開連接的FIN請求
如上圖，前四個POST發到Host: pmir.3g.qq.com，都復用了連接
后5個POST發到Host: eventlog.beacon.qq.com，完畢后客戶端主動斷開連接，下次再通信時重連，開銷較大，重傳較多
客戶端發出的HTTP header中，含有keep-alive，說明希望保持連接，與最后主動斷開連接的行為相矛盾
*【期望結果】
POST /analytics/upload?mType=beacon?rid=852c41d74def6050 HTTP/1.1
Host: eventlog.beacon.qq.com
請確認上述HTTP通訊是否為多次頻繁的業務，如是，則建議keep-alive復用連接通道，可加快傳輸速度
3. 客戶端wspeed.qq.com上報，http header考慮修正
過濾條件：tcp.stream eq 35
HTTP 200 OK下來以后，服務器主動關閉了連接，但客戶端在15秒以后才答復FIN，可否更及時的發出FIN（看上去有點像timeout=15之后的close_socket邏輯）
服務器的IP是
*【期望結果】
Accept-Encoding: gzip 看起來是明文通訊，請修正
Connection: Keep-Alive 看似一次性的上報，請考慮不keep-alive
4. 客戶端已經收到后台ACK的情況下，還做TCP重傳，考慮邏輯BUG
可以下載附件 流量抓包.7z ，用WireShark打開分析
過濾條件：tcp.stream eq 41
下圖中，紅框部分，已經收到了ACK=183和1543的應答包
但接下來的TCP重傳（No. = 1356），又傳一遍seq=183的包
*【期望結果】
已經被確認的包，不用重傳
5. 手空的運營資源圖片含冗余信息，最誇張的圖片冗余量可達97%
可以下載附件 流量抓包.7z ，用WireShark打開分析
普遍頭部總有1KB的冗余信息，含Adobe的URL等
對於2K的小圖，可節省50%流量，弱網絡環境下提升1倍下載速度（少一次TCP來回）
補充一個非常誇張的，17KB的例子
zhibojian0930.png，看上去就是這樣一個小圖
冗余頭部就有5KB：
接下來，這樣的空行，有12KB！
空行完了以后，最后才是顏色表數據，僅471字節——這個PNG只需0.5KB就足夠了，冗余量達97%
*【期望結果】
后台發布運營資源時，所有png、jpeg圖片，應保障冗余的Header被清理掉
xpacket是一個xml擴展頭，屬於用戶看不見的冗余信息
6. 【專項】【流量】i.gtimg.cn的內容強制重傳，實際上客戶端都收到了，流量浪費較多
*【實際結果】
過濾條件：tcp.stream eq 37
112.90.149.87:80
i.gtimg.cn
過濾條件：tcp.stream eq 39
客戶端100%收到了，100%都是Dup ACK，流量浪費比較嚴重
*【期望結果】
內容分片的強制重傳是否有必要？
抓包表明客戶端100%收到了，都答復Dup ACK
每一個包都浪費1416字節，性價比不高
PS. 三次握手的強制重傳是可以保留的，浪費流量不多
7. 專項】【流量】10.228.26.220:80重傳SYN,ACK時，seq=23172347，是異常的seq值
*【實際結果】
過濾條件：tcp.stream eq 52
163.177.67.189:80
所屬部門/業務： 無線業務系統，公共框架服務->LB_V2->lb_深圳_聯通_蛇口高科DC3樓組
下圖紅框中，疑似重傳握手應答的SYN,ACK包，seq=23172347
tcp.stream eq 53
163.177.113.14:80
seq=1366874031
tcp.stream eq 62
112.90.149.110:80
seq=1235184555
*【期望結果】
seq=0
8. 【專項】【流量】與112.90.149.110:80通信時，56字節的ACK包到達率極低，導致整體重傳了2遍
*【實際結果】
過濾條件：tcp.stream eq 56
GET /qzone/em/stamp/weather/20150527/city_203_1432710034_b.png
112.90.149.110:80
看上去像是客戶端發出去的所有ACK包（含握手的），在后台那邊全都丟了，導致整個png被重傳了2遍
*【期望結果】
在server/client上同時抓包測試，確認原因
9. 【專項】【流量】后台發了三遍FIN,ACK，最終客戶端發了RST才停止傳輸，請考慮連接泄漏問題
*【實際結果】
過濾條件：tcp.stream eq 23
業務：112.90.83.23:80
所屬部門/業務： 基礎架構部，[TEG][雲接入]->[TGW][10G專區]->TGWLD
后台9秒時已發FIN, ACK，僅過了3秒在12秒時，又發FIN, ACK
一分鍾后，在78秒時TCP連接還沒關閉，又發FIN，ACK
*【期望結果】
客戶端的ACK包僅56字節，即便是2G網絡環境下，到達率也比較高
從工作經驗判斷，客戶端有兩次ACK應答，不至於后台全都沒收到
所以，請排查連接泄漏問題或者主動丟棄包的問題
10專項】【流量】僅過2秒就TCP重傳整個HTTP 200包，浪費1K的流量
*【實際結果】
過濾條件：tcp.stream eq 20
業務：GET /club/item/parcel/android_magictab.json
下圖中，13秒時已下發HTTP 200，僅過了2秒，又TCP重傳下發了HTTP 200，浪費1K流量
*【期望結果】
2G網絡環境下，一個ACK包等2秒才抵達后台，是正常的情況，但這么快就發生了TCP重傳，導致了流量的浪費，這反而導致更擁塞的情況
11. 專項】【流量】qzonestyle.gtimg.cn的內容強制重傳，實際上客戶端都收到了，流量浪費較多
*【實際結果】
過濾條件：tcp.stream eq 64
112.90.149.100:80
所屬部門/業務： 架構平台部，[CDN][CDN自建]->[圖片類]->[SNG][互聯網圖片]
qzonestyle.gtimg.cn
客戶端100%收到了，甚至連FIN,ACK都發出去了，后台再次強制重傳，完整的又傳了一遍PNG
但客戶端100%都是Dup ACK，流量浪費比較嚴重
*【期望結果】
內容分片的強制重傳是否有必要？
抓包表明客戶端100%收到了，都答復Dup ACK
每一個包都浪費1080字節，性價比不高
12. 【專項】【流量】i.gtimg.cn的若干json體積較大，考慮啟用gzip壓縮傳輸
*【實際結果】
過濾條件：tcp.stream eq 26
112.90.149.87:80
所屬部門/業務： 架構平台部，[CDN][CDN自建]->[圖片類]->[TEG][X2公共平台]
i.gtimg.cn
*【期望結果】
75KB的明文json，如果用Accept-Encoding : gzip 壓縮傳輸的話，預計可以節省到10KB
13. 【專項】【流量】imgcache.qq.com的若干json體積較大，考慮啟用gzip壓縮傳輸
*【實際結果】
過濾條件：tcp.stream eq 29
GET /club/mobile/profile/income_call/fun_call_0.0.0.0_0_1429772543.json?mType=Vip_FunCall
97KB的明文json，預計可以壓縮到10KB
158KB的明文json，預計可以壓縮到20KB
15. 【專項】【流量】179KB的bsdiff_base_30363.zip，使用了無壓縮的打包方式，浪費流量
*【實際結果】
過濾條件：tcp.stream eq 39
GET /pc/misc/qmobile/native/package/20150526/bsdiff_base_30363.zip
183.232.30.100:80
所屬部門/業務： 架構平台部，[CDN][CDN自建]->[圖片類]->[SNG][互聯網圖片]
PK是zip文件的header，后面的內容，179KB全部都是明文的
*【期望結果】
zip文件應使用壓縮方式，否則浪費流量