一、追溯

去gameloft笔试，有一个题目是说：

叫你去设计一个FPS（第一人称射击游戏），你是要用TCP呢还是要用UDP，说明理由 。

二、学习

这是两篇网上找到的文章，写非常不错。

当时笔试的时候自己没想到这么全，但大概想法都是一致的，摘录下来再学习一下。

1.网络游戏程序员须知 UDP vs TCP

作者：rellikt@gmail.com

首发链接：http://blog.csdn.net/rellikt/archive/2010/08/21/5829020.aspx

这篇教程让我们就从最基本的网络数据收发开始谈起吧。其实这部分才是网络程序员应该做的最基础最简单的部分，但是这部分如果想要做好相对来说还是很有技巧和困难的。而且如果这部分你没做好，在多人对战类游戏中它带来的影响是极其恶劣的。

你可能听说过端口这个概念，也可能知道TCP和UDP这两个概念。在做网络开发的的时候，我们首先要做的就是选择合适的协议。到底是TCP，还是UDP，或者是两者混合来用呢？这是一个问题。

其实来说，你的选择应该和你需要做的游戏类型相关。所以首先如果你是做网络游戏开发的，从现在起，我默认你对一些知名的网络游戏，比如COD,Quake, Unreal, CS已经很熟悉了。

既然我们要谈网络游戏的协议选择，我们就先得对各种协议来个深入的了解，这样到底应该选择那种协议也就不言而喻了。

TPC/IP

TCP

TCP解释为传输控制协议，IP解释为网络协议。他们合起来就完成了你日常网络的大部分工作，比如写email，看网页等。

假如你曾经使用过TCP，那么你肯定知道TCP是可靠协议。即你先在两台机器间建立连接，然后你再在两台机器上开始传输数据，传输的过程和文件读写很像。你在一头写，在另外一头读而已。

TCP协议是可靠而且有序的，这个意味着TCP负责保证你的数据可以完整而且有序的传输到另外一端。TCP是通过流的方式来传输数据的，这就意味这TCP会负责把你的数据切分，打包，然后具体传输。

最后记住，TCP传输其实就和读写文件一样简单。  by rellikt

IP

IP协议的抽象简单概念与IP协议底层传输的复杂真实实现形成鲜明对比。

这里不需要任何连接的概念，数据包从一个电脑传输到另外一个电脑，就像你在上课的教室里面传纸条一样。你只要给出一个最终的目的地，包自然会传到那个终端，当然中间还会经过好多层的路由递送。

你完全不能确定自己的包最终会不会到达目的地，只能希望它到达。如果你想知道包最终是否到达，那你就必须让接收者收到以后做出回复。

事实上，整个过程可能还要更复杂一些，由于没有一台机器能够预知包可以最快到达的完整路由途径，所以有时候IP协议会将包复制多份发出，这些包会走不同的路由，因此他们一般也会在不同的时刻到达。

你必须了解因特网路由问题的设计原则是自主组织路径，自主修复路径。所以当你思考问题的底层是如何实现时那是相当带劲的，当然你可以在相关的教科书上找到你想要的内容或者wiki。

UDP

我们已经有一种可以像写文件一样稳定传输数据的方法了，如果我们还想要一种可以自由的收发包的方法，我们可以怎么做呢？

这里我们可以用到UDP。UDP解释为“user datagram protocol”（用户自定义数据协议）。它和TCP类似也是建立在IP协议上的，不过他相比起TCP来在IP协议上只做了薄薄的一层协议。

我们可以使用UDP协议直接对指定的IP和端口发包，比如 1.0.0.127:21（本机的FTP端口）。这个包会从发送者自己路由到接收者手中，当然也有可能半路丢失掉。

在接收端，我们只要侦听相关端口就可以了，当有包从任何电脑发来的时候（这里没有连接的概念），我们在得到包的数据的同时，也得到了包的发送者的IP和端口数据，发送包的大小。

UDP是不稳定可靠的传输协议，事实上大部分的包是会被送达的，但是你一般会有1%到5%的丢包率。甚至你会发现有段时间，你连一个包都收不到。路由路径上的那些机器出了点啥问题，谁知道呢？

有时候收包的顺序和发包的顺序也是不同的，可能你发包的时候是1,2,3,4,5的顺序发。收到的包就变成1,3,4,5,2的顺序了。当然大部分时候这个顺序是不会乱的。但是这个谁都不敢打保票。

