首先，来说明下网络延迟会对网游中施放技能造成多大影响。
假设你在施放一个读条2秒的四象，而你的网速为100ms(毫秒)，也就是说你有100ms的延迟，那么不考虑剑三的延迟补偿机制的话，整个施放过程如下：
时间t0=0.0秒时，你施放四象，客户端将之发送至服务器
时间t1=0.1秒时（t0+100ms），服务器收到四象指令，服务器端施法开始并发送确认信息到客户端
时间t2=0.2秒时（t1+100ms），客户端收到服务器端的确认信息并开始施法动画
时间t3=2.1秒时（t1+2.0秒），服务器端完成施法并将完成信息发送至客户端
时间t4=2.2秒时（t2+2.0秒），客户端完成施法并将完成信息反馈给服务器，同时收到服务器端的完成信息，读条结束。
（关于t4这步，客户端必须收到服务器的完成施法信息才会把读条结束掉，这就是为什么网络卡的时候，读条读完了，但就是不结束读条的原因，因为客户端一直没有收到服务器反馈回来的完成信息。）
从以上看出，如果没有延迟补偿机制，那么实际施法时间往往是读条时间+延迟X2。为什么读条打断后，法术仍然能放出也是因为延迟，详细机制如下：
时间t0=0.0秒时，玩家施放四象，客户端将之发送至服务器
时间t1=0.1秒时（t0+100ms），服务器收到四象指令，服务器端施法开始并发送确认信息到客户端
时间t2=0.2秒时（t1+100ms），客户端收到服务器端的确认信息并开始施法动画
时间t3=2.0秒时（t0+2.0秒），玩家取消施法，客户端将取消信息发送给服务器
时间t4=2.1秒时（t1+2.0秒），服务器端完成施法
时间t5=2.1秒时（t3+100毫秒），服务器收到施法取消指令并无视之，因为施法已经完成
时间t6=2.2秒时（t2+2.0秒），客户端收到服务器完成信息，四象出手
简单来说就是你打断了读条，但由于延迟，服务器那边你实际上已经完成了施法。
下面来说说延迟补偿机制：
按B叔的帖子，剑三的延迟补偿机制应该是服务器取得玩家的大致延迟时间后，相应的将读条时间缩短，如果是瞬发技能，我认为GCD转圈时间也应当会相应缩短，这样的机制是能节省掉t2步骤的延迟时间，
详细机制如下：
时间t0=0.0秒时，你施放四象，客户端将之发送至服务器
时间t1=0.1秒时（t0+100ms），服务器收到四象指令，服务器端施法开始并根据客户端的延迟发送确认信息到客户端
时间t2=0.2秒时（t1+100ms），客户端收到服务器端的确认信息并开始读条时间为（2。0秒-100ms延迟）施法动画
时间t3=2.1秒时（t1+1.9秒），客户端完成施法并将完成信息反馈给服务器，同时收到服务器端的完成信息，读条结束。
所以剑三的读条延迟时间大致上是读条时间+延迟。
在不怎么增加服务器负担的情况下，这样的机制还是很不错的。
下面提下WOW的延迟补偿机制，WOW在TBC以前，如果在读条，那么玩家按下技能，会在客户端直接被拦截，不会发送到服务器端，（剑三目前应该也是如此，客户端有选择的拦截掉一部分信息最大的好处就是降低服务器压力），TBC以后的延迟补偿机制最关键的就是修改掉了这点，也就是玩家每按一次技能，都会把施放技能的请求发送到服务器端，如果服务器端已经完成施法，则可以立刻开始新的施法请求。
CTM的排列机制相对来说更先进一点，但核心还是玩家每按一次技能，都会把施放技能的请求发送到服务器端。
这样的机制虽然理论上是可以把延迟影响降到最低，但坏处是会大大增加服务器端压力。
