经验谈：无线网关潜规则及开发建议

　　本文来自腾讯大讲堂(DJT.QQ.COM)，转载请注明出处。

　　作为腾讯无线的一名研发人员，我和我们的团队在开发和运营过程中碰到了一些有线网络环境碰不到的问题，也积累了一些经验，希望分享给大家。

      我们经常碰到的网络问题都和网关有关，由于无线网关设备的供应商很多（华为，中兴，诺西等），难免存在不同的限制和规则，而且一旦发现问题，设备的更新速度也比较慢，但业务又需要快速调整，所以要想办法兼容这些规则。

      首先对两个出现比较多的名词解释下：

       接入点（apn）：上网方式，常见的有cmwap，cmnet，ctwap，ctnet，3gnet，3gwap等。

       Wap网关：在用户手机和业务服务器中间的一个代理层，在这里会控制一些计费，头部转换等。

        1.关于网关限制回包和限制上传包的大小

       机制回溯：国内几乎所有厂家的网关都有一个开关，可以来设置用户上传数据或服务器返回数据的大小，如果超过大小就截断或者直接失败，例如诺西的一些网关限制回包为3M，华为部分是10M，有些没有打开这个开关。原因主要是性能问题，因为网关的策略一般是把数据包收全后发给用户或者服务器，那么对于高并发的请求以及大量的用户，一旦下载或者上传增加，那么系统内存必然是个瓶颈，所以用限制大小来缓解，这个在设备上修改的难度也很大。

       导致问题：用户经常下载失败或者下载成功了安装失败，上传的时候直接提示错误，小图成功，大图失败等。

       开发建议：下载包那个实在是没有办法了，现在安卓和爱疯的包动不动就十几兆，所以还是推荐支持断电续传，通过多次少量来下载，这样可以提高成功率，也是运营商推荐的做法。上传有点矛盾，高清无码是我们的追求，但是大小限制摆在这里，建议是有限压缩，分片上传，也是用迂回的策略来提高成功率，让用户无码。

        2.关于资费提醒页面，业务推荐页面，网络欢迎页面

       机制回溯：这里的问题也是出现在当月第一次联网或者当天第一次联网的时候（具体视网关配置而定），用户联网的时候如果访问的域名或者ip不在资费提醒白名单中，则会出现资费提醒页面或者是欢迎页面，而这个时候用户需要手动点一下允许才能通过这个页面，具体的引导多为302和直接200返回提醒页面。

       导致问题：这里的问题就是我们的请求拿到的并不是我们希望返回的数据，而且在有些提醒中，如果用户不点击允许，只是重连，多少次也还是会有这个提醒，这就导致了如果终端支持go也支持了重连，但是仍然会失败。

      开发建议：支持go和重连同时post尽量不放第一个请求，另外加上重试次数的限制，比如重试5次都失败，则页面上提示用户用浏览器打开或者直接调用系统浏览器来打开网址，很有可能就会涉及需要用户主动点击的页面，然后再回来软件内部进行操作。

       3.关于x-online-host头部的作用和设定

       机制回溯：这个字段算是wap方式下一个特殊产物了，因为wap网关全部代理了手机的上网行为，也就是任何访问都会到10.0.0.172（类似这个）去接受网关的代理，如果需要往其他域名发送请求就有问题，因为请求都要用http://10.0.0.172/xxxxxxx类似的格式发到网关，那么网关就没有办法知道要访问的真实目标域名，于是就有了xonline这个头，让业务把目标的域名放在这个头部里面，然后由网关解析：如果没有http://的话，则作为相对URI，用X-Online-Host字段进行补全；如果有http://字段的话，则将host替换为X-Online-Host的值。

       导致问题：现在网关基本都有优化，如果没有这个头也没有关系，不过在工作中还是碰到了几个与之相关的问题，2011年有一段时间如果在cmwap接入点下不加x-online-host头，则手机侧发送任何post包都会直接被拒绝，另外还有一个问题就是这里中划线还是下划线的问题，应该是中划线，但是有些网关碰到下划线也能正常工作，不过不能保证。

        开发建议：判断用户的联网方式，如果是wap方式则将x-online-host头加上，内容为业务具体的域名。另外推荐一种做法，服务器拿到用户ip后计算出合适的服务器ip给用户，然后用户采用直接ip的方式来访问，同时还能减少域名解析的时间。

        4.关于serverlist以及写死服务器ip

        机制回溯：这个不用多说，相信大家都被放出去的终端版本里面有写死ip，导致迁移难，故障恢复难的事情困扰过。

        导致问题：难容灾，不方便迁移，而且一旦没有记录，后续撤销服务器的时候会因为不知道哪里来的访问而头疼。

       开发建议：支持可以配置的serverlist。大部分产品的做法是下发serverlist，客户端按照顺序尝试，比如联通的用户给下发依次为联通、电信、移动的服务器，如果联通服务器失败则走电信，然后如果全部失败需要有一个域名解析作为备份策略，以防失败的时候能够从域名的dns来控制用户的访问。当然serverlist如何下发，客户端按照什么方式来请求需要单独考虑。

         5.关于泛域名解析的一个潜规则

         机制回溯：android自带浏览器以及部分浏览器不能解析cname到泛域名的域名。比如a.qq.com cname到*.qq.com，那么浏览器在访问a.qq.com就会出错。（关于泛域名，其实就是如果xxx.qq.com没有单独申请解析，但是*这个泛域名有解析那么就会走*，这个可以减少域名解析申请工作）。

        导致问题：域名访问失败。

        开发建议：尽量避免cname到一个泛域名。

        6.关于wap网关主动超时断开或者超时重连

       机制回溯：wap网关上通常有一个设定，是关于和手机之间的超时的设定，具体就是当tcp链接建立以后如果一段时间没有任何数据交互，则网关会主动发送fin或者rst关闭这个tcp链接，这里主动发送是指分别向手机和服务器各发送结束包。这里一段时间可能是15s或者30s不等。目的是为网关节省tcp established的链接。

       导致问题：第一是对于主动使用keepalive头的应用，一般keepalive的链接，服务器发完数据后不会主动去断开这个链接，中间如果没有数据的时候很可能被网关主动断开，导致访问耗时增加。第二是对于有长连接的应用比如手机QQ，问题也是没有数据的时候被网关断开，增加耗时。第三是有些信号差的地方手机到网关中间质量不太好，会有短暂没有数据的情况，网关也会主动关闭，导致访问失败，比如软件下载这种耗时比较长的应用。

       开发建议：断开链接一般只会导致耗时增高，因为需要重新建立链接，重新dns等，所以一般业务不用十分在意，对于延时有较高要求，且对于链接保持有要求的应用应该考虑定期的数据交互，比如每15s中在同一个链接上发送心跳等策略，当然流量需要另外考虑。

        7.关于server端开发和服务器设定的一些建议

        机制回溯：这里主要还是因为网关功能比较多，经常出问题的：经过网关后一个访问可能由相对路径变成全路径访问，也就是会出现由GET /qcy.jsp变成GET http://a.qq.com/qcy.jsp这样的全路径；经过网关后一些访问请求里面的特殊字符可能会被转义，比如空格变成%20之类；经过网关后http header里面的字段可能由首字母大写变成小写，从Host变成host这样。

       造成问题：如果服务器不支持，访问就会失败，404或者500返回。

       开发建议：服务器需要支持绝对路径访问（rfc标准），要能够兼容header的大小写。那个被转码没有办法，只能说在开发过程尽量保持大小写的一致（最好都是小写）并且少用特殊字符尤其是空格，最后就是server默认要支持keepalive方式。

        服务器设定：服务器本身这里只说下最关键的tcp快速回收参数（tcp_tw_recycle），部署在最前面和用户直接交互的机器（接入层，或者对外提供服务的机器）这个参数必须要0，关闭。原因就是网关是属于很多用户公用一个出口的，时间戳会对系统的判断造成影响，可能导致服务器一个时间只给最新时间戳的服务，其他都直接回收。另外，对于下载类的

server，最好放弃关于一个链接超时的设置，在无线环境下多久的时间也有，比如下载一个20M的需要几个小时，是可能的，需要特别关注下。

        8.关于数据大小对于用户速度和成功率的影响

        机制回溯：正是因为在无线环境中用户的包往往需要经过几百ms才能到服务器，这里就可以想到在tcp链接中，客户端的一个ack有多值钱，如果一个请求被分成了10个包，假设客户端回复了三个ack，那么就光这里就耗去了大概两秒钟，而且等待ack的过程中基本访问是卡住的。另外就是多一次来回失败率也会上升的。

        导致问题：体验差，访问慢，失败率高。

        开发建议：首先控制回复的数据的大小，这是重中之重；用gzip来尽量缩小回包；另外就是想办法调优tcp协议，让客户端需要发的ack尽量少，但是这里很大程度和手机系统的实现还相关，这里没有太多尝试过，能做的应该是调大初始窗口，发送缓存，加快重传的时间间隔等，让一次性尽可能发更多的数据，发现问题后也能尽快发起重传。

希望这些经验能对刚进入无线领域的朋友有所帮助。