手游接入层优化那些事

一．移动网关特性解决方案

移动网关时序错乱解决方案

移动游戏比PC游戏多了中国移动运营商和wap/net等APN接入，网络变得复杂。

选择网络质量有保障的上海三通机房（移动/电信/联通）。

 

针对移动cmwap时序错乱导致丢包解决方案。

移动网关cmwap是属于很多用户公用一个出口的类型，而且cmwap发来的包的时间戳是乱跳的，如果打开了tcp_tw_reccycle就会把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”。所以手游服务器必须把/proc/sys/net/ipv4/tcp_timestamps 改为0。

7层协议串号解决方案

微信区域名与手Q区域名使用相同的vip，在访问同一个业务时，某些操作情况下在短时间内访问此两域名，客户端代理防火墙或者某些移动网关看到两域名解析成同一个目标ip，将两个请求合并在同一个连接中；

解决方案：

对于7层协议业务，微信区和手Q区申请不同的vip解决。 

 

TGW负载不均衡解决方案 

天天酷跑扩容后过载：由于tgw负载不均衡的影响，当单机在线超过2.2w时如果tgw仍然导入新链接到此机器，会导致用户登录不成功影响用户体验。

tgw是根据权重轮询来分配新进连接的。只要rs的提供的服务端口是可用的，权重是正常，它就会一直分配新进连接到rs上。

由于TGW探测rs实时连接数的机制还没办法得到准确数据，所以他们暂时也没办法根据rs的连接空闲情况来分配新进连接。

 

解决方案：

借鉴最小加权连接的思想，增加一个外围模块，负责扫描不同rs 的负载（暂定为当前连接数），如果负载比与业务设置的配置权重比不一致，就动态调整实时权重比例， 直到RS的负载比与配置权重比几乎一致为止。(误差5%以内视为近似相等，不再动态调整权重) 

调整开始：发现RS1:RS2负载/权重差异>5%的精度，即发起调整

调整结束：发现RS1:RS2负载/权重差异≤5%的精度，就结束调整

调整频率：每隔5秒

调整算法：

 

移动游戏国外用户解决方案

由于移动用户的移动特点，部分用户会在国内下载了手游到港澳台或者国外使用。

受国际出口带宽限制和GFW影响，体验很不好。

 

解决方案：

在上海三通机房基础上需增加香港接入点（香港TGW直连上海RS）。

推动香港深圳专线扩容。 

 

手游域名劫持解决方案

运营由于节省网间流量，加快用户访问速度等原因，会对域名进行劫持，导致游戏不能访问。

解决方案：

1.wifi用户接入公司域名劫持监控系统。

2.2g/3g用户调用sdk进行域名监控。

3.香港用户通过部署客户端监控APP进行域名监控。

4.SDK提供故障定位工具，发现域名劫持后引导用户解决。

可选解决方案：

SDK自己实现DNS功能，并接管手游的socket通讯。

 

二．手游DDOS攻击优化方案

手机端多用户共出口移动网关场景，以及弱网情况的存在，基于此攻击手法的源IP+TTL的防护验证算法对此类手游业务有一定的影响，导致在防护过程中，业务存在用户在线的异常波动，少量用户无法登录游戏或登录多次才能成功。

解决方案：

一．手游保护策略和端游分开，手游防护算法策略配置为1~6秒(端游3秒左右)。

二．在同城大容量防御节点机房部署多个VIP。

 

三．手游容灾调度解决方案

精品手游解决方案：

开放平台游戏解决方案：

优化效果：

 

四．异构架构特性解决方案：

服务器国外部署解决方案

优化前网络访问图：运营商国际出口带宽和防火墙是游戏访问的瓶颈。

优化后网络访问图：我们通过腾讯的TGW同运营商接入，腾讯深圳香港专线，ip tunnel技术和四层代理转发技术，绕开了国际出口带宽和防火墙两个瓶颈点。

访问优化效果：（单次访问时间，一次游戏登录或交互有多次访问）

Wifi访问平均耗时由724ms优化到198ms，非wifi访问平均时间由1173ms优化到621ms。

当前方案风险：

1.游戏直连和代理两种方式wap方式接入的成功率较低（移动cmwap，联通uniwap，电信ctwap），wap用户占所有用户6%左右，其中移动cmwap用户占移动用户13%左右。
2.HA代理只支持IP方式转发，当king的域名ip发生变化时，已经和king达成一致IP变更时提前知会我们进行转发IP切换。同时我们也做好各种连通性监控：
3.分钟级游戏域名解析，发现解析域名和转发域名不一致马上告警。
4.转发服务器IP连通性测试，发现转发IP无法链接马上告警。
5.TGW转发请求数的监控。

 

 

 

法律风险已经备案：

1.通过专线在腾讯内地、香港之间做数据交互，专线本身也是接受国家相关部门的监管的，不存在违规问题。