UDP只能保证你一件事，那就是包的完整性。你如果发一个256bytes的包，那么对方收到的肯定也是一个256bytes的包。他不会只收到半个包之类的。当然这其实也是UDP唯一能保证你的事情。其他事情都要靠你自己去订制。 by rellikt

TCP vs UDP

我们现在要做一个选择了。开发游戏到底是用UDP好呢？还是用TCP好呢？

首先我们连列一下他们的有缺点：

TCP：

1. 基于连接的协议。

2. 可靠性和数据包的序列性是有保证的。

3. 自动为你的数据封包。

4. 确保包的流量不会超出你的网络链接的负载上限。

5. 简单易用，你只需要像写文件一样去读写就万事大吉了。

UDP：

1. 没有连接的概念，如果你想要，自己去实现去。

2. 没有关于可靠性和包序列性的保证，包可能会丢失，重复，乱序。

3. 你必须自己去封包。

4. 你必须自己确保自己的数据包不会流量过大从而导致超过链接负载上限。

5. 你必须自己处理包的丢失，重复，乱序的情况，如果你不想他们对你的程序造成麻烦，必须要自己实现代码来做出应对。

这样一比，我们显然应该用那个TCP协议了。它完成了所有我们想要的特性，实在是太完美了，不是吗？by rellikt

TCP的真实工作情况

TCP和UDP都是基于IP协议的，但是他们的本质确实截然不同的。UDP和它底层的IP协议类似，TCP却将很多东西进行了抽象，它使你在使用它的时候感觉就像读写一个文件一样，事实上他对你隐藏了很多复杂功能的实现细节。

它到底是如何实现这些细节的呢？

首先，TCP是流性质的协议，你将数据一个比特一个比特的写入流，然后TCP来确保他们会最终到底目的地。我们必须明确：TCP协议是基于IP协议的，IP协议是基于数据包的。这里TCP其实是把我们的数据流在底层进行了打包。事实上有一些TCP协议中的代码就是把我们的数据流进行排队，然后依次写入包中，当包写入了足够多的数据以后，它就会把包发走。

这里就会导致一些问题，因为你不能控制底层的打包和传输，所以当很小的用户输入数据写入数据流的时候，TCP可能会凑满一定量的数据（比如100bytes），然后再打包发送。这样的话，在实时性上面就会很差，因为也许你会需要这些包越快到达越好。这些小延迟也许就会大大的影响你的游戏性。

TCP中其实有一个TCP_NODELAY的选项，使用这个选项以后，你的数据就会跳过TCP的队列打包过程，直接发送。

但是即使你使用的这个技术，你在多人网络游戏中还是会遇到不小的问题。

这些问题源自于TCP实现可靠传输的机制。by rellikt

TCP是如何实现可靠传输的

基本上来说，TCP将数据流中的数据做成封包，然后将他们通过不可靠的IP协议发送，然后在接收端重组这些包成为数据流。

但是当一个包丢失的时候TCP会做些什么呢？当包重复和乱序的时候TCP又做了些什么呢？

这里我不想做太深入的介绍，有兴趣的读者可以在wiki上找到他们需要的细节。大致来说，TCP发现丢包的时候，会要求发送者重发，重复的包会被丢弃，乱序包会被排序，事实上他就是这么保证传输的可靠性的。

这里的丢包处理对游戏来说就很糟糕了。TCP中，如果你发现丢包了，必须等待发送者进行重发，在重发的包到来以前，即使有新包来，你也只能让他们在队列里等着，不能读取，这个等待的时间大概是ping值的1.5倍，如果重发的包再次丢失的话那就是3倍的时间。假设你的ping值是125ms，丢包一次就会延迟200ms左右，如果连续丢包就是400ms，这样的情况在大多数即时类游戏中是不能忍受的。

为何你不能选用TCP作为游戏开发的网络协议

通过上面的论述，其实已经很明白了。在注重即时性的游戏中，对于延迟的要求是很苛刻的，我们可以丢包，但是如果我们收到了比丢掉的包更新的包的话，我们完全可以不管丢掉的包。我们只关注当前数据。

这里我们来假设一个最简单的多人游戏的模型。比如一个FPS游戏，你在客户段每次将输入的数据（比如前进，跳跃，开火）发送到服务器端，然后服务器端将玩家当前的位置和情况发回给客户端来做显示。

