首先弱网环境丢包的问题，丢包不可避免，如果用tcp的话，指数退避的算法会更加大延迟，在结合位置同步的特点，位置同步总的来说是可以丢包但是要保序，同步下来的时候丢几个旧的位置不影响客户端的表现，所以协议选择上可以采用纯udp，在逻辑实现的时候，每个同步消息带个index来客户端自己丢弃过时的移动同步包。同理客户端上传<当前位置，遥感方向>的时候依然可以用udp。如果采用kcp协议，可以通过冗余包的形式来对抗丢包。
如果想要足够好的手感，手感这个词比较感性，我们具体化到可以落地的描述就是“一定的网络延迟以及一定的丢包的情况下，玩家希望操作的时候能够及时得到相应，哪怕预测失败的情况下，也尽量不要给玩家比较差的反馈感，比如突然回头强拉等”
如果延迟不高或者丢包不高的情况下，可以选择客户端先行，服务端信任客户端，只是校验下合法性速度就行了。但是如果网络延迟比较高的情况下，比如较高的下行延迟，本身33ms就客户端就可以收到一个<当前位置，遥感方向>的消息包，由于延迟66ms收到，那么客户端走完了还有33ms是预测继续前进还是停下等待？如果想表现好，最好要继续按照<遥感方向>来预测，但是速度应该发生变化，速度应该先快后慢，等着新的移动同步包下来。如果发现有偏移加速追上。加减速的变化函数怎么设计很关键，初期速度几乎不变，随着时间变化越来越小。这里考虑使用正态分布函数或者类似二次函数来膨胀时间,来达到平缓的加减速的目的。如果延迟或者丢包太严重了，也还需要强拉来兜底。
怎么提高手感，降低网络卡顿等因素，服务器的部署和匹配算法也非常关键，要保证玩家尽量都可以到自己可以延迟比较低的服务器进行战斗。如果是MMO，给玩家传送的副本也应该偏向于延迟偏低的副本。再者类似加速器的思路，手机端wifi和5G两条连接，消息包走2条路由，保证消息包可以最快的一条到达。
这里只是提到了常用的优化思路。终极的办法怎么提高预测成功率，然后预测冲突后，怎么尽可能低成本的回滚。比如是否可以通过机器学习来提高预测成功率（貌似google云游戏有这种黑科技），是否可以类似ECS模式的面向数据编程，数据变化回滚时，表现也随之有回滚方案。
