为什么MOBA 吃鸡游戏不推荐用tcp协议

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

不同传输层协议在可靠性、流量控制等方面都有差别，而这些技术细节会对延迟造成影响。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做了性能测试，详情可参见：https://github.com/skywind3000/kcp/wiki/KCP-Benchmark， 从测试情况可以看到，kcp表现不错，其次是enet，表现最差的是udt。不过，这里也提出一个问题，原始enet保留了tcp重传的指数避让特性，每次重传间隔还是乘以2，默认rto也较高，这可能是测试中enet表现不如kcp的主要原因，如果对enet代码稍作调整，结果又当如何?这里，我们先排除传输性能，从其他方面对enet和kcp做一对比(满分5分).