wireshark网络实战分析二

Posted 2020-12-16 chongyou

在几年前在专项测试组，专项老大带着我一起做一个应用的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文件应使用压缩方式，否则浪费流量