在这个最简单的模型中，只要有一个包丢失了，所有的东西都必须停下来等包的重发，任何操作都得停掉，你不能移动也不能射击。等到这个包到达的时候，你总算能继续操作了。但是可能你会发现还有一堆等等待重发的包在排队，于是你只好继续等，而且可能你收到的这个重发包对游戏来说已经失去时效性，完全没意义了。这样的游戏你能忍吗？

不幸的是你对TCP协议的这个行为完全无能为力。这是TCP协议的本性，就是它保证了TCP协议的可靠性的。

我们不需要这样无法订制的可靠性协议。我们需要自己进行订制丢包时的处理原则。这也是我们在开发游戏时，避免使用TCP协议的原因。

是否可以混合使用TCP和UDP协议呢？

上面的结论中，我们可以明确知道，一些类似玩家操作，玩家位置的时效性相关数据，我们必须不能使用TCP协议。但是有些数据确是必须保证可靠性的，那我们是否可以使用TCP协议来做同步呢？

这个想法是很好的，我们可以在玩家操作等即时性很强的数据上使用UDP协议，在玩家AI，数据加载，玩家对话等序列性很强的数据上使用TCP。如果你愿意的话，甚至可以为不同的AI创建不同的TCP连接，以免一个AI的丢包会影响的另外一个AI的即时性。

看上去这是一个不错的思路。但是这仅仅是看上去而已。由于TCP和UDP都是基于IP协议的，事实上他们在底层会互相干扰。关于干扰的细节我这里就不详细论述了，想了解的读者可以阅读这篇文章。 by rellikt

结论

我的建议是在游戏中仅仅使用UDP作为网络协议，即使要使用TCP也是自己在UDP的基础上实现一种类TCP的协议。这也是现代游戏中流行的网络架构。

接下来的文章中我会介绍如何实现这套架构。下一篇会讲的比较实际点，讲关于如何使用UDP收发包。尽请期待。 by rellikt

2.FPS游戏服务器设计的一些想法(FROM 高总)

链接：http://blog.csdn.net/sunguangran/article/details/6064256

      FPS游戏，至今我还没有真正设计过。从去年到盛大、今年到金山，感谢校长、锦州，让我有很多机会和公司内外的团队沟通和互相学习，加上自己有qqtang server的设计经验，对FPS游戏慢慢有些了解，经过不断的讨论，对其中的细节也逐步有些深入。因为没有完整设计过FPS游戏，所以很多想法可能是有很大偏差的，只是总结一下这1年多以来的心得。

一、玩家的游戏数据转发采用 UDP+应用层确认？ 还是 UDP+TCP ？

      qqtang游戏数据转发采用的后者，所有游戏数据（移动+捡道具+泡泡爆炸等）都通过UDP来转发，但是对于捡道具、泡泡爆炸等游戏关键数据是还会用tcp再转发一次。这样设计的原因是如果只有UDP（没有确认，不能重传）转发，UDP包丢失的话，就会导致游戏逻辑混乱，比如有个道具在界面上，不能捡，但是又阻碍人物行走；或者泡泡永不爆炸等情况。这些关键数据如果采用TCP转发就保证可靠性，而对于人物移动包，部分丢失不会影响游戏逻辑，所以只用UDP转发，也减少了流量。

反恐行动1的游戏包只有UDP转发，今年3月份和他们沟通的时候我一直都不是很明白他们是怎么保证可靠性的，后来才想清楚。它的转发逻辑应该是移动包等（允许一定丢失率的包）通过UDP转发，而且没有确认机制；游戏关键数据包（比如中弹、换枪等）也是通过UDP来转发的，但是这些包在应用层有确认和重发机制来保证数据的可靠传输。

到底哪种方式更好了，可以参考下qq server和qqgame server：

      2003年qq server采用的是公司自己设计的ftcp协议，就是基于UDP、在应用层实现可靠传输的协议。它主要是解决当时select模型的接入量和效率问题，当时qqgame也采用了ftcp协议来提高qqgame server的负载。但后来发现它不适合在游戏server上使用。原因是qqgame有20K以上的大包，ftcp协议要求我们进行拆分成n多小包发送，每个小包丢失都会导致整个大包的接收失败。采用ftcp协议能提高了接入量但单个用户的服务质量下降。最后没有办法我们还是用了select模型（半年后改为epoll模型，大大提高了接入量）。

