这几天随着客户端一个新版本发布，运维发现CDN的流量猛跌：
话说流量就是金钱，流量就是工资。领导很生气，后果很严重。没什么好说的，赶紧查！一开始怀疑服务端有问题，先受伤的总是我们，当然这也是没错的，因为发出去的版本泼出的水，当然先排查能迅速解决的问题。屎劲查（IIS日志分析、CND日志分析……此处省略N个字），确实发现了个bug，但修复后发现流量并没有恢复。
于是运营统计了下用户的意见反馈信息：
发现大部分用户都是说cmwap下面有问题，于是赶紧在测试环境试了下，果然重现了，既然重现了按理说问题很好查了，其实这时我已经比较肯定是客户端的代码有问题了。于是开始排查客户端上传的错误日志，但不知道是错误信息记录不完整还是上传不及时，客户端的一些错误码并没有指引我们走到正确的路上……客户端开发也说新老版本代码没区别。
既然服务端没问题，客户端也好好的，那么只能怀疑是cmwap网络中间传输有问题了，因为cmwap的确是比较奇葩的。我开始怀疑cmwap是不是把http什么请求头过滤掉导致的？就在我茅厕顿开的时候，客户端发现了:
说是bug也不完全算。客户端发现新老版本有个区别就是请求服务端的时候多带了一个http头：Accept-Encoding:gzip
我们都知道：
据HTTP协议，如果你可以处理GZip格式，并且希望服务器以GZip的格式来返回内容，需要在HTTP的请求的Header中声明"Accept-Encoding"为"gzip"，如果服务器可以将内容压缩为GZip格式，那么服务器返回的Response的Header中将会设置"Content-Encoding" 属性的值是gzip，同时将返回的内容压缩为GZip格式。
但是事实却发现移动的WAP网关似乎没有按套路出牌，要不就是把gzip给吞了但同时又压缩了，要不就是返回了Content-Encoding但是没压缩，而且似乎并不是每次都会有问题。至于具体细节，客户端上传的错误信息没有价值，我也没好意思找他们要代码联调。反正测试环境把gzip去掉是好了，等着故障报告吧。
从这次故障我得出三点式泳衣是有益的：
1、上线前的集成测试的重要性；
2、错误信息记录准确完整的重要性；
3、用户反馈的重要性（新打的客户端包正在给反馈的用户在测试）。
PS:哪位大神对移动WAP网关比较了解，不吝赐教，总感觉这还不是真相，但跟mh370失联一样真相只有一个！
PPS:对不起大家，我标题党了。为mh370上的所有人祈福，奖金没了可以再赚，生命只有一次。
欢迎访问我的新博客：http://zhanjindong.info/2014/03/13/cmwap-accept-encoding-issue/