11UDP︰用户数据报协议.ppt

第11章 UDP：用户数据报协议 U D P是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个U D P数据报，并组装成一份待发送的I P数据报。 这与面向流字符的协议不同，如T C P，应用程序产生的全体数据与真正发送的单个I P数据报可能没有什么联系。 U D P不提供可靠性：它把应用程序传给I P层的数据发送出去，但是并不保证它们能到达目的地。 由于缺乏可靠性，我们似乎觉得要避免使用U D P而使用一种可靠协议如T C P。 应用程序必须关心I P数据报的长度。如果它超过网络的M T U，那么就要对I P数据报进行分片。 如果需要，源端到目的端之间的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做。 U D P检验和覆盖U D P首部和U D P数据。回想I P首部的检验和，它只覆盖I P的首部—并不覆盖I P数据报中的任何数据。 U D P和T C P在首部中都有覆盖它们首部和数据的检验和。U D P的检验和是可选的，而T C P的检验和是必需的。 U D P检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为了发现U D P首部和数据在发送端到接收端之间发生的任何改动。 IP分片 ，物理网络层一般要限制每次发送数据帧的最大长度。任何时候I P层接收到一份要发送的I P数据报时，它要判断向本地哪个接口发送数据（选路），并查询该接口获得其M T U。I P把M T U与数据报长度进行比较，如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发生在中间路由器上。 把一份I P数据报分片以后，只有到达目的地才进行重新组装（这里的重新组装与其他网络协议不同，它们要求在下一站就进行进行重新组装，而不是在最终的目的地）。 重新组装由目的端的I P层来完成，其目的是使分片和重新组装过程对运输层（ T C P和U D P）是透明的，除了某些可能的越级操作外。 对于发送端发送的每份I P数据报来说，其标识字段都包含一个唯一值。该值在数据报分片时被复制到每个片中（我们现在已经看到这个字段的用途）。标志字段用其中一个比特来表示“更多的片”。除了最后一片外，其他每个组成数据报的片都要把该比特置1。 片偏移字段指的是该片偏移原始数据报开始处的位置。另外，当数据报被分片后，每个片的总长度值要改为该片的长度值。 最后，标志字段中有一个比特称作“不分片”位。如果将这一比特置1，I P将不对数据报进行分片。相反把数据报丢弃并发送一个I C M P差错报文给起始端。 当I P数据报被分片后，每一片都成为一个分组，具有自己的I P首部，并在选择路由时与其他分组独立。这样，当数据报的这些片到达目的端时有可能会失序，但是在I P首部中有足够的信息让接收端能正确组装这些数据报片。 尽管I P分片过程看起来是透明的，但有一点让人不想使用它：即使只丢失一片数据也要重传整个数据报。 为什么会发生这种情况呢？因为I P层本身没有超时重传的机制——由更高层来负责超时和重传（T C P有超时和重传机制，但U D P没有。一些U D P应用程序本身也执行超时和重传）。 当来自T C P报文段的某一片丢失后，T C P在超时后会重发整个T C P报文段，该报文段对应于一份I P数据报。没有办法只重传数据报中的一个数据报片。事实上，如果对数据报分片的是中间路由器，而不是起始端系统，那么起始端系统就无法知道数据报是如何被分片的。 就这个原因，经常要避免分片。 使用U D P很容易导致I P分片（在后面我们将看到， T C P试图避免分片，但对于应用程序来说几乎不可能强迫T C P发送一个需要进行分片的长报文段）。 简单的类似的例子：ping -l 65500 DestnationIP 最大UDP数据报长度 理论上，I P数据报的最大长度是6 5 5 3 5字节，这是由I P首部（图3 - 1）1 6比特总长度字段所限制的。去除2 0字节的I P首部和8个字节的U D P首部， U D P数据报中用户数据的最长长度为6 5 5 0 7字节。但是，大多数实现所提供的长度比这个最大值小。 我们将遇到两个限制因素。第一，应用程序可能会受到其程序接口的限制。socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于UDP socket，这个长度与应用程序可以读写的最大U D P数据报的长度直接相关。 第二个限制来自于T C P / I P的内核实现。可能存在一些实现特性（或差错），使I P数据报长度小于6 5 5 3 5字节。