一、例子
1.从小霸王游戏机帧同步，没有服务器，但是搜集每个手柄操作。 发的是向上的指令，一个人是向上+攻击指令。
2.军队中，每个人抬腿，你说1大家都抬左腿，说2都抬右腿，这样子一直持续下去，队列往前走。
这样子保证每个客户端状态都一样，
因为:有了相同的指令，每个逻辑帧相同的时间，就能确保它状态一致。
3.每个车以60公里的速度往前行走，行走了3s，每个客户端都这样子算的话，是不是走了距离是一样。
二、帧同步得核心理念
状态同步的话，则是服务器计算好，客户端直接显示就行。帧同步则只同步玩家输入指令，比如：向上走了，按了攻击键了。 像王者荣耀上的按钮，不要理解成一个技能，而是理解成按钮，1是普攻，2是跳起来打人，3是大招，你按1，则转发给服务器，服务器转发给你1，所有客户端都执行1的按钮，这样子就会释放同一个技能。 咱们要让所有的客户端在相同的逻辑帧在相同的时间执行相同的操作。 做的时候想想概念，走正步。
三、
帧同步采集的是指令而不是数据。
帧同步解决同步一致性的问题。
四、tcp、udp的选择
tcp可靠性的意思:
确保数据到达。
有重传机制， 网络差的时候延时高。
udp
不可靠连接: 不能保证数据送达，不保证顺序。
没有重连机制，丢了就丢了。
因为没有tcp重传机制，可以在延迟低的情况下自定义重发机制，所以延迟相对tcp低。
帧同步更适合udp:
帧同步通常是连续的数据流。
一帧丢了，下一帧会覆盖更新。
可以通过这弄不的逻辑来避免消息顺序问题。
可以自定义或者干脆不做确认机制。
带来了更低的延迟。
补帧、追帧、跳帧。
包序号控制。
但是：现在网络环境已经足够好，不是必须得udp.
五、实现帧调度机制
1.建立固定的逻辑帧率，比如:每秒20帧或30帧，客户端按照固定间隔执行逻辑帧，不受渲染帧率影响(渲染unity可以走60帧，但是逻辑帧必须是固定的，也就是逻辑和渲染分离)， 需要实现等待帧机制，当某一帧的输入还未完全收集时，暂停逻辑执行直到输入到齐或超时(之前是:"锁定帧", 比如之前的:，局域网某个人断开连接时，需要等待它连接或者直接游戏结束了)。
2.服务端:
服务器会维护一个严格的逻辑帧时钟，比如:每秒20帧也就是50ms一个逻辑帧，收集这一帧内所有客户端发送的输入数据，然后将这些输入打包成一个帧数据包，广播给所有客户端。(相当于服务器有个定时器每50ms执行一次，会搜索这个之间客户端发送的数据，比如:50ms执行一次，到下一个50ms执行之间，客户端发送过来的这些输入的数据，一直收集，等到下一个50ms的话，相当于这一帧的数据，然后发送给客户端，客户端再根据这些数据进行一个显示或者逻辑，)
3.客户端: 收到服务器发送过来的帧数据后，把当前帧采集的指令输入打包发给服务器()。