TCP/IP卷一:58---UDP之(路径MTU发现机制(PMTUD)、UDP最大数据报长度(数据报截断)、UDP/IPv4和UDP/IPv6数据报的转换)
发布日期:2021-06-29 22:32:59 浏览次数:3 分类:技术文章

本文共 2177 字,大约阅读时间需要 7 分钟。

一、采用UDP的路径MTU发现

  • MTU介绍见文章:

UDP的路径MTU发现

  • 让我们考察使用UDP的应用程序与路径MTU发现机制(PMTUD)之间的交互过程
  • 对一个像UDP这样的协议来说,调用这样协议的应用程序一般只控制输出数据报的大小,如果有方法能确定一个可以避免分片的合适的数据报大小,那么这会是很有用的
  • 传统的PMTUD使用ICMPPTB消息(见前面ICMP文章)来获得一个最大分组大小,其沿着一条路由路径传输不会引人分片。典型地,这些消息在UDP层之下被处理,对应用程序不可见,因此,它们要么是一个API调用,被应用程序用于获取对路径(与每个路径的目的地 都已通信过)的MTU大小的当前最好的估计,要么是不被应用程序所知的、能独立地进行 PMTUD的IP层。IP层经常基于每个目的地址缓存一个PMTUD信息,并且当没有更新时就让它超时

例子

  • 待续

二、UDP最大数据报长度

  • IP数据报的最大长度:
    • IPv4:一个IPv4数据报的最大长度是65535字节,这由IPv4头部的16位总长度字 段决定(见前面Internet文章)。除去20字节不带选项的IPv4头部和一个8字节的UDP头部,就剩下最大65 507字节留给一个UDP数据报的用户数据
    • IPv6:对于IPv6,假设没使用超长数据报,16位负载长度字段可允许655527字节的有效UDP负载(65535字节的IPv6负载中的8字节 被用于UDP头部)
  • 然而,有两个原因使得这些大小的满额数据报不能被端到端投递:
    • 第一,系统的本地协议实现可能有一些限制
    • 第二,接收应用程序可能没准备好去处理这么大的数据报

实现限制

  • 协议实现给应用程序提供一个API以让它选择一些默认缓存大小来进行发送和接收。某些实现提供的默认值小于最大IP数据报大小,实际上有些还不支持发送大于几十kB的数据报(尽管这个问题不多见)
  • API套接字提供一组函数让应用程序能够调用以设置或查询接收和发送缓存的大小。对于一个UDP套接字,这个大小与应用程序可读或可写的最大UDP数据报大小直接关联。典型的默认值是8192字节或65 535字节,但一般可以调用setsocketopt() API来设置更大的值
  • 在前面Internet协议文章中我们提到过一台主机重组分片时要提供足够的缓存来接收至少一个576字节的IPv4数据报。许多UDP应用程序被设计成限制数据报的大小在512字节或更小以下(这使得IPv4数据报小于576字节)。对UDP数据报的大小使用了这些限制的例子包括DNS和DHCP

数据报截断

  • UDP/IP能发送和接收一个给定大小的(大)数据报并不意味着接收应用程序就能够读取这种大小的数据报
  • UDP编程接口允许应用程序指定每次一个网络的读操作完成时返回的最大字节数。如果接收的数据报超过这个指定大小会发生什么?
    • 大多数情况下,这个问题的答案是API截断数据报,丢弃这个数据报里超过接收应用程序指定字节数的任何超额数据
    • 然而,每种实现的具体操作是不同的。一些系统把这些数据报的超额数据放到后续的读操作中,另一些则通知调用者有多少数据被截断了(或有些情况是通知有一些数据被截断但不知具体是多少)
  • 备注:
    • 在Linux中,MSG_TRUNC选项可被套接字API用来查看有多少数据被截断
    • 在HP-UX上,MSG_TRUNC却是一个标志,当一个读操作返回“有数据被截 断时”就进行设置。SVR4(包括Solaris 2.x)的套接字API不会截断数据报。任何 超额的数据都被返回给后续的读操作。对一个UDP数据报进行的多次读操作是不会通知应用程序的
  • 在我们讨论TCP时会发现,它给应用程序提供连续的字节流,没有任何消息边界。因此,应用程序可得到它请求的任意大小的数据量,可供给充足的数据(如果不行,通常可以等待)

三、UDP/IPv4和UDP/IPv6数据报的转换

  • 在第7章我们讨论了一个用于从IPv4传送IP数据报到IPv6(或反之)的框架。前面“防火墙和NAT”文章描述了这个框架如何应用到ICMPo像第7章描述的那样,当UDP经过一个转换器时,转 换就会发生,除了针对UDP校验和的一些问题。对于UDP/IPv4数据报, UDP头部的校 验和字段允许为0(不计算),而UDP/IPv6则不然。后果是,校验和为0的完整数据报到 来时,从IPv4转换到IPv6产生的结果是,生成一个带有完整进行了计算的伪头部校验和 的UDP/IPv6数据报,或者是丢弃了到来的数据报。转换器应提供一个配置选项来选择取舍哪种情况,因为产生这些校验和的开销可能是不能接受的。如果使用了非校验和中立的地址映射的话(见前面防火强的文章),包含非零校验和的分组在任一边被转换时都要求更新校验和
  • 分片数据报出现另一个挑战。对于无状态的转换器,被分片的带有零校验和的UDPAPv4 数据报不能转换,因为没有合适的UDP/IPv6可以计算。这些数据报被丢弃。有状态的转换器(即NAT64)可以重组许多分片和计算要求的校验和。被分片的带有已计算校验和的UDP/IP 数据报在转换的两边都被当作普通分片处理,如前面文章“防火墙和NAT”。大UDP/IPv4数据报需要分片以 适合转换后的IPv6最小MTU,它们同样被当作普通IPv4数据报处理(即它们按需求分片)

转载地址:https://dongshao.blog.csdn.net/article/details/103992785 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:Linux(内核剖析):23---中断下半部之(下半部总体概述)
下一篇:TCP/IP卷一:57---IP分片与重组、IP分片重组超时、IP分片和ARP/ND之间的交互

发表评论

最新留言

路过,博主的博客真漂亮。。
[***.116.15.85]2024年04月12日 02时52分28秒