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

阅读: 评论:0

弱⽹络环境下最优调度和优化传输层协议⽅案
转载:
背景
与有线⽹络通信相⽐,⽆线⽹络通信受环境影响⽐较⼤(例如⾼层建筑、⽤户移动、环境噪⾳、相对封闭环境等等),⽹络的服务质量相对来说不是⾮常稳定,导致⽤户经常会在弱信号的⽹络环境下通信。⽽当⽤户在这种⽹络环境下通信时,则存在较多的丢包、误码、超时、连接中断以及难以接⼊⽹络等情况。通信除了受环境影响以外,⽹络覆盖和室分系统不完善、邻区漏配、导频污染、过载控制等原因也都会产⽣⽆线呼叫掉线、服务质量下降等问题。
如何度量和模拟“弱⽹络”对移动APP的开发有着重⼤的意义:节约测试成本、易于问题重现、加快产品上线等。⼀般的⽅法是使⽤“丢包率”和“⽹络延时”来定义和衡量“弱⽹络”[10-12]。
在⽆线⽹络通信中,⽆线资源(频率、时间、空间等)是⾮常稀缺的。为了满⾜更多⽤户的PS业务需求,移动系统会尽可能地把⽆线资源复⽤给不同的⽤户。⽐如,当⽤户在⼀定时间内(对于3G,⼀般是15秒,对于2G,可能会⽐较短)不再传送数据时,移动系统会主动回收分配给该⽤户的⽆线资源,以复⽤给其它⽤户。当该⽤户再次需要通信时,移动设备(Mobile Equipment)需要重新申请⽆线连接,然后
才能发送数据。另外,当ME处于能够随时发送数据的状态时,会消耗⼤量的电能。所以为了节能,ME发现在⼀定的时间内(⼀般是2~10秒)没有数据传送时,也会主动要求释放⽆线资源。申请⽆线资源是⾮常昂贵的操作,需要⽐较多的信令(⼤约相当于发送或接收⼀条短消息),如果频繁发送⼩数据包(⽐如⼼跳),容易导致“信令风暴”。上述的这种类似“快速休眠”特性的延时到底有多长,与ME和⽹络都有关系,没有办法⼀概⽽论。⽆线⽹络的延时情况可以参考图1:
需要注意的是:在实际情况下,对于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服务器来实现最优调度,其拓扑结构如下:
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]
[2]
[3]
[4]
[5]
[6]
[7]
abs082[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]

本文发布于:2023-07-29 02:27:53,感谢您对本站的认可!

本文链接:https://patent.en369.cn/patent/4/196611.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:客户端   域名   列表
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2022 Comsenz Inc.Powered by © 369专利查询检索平台 豫ICP备2021025688号-20 网站地图