11.1 引言
UDP 是一个简单的 面向数据报 的运输层协议:进程的每个 输出操作 都正好产生一个 UDP数据报,并且组装成一份待发送的IP数据报。
这与 TCP 不一样,它是 面向流字符 的协议,应用层程序 产生的全体数据 与 真正发送的单个IP数据报 可能没有联系。
UDP协议并不提供超时重传,出错重传等功能,也就是说其是 不可靠(unreliable)的协议。
UDP 把应用程序传给IP层的数据发送出去,但是并不能保证它们都能到达目的地。
应用程序必须关心 IP数据报 的长度。如果它超过网络的MTU(最大传输单元),那么就要对 IP数据报 进行分片。路径MTU:两台主机之间的路径中 最小的MTU。
11.2 UDP首部
该部分参考资料:详解学习笔记 UDP
UDP首部:
端口号表示 发送进程 和 接收进程。
这里教材讲的不清不楚的。引用一段别人所写的博客。
由于很多软件需要用到UDP协议,所以UDP协议必须通过某个标志用以区分不同的程序所需要的数据包。端口号的功能就在于此,例如某一个UDP程序A在系统中注册了3000端口,那么,以后从外面传进来的目的端口号为3000的UDP包都会交给该程序。端口号理论上可以有2^16这么多。因为它的长度是16个bit。
TCP/IP协议族中用端口号来标识进程;
端口号 是在 0 到 65535 之间的 整数;
客户程序 随机选取的 临时端口号;
每一种服务器程序 被分配了 确定的全局一致的 熟知端口号;
每一个客户进程 都知道 相应的服务器进程的 熟知端口号。
也就是说,根据端口号,可以知道它所代表的是哪一个进程。
在之前的内容里面,有介绍 TCP 和 UDP 通过 目的端口号 来 分用 来自IP层的数据 的过程。由于IP层 已经把 IP数据报 分配给了 TCP 或者是 UDP(通过 IP数据报 的 协议字段,TCP值为3,UDP值为4),所以 TCP端口号 由 TCP 查看,UDP端口号 由 UDP 查看。
UDP数据报 长度字段 指的是 UDP首部 和 UDP数据 的字节长度,而 IP数据报 长度字段指的是数据报全长。那么 UDP数据报 长度字段 的值 = IP数据报 长度字段 的值 - IP数据报首部 的长度。
11.3 UDP 检验和:保证数据的完整性
该部分参考资料:UDP协议及包格式
UDP 检验和的 目的:保证数据的完整性。
UDP 检验和 覆盖 UDP首部 和 UDP数据,而 IP 检验和只覆盖首部,并不覆盖任何数据。
TCP 和 UDP 都有检验和,UDP是可选的,而TCP是必需的。
UDP 检验和的求法利用了和 IP 检验和 求法类似的 16bit 的 二进制反码求和。但是有不同的地方。
检验和求法 不同之一:填充字段
UDP 数据报的长度可以是奇数字节,但 检验和算法 是把 若干个16 bit字相加。
解决方法是:在最后增加填充字节0。这只是为了 检验和的计算(也就是说,这些可能增加的 填充字节 不会被传送)。
检验和求法 不同之二:伪首部
为了 计算检验和 而在 UDP数据报和TCP段 设置一个十二字节长的 伪首部。
伪首部 包含 IP首部的一些字段:32位源IP地址,32位目的IP地址,8位协议字段。目的是让 UDP 两次检测数据是否已经准确到达目的地。没有准确到达目的地,比如 IP没有接受地址不是本机的数据报,以及 IP 没有把 应该 传给另一高层的数据报 传输给UDP。
如果 发送端 没有计算检验和(传送的检验和为0),而接收端 检测到检验和有差错,UDP数据报就会被悄悄的丢弃,不产生任何差错报文。
总而言之,UDP 在 完成进程 到 进程的通信 中 提供了 有限的差错检验功能。
11.5 IP分片
物理网络层一般要限制每次发送数据帧的最大长度,任何时候 IP层 接收到一份 待发送的 IP数据报 的时候,它要判断向本地哪个接口发送数据(选路),并查询该接口获得MTU。IP 比较 MTU 和 数据报长度,如果需要的话(数据报长度 > MTU),则进行 IP分片。
分片 可以发生在 原始发送端主机上,也可以发生在中间路由器上面。
把 IP数据报 分片之后,只有 到达目的地 才重新组装。
重新组装 由 目的端的IP层 进行,目的:让分片和重新组装的过程 对 运输层(TCP/UDP) 透明。IP首部中包含的数据为 重新组装 提供信息。
分片之后的数据报可能再进行分片。分片之后 每一片都是一个 分组,具有自己的 IP首部。
回忆 IP首部
IP首部 中用于 分片和重组 的部分:
- 标识字段
- 标志字段
- 片偏移字段
标识字段:16bit,对于发送端发送的每一个IP数据报来说,这个标识字段有一个唯一值,也就是说,标识字段是用于区分数据报的。
在数据报分片的时候,被复制到每个片中。
标志字段:很重要,有3bit。
- 一位无效位
- 一位表示 是否有更多的片(MF, More Fragment),除了最后一片(MF = 0)之外,其余片 值均为1(MF = 1 代表后面还有片)。让接收端知道什么时候完成分片组装。
- DF (Don't Fragment),表示无法分片。
片偏移字段:说明了在原来的数据报中的相对位置。
回到IP分片
IP分片 过程看起来是透明的,但是:即使只丢失一片数据报的分片,也要重传一整个数据报。没有办法只重传数据报中的某一个数据报片。
原因是:IP层没有超时重传机制,由更高层负责超时重传(TCP有,UDP没有,但是 UDP的一些应用程序 本身也执行 超时和重传)。TCP在超时之后,会重新发送整个TCP报文段,对应于一个IP数据报。
起始端系统不清楚IP报文是怎么被分片的。
在分片时,除了最后一片,其他每一片的数据部分 都是 8字节 的整数倍。
术语的解释
IP数据报 指的是 端对端 的传输单元(分片之前,重新组装之后)。
分组 指的是 在 IP层 和 数据链路层 之间传送的数据单元。
分组 可以是 一个完整的IP数据报,也可以是IP数据报的一个分片。
ICMP不可达差错(需要分片)
发送 ICMP不可达差错报文 的另外一种情况是:当路由器收到一份需要分片的数据报,而在 IP数据报的首部 又设置了 DF(不分片) 的标志比特。
可以利用这个报文(含下一站网络的MTU) 判断到达目的端的路径MTU(最小MTU),称作 路径MTU发现机制。
如果路由器没有提供这种ICMP差错报文格式,则把下一站的MTU设为0。
在点对点链路中,不要求两个方向上的MTU为相同值。
11.7 利用Traceroute 确定路径MTU
Traceroute 所要做的:发送分组,设置“不分片”标志比特。Traceroute 程序本身也是利用 IP数据报 中的TTL字段。
11.9 UDP 和 ARP 之间的交互作用
使用 UDP,可以看到 UDP 和 ARP 典型实现之间的有趣的(但常常未被提交的)交互作用。
假定此时主机的 ARP缓存是清空的,那么在发送第一个数据报片的时候,就必须交换 ARP请求 和 应答。
那么此时就提出了两个问题:
- 在接收到应答之前,其余数据报是否做好了发送准备?
- 如果做好了发送准备,那么在等待的过程中,它会如何处理发送往给定目的地的多个报文?
产生结果是令人吃惊的,首先在第一个ARP应答返回之前,产生了六个ARP请求,其原因是 IP很快产生了六个IP数据报片,而每个数据报片生成了一个 ARP请求。
第二,在收到第一个 ARP应答 的时候,只将最后一个 IP数据报片 发送给目的端。
这种情况,称为 ARP洪泛。即以 高速率重复 发送到 同一个IP地址 的 ARP请求。
ARP 应该保留至少一个报文,而这个报文必须是最后一个报文。
当第一个到达的数据报片 出现的时候,目的端 IP层 必须启动一个计时器,值为30s或者60s,如果超时,且所有数据报片没有全部到达(没有出现 MF = 0 的数据报片),则将这些报片全部丢弃。否则会引起接收端缓存满。
如果按照上面的情况丢弃数据报,没有ICMP消息的产生。这是因为 并未接收到 包含UDP首部的 偏移量为0 的第一个数据报片(注意区别 第一个 和 第一个到达的),除非接收到,否则不要求产生任何ICMP报文。
这样的话,上层:TCP或者UDP的应用程序,最终会超时重传。
11.10 最大UDP数据报长度
UDP数据报 中用户数据的最大长度:65507字节。
限制因素:
- 应用程序受到其端口的限制。
- TCP/IP 内核实现,导致实现特性(或者差错),使IP数据报 小于65535字节。
数据报截断
IP能够发送或者接收特定长度的数据报,并不意味着,接收应用程序也可以读取该长度的数据。
UDP 接口允许应用程序指定每次返回的最大字节数。但是 如何解决 接收到 的数据报长度 大于 应用程序所能处理的长度?取决于 编程接口和实现。
11.11 ICMP源站抑制错误
使用UDP 可以产生 ICMP 源站抑制 错误。
当一个接收端(系统) 接收数据报的速度 >>(远大于) 处理速度 的时候,缓存很容易用完。这个时候就 可能 产生这个错误 (注意可能,即使缓存已满丢弃了部分数据报,也并不要求这样做):
别再发送啦,我快受不了了!!
11.12 UDP服务器的设计
客户端的设计和实现 比 服务端的要轻松很多。服务器端需要与操作系统进行交互作用,而且大多数情况下,需要处理多个用户。
服务器启动之后处于休眠状态,等待客户请求的到来。
大多数 UDP服务器,是重复型服务器。(参见第一章)
11.12.1 客户IP地址 及 端口号
来自客户的 是 UDP数据报。IP首部包含源端和目的端IP地址。UDP首部包含了源端和目的端的UDP端口号(用于 分用)。当应用程序接收到 UDP数据报 的时候,操作系统必须告诉它是谁发送的消息(即告诉 源端IP地址 和端口号)。
这个特性允许一个 交互UDP服务器对多个客户进行处理,并发送应答。
11.12.2 目的IP地址
一些应用程序需要知道 数据报 是发送给谁的,即目的IP地址。如果目的IP地址是广播地址,则自动忽略。
这要求操作系统 告诉应用程序 目的IP地址。
11.12.3 UDP输入队列
大多数UDP服务器 是 重复型服务器。这意味着 单个服务器 在 单个UDP端口上 处理 所有的请求。UDP将所有请求自动排队,将以接收顺序传给输入端。UDP输出队列 是 FIFO的(先进先出)。排队溢出造成的数据报丢失是可能存在的。
2016/8/4