弱网络环境下最优调度和优化传输层协议方案

一、背景

与有线网络通信相比，无线网络通信受环境影响比较大（例如高层建筑、用户移动、环境噪音、相对封闭环境等等），网络的服务质量相对来说不是非常稳定，导致用户经常会在弱信号的网络环境下通信。而当用户在这种网络环境下通信时，则存在较多的丢包、误码、超时、连接中断以及难以接入网络等情况。通信除了受环境影响以外，网络覆盖和室分系统不完善、邻区漏配、导频污染、过载控制等原因也都会产生无线呼叫掉线、服务质量下降等问题。

如何度量和模拟“弱网络”对移动APP的开发有着重大的意义：节约测试成本、易于问题重现、加快产品上线等。一般的方法是使用“丢包率”和“网络延时”来定义和衡量“弱网络”[10-12]。

在无线网络通信中，无线资源（频率、时间、空间等）是非常稀缺的。为了满足更多用户的PS业务需求，移动系统会尽可能地把无线资源复用给不同的用户。比如，当用户在一定时间内（对于3G，一般是15秒，对于2G，可能会比较短）不再传送数据时，移动系统会主动回收分配给该用户的无线资源，以复用给其它用户。当该用户再次需要通信时，移动设备(Mobile Equipment)需要重新申请无线连接，然后才能发送数据。另外，当ME处于能够随时发送数据的状态时，会消耗大量的电能。所以为了节能，ME发现在一定的时间内（一般是2~10秒）没有数据传送时，也会主动要求释放无线资源。申请无线资源是非常昂贵的操作，需要比较多的信令（大约相当于发送或接收一条短消息），如果频繁发送小数据包（比如心跳），容易导致“信令风暴”。上述的这种类似“快速休眠”特性的延时到底有多长，与ME和网络都有关系，没有办法一概而论。无线网络的延时情况可以参考图1：

图1 无线网络延时[9]

需要注意的是：在实际情况下，对于GPRS/EDGE网络出现秒级别的延时也不奇怪。

移动终端APP在通信的过程中消耗电量的情况如何，降低电能消耗的原则有[13]：

1）3G下传输数据消耗的电量是WIFI下的几十倍；

2） 手机在传输数据的状态下消耗的电量要远远高于IDLE状态下消耗的电量；

3）降低发包频率，尽可能地把数据包合并，然后一起发送；

ME通过无线网络接入服务器的整个过程如下（以ME主动发起请求为例）：

A）分配无线连接，建立上下行专用的高速信道；

B） 解析接入点(APN)域名，获取接入Internet的网关GPRS支持节点（GGSN）的IP，然后GGSN进行鉴权，以及为ME分配IP；

C）GGSN执行DNS查询；

D）建立TCP连接；

E）接收或发送数据；

F）如果没有数据传输，超过一定的时间，释放无线连接；

G）如果没有数据传输，超过一定的时间，释放TCP连接；

在整个过程中，减少DNS的影响可能是首要的目标，移动网络的DNS有如下特点[1]：

·             有一部分全国范围的DNS承载了超过40%的全网用户；

·             很多山寨机的终端local dns设置是错误的；

·             也包括有线网络遇到的问题：域名劫持、DNS污染、老化和脆弱等问题；

·             现有的DNS不能把用户调度到服务的“最优接入点”；

从以上分析可知，如何保证移动互联网的产品提供稳定的、可预期的服务质量，具有非常大的挑战。以下几点原则可能会有帮助：

1） 断线重连。这可能是最重的一个特性，因为在无线网络中有太多的原因导致数据连接中断了。

2） 由于创建连接是一个非常昂贵的操作，所以应尽量减少数据连接的创建次数，且在一次请求中应尽量以批量的方式执行任务。如果多次发送小数据包，应该尽量保证在2秒以内发送出去。在短时间内访问不同服务器时，尽可能地复用无线连接。

3） 优化DNS查询。应尽量减少DNS查询、避免域名劫持、DNS污染，同时把用户调度到“最优接入点”。

4） 减小数据包大小和优化包量。通过压缩、精简包头、消息合并等方式，来减小数据包大小和包量。

5） 控制数据包大小不超过1500，避免分片。包括逻辑链路控制（Logic Link Control）分片、GGSN分片，以及IP分片。其中，当数据包大小超出GGSN所允许的最大大小时，GGSN的处理方式有以下三种：分片、丢弃和拒绝。

6）优化TCP socket参数，包括：是否关闭快速回收、初始RTO、初始拥塞窗口、socket缓存大小、Delay-ACK、Selective-ACK、TCP_CORK、拥塞算法(westwood/TLP/cubic)等。关于这些参数的优化建议可以参考[1-8, 30]。做这件事情的意义在于：由于2G/3G/4G/WIFI/公司内网等接入网络的QoS差异很大，所以不同网络下为了取得较好的服务质量，上述参数的取值差异可能会很大。

