wwwmgm8001 10

wwwmgm8001:重传类算法性能评估方案,实测数据

相关阅读

「腾讯云游戏开发者技术沙龙」1月19日杭州站报名开启啦~畅谈游戏加速

经典游戏服务器端架构概述
(1)

阻击外挂:《龙之谷手游》安全测试的那点事


此文已由作者授权云加社区发布,转载请注明原文出处

**传输层协议和延迟**

不同传输层协议在可靠性、流量控制等方面都有差别,而这些技术细节会对延迟造成影响。tcp追求的是完全可靠性和顺序性,丢包后会持续重传直至该包被确认,否则后续包也不会被上层接收,且重传采用指数避让策略,决定重传时间间隔的RTO(retransmission
timeout)不可控制,linux内核实现中最低值为200ms,这样的机制会导致丢包率短暂升高的情况下应用层消息响应延迟急剧提高,并不适合实时性高、网络环境复杂的游戏。

加速方案:

基于udp定制传输层协议,引入顺序性和适当程度或者可调节程度的可靠性,修改流控算法。适当放弃重传,如:设置最大重传次数,即使重传失败,也不需要重新建立连接。比较知名的tcp加速开源方案有:quic、enet、kcp、udt。其中,quic是源自google的tcp替代方案,其主要目的是为了整合TCP协议的可靠性和UDP协议的速度和效率,其主要特性包括:避免前序包阻塞、减少数据包、向前纠错、会话重启和并行下载等,然而QUIC对标的是TCP+TLS+SPDY,相比其他方案更重,目前国内用于网络游戏较少。kcp的作者是国内优秀开发者,社区也发展良好,kcp的作者和社区开发者对enet、kcp、udt做了性能测试,详情可参见:github.com/skywind3000/kcp/wiki/KCP-Benchmark
,从测试情况可以看到,kcp表现不错,其次是enet,表现最差的是udt。不过,这里也提出一个问题,原始enet保留了tcp重传的指数避让特性,每次重传间隔还是乘以2,默认rto也较高,这可能是测试中enet表现不够好的主要原因,如果对enet代码稍作调整,结果又当如何?这里,我们先排除传输性能,从其他方面对enet和kcp做一对比(满分5分)。

wwwmgm8001 1

enet和kcp对比

我们对libenet略微做一些调整——默认rtt从500ms调整成50ms,
去除超时重传的指数避让策略。Linux下用TC命令模拟网络延迟和丢包率,控制延迟分别为30ms,
50ms, 70ms,控制丢包率分别为1%, 3%, 5%, 7%,
10%,在模拟出的不同网络环境下,对tcp,
原始enet和改进后的enet进行了对比测试。

wwwmgm8001:重传类算法性能评估方案,实测数据。测试中考察两个性能指标:

1)平均响应时间;

2)响应时间超过300ms的包的比例。

libenet的代码调整:

wwwmgm8001 2

调整默认RTT为50ms

wwwmgm8001 3

取消指数避让

tc命令如下:

wwwmgm8001:重传类算法性能评估方案,实测数据。延迟100ms(rtt为200ms): tc qdisc add dev eth0 root netem delay 100ms

wwwmgm8001:重传类算法性能评估方案,实测数据。1%丢包率:tc qdisc add dev eth0 root netem loss 1%

对比数据如下:

wwwmgm8001 4

不同丢包率和网络延迟下TCP协议、ENET、优化后ENET的平均响应时间对比

wwwmgm8001 5

不同丢包率和网络延迟下TCP协议、ENET、优化后ENET的超时响应比例对比

从图中可见,在平均响应方面,TCP协议的劣势不明显,在延迟为30ms,丢包率为1%时,改进后的enet平均rtt为69ms,
原始enet平均rtt为67ms,
tcp平均rtt为67ms;但是从响应时间超过300ms的比例看,在延迟为30ms,丢包率为1%时,改进后的enet
rtt超过300ms的包为0,而tcp
rtt超过300ms的比例则超过了2%,如果是在游戏中,这个表现已经能明显影响游戏体验了。结果表明,tcp在网络稍不稳定的情况下就已经有比较大的问题了,改进后的enet有明显优势。

