“21天好习惯”第一期-11

“21天好习惯”第一期-11 无连接运输：UDP

由【RFC 768】定义的UDP只是做了运输协议能够做的最少工作。除了复用/分解功能及少量的差错检测外，它几乎没有对IP增加别的东西。实际上，如果应用程序开发人员选择UDP而不是TCP，则该应用程序差不多就是直接与IP打交道。UDP从应用进程得到数据，附加上用于多路复用/分解服务的源和目的端口号字段，以及两个其它的小字段，然后将形成的报文段交给网络层。网络层将该运输报文段封装到一个IP数据报中，然后尽力而为地尝试将此报文段交付给接收主机。如果该报文段到接收主机，UDP使用目的端口号将报文段中的数据交付给正确的应用进程。值得注意的是，使用UDP时，在发送报文段之前，发送方和接收方的运输层实体之间没有握手。正因为如此，UDP被称为是无连接的。
DNS是一个通常使用UDP的应用层协议的例子。当一台主机中的DNS应用程序想要进行一次查询时，它构造了一个DNS查询报文并将其交给UDP。无须执行任何与运行在目的端系统中的UDP实体之间的握手，主机端的UDP为此报文添加首部字段，然后将形成的报文段交给网络层。网络层将此UDP报文段封装进一个IP数据报中，然后将其发送给一个名字服务器。在查询主机中的DNS应用程序则等待对该查询的响应。如果它没有收到响应（可能是由于底层网络丢失了查询或响应），则要么试图向另一个名字服务器发送该查询，要么通知调用的应用程序它不能获得响应。
根据上述描述，我们也许想知道，，为什么应用开发人员宁愿在UDP之上构建应用，而不选择在TCP上构建应用？既然TCP提供了可靠数据传输服务，而UDP不能提供，那么TCP是否总是首选的呢？答案是否定的，因为由许多应用更适合用UDP，原因主要有以下几点：

• 关于发送什么数据以及何时发送的应用层控制更为精细
  采用UDP时，只要应用进程将数据传递给UDP，UDP就会将此数据打包进UDP报文段并立即将其传递给网络层。在另一方面，TCP有一个拥塞控制机制，以便当源和目的主机间的一条或多条链路变得极度拥塞时来遏制运输层TCP发送方。TCP仍将继续重新发送数据报文段直到目的主机收到此报文段并加以确认，而不管可靠交付需要多长时间。因为实时应用通常要求最小的发送速率，不希望过分地延迟报文段的传送，且能容忍一些数据丢失，TCP服务模型并不是特别适合这些应用的需要。

• 无须连接建立
  TCP在开始数据传输之前要经过三次握手。UDP却不需要任何准备即可进行数据传输。因此UDP不会引入建立连接的时延。这可能是DNS运行在UDP之上而不是运行在TCP之上的主要原因（如果运行在TCP上，则DNS会慢得多）。HTTP使用TCP而不是UDP，因为对于具有文本数据得Web网页来说，可靠性是至关重要的。

• 无连接状态
  TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数以及序号与确认号得参数。要实现TCP得可靠数据传输服务并提供拥塞控制，这些状态信息是必要得。另一方面，UDP不维护连接状态，也不跟踪这些参数。因此，某些专门用于某种特定应用得服务器当应用程序运行在UDP之上而不是运行在TCP上时，一般都能支持更多得活跃用户。

• 分组首部开销小
  每个TCP报文段都有20字节得首部开销，而不是UDP仅有8字节得开销。

UDP报文段结构

|源端口号|目的端口号 | — 32比特
|-长度-|-检验和-|
| 应用数据（报文） |
UDP报文段结构上所示，它由RFC 768定义。应用层数据占用UDP报文段的数据字段。例如，对于DNS应用，数据字段要么包含一个查询报文，要么包含一个响应报文。对于流式音频应用，音频抽样数据填充到数据字段。UDP首部只有4个字段，每个字段由两个字节组成。

UDP检验和

UDP检验和提供了差错检测功能。检验和用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发声了改变（例如，由于链路中的噪声干扰或者存储在路由器中时引入问题）。发送方的UDP对报文段中的所有比特字的和进行反码运算，求和时遇到的任何溢出都被回卷。得到的结果被放在UDP报文段中的检验和字段。