7） 在弱网络的情况下，TCP协议中的ACK包是非常昂贵的，延时甚至能够达到秒级别[14]，而TCP协议的拥塞控制、快速重传、快速恢复等特性都非常依赖接收端反馈的ACK包。可想而知，如果发送端接收到的ACK包延时太长，会严重影响TCP协议的效率。但是如果发送ACK太多又会占用宝贵过多的无线资源。在移动网络下通信，“在可靠的连接上，如何在减少ACK包的情况下，降低数据包的延时”是研究的热点[15-28]。基本的思想：平衡冗余包和ACK包个数，达到降低延时，提高吞吐量的目的。例如SGSN和GGSN之间的通信实现：二者之间通过UDP协议通信，发送者在无新的数据包的情况下，每隔一定的时间重试已发送的包，达到最大重试次数后，则丢弃该包。

8） TCP的拥塞控制算法是以“丢包意味着网络出现拥塞”为假设设计的，很明显这个假设在无线网络环境下是不合适的。但是在无线网络环境下，在设计可靠UDP协议时是否能够完全丢弃拥塞控制呢？[39]中提出了几种在无线网络环境下的TCP友好的拥塞控制算法。

9） 长连接/短连接，支持不同协议（TCP/UDP, http、二进制协议等），支持不同端口等。关于更多的建议请参考[1,14,29]。

目的

在无线网络环境下，本文将从最优调度和优化传输层协议两个方面来讨论如何保证客户端和服务器的通信成功率，以及提高通信效率。

最优调度设计

系统分解

设计一个新的DNS服务器来实现最优调度，其拓扑结构如下：

图2DNSvr的拓扑结构

TGCP SDK的职责：

I） 用HTTP的Get/Post方法从DNSvr获取游戏服务器和DNSvr本身的最优接入点列表。Get/Post方法的查询参数包括uin/openid、客户端版本号、IP列表的MD5（注意IP顺序）、域名列表、VIP、ServiceID等。

II） 缓存访问游戏服务器和DNSvr的IP列表，以及其它元数据（比如IP列表等），且以APN为主键[34]。

III） 满足一定的条件下，要主动更新缓存的IP列表，例如缓存过期。

注意：这些职责也可以从TGCP SDK中分离，形成一个独立的SDK。

Tconnd的职责：

·             路由查询请求给活动的DNSvr；

·              

DNSvr的职责：

I） 根据静态和动态策略来决定客户端的“最优接入点”。静态策略：根据uin/openid、客户端版本号或者强制规则来决定IP列表；动态策略：灯塔根据测速数据动态决定用户的游戏服务器接入点。

II） 支持以手动或自动的方式拉黑某些IP。自动方式：由游戏服务器的接入tconnd向DNSvr上报其是否存活（需要向多个点上报，包括用公网IP上报），如果在一定时间内没有接收到上报或者上报消息中明确所有的逻辑服务器已经挂掉，则自动拉黑相应的IP。如果业务恢复，则自动激活相应的IP。如果项目组接入TGW，对于某个IP和端口是否可用，则需要考虑进程与VIP的映射关系。

III） 在tcaplus中缓存灯塔的计算结果。此时要求DNSvr能够根据客户端IP判断所属的国家、省份、运营商和网关（可以通过访问MIG的IP库实现）[37]。如果缓存了灯塔的计算结果，当缓存超时后，要重新从灯塔拉取相应数据。

灯塔的职责（即哈雷项目[38]）：

根据客户端IP和服务器接入点IP，返回最优的接入点列表，包括IP的排序，以及客户端接入的国家、省份、运营商、APN和网关。

Tcaplus的职责：

保存游戏接入的IP列表和端口、静态策略，或缓存灯塔的计算结果；

主要的流程

·             客户端批量解析域名流程

1.          TGCP以APN和域名列表为关键字查询缓存，如果存在且没有过期，则直接把IP返回给用户。如果指定强制解析域名列表，则跳过此步骤；

2.          TGCP用预配置或缓存的IP向DNSvr发起查询请求，如果成功返回结果，则执行步骤3，否则，重试IP列表中的其它IP，如果都失败，则用域名访问DNSvr。注意：如果是结果格式不正确，则使用上次的IP重试，不要更换IP重试[14,29]。

3.          DNSvr比较客户端IP列表和当前最新的IP列表的MD5，如果相等，则告诉客户端不需要更新本地缓存。否则，TGCP把接入游戏服务器和DNSvr的IP列表写入本地。注意：在访问服务器时，这些IP的优先级要高于静态配置在客户端的IP。

·             客户端使用域名访问游戏服务器流程