基于上面的数据,google提出了对此类算法的一个简单评估方案:
采用现网流量进行对比测试:在西欧的服务器上面部署了三组服务器运行了五天(one
weekend plus 3 weekdays)的数据。具体描述如下:

wwwmgm8001:重传类算法性能评估方案,实测数据。wwwmgm8001:重传类算法性能评估方案,实测数据。加速方案

基于udp定制传输层协议,引入顺序性和适当程度或者可调节程度的可靠性,修改流控算法。适当放弃重传,如:设置最大重传次数,即使重传失败,也不需要重新建立连接。比较知名的tcp加速开源方案有:quic、enet、kcp、udt。其中,quic是源自google的tcp替代方案,其主要目的是为了整合TCP协议的可靠性和udp协议的速度和效率,其主要特性包括:避免前序包阻塞、减少数据包、向前纠错、会话重启和并行下载等,然而QUIC对标的是TCP+TLS+SPDY,相比其他方案更重,目前国内用于网络游戏较少。kcp的作者是国内优秀开发者,社区也发展良好,kcp的作者和社区开发者对enet、kcp、udt做了性能测试,详情可参见:,
从测试情况可以看到,kcp表现不错,其次是enet,表现最差的是udt。不过,这里也提出一个问题,原始enet保留了tcp重传的指数避让特性,每次重传间隔还是乘以2,默认rto也较高,这可能是测试中enet表现不如kcp的主要原因,如果对enet代码稍作调整,结果又当如何?这里,我们先排除传输性能,从其他方面对enet和kcp做一对比(满分5分):

 

wwwmgm8001 6

我们对libenet略微做一些调整——默认rtt从500ms调整成50ms,
去除超时重传的指数避让策略。Linux下用TC命令模拟网络延迟和丢包率,控制延迟分别为30ms,
50ms, 70ms,控制丢包率分别为1%, 3%, 5%, 7%,
10%,在模拟出的不同网络环境下,对tcp,
原始enet和改进后的enet进行了对比测试。

测试中考察两个性能指标:

1)平均响应时间;

2)响应时间超过300ms的包的比例。

libenet的代码调整:

wwwmgm8001 7

图 1 调整默认RTT为50ms

wwwmgm8001 8

图 2 取消指数避让

tc命令如下:

模拟延迟100ms(rtt为200ms): tc qdisc add dev eth0 root netem delay 100ms

模拟1%丢包率:tc qdisc add dev eth0 root netem loss 1%

对比结果数据如下:

 

wwwmgm8001 9

图 3 不同丢包率和网络延迟下TCP协议、ENET、优化后ENET的平均响应时间对比

 

wwwmgm8001 10

图 4 不同丢包率和网络延迟下TCP协议、ENET、优化后ENET的超时响应比例对比

从图中可见,在平均响应方面,TCP协议的劣势不明显,在延迟为30ms,丢包率为1%时,改进后的ENET平均RTT为69ms,
原始ENET平均RTT为67ms,
TCP平均RTT为67ms;但是从响应时间超过300ms的比例看,在延迟为30ms,丢包率为1%时,改进后的ENET
RTT超过300ms的包为0,而TCP
RTT超过300ms的比例则超过了2%,如果是在游戏中,这个表现已经能明显影响游戏体验了。结果表明,TCP在网络稍不稳定的情况下就已经有比较大的问题了,改进后的ENET有明显优势。

**Moba类游戏为什么对网络延迟要求高?**

