网络游戏程序员须知 UDP vs TCP
这篇教程让我们就从最基本的网络数据收发开始谈起吧。其实这部分才是网络程序员应该做的最基础最简单的部分，但是这部分如果想要做好相对来说还是很有技巧和困难的。而且如果这部分你没做好，在多人对战类游戏中它带来的影响是极其恶劣的。
?你可能听说过端口这个概念，也可能知道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
?
?写了老半天，总算翻译完了，大家如果喜欢的话，下周有空我再翻译一章吧。就这样了。
?
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/rellikt/archive/2010/08/21/5829020.aspx
