1.4.1  UDP

前面已经讲过，UDP就是用户数据报协议。数据报本质上就是一个单一的数据包。UDP协议比较简单，它也不像更复杂的协议（例如TCP协议）那样提供可靠传输。本质上，只是将包发送出去并希望它到达目的地。这是一种“发送后不理它（fire and forget）”的协议。图1.11展示了UDP首部格式。

图1.11　UDP包的首部格式

注意：UDP的端口（port）域长度是16比特（很快就会看到，TCP的也是这么长）。这就意味着总共可以使用65 536个端口。1024以下的端口留给专门的应用层协议使用，这是由因特网地址分配机构（Internet Assigned Numbers Authority，IANA）来指定的。若想查看这些端口列表，可以访问网站http://www.iana.org。IANA所分配的端口号比如有HTTP（80）、FTP（21）、Telnet（23）、SMTP（25）以及数百个无人听说过的其他协议。一般来说，应该在程序中尽量使用1024以上的端口号。如果登录账户不是root账户，则在基于UNIX的系统中运行程序时，甚至不允许打开1024以下的端口（对服务器来说）。表1.2列出了常用的端口号。

表1.2  常用端口号

^[*]有关Pieserver的更多信息请参见http://ronpenton.net/projects。

在图1.11中首先应该注意首部长度只有64比特，或者说8个字节。这一包首部相当短，至少与其他协议相比算是很短的。

接下来注意两个端口域。我们知道，包到达目的地后，接收机实际上根本无法断定包要到达哪个程序。因此，就提出了端口这一思想。当端口接收到一个包时，操作系统应该从包中将端口号读出来，并将此包发送给合适的程序。这样，同一台机器上就可以有许多不同的程序，所有这些程序都同时使用网络连接。

在图1.11中，还应该注意长度和校验和域。长度表示包括首部在内的包数据的长度。校验和域包含包中数据的校验和，以便于接收机能够断定数据是否完整无损。如果数据并不是完整无损的，则接收方干脆就丢弃此包，当作此包根本就没到达一样。

UDP是一种无连接的协议。这就意味着UDP程序彼此并不相互连接，它们只是发送包，期望服务器接收包。而其他一些协议，尤其是TCP，则不会接收即将到达的包，除非是先明确地连接到另一端。

UDP并不能保证发送的包成功交付给接收方，这一事实产生了一些问题。在节奏快的游戏中，服务器不断地向客户端发送有关其他玩家位置的更新信息，保证成功交付不会有太大的问题。例如，如果发送一个位置更新包，但接收方根本就没有收到，则可靠的协议（例如TCP）将一直试着发送包。但是，等到协议最终将原始的包发送出去时，玩家的位置可能已经变了。因此，在这种情况下，UDP就是一种很有用的协议。

但对于重要的数据会有什么后果呢？如果游戏中发生了某种情况，而游戏已经开始，这样以后将不会重新发送数据，结果会怎么样呢？最终，玩家可能会完全丢失一个重要的游戏事件（例如，射击），然后就不再同步。在这种情况下，UDP就不是一个明智的选择。

对于MUD和MMOG，一般来说，使用UDP并不理想，因为在这些游戏类型中所发生的大多数事情都是基本事件，也就是说，事件一旦发生，玩家就绝对需要知道到底发生了什么事。