在第一篇文章中我们讲了帧同步的核心：如何保证各个客户端的一致性。保证不同客户端各自计算的结果都相同就能确保帧同步玩法的正确有效，但如果服务端消息没下来前整个客户端画面一动不动，体验是非常不好的。在确保一致性的前提下做一些预表现以及降低网络传输的延迟能给到玩家更好的体验。这篇文章主要讲这方面的一些优化，另外还有关于不同步问题的定位排查、防止客户端修改作弊、断线重连与网络消息堆积时的一些处理方案。
UDP传输：TCP传输因为在底层做了各种关于可靠性及稳定性的处理（详细可见《计算机网络——传输层：TCP与UDP》），所以延迟会比较高。而在帧同步战斗中，操作需要上行到服务器然后经过转发到达到各个客户端才能推进真正的逻辑，低延迟对玩家操作体验非常重要。而帧同步战斗这种频繁（1秒30帧）的传输小量（只转发操作）的数据，用UDP也是很有优势的。在相同的网络环境下，UDP可以在一个逻辑帧内完成来回的，延迟在33ms以内，而使用TCP至少要3-4个逻辑帧才能完成来回，延迟在130ms以上。
使用UDP传输需要自己处理乱序和丢包的问题。帧同步战斗中，服务器定时派发的帧数据本来就是有序号的，所以乱序到达的问题只要缓存起来按顺序使用就可以了。而丢包的问题我们可以采用冗余传输来尽量避免。服务器一次下行中不仅带上当前第n帧的信息，还可以带上n-1，n-2或更多的冗余信息，这样只要不是连续丢多个包，都能保证客户端最终收到连续的帧信息。如果客户端当前在等第t帧， 但已经收到第m帧的信息，m-t的差值大于一定程度，就认为已经连续丢了多个包，这个时候靠冗余信息已经拼凑不回来完整的序列了，就需要利用TCP重新请求缺失的帧，服务端用TCP把客户端请求的帧信息重新补发。利用TCP来做请求重传虽然速度慢，但可以保证一定能收到。具体流程图如下：
Continue reading