问题分析方法

昨天遇到一件乌龙事件，客户反馈说我们SDK统计的传输数据量不准确，服务器响应通过gzip压缩后传输，我们统计的是压缩前大小。为了验证这个问题我做了以下步骤：

1.请运维同学帮忙搭了一个http gzip响应地址；

2.写测试程序请求该地址，log输出响应字节数（使用Apache HttpClient，通过response.getEntity().getContentLength()获取）；

3.分别用听云和newRelic嵌码测试，验证其采集到的传输字节数。

（中间各种曲折不细说了，需要注意1.听云采集网络数据必须等响应读完，即inputStream.read()!=-1,inputStream.close()；2.打包时验证听云或者newRelic是否打进去： [dx] [NBSAgent.debug] NetworkBench begin或 [dx] [newrelic.info] Marking NewRelic agent as instrumented）

后来听说客户用了开源框架AsyncHttpClient,于是又用该框架写了一个demo，这个框架是自动gzip解压缩的，并且是异步传输，验证结果听云和newRelic都可以正确统计压缩后的传输字节数。

结果！就在我发完测试报告的第二天！再测试时发现听云和newRelic统计字节数都变成了压缩前大小！！

造成字节数变化的有三个因素：1.服务器端变了；2.SDK统计有问题；3.开源库的问题。

我首先排除了服务器端的原因，因为之前已经统计到确实是gzip压缩的，帮我们搭环境的运维同学不会闲着没事动它；

其次排除了SDK的原因，因为我用HttpClient测了几次都没问题；

基本上我已经认定是开源库的问题了，搜了一下果然有人说这个库不安全。

就在我准备建议客户放弃使用这个库的时候，开发同事说可能是服务器端的原因，我又去确认了一下，结果！piapia打脸啊！原来我测试用的这个域名是动态分配的，只有在指向某一个IP的时候才是gzip压缩的。。。。

这个故事告诉我什么教训呢？

1.不要想当然，妄下结论，多测试几次；

2.需要学习一下服务器端的开发和环境搭建。