我们知道,不同类型的游戏因为玩法、竞技程度不一样,采用的同步算法不一样,对网络延迟的要求也不一样。例如,对于炉石传说、斗地主、梦幻西游等回合制游戏来说,同时只有一个玩家在操作双方数据,无数据竞争,且时间粒度较粗,甚至可通过特效掩盖延迟,因此对网络延迟的要求不高,即便延迟达到500ms~1000ms,游戏也能正常进行;对于传统mmorpg来说,多采用状态同步算法,以属性养成和装备获取为关注点,也有一定竞技性,出于对游戏流畅性的要求,对延迟也有一定要求,同步算法的优化程度不一样,这一要求也不一样,一般情况下为保证游戏正常进行,需要响应延迟保持在300ms以下;相比之下MOBA类游戏多使用帧同步为主要同步算法,竞技性也最高,无论从流畅性,还是从公平性要求来说,对响应延迟的要求都最高,根据业内经验,当客户端与服务器的网络延迟超过150ms时,会开始出现卡顿,当延迟超过250ms时,会对玩家操作造成较大影响,游戏无法公平进行。这里,我们不对同步算法做进一步说明,重点说一下协议的问题。

tcp的状态切换函数使用的是:tcp_set_ca_state,下面将所有的相关函数调用:

MOBA类和“吃鸡”游戏为什么对网络延迟要求高?

我们知道,不同类型的游戏因为玩法、竞技程度不一样,采用的同步算法不一样,对网络延迟的要求也不一样。例如,MOBA类游戏多使用帧同步为主要同步算法,竞技性也较高,无论从流畅性,还是从公平性要求来说,对响应延迟的要求都最高,根据业内经验,当客户端与服务器的网络延迟超过150ms时,会开始出现卡顿,当延迟超过250ms时,会对玩家操作造成较大影响,游戏无法公平进行。类似地,“吃鸡”游戏(如《绝地求生》)玩法对玩家坐标、动作的同步要求极高,延迟稍大导致的数据不一致对体验都会造成较大影响,其实时性要求接近MOBA类游戏。而对于传统mmorpg来说,多采用状态同步算法,以属性养成和装备获取为关注点,也有一定竞技性,出于对游戏流畅性的要求,对延迟也有一定要求,同步算法的优化程度不一样,这一要求也不一样,一般情况下为保证游戏正常进行,需要响应延迟保持在300ms以下。相比之下,对于炉石传说、斗地主、梦幻西游等回合制游戏来说,同时只有一个玩家在操作双方数据,无数据竞争,且时间粒度较粗,甚至可通过特效掩盖延迟,因此对网络延迟的要求不高,即便延迟达到500ms~1000ms,游戏也能正常进行。这里,我们不对同步算法做进一步说明,重点说一下协议的问题。

后话

对于开发人员来说,优化协议和同步算法是在已有网络环境下提升用户体验的可用方法,也是较平民化的方法,在网络抖动有限、丢包并不频繁、网络环境不至于太差的情况下,的确能有效提高游戏体验;然而这种方法也存在局限性,在网络环境超出可控范围,如在地铁上、商场里等人潮拥挤、存在网络热点,延迟或丢包率极高的环境中,还是无法解决问题,所谓“巧妇难为无米之炊”,再牛X的协议和算法,也无法点石成金,要从根本上解决问题,最终还是要回到网络质量上。和平民化方法相比,改变网络质量需要在资源和底层调度策略上的积累,如何优化遍布全国各地乃至全球各地的玩家网络接入点到服务器端的网络链路?如何优化玩家客户端最后一公里即客户端到无线基站的接入qos(Quality
of
Service
)?这种方法可以称之为高富帅方法,而有这种大规模需求,又能采用这种方法的,放眼望去,恐怕只能看到一家公司了:腾讯。好消息是,腾讯已经将这种能力在腾讯云开放了,称之为:智营网优,cloud.tencent.com/document/product/594/10028 

下面是引自谷歌的一个统计数据:

传输层协议和延迟