2.游戏的帐号系统是通过MSDK接入的，在MSDK中，用户的帐号信息，关系链信息等敏感数据都已经转换为openID，不是直接使用用户帐号，所以不会涉及泄漏玩家帐号和个人隐私信息的泄漏问题。在整个数据的传输过程中，MSDK也对数据从客户端到服务端做了全程的加密处理，防止被篡改和泄漏。

 

手游多端口代理解决方案 

IEG手游接入这边，需要接入一个日本游戏monster strike，这款游戏用到了一个叫stun的协议，RFC号为5766，是用于UDP，TCP穿透NAT连接用的协议。由于有了这个协议的存在，我们在跨运营商运营方面，使用起TGW就变得非常困难。（需要配置数万个端口）

 

建议进行结构改造，以适应TGW的跨网访问使用。在TGW和TURN SERVER之间架设一层TCP层代理，以解决跨网访问问题及大范围的端口收敛工作。 

 

一．原有结构访问流程

原有结构访问方面，主要是利用turn server做NAT的穿透，通过一个relay adress进行中转，本文中，relay adress就是turn server ip + port 16000。

 

1.Host user A用户向turn server的3478端口发起连接，申请资源

2.Turn server反馈，可以用turn server ip + port 16000作为 relay address

3.Host user A向turn server的 16000端口发起连接，和relay address建立tcp连接

4.User B通过APP server知道host user A的IP和端口后（turn server port 16000），向其发起连接，连接成功后，user A和user B通过relay adress建立起 P2P关系。

问题：

1.服务器几乎没有外网IP

2.不同运营商用户的连同一个IP，网络质量很差

3.一个房间一个端口，资源浪费严重，按照50W在线需要40W端口。

二． 跨网代理方案访问流程

 

1.Host user A向TGW发起连接，申请资源

2.TGW通过IP TUNL技术把流量转发至turn server的3478端口

3.Turn server返回申请的relay address port16000到TGW

4.TGW把relay address发给host user A

5.Host User A把relay address（IP + port）发给APP SERVER

6.Houst user A向TGW发起连接请求，带上appid，openid/mid，ip，port

7.TGW通过IP TUNL把连接请求转向proxy，proxy连接成功后，接收host user A发过来的appid， opened，mid(mac地址)， ip，port，用于下一步连接。

8.通过带上来的IP和port ，proxy连接对应的turn server 的IP和port。

9.User B通过APP server查到需要的IP和PORT

10.User向TGW发起连接请求，带上appid，openid/mid，IP， PORT。 

11.TGW通过IP TUNL把连接请求转向proxy，proxy连接成功后，接收user B发过来的appid， uid， IP，PORT，用于下一步连接。

12.通过带上来的的IP和PORT，proxy连接到对应的turn server port 16000上。

优点：

1.       有效的解决端口资源问题，对外只用一个端口即可。

2.       有效解决不同运营商网络访问问题，使用域名访问。

3.       游戏方客户端和服务端几乎不用修改，msdk提供底层封装connect协议的接口。

4.       可在proxy统一进行抓包、日志查询、恶意流量控制、防雪崩等操作。

 

三．拆房间的过程

分两种情况:

1.普通用户退出或断线。

这种情况，proxy检测出退出或断线的用户属于普通用户后，直接拆掉与turn server建立的连接即可。 

2.Host user退出或断线。

这种情况下，proxy一旦检测出退出或断线的是Host用户，则把对应连接到同一个IP和PORT的所有到turn server的连接全部断开。 

3.App server发出关闭房间信号。

处理方法同2 

4.Turn server断开连接，无论turn server断开的是哪个从proxy到turn server连上来   的连接，proxy均   需要关闭对应的user到proxy之间的连接即可。即由turn server管理      正常连接请求，proxy只做透明的转发处理。

 

四．其他需求点 

安全需求：

1.安全访问控制列表。我们需要在proxy上建立一个安全访问的端口列表，确保访问端口是落在安全访问端口的白名单内，避免用户伪造请求，发送一个（举例）向turn server的36000或56000及任何高危端口的请求。 

2.端口请求数量限制。对于任意一个turn server端口，我们可以对其进行连接数量的限制，以避免攻击流量导致端口大幅度占用。

 

Debug需求：

1.在用户向TGW发起连接请求时，带上openid/mid，以对连接进行唯一性判断和跟踪，降低debug的难度，提高debug的效率和准确性。

2.日志方面，需要兼顾有效debug及日志量庞大这个问题。默认采取客户端连接，断开，及异常如超时，闪断等情况的日志，其他正常传输的日志则不进行记录，以取得在debug和日志量庞大中的平衡点。

 

作者：张丹，新终端运维中心副。

本文由腾讯WeTest授权发布，如需转载请联系腾讯WeTest获得授权。