家里宽带很多人连，搞的我玩游戏延迟特别高，有什么方法给自己电脑固定个网速么？_百度知道当前位置>>>
不论是我们访问网络还是玩游戏，都对网速有要求，网速越快越好，什么叫做网速，不仅仅是上传下载的速度，更有着网络延时的意思，这里小编跟大家说下网络延时在大怎么处理！延时的定义数据在网路设备之间传输（即通过服务器，终端，网线，网络协议传输）中间会有一定的延时性。也就是说，不论是你是用现在最流行的光纤还是用以前古老的同轴电缆，网络延时都是在的，这种延时几乎无法避免，只是大小有区别。 延时单位：毫秒（MS） 　如何定义网络延迟程度，我们一般用ms来表示延时的高低，一般来说如果延时越低就表示我们的网络越流畅，玩游戏看电影反应速度也就会越快，以下是各个延时的描述：　　（网络延迟PING值越低速度越快） 　　1~30ms：极快，几乎察觉不出有延迟，玩任何游戏速度都特别顺畅 　　31~50ms：良好，可以正常游戏，没有明显的延迟情况 　　51~100ms：普通，对抗类游戏能感觉出明显延迟，稍有停顿 　　&100ms：差，无法正常游戏，有卡顿，丢包并掉线现象 　　计算方法：1秒=1000毫秒（例：30ms为0.03秒） 怎么测试我们的延时呢？以下给出方法：ps：这里小编以百度的测试延时:点击开始，在运行里输入“CMD”。在弹出的命令提示框里输入“ping 要测试的地址 -t”或&ping 域名-t&。输入完成之后，程序就开始跑延迟测试了。过一段时间之后，你按“Ctrl+C”就可以停止测试并得出计算结果。如下图红圈所示： 为了使测试更加真实有效，玩家可以尽量让程序多跑一段时间，并且尽量在黄金时间测试。这样更具有代表性！ 网络延迟高怎么办？网络延迟常见原因分析首先你要考虑到你的网络运营商给你提供的是什么网络，就国内来说，电信毋庸置疑属于最好的一个，其他的联通，铁通，移动，等等对比电信来说还是有一定差距！当然还有其他的一些宽带，各种不稳定，要是玩游戏一下延时高一下延时低这是正常情况！ 如果你上网的地方是多人共享网络的话，你要考虑别人是不是在抢网速。比如用讯雷,P2P这类的软件在疯狂的抢宽带，碰到类似这种流氓抢流量的软件，你一定要记得使用完成一定要退出，如果不退出，后台偷偷上传是常有的事情，另外如果是朋友在用，最好在路由设置里面限制网速，不然玩游戏就会一步一卡！ 如果正常使用网络延时高，可以尝试将路由器恢复出厂设置。路由长时间连续工作对其工作效率还是有一定影响的，如果明显感觉到某一段时间网速明显变卡，不妨恢复出厂设置，一般路由器恢复出厂设置是抵住后面的小黑点，通上电。几秒后，路由器会恢复出厂设置。再重新设置一下。如果不行只能换个了。 还有一种情况是你系统中毒，可以先将杀毒软件升级到最新。在安全模式下全面杀毒。如果杀不了毒或不高兴杀毒的话。可以将系统格式化后重新***。但重装后要立即***杀毒软件，并升到最新，杀一下毒。最后一种情况，如果笔记本离无线路由器过远，或中间间隔墙太多也会造成网络延迟。可以照第四步的情况PING一下无线路由就知道了。还有如果你用的是太小的宽带也会如此，比如你了手机移动的2G网络上网这都是正常现象。总之，想要改善网延时，最根本从硬件上着手，用稳定的运营商，离wifi距离不要太远等等。最后，如果您还有什么意见或者建议，请到u大师官网留言 ，或者到u大会论坛发帖，也可以直接联系***，祝生活愉快！
少侠请留名FPS游戏中，在玩家的延时都不一样的情况下是如何做到游戏的同步性的？
如果不是同步的话，游戏的公平性怎么保证呢？那些cf,cs的比赛是如何解决这个问题的？
声明：下面会大量使用CSGO作为例子，这是因为Valve在多人游戏的网络通信方面做得较好，可以当做一个典型来分析。========================================================先讲多人竞技游戏中客户端和服务器是如何互动的吧游戏中所有的逻辑判定都是由服务器完成的，客户端只负责发送请求和接收服务器的反馈，并把反馈具象化。拿CSGO做例子吧，比如你（玩家A）拿着AK瞄准了玩家B的头开了一***，那么你的客户端会向服务器发送一个数据包，里面包含了谁（你）拿着什么武器（AK）从什么位置（你在地图上的坐标）向什么方向（角度）开了一***。服务器收到后进行判定，这一***的伤害会经过玩家B的头部模型，判定为爆头伤害，数值为104（这个值是瞎编的），因此判定玩家B死亡。然后向所有玩家的客户端通信，更新当前游戏状态，其中会包括玩家A用AK爆头击杀了玩家B，也会包括其他游戏信息，比如玩家的位置等等。你（玩家A）收到通信后再你的GUI上显示你击杀了玩家B，而玩家B则会收到被你击杀的信息。接着讲一个概念，叫服务器的通信频率（tick rate）。事实上服务器不是实时地向玩家通信来更新游戏状态的，因为这样需要的计算量很大，同时对网络带宽的要求也会高的不现实。因此服务器会以一定的频率来进行通信。 CSGO在娱乐模式下通常采用60Hz的频率，也就是说每过1/60秒玩家的客户端就会收到一次新的信息。如果回到上面那个例子，那么实际情况应该是：你（玩家A）拿着AK瞄准了玩家B的头开了一***，你的客户端会向服务器发送一个数据包，服务器接收后进行判定。判定完成后等待至下一次通信，再向所有玩家更新游戏状态。也就是说游戏过程其实是一个离散的过程而非连续过程。=====================================================================上面的例子都假设客户端和服务器之间的延迟无穷小。那么当玩家Ping很大的时候会发生什么的呢？假设你（玩家A）与服务器之间存在100ms的延迟（单向，往返则是200ms），其他玩家的延迟忽略不计，服务器的通信频率足够大（频率不够大还会造成其他很严重的问题，这个放在后面讲）。你在某一刻向服务器发送了一个请求（比如向前走），那么这个请求会在100ms之后到达服务器。服务器判定后返回结果，再经过100ms你的客户端会收到确认，服务器已经把你的位置向前移动了若干距离。假设客户端在没有收到任何服务器的更新前画面都不会变化，那么着200ms内你就会觉得游戏“卡顿”。实际上在很多游戏里（比如CSGO）在这200ms里你看到你自己是在向前走，实际上那只是客户端“擅自”在绘制你前进的样子。这是一种延迟补偿策略，称为“客户端预测法”。也就是说客户端能够大致预测游戏未来的走向，因此在接收到服务器更新前会把预测到的画面先绘制出来（比如移动，武器的开火效果，弹药计数的变化等等）。收到服务器通信后如果有出入则立刻纠正为服务器提供的数据。这也是很多时候如果延迟很大玩家会体验到“明明往前走了过了一会又瞬移回到之前的位置”的原因。类似的体验还有“明明开了好几***而且也都显示了过了一会弹药计数只减少了一点点”。既然扯到这里了那就认真的讲下延迟补偿策略（lag compensation）。一般补偿策略分服务器端和客户端两类。前面的预测法属于客户端一侧的。其他的客户端一侧的策略还有插帧法。所谓插帧法就是客户端会记录之前一次从服务器收到的信息，然后在接受到下一次通信的时候不立刻更新游戏画面，而是逐渐的更新画面（比如两次通信间玩家B移动了10单位距离，客户端会绘制玩家B以一定的速度移动了这10单位距离，而非立刻绘制玩家B瞬间移动了10单位距离）。 插帧法的问题在于如果玩家并未沿直线运动且其直线路径中有本应不能通过的物体在（比如绕过一堵墙），客户端会绘制出该玩家穿墙而非绕过去的动作。---------------------------------------------------------------------------------------------------------------------------在服务器端常用的策略有：1.“眼不见为净”法。很多时候服务器不去补偿玩家的延迟是一个合理的做法，特别是如果游戏内进行的事件非常多（想想行星边际2里面千人同图混战的情形）。浪费宝贵的服务器资源去补偿个别玩家的延迟是不明智的。这个策略的缺点很明显，就是玩家有可能会对游戏体验不满意。2.“倒带”法。采用倒带法的服务器会记录刚刚过去一段时间内（比如0.5秒）游戏内的所有信息。当一个有延迟的玩家（比如200ms）向服务器发送一个请求，那么服务器在处理这个请求的时候会调取0.2秒前游戏的状态然后进行判定，在把判定结果对所有客户端进行同步。如此一来该玩家的操作虽然有延迟但也能与他/她所看见的画面一致。 该策略的最大问题在于它让不同延迟之间的玩家被迫体验较大的延迟。举个例子，假设游戏里击杀时间（TTK）足够小，玩家A（10ms延迟）和玩家B（延迟200ms）对射，两人都是空血（一次攻击即死），A比B先开火（时间差很小，比如50ms）。玩家A的次攻击很快（10ms后）就得到了处理并记录在服务器中，玩家B被判死亡。然而在200ms后玩家B的请求到达，服务器倒带0.2秒，此时玩家AB都未死亡，因此玩家B的攻击有效，玩家A也被判定为死亡。 如果没有延迟，那么服务器应该会判定玩家B死亡，因此玩家B将无法攻击，玩家A应该存活。换句话说采用倒带法的服务器里如果有一个延迟很大的玩家将会拖累其他低延迟玩家的游戏体验。----------------------------------------------------------------------------------------------------------------------------Bonus：前面的例子都是以服务器的通信频率足够高为前提的，下面简要描述一下低通信频率带来的问题。这里我要举的例子是大名鼎鼎的《战（和谐）地4》（下称BF4）。BF4在刚刚发布的时候可谓是Bug满天飞整一个就是半成品，其中非常严重的就是网络通信问题（netcode issue）。根据制作组DICE提供的信息，BF4的通信频率是10Hz。这是一个相当低的设定了，大多数FPS的通信频率在30Hz左右，而CSGO为60Hz，电子竞技比赛时一般服务器的通信频率还会提高到120Hz（因为比赛时大家都是在一个局域网里所以延迟很小高频通信能够更加精确反映游戏内状态）。由此带来什么糟糕的后果呢？ 1.游戏体验的不连贯。BF4的客户端，和其它很多游戏一样有应用客户端预测法来补偿延迟。但是因为服务器更新的频率是在太慢了（0.1秒才更新一次，人类的反应时间差不多略小于0.1秒，即玩家已经可以感觉到其中的不连贯）。拿移动来举例吧，玩家正常的前进，突然玩家的延迟很短暂的增加了一下然后又回到正常（也就是spike），那么其中某一次移动的请求就会花更多的时间到达服务器。客户端这边因为没有收到服务器的通信而绘制了玩家前进的样子，0.1秒后服务器告知客户端实际的位移小于绘制的距离，客户端进行纠正（瞬间向后退）而0.1秒可以前进很大一段距离了（至少肉眼可以感觉出来有变化了），如此瞬移回退让玩家感觉非常不舒服，即使延迟很小只要有变化就有可能发生这种情况。同样的情况适用于玩家看到的其他玩家所在的位置。在服务器中敌人的位置往往比客户端上显示的要滞后，因此很多时候明明瞄准了却打不中。相对的，如果提高通信频率，客户端“擅自”绘制的画面和服务器数据能够以更高的频率进行纠正，其中每次产生的变化都不会让玩家察觉。2.“瞬间”击杀（Instant Kill）。BF4里的自动武器射速绝大多数都超过了600RPM（即每0.1秒一发），高射速武器如AEK971可以达到900RPM甚至更高。而大多数武器在近距离内都是造成25伤害（玩家满血100）。因此玩家（A）完全可以在0.1秒内发射至少2发子弹，在近距离内击杀生命值小于等于50的玩家（B）（这个边界值随射速提高而提高，如AKE971可以在0.1秒于近距离击杀生命小于等于75的玩家）。假设玩家A开始射击的一瞬间服务器刚好进行了一次对客户端的通信，玩家A在之后的两次发送射击请求都被服务器接收并判定（玩家B死亡），而一直到玩家A开火后的0.1秒内玩家B都没有接收到任何被攻击的信息。0.1秒后玩家B死亡，而玩家B的客户端只能绘制一次玩家A开火（虽然收到两次开火的信息），且因为玩家B已经死亡客户端只显示kill cam。 简单来说玩家B完全没有还手或者躲藏的机会，因为玩家B一直都认为自己没有受到攻击，只是在一瞬间就被A打死了。对玩家A来说整个过程没有任何问题，而玩家B则是个冤大头。此时的BF4已经失去了竞技的平衡性。--------------------------------------------------------------------------------------------------在BF4发布八个月后（没错，八个月，期间发布了数款BF4的DLC），发行商EA（果然不要脸）终于决定要修复这些问题。一开始他们决定吧BF4的服务器端通信频率提高到30Hz。然而BF4是一款复杂度远远超过其他FPS游戏的一款作品（64人，海陆空载具，弹道分析【BF里的子弹并非是在发射的瞬间就击中了敌人而是要经过一定的飞行时间才会击中，且还会受到重力影响而下坠】），30Hz的通信频率就已经让很多玩家的电脑吃不消了。后来采取了一个折中策略，玩家附近的游戏状态以30Hz的频率进行更新，而距离玩家较远的信息继续以10Hz的频率来更新。 同时还提供一个选项允许客户端以更高的频率向服务器“索要”数据（当然其中造成的硬件负担不可小觑）。目前BF4的网络通信已经恢复到“可玩”的状态。根据某些资深玩家推测，BF4的服务器无法以超过30Hz的频率进行通信，主要原因是其引擎寒霜3内核有缺陷。因此BF4不太可能成为一款竞技游戏走向电竞舞台。=======================================================更新（闲扯淡内容）：感觉既然扯了BF4的低频通信那就再在战地系列里扩展一下吧。最早出现低频（10Hz）通信的战地系列游戏是战地：叛逆连队2（BF:BC2），然后战地3（BF3）也沿用了一样通信频率。细心的玩家会发现自BFBC2以来所有的战地系列游戏使用的都是寒霜（Frostbite）引擎 （BFBC2是寒霜，BF3是寒霜2，BF4和战地：硬仗BFH是寒霜3）。使用低频和引擎的关系很大（如之前所述）。我在这里想讲的是同样是使用低频通信，同样存在严重的网络通信问题，BFBC2被誉为神作被很多战地系列的老玩家奉为经典，而BF4被黑的死去活来（youtube上和Reddit论坛上甚至有针对DICE的檄文）的原因。BFBC2是2009年发布的FPS游戏，是第一款使用寒霜引擎的多人FPS（当时也是DICE拿来卖引擎的作品，和孤岛危机类似）。在发布后立刻好评如潮，时至今日在北美依然有不少服务器在线供玩家游戏（包括其DLC越南）。当时很多玩家都没有注意到低频通信带来的问题，即使瞬杀等问题存在。这里最主要的一个原因在于BFBC2中武器的设定。BFBC2中所有的武器（除去栓动狙击步***和携带独头弹的泵动式霰弹***）伤害都比较小，常规的突击步***和卡宾***通常需要5-7发（击中躯干）才能击杀一个满血的敌人，远距离需要更多，而轻机***往往需要7法以上，但远距离伤害不减少。这主要带来的一个特征就是TTK（击杀时间）相对当时很多主流FPS游戏都要长（相比使命召唤，CS：S等，网游不考虑在内）。因此在10Hz的通信环境下，要出现和BF4中类似的瞬杀的情况条件苛刻很多（玩家的生命值必须非常低，而不是50%或者75%以下）。同时BFBC2中的武器射速普遍没有那么高（高射速应该是从BF3开始的），因而即使玩家生命值很低需要击杀的时间也可能会超过0.1秒，那么玩家就能够有足够的反应时间。另外BFBC2最多只允许32人同服游戏，近距离的接战没有那么混乱，玩家感觉到“莫名其妙就死了”的概率也低很多。在BFBC2发布后的一段时间开始有玩家注意到了网络通信中的瑕疵，并尝试在youtube上制作视频进行说明，但并没有得到很多响应。说到底当时BFBC2绝对是跨时代的作品，其优秀的游戏品质和创新的设定让玩家对网络通信中的瑕疵更加宽容。试想一下，BFBC2是世界上第一款引入全场景可破坏的FPS游戏，是第一款强调步兵小队作战的战地游戏，是第一款主推快攻（rush）模式的FPS游戏（这个模式貌似还是只在战地系列中有，RO2和Insurgency有类似的模式但不同），玩家自然对其百般推崇。网络通信中的小瑕疵？没关系，玩的爽就行。---------------------------------------------------------------------到了BF4发布的时候，很多玩家怒了。第一，BF4很大程度上只是BF3换了层皮，而且开发很不完善，bug很多（前面有提到），玩家对DICE极度不满，自然就有人出来挑刺。第二，BF4武器射速以及伤害模型的问题，使得网络通信质量问题更加凸显，youtube上大量的视频都表明要复原通信问题比BFBC2简单很多。说起来EA和DICE也是脸皮很厚的，发布后八个月（之前提到过）才开始尝试修复。他们的理由是：“开发人员去度假了”。
网游技术发展真够慢的，怎么大家十年前在讨论同步问题，十年后还有人在讨论这个问题呢？何为延迟补偿？如何进行坐标差值？B客户端屏幕上A已经跑到东边了，但是收到服务器说“A正在西边往北跑”，B到底该何去何从？各位说了那么多DR，TimeWrap，LockStep，自己实现过没有？有产品上线没有？这些问题明明很简单，却总被形容得云山雾罩的，离落地编码还是那么的遥远。我若干年前的一个实现版本，将简明扼要的解决这个问题：--------------------------------------------------------------------------------------------------------------影子跟随算法由普通DR（dead reckoning）算法发展而来，我将其称为“影子跟随”意再表示算法同步策略的主要思想：屏幕上现实的实体（entity）只是不停的追逐它的“影子”（shadow）。服务器向各客户端发送各个影子的状态改变（坐标，方向，速度，时间）。各个客户端收到以后按照当前重新插值修正影子状态。影子状态是跳变的，但实体追赶影子是连续的，故整个过程是平滑的。前面的1号终端控制红色飞船P1向左飞，并把自己的状态时时告诉服务器
后面的2号终端上接收到飞船P1的影子S1的状态（向左移动），并让P1的实体追赶S1网络性能指标一：带宽，限制了实时游戏的人数容量网络性能指标二：延时，决定了实时游戏的最低反应时间使用该算法可以容易的开发出一款马里奥赛车，或者Counter Strike，详细说明见后：
算法比较：帧间同步：不同客户端每帧显示相同的内容，键盘/时钟数据传到服务器，服务器确认后所有终端做出响应，多用于局域网游戏，比如红警（需要等待客户端），街霸II的网络版（360），可参考 LockStep，TimeWrap算法，网速要求高，复杂度低，见我的旧文。插值同步：不同客户端显示不同步，但是状态同步，常见的Dead Reckoning（或叫导航插值），效果好，但复杂度高。常见于竞速类游戏和 FPS游戏。算法定义：时间：单位为帧（FPS=10），开始由服务器告诉向所有客户端，每5分钟同步。玩家：每个玩家控制自己的实体，并在每贞将状态改变告知服务器。状态：状态数据 = 实体ID + 坐标 + 方向 + 速度 + 时间（贞）。插值：收到新状态包后将根据其运动方向与时间，根据现有时间计算新状态。跟随：实体不停的追踪自己的影子，追上后与影子保持状态同步。相位滞后：可选参数，实体与影子保持一定距离同步，相当于保持一定车距，这样在控制者突然停止的时候，不容易因为网络延迟跑过了又被拉回来。
惯性移动：可选参数，开始移动或者停止或者改变方向都有加速度，这样就不需相位滞后了。
每次服务器向各个客户端同步时间的时候，由于延迟，所有客户端的时间都是慢于服务器的，这没有关系，只要大家在一定误差范围内以相同的速度增加，就完全没有问题。
图2 IDC网络响应在公网平均130ms的Latency下，是不存在“完全的”的同步情况。如何通过消除/隐藏延时，将用户带入快速的交互式实时游戏中，体验完美的互动娱乐呢？
让所有的用户屏幕上面表现出完全不同的表象是完全没有问题的；
把这些完全不同表象完全柔和在一个统一的逻辑中也是完全没有问题的。
需要根据具体情况，分清楚哪些我们可以努力，哪些我们不值得努力，弄明白实时游戏中同步问题关键之所在，巧妙的化解与规避游戏，最终在适合普遍用户网络环境中(200ms)，实现实时快速互动游戏。
案例解析：Counter Strike实现CS的话，首先我们需要给人物移动加上惯性，比如静止状态突然开始移动，那么需要0.5-1秒的加速过程，而移动中突然停止也需要0.5-1秒的减速过程，这样就实现了无差别同步，不需要相位滞后来避免拉扯影响用户感。
同时开***射击采用客户端判断，也就是说如果我看见你在墙前面，开***射中，那么我向服务器发送“我击中你了”，这时有可能真实的你在墙后，那么表现出来的就是我看见我打中你了（减不减血由服务段判断），而你没有看见我，觉得我穿墙打中你了。
图3 CS的同步逻辑关键状态进行缓存，不然如果别人向前连续跳五次，每次取得状态都取到最高点的话，别人客户端上的影子和跟随的实体会奇怪的持续的飞在天上，所以需要将起跳和落地这两个关键状态缓存，实体追赶时只有追上的第一个状态（一号影子）才能追逐第二个状态（二号影子）。
由此可以在完全时间同步的情况下平滑的跑动、跳跃，开***射击采用客户端判断后手感得到提高，唯一需要担心的就是外挂，外挂多是实时游戏的代价，只能通过Cheating
Death等工具防止了。
案例解析：马里奥赛车用该算法实现马里奥赛车是很简单的，影子和实体都使用惯性，由于赛车惯性很大，不容易有突变的状态更新，所以效果会比FPS游戏更好。
玩家碰到道具后，马上在屏幕上隐藏该道具的显示并通知服务器，由服务器决断道具属谁，由于刚碰到道具就隐藏所以不会有碰到道具却在一段时间内无法取得延迟现象。
游戏道具系统实现也很容易，比如那个将当前第一名炸毁的道具，它的描述是：原角色+对象角色+约定发生时间。既然知道对象是谁，什么时间发生，那就更本不需要怎么同步了，所有客户端和服务器在该时间让炸弹爆炸就得了，这种手法类似即时战略游戏。
游戏还有一类道具是可以发射的乌龟壳，这个东西属于有弹道的发射物，类似Quake里面的某些武器，需要作一些同步处理，基本特性是服务器判断起决定作用，客户端同步判断，如果客户端与服务器都判断集中，那就集中；如果客户端判断集中而服务器判断没有集中，那会看到该角色似乎被打了一下，但很快又恢复了速度向前冲。
由于赛车本身就具备惯性比较大的特点，因此同步效果是比较好的，可以在更大的延迟情况下表现得和FPS差不多（比如300ms效果相当于FPS的200ms）。
非可靠包：该“影子跟随算法”支持非可靠传输协议，如果使用非可靠传输，那么我们按照特定频率（如每秒10次）定时发送状态更新，因为协议中每个更新包出了位置外还有速度、方向和时间，甚至还能加速加速度，因此我们丢一个包没有关系，可以根据后来的包重新计算插值。只有关键状态更新时才需要可靠传输，这就避免了TCP中丢包时RTO指数增长造成的延迟了。
负面情况：该算法缺点就是无法向“帧间同步”算法那样，每次发送按键给服务器，服务器处理后再反馈结果，在局域网中（平均延迟&5ms），这样的效果相当于单机游戏一样即时，游戏性也能很复杂。然而在Internet中（平均延迟130ms，设计基准200ms，每秒最多发送10个数据包）该算法却不能像单机游戏那样有复杂的场景互动，有类似格斗游戏的即时的动作判定。
许多策划在设计实时动作游戏时很多设计我们都难以实现，这样因为策划不容易明白哪些我们能做，哪些我们不能做。即便程序员精通同步理论，策划也经常碰壁。
当多数设计被程序员回复“无法实现”后，策划只有采取一种消极设计（砍掉很多有意思的互动元素），于是网络游戏的表现力到今天还是差单机游戏一大截。
这些问题也并不能因为“影子跟随算法”的提出而得到改进，大于100ms的判定时间，都很难做到即时。
最后，该算法编码复杂度比其他同步策略高，因为服务器需要计算一份影子数据，各个客户端需要计算一份影子数据，还需要计算实体追赶，而这三种计算都需要在同样的时钟下保持一致，这就增加了编码与调试的复杂度。
总结话题：Internet特点是“高带宽，高延迟”，可以说从本质上Internet就不是为了游戏而设计的。故此Internet绝对意义的同步是不存在的。“影子跟随算法”的核心思想有几个：时钟同步，客户端先行，平滑追赶。通过这三个特性，我们能够在近似时间同步的情况下，模拟各种物体的移动过程，而使用该算法的前提是设计者需要根据各个游戏的特性研究不同的优化技巧，策略因游戏而变。
比如发送状态更新包时，不需要每次都发送，而可以只发送改变的状态。什么时候我们觉得改变了？就是当客户端实体与自己的影子之间的误差大于某特定数值时我们才发送更新包，这样虽然玩家在原地做左右摇摆的小幅度移动，只要没有超出范围，都不需要发送新的状态更新，其他玩家机器上看起来，它是站着不动的。
比如当发现某客户端5秒钟没有相应了，那么就将该人物的影子冻结住，永远不要为了等待某个数据而不让游戏进行下去。
本算法需要客户端与服务器维护相同的时钟，当每5分钟同步的时候，直接根据服务器的时钟替换当前时钟就行了，不需要重新计算所有影子的位置，因为后续的状态数据将会马上刷新这些状态。更不需要将测量到的PING值考虑进去，该算法与PING具体值无关。
当发现策划案子不可行时，寻找近似替代方案，比如减少“一次性的”“决定性的”事件发生，比如延长导弹在空中飞行的时间，比如将敌人加入HP分多次打死，而不是以及毙命，等等，都是大家可以发挥想象的地方。
相关例子：文章相关DEMO如果有需要的话，可向我索要。
参考阅读：韦易笑（2006），韦易笑（2005），
没有绝对的同步，服务器会模拟你的动作，你可能突然卡了一下没发过去，但是服务器那已经动了，你要是偏差的太多，就拉会拉人，导致你会看到有些人闪来闪去，具体规则就看设计了
首先，不存在通用的延迟解决方案。其次，延迟处理方案其实非常简单，最多只是麻烦些而已。关键在于两点：1.重点偏向。开发商，你们愿意偏向于哪个重点？公平？刺激？照顾低延迟？节约流量？等等。不同的重点偏向，会带来不同的系统设计、算法，会导致不同的用户体验。2.代价。开发商，你们愿意为了提高用户体验，花费何种代价？普通渣渣淘汰二手服务器还是超高主频的定制服务器？渣渣二线联通铁桶网络还是骨干BGP放核心节点然后专线到各省各IDC的子CDN节点？最后提醒：设计一款网络游戏，在需求收集时期就需要把网络问题考虑进去，而不是等游戏都做好了，再去根据网络做优化。
CF这种FPS类型的游戏，当ping高于50的时候通信延迟就会比较明显了，达到100则有明显感觉的延迟。 而ping的好坏依赖于服务器的DNS和宽带运营商，上行速度太小会影响通信传输。而我国大部分宽带都是ADSL，在一些需要30HZ以上传输数据的游戏里，对网络和硬件都是考验，而ADSL上行速度被限制严重所以很多时候用ADSL的用户会ping很高，实际是由于上行带宽很小或被占用。游戏同步性，楼上回答很好了，不多说。
网络延时是无法避免的，延时长短也是无法量化的，因此无法做到和单机一样的效果。可以通过一些类似于时间戳之类的概念去修正----接受数据方根据相对时间来决定游戏的逻辑表现。但是这样会又造成表现上的时间黑洞，也就是所谓的“跳帧“。但至少从数据上看，是近似同步了。
已有帐号？
无法登录？
社交帐号登录