【TCP/IP详解-清晰版】第11章 UDP用户数据报协议

0.链接

用udp实现一个回显服务器

1.引言

UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发
送的IP数据报.这与面向流字符的协议不同,如TCP,应用程序产生的全体数据与真正发送的单个IP数据报可能没有
什么联系.

RFC 768 [Postel 1980]是UDP的正式规范.

UDP不提供可靠性:它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地。

2.UDP首部

2.1 UDP首部的解析

端口号表示发送进程和接收进程。
TCP和UDP用目的端口号来分用来自IP层的数据.
IP层已经把IP数据报分配给TCP或UDP(根据IP首部中协议字段值),因此TCP端口号由TCP来查看,而UDP端
口号由UDP来查看.TCP端口号与UDP端口号是相互独立的.


尽管相互独立，如果TCP和UDP同时提供某种知名服务，两个协议通常选择相同的端口号.
这纯粹是为了使用方便，而不是协议本身的要求.
UDP长度字段指的是UDP首部和UDP数据的字节长度.
该字段的最小值为 8字节(发送一份0字节的UDP数据报是OK).这个UDP长度是有冗余的.
IP数据报长度指的是数据报全长(图3-1),因此UDP数据报长度是全长减去IP首部的长度(该值在首部长度字段中
指定,如图3-1所示).

2.2 友情链接-IP数据报的格式

析图3-1中的首部.

最高位在左边,记为0bit；最低位在右边，记为31bit。
4个字节的32 bit值以下面的次序传输：
首先是0～7bit,
其次8～15 bit,
然后16～23 bit，
最后是24~31 bit.
这种传输次序称作big endian字节序.
由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序.

以其他形式存储二进制整数的机器,如little endian格式,则必须在传输数据之前把首部转换成网络字节序.

目前的协议版本号是4，因此I P有时也称作IPv4.

3.10节将对一种新版的IP协议进行讨论.
首部长度指的是首部占32bit字的数目,包括任何选项.
由于它是一个 4比特字段，因此首部最长为60个字节.
在第8章中，我们将看到这种限制使某些选项如路由记录选项在当今已没有什么用处.
普通IP数据报（没有任何选择项）字段的值是5.
服务类型(TOS)字段包括一个3bit的优先权子字段(现在已被忽略),4bit的TOS子字段和1bit未用位但必须置0.
4bit的TOS分别代表：最小时延、最大吞吐量、最高可靠性和最小费用.
4bit中只能置其中1bit.
如果所有4 bit均为0，那么就意味着是一般服务.
RFC 1340[Reynolds and Postel 1992]描述了所有的标准应用如何设置这些服务类型.
RFC 1349[Almquist 1992]对该RFC进行了修正，更为详细地描述了TOS的特性.
图3-2列出了对不同应用建议的TOS值.在最后一列中给出的是十六进制值,因为这就是在后面将要看到的
tcpdump命令输出.

3.UDP检验和

UDP检验和覆盖UDP首部和UDP数据.回想IP首部的检验和,它只覆盖IP的首部—并不
覆盖IP数据报中的任何数据。
UDP和TCP在首部中都有覆盖它们首部和数据的检验和。 
UDP的检验和是可选的，而TCP的检验和是必需的。
尽管UDP检验和的基本计算方法与我们在3.2节中描述的IP首部检验和计算方法相类似
(16 bit字的二进制反码和),但是它们之间存在不同的地方.
首先,U D P数据报的长度可以为奇数字节,但是检验和算法是把若干个16bit字相加.
解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算(也就是说,可能增加的填充字节不被传送).

其次，UDP数据报和TCP段都包含一个12字节长的伪首部，它是为了计算检验和而设置的.
伪首部包含IP首部一些字段。其目的是让UDP两次检查数据是否已经正确到达目的地
(例如，IP没有接受地址不是本主机的数据报,以及IP没有把应传给另一高层的数据报传给UDP).
UDP数据报中的伪首部格式如图11-3所示.

在该图中，我们特地举了一个奇数长度的数据报例子，因而在计算检验和时需要加上填
充字节。注意，U D P数据报的长度在检验和计算过程中出现两次。
如果检验和的计算结果为 0，则存入的值为全 1（6 5 5 3 5），这在二进制反码计算中是等效
的。如果传送的检验和为0，说明发送端没有计算检验和。

如果发送端没有计算检验和而接收端检测到检验和有差错，那么 U D P数据报就要被悄悄
地丢弃。不产生任何差错报文（当 I P层检测到I P首部检验和有差错时也这样做）。
U D P检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为
了发现U D P首部和数据在发送端到接收端之间发生的任何改动。
尽管U D P检验和是可选的，但是它们应该总是在用。在 8 0年代，一些计算机产商在默认
条件下关闭U D P检验和的功能，以提高使用 U D P协议的N F S（Network File System）的速度。
在单个局域网中这可能是可以接受的，但是在数据报通过路由器时，通过对链路层数据帧进
行循环冗余检验（如以太网或令牌环数据帧）可以检测到大多数的差错，导致传输失败。不
管相信与否，路由器中也存在软件和硬件差错，以致于修改数据报中的数据。如果关闭端到
端的U D P检验和功能，那么这些差错在 U D P数据报中就不能被检测出来。另外，一些数据链
路层协议（如S L I P）没有任何形式的数据链路检验和。
Host Requirements RFC声明，U D P检验和选项在默认条件下是打开的。它还声明，
如果发送端已经计算了检验和，那么接收端必须检验接收到的检验和（如接收到检验
和不为0）。但是，许多系统没有遵守这一点，只是在出口检验和选项被打开时才验证
接收到的检验和。