游戏性能优化,需要从多个层面进行。美术资源层,降低不必要的网格顶点数、使用可硬件加速的贴图格式和合并渲染队列等。策划需求层,需要掌握技术基本原理,规避技术难度高、风险大的游戏需求、使用“障眼法”掩盖技术缺陷等。程序技术层面,尽可能不改变需求下实现更优的算法、同时使用严格的测试用例(如同步坐标还原测试)校对核心算法的准确性。而在本文旨在考虑的网络层性能忧化,除了考虑数据流量大小和更忧化封/解包算法外,还可以从OSI七层网络协议中寻找办法,较容易操作的是网络传输协议,协议代表有TCP、UDP和SCTP。SCTP有良好的特性,但该协议起步晚目前尚未广泛使用,大多应用程序开在TCP和UDP中作出选择。
UDP更适合实时类游
任何技术都有优缺点,是场景选择技术,而不是技术带着场景走。TCP提供的发送窗口、可靠性、延时ACK、Nagle算法和慢启动与拥塞控制等功能,在特定场景下有时反而成为负担。但是如果数据逻辑有严格的顺序逻辑关系,就应该使用TCP而不是Udp。UDP的网络传输更快,这非常适合实时类型游戏。以下是来自互联网,有关TCP与RUDP在弱网络掉包的情况下传输性能测试,横轴表示RTT(往返时间)、纵轴表完成输出占比量。
右上角的图例尤其突显RUDP在高掉包率网络环境下的优势,RUDP在[50-150]毫秒内完成约70%的数据传输量,而TCP完成的传输量较为平均地分布在各个延时区。再依据另外3个数据图,更能反映出RUDP相比TCP在更短的延时内完成了大部分数据量的传输
总结出TCP以下特性,减弱其传输性能
* 发送窗口
应用层调用Send时,数据并没有立即送出,只是先将数据拷贝到发送缓存区,此后由发送窗口机制分组送出。
* 延时ACK
TCP同时发送多个分组并且会累积ack,以太网最大的数据帧空间是1518字节,而一个ack占用空间约60字节,只占总空间的4%。为了提高宽带利用率,以及降低大量ACK包造成网络拥堵,TCP延迟40ms发送,如果这段时间内有数据发送到对端,则捎带发送ack
* Nagle算法
TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据。Nagle算法就是为了尽可能发送大块数据,避免网络中充斥着许多小数据块,算法要求一个TCP连接上最多只能有一个未被确认的未完成的分段,在该分段ack到达之前不能发送其他的分段。
假如client发送一个http请求个server。这个请求时1600byte,MSS是1460byte。那么就会分成两个TCP包,第一个1460byte,剩下的140byte放在第二个包。第一个包发送到server时,由于server开启了delay ack,所以没有立即ack,又因为server没有收到完整的http请求包,所以也没有立即进行http response,这就导致ack会一直等到40毫秒的delay时间。其实如果client立即发送第二个包,server收到后立即做出http response也不会有问题。问题时client启动了Nagle算法,第一个包没有收到ack,第二个包就不会立即发送出去。两边相互等m,这就是性能问题的核心原因。解决办法是向TCP套接字设置选项TCP_NODELAY关闭Nagle
* 慢启动与拥塞控制
慢启动与拥塞控制都是为防止过多的数据注入到网络,造成网络拥堵。慢启动算法就是在主机刚开始发送数据报的时候先探测一下网络的状况,如果网络状况良好,发送方每发送一次灵气都能正确的接受确认。那么就从小到大的增加拥塞窗口的大小,即增加发送窗口的大小cwnd。然而不断增大的发送窗口会增大网络负载,所以设置一个慢开始门限值ssthresh,当cwnd > ssthresh时,使用拥塞控制算法,停用慢启动算法。
Raknet
官网主页可以了解到,Raknet初始是为多人对战游戏而设计的网络库,之后得到不断完善并转向商用。2014年