不同传输层协议在可靠性、流量控制等方面都有差别,而这些技术细节会对延迟造成影响。tcp追求的是完全可靠性和顺序性,丢包后会持续重传直至该包被确认,否则后续包也不会被上层接收,且重传采用指数避让策略,决定重传时间间隔的RTO(retransmission
timeout)不可控制,linux内核实现中最低值为200ms,这样的机制会导致丢包率短暂升高的情况下应用层消息响应延迟急剧提高,并不适合实时性高、网络环境复杂的游戏。

总结

测试结果符合预期,在实时性方面,tcp协议的网络抗性欠佳,对moba类或其他实时性要求较高的游戏,我们不建议使用tcp作为协议载体。事实上,王者荣耀,乱斗西游的通信协议也确实是基于udp封装的,别问我是怎么知道的。

Recovery = fast recoveries and timeout recoveries.

总结

测试结果符合预期,在实时性方面,TCP协议的网络抗性欠佳,对MOBA类或其他实时性要求较高的游戏,我们不建议使用TCP作为协议载体。事实上,王者荣耀,乱斗西游的通信协议也确实是基于UDP封装的,别问我是怎么知道的。

Fast Recovery 重传占比多少?

后话

对于开发人员来说,优化协议和同步算法是在已有网络环境下提升用户体验的可用方法,也是较平民化的方法,在网络抖动有限、丢包并不频繁、网络环境不至于太差的情况下,的确能有效提高游戏体验;然而这种方法也存在局限性,在网络环境超出可控范围,如在地铁上、商场里等人潮拥挤、存在网络热点,延迟或丢包率极高的环境中,还是无法解决问题,所谓“巧妇难为无米之炊”,再牛X的协议和算法,也无法点石成金,要从根本上解决问题,最终还是要回到网络质量上。和平民化方法相比,改变网络质量需要在资源和底层调度策略上的积累,如何优化遍布全国各地乃至全球各地的玩家网络接入点到服务器端的网络链路?如何优化玩家客户端最后一公里即客户端到无线基站的接入QoS
(Quality of
Service)?这种方法可以称之为高富帅方法,而有这种大规模需求,又能采用这种方法的,放眼望去,恐怕只能看到一家公司了:腾讯。好消息是,腾讯已经将这种能力在腾讯云开放了,称之为:智营网优。现在申请,免费试用!

想了解更多有关游戏加速方案和案例,立即报名1月19日腾讯云GAME-TECH沙龙杭州站,我们一起探讨:

直播链接:

Group2 恢复时延比Group1 减少仅仅2%

欢迎大家前往云加社区,获取更多腾讯海量技术实践干货哦~

tcp初始化时,对TCP的连接进行变量进行初始化:

作者:腾讯云游戏行业资深架构师 余国良

Group 1: RACK off, TLP off

1、用数据说话

来源 /腾讯课堂Coding学院(ID:ke_coding)

快速重传和精准重传两者是一个矛盾体,是时间和空间的矛盾,永远无法调和,只能在其中折中。

在一定的传输时间内,在loss
Recovery花费的时间越小,就说明有更多的时间传输新的数据,因此可以说明有更好的传输效果。

没有到任何dupack就意味着FR和ER机制都是无法生效的。

如何理解这个测试方案以及测试结果:

这个是一个方案,比较直观,直接是伪重传数量。另外一个方案则是计算TCP的重传率,对比两台机器的重传率即可得到那边的重传更多,消耗的流量更大。再者,也可以统计两台机器的流量,流量更多,在下载数目一样的情况下,则说明伪重传更多。

解决问题的首要思路还是要了解问题的瓶颈在哪里。如果这些TCP重传类的算法放在网络链路质量很好的环境下,进行测试和验证,其提升肯定是非常有限的。还有就是没有适用于任何场景的万能算法。

6、总结

tcp.h

RTO/RTT分布如何?

实验结果:

3、性能评估方案