1.          如果本地存在有效的IP（即存在对应APN的IP列表，且没有失效），则使用IP访问游戏服务器。

2.          否则，发起“客户端批量解析域名流程”后，再访问游戏服务器。

·             游戏服务器接入tconnd主动上报状态流程（仅供参考）

1.          Tconnd周期性向DNSvr上报心跳消息，其中包含本接入点是否可用的信息。

2.          DNSvr在一定的时间内没有收到心跳消息或者相应的接入点不可用，则把相应的IP和端口拉黑，黑掉的IP不在下发给客户端。

注意：实际部署的时候，游戏接入的Tconnd要向多个DNSvr接入tconnd上报。

·             向客户端主动push接入点列表的流程

1.          当TGCP连接到游戏服务器接入的Tconnd时，Tconnd要向DNSvr发起请求，以校验当前接入IP的质量和时效性。如果IP列表发生变化，Tconnd要把最新的IP列表下发给客户端缓存起来。

2.          当TGCP下次访问游戏服务器时，则使用最新的IP列表。

·             客户端访问DNSvr失败的流程

1.          如果访问DNSvr失败（包括IP+域名），如果配置了本地IP，则直接用IP访问游戏服务器，否则用域名访问。

优化传输层协议设计

在原有tconnd支持的可靠UDP的基础之上，添加以下逻辑：

·              数据压缩；

·             数据加密；

·             合并多个数据包；

·             支持流式数据传输，便于控制每个UDP包的大小，也便于数据加密和压缩；

·             可选地支持[39]中的拥塞控制算法；

·             即使没有接收到ACK包，也需要主动重试以发送的数据包；

参考文件

[1] 一秒钟法则，http://www.infoq.com/cn/articles/1sec-rule-from-tencent；

[2]Linear network coding， http://en.wikipedia.org/wiki/Linear_network_coding；

[3]Network Coding for Wireless Applications: A Brief Tutorial，http://www.ctr.kcl.ac.uk/IWWAN2005/papers/81_invited_Muriel.pdf；

[4]Application of Network Coding in TCP,http://stanford.edu/~kvenkat/documents/ee673_report.pdf;

[5]CodeMP: Network Coded Multipath to Support TCP in Disruptive MANETs,http://nrlweb.cs.ucla.edu/publication/show/753;

[6]Enhanced Network Coding Scheme for Efficient Multicasting in Ad-Hoc Networks,http://www.wseas.us/e-library/conferences/2013/Dubrovnik/ECC/ECC-64.pdf；

[7]Evaluation and Enhancement of TCP with Network Coding in Wireless Multihop Networks,http://uu.diva-portal.org/smash/get/diva2:408936/FULLTEXT01.pdf；

[8]Linear Network Coding to Increase TCP Throughput,http://www.unc.edu/~marzuola/Math547_S13/Math547_S13_Projects/A_Britt_Section001_NetworkCoding.pdf;

[9]TenDoc: Network Coding-based Software for Wireless Ad hoc Networks,https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CBwQFjAA&url=http%3a%2f%2fwww%2ethinkmind%2eorg%2fdownload%2ephp%3farticleid%3dmesh_2011_2_20_50015&ei=DgTXU9C9Osfn8AXjk4HADw&usg=AFQjCNG9pLly4EMcbgxuG6qd-kF1n4UumQ；

[10]Network coding meets TCP: theory and implementation,https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CC4QFjAB&url=http%3a%2f%2fdspace%2emit%2eedu%2fopenaccess-disseminate%2f1721%2e1%2f75026&ei=TwTXU_KtHIr18QWLpYCQAg&usg=AFQjCNH0yZ1-pQJcr74U3YxCI-i5zYnzNw；

[11]NCAPQ: Network Coding-Aware Priority Queueing for UDP Flows over COPE,http://www.deepdyve.com/lp/institute-of-electrical-and-electronics-engineers/ncapq-network-coding-aware-priority-queueing-for-udp-flows-over-cope-kb0IcVwFsF；

[12]The Importance of Being Opportunistic: Practical Network Coding for Wireless Environments, http://www.mit.edu/~medard/PAPERS/paper142.pdf;

[13]TCP and Network Coding Equilibrium and Dynamic Properties,http://www.networkcoding.org/posters/23.pdf；

[14]Low Computational Complexity Network Coding for Mobile Networks，http://vbn.aau.dk/files/123241894/Thesis_Low_computational_complexity_network_coding_for_mobile_networks_.pdf；

[15]Video Streaming with Network Coding,http://www.vis.uky.edu/~cheung/doc/jsps08.pdf；

[16]哈雷项目for互娱研发部_20140806.pptx，哈雷项目；

[17] TCP-Friendly Congestion Control over Wireless Networks,http://www.researchgate.net/publication/2879726_TCP-Friendly_Congestion_Control_over_Wireless_Networks;