zoukankan      html  css  js  c++  java
  • 飞机找不到,流量哪去了?记一次移动WAP网关导致的问题

    这几天随着客户端一个新版本发布,运维发现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/

  • 相关阅读:
    evernote100个做笔记的好方法
    平衡二叉树的调整模版
    晨间日记的奇迹
    hdu 2952 Counting Sheep
    hdu 1535 Invitation Cards
    poj 3259 Wormholes(spfa)
    poj 2263 Heavy Cargo(floyd)
    poj 3268 Silver Cow Party(SPFA)
    hdu 1690 Bus System
    hdu 3631 Shortest Path(Floyd)
  • 原文地址:https://www.cnblogs.com/zhanjindong/p/3599360.html
Copyright © 2011-2022 走看看