反恐的模型（UDP+UDP应用层确认）和qqtang server（UDP+TCP），这两个模型，我比较建议用前者。

        1）fps游戏过程当中没有大包出现。

        2）统一采用udp，设计简单、逻辑一致。

        3）流量更小，FPS游戏对网络延迟要求很高，UDP的丢包率不高，所有关键包都转发浪费不少流量。

二、P2P模型？ 还是 C/S模型？

类似于qqtang、泡泡堂、泡泡卡丁车或者cf等游戏几年前我们设计的思路都采用的是P2P方式。记得2004年的时候，带宽的成本好像是一个月30W/G。现在的成本好像只有1/6-1/3，未来成本还会持续下降。

我之前统计qqtang的P2P打通率大概是70%，大约有70%的流量是通过P2P方式传输的，降低了运营商成本。但是整个互联网大环境的趋势对于P2P是不提倡的，另外重要的是P2P的方式导致程序设计很复杂，对于团队特别是创业团队是一个比较大的瓶颈，还会导致服务器的防外挂机制设计困难，玩家和玩家游戏数据的互通让server很难参与到其中来控制。

        qqtang是p2p模型，cf、反恐都是c/s模型，从个人经验看，除非在p2p上很有经验，否则采用cs模型可能更合适。

三、大厅服务器和游戏服务器的分离

        qqtang server的大厅和游戏是处于一个物理和逻辑服务器。crossfire的大厅服务器是集中在IDC机房，游戏逻辑服务器分布在CDN中。玩家开房进入游戏状态后会登录到游戏服务器上进行游戏，这种就近接入的方式在crossfire的运营上非常成功，很好的解决了FPS对网络延迟要求高的问题。

反恐行动1在服务器的分布上就没有像crossfire那样做，绝大部分玩家玩得还是不错，有少量的玩家反应有点卡。还好反恐行动2会解决这个问题，反恐行动2各方面都做了很大的优化，相信会有更佳的表现。

        FPS游戏因为对网络要求非常高，所以采用了分地域、就近接入的方式，这点和mmog有很大的不同，也是fps运营质量的保证。

四、玩家状态是即时转发还是状态同步

锦州之前设计的活力风暴时采用后者方案，每50ms把玩家的状态广播一次，玩家在50ms内发生的2次行为比如换过2把枪，只会把后面的状态记录下来。这会导致

         1）录像回放不好做，因为没有完整的行为过程，

         2）50ms的状态转发不会很精确，延时不确定，而且同步线程和主逻辑线程也有同步问题会无端增加延时。

         3）流量增加，每次状态同步会把一些没有变化的数据同步。 
         qqtang采用的是前者，程序设计相对复杂一点；但消息延迟更低，记录了游戏世界的事件逻辑。

五、服务器行走模拟？

服务器行走模拟的基础是采用cs模型，锦州之前采用unreal解决方案进行过测试，如果服务器做行走模拟可以很好的解决反外挂的问题，但是开销实在太大，物理碰撞之类的运算量太大；类似的尝试也在qqtang做过，我接手qqtang的时候还有服务器行走模拟的代码，最后发现cpu开销太大取消了。

服务器硬件的持续发展也许会让服务器行走模拟成为可行，如果可行，fps游戏的反外挂天然将形成了一个天然的屏障。

六、玩家伤害判断和防外挂

由于服务器计算碰撞的代价太大，所以玩家伤害等行为除了服务器做一定的校验外，主要是靠玩家之间互相的验证来实现的。在网络要求高的游戏中，一般我们都是以服务好网速更好的玩家为原则的，所以fps游戏防外挂是个比较艰巨的任务，就像之前的qqtang一样，客户端承担了太多的运算，同时又要保证好的用户感，就需要游戏逻辑中增加更多的防外挂的考虑。qqtang主要采用的是扫描特征码、动态代码执行等方案。

        unreal在fps已经形成了一套相对完整的解决方案，反恐1中已经得到验证，开发门槛低，效率还可以，也许未来的fps游戏可以采用现成的方案，开发者只需要完成主体框架和游戏内细节逻辑。

没有完整开发过一款fps游戏，这些都是一些想法总结而