格式

头部8字节, 四个字段各2Byte

长度2Byte -> 在这里虽然依旧能够到达65535Byte, 但是是冗余的, 在IP数据报中已经记录大小.

校验和2Byte -> 在IPv4中做12字节伪头部 or 在IPv6中做40字节伪头部进行校验. 穿过NAT后, 伪头部会被修改.

IPv6和UDP

• IPv4中校验和功能可以不打开, 但是IPv6数据报不提供校验功能, 因此在UDP中必须校验.

• IPv6支持超长数据报(记录长度使用了32位), 但是UDP记录长度的位置只有16位, 因此如果溢出的话, 则使用0来记录大小

• Teredo : 使用IPv4来传输IPv6网络数据包. 由微软开发, 并提供了teredo.ipv6.microsoft.com来作为中转服务器. 其行为和NAT打洞和中转服务器类似

值得注意的是:

1. teredo协议在记录原IP, 端口号的时候按位取反, 防止NAT去重写信息.
2. teredo协议在生成IPv6地址的时候, 虽然有规则, 但是仍然加入随机值, 防止地址猜测攻击

UDP-Lite

可以容忍部分的内容错误

下一头部字段 136

头部中的校验和字段变成了校验范围, 能够选择校验0~65535中的前多少. 但是这个值在1~7之间是非法的, 因为头部要求必须被校验

IP分片

MTU常见的是1500Byte,留给UDP内容是1472Byte.

如果超过这个大小, UDP就会被分片. 不同的分片段有同一个IP数据报序号. 前面的片MF被设置"还有更多". 每一个分片带有偏移字段, *8后代表最终携带的字节.

在非第一个分片的IP数据报中, 没有说明"下一个头部"的号码.

拥有更大的偏移量的片会被优先投递, 让接收方提前知道这个UDP数据报到底有多大, 可以提前分配内存

IP分片重组超时

只对前两个分片报告ICMP超时, 后续的不再报告.

甚至有可能根本不报告, 因为收到的前两个数据报中没有携带端口信息, 导致ICMP数据报缺少内容

收到第一个分片就开始计时, 收到后续分片不重置计时器, 一般是30s超时

MTU发现

发送的第一个UDP数据报可能默认是DF(不要分片)的, 这样如果IP数据报大小大于MTU时会被直接丢弃, 并返回一个ICMP消息. 如果在网络层报告的MTU信息之后, 这个程式还在运行, 那么就会利用这个MTU发现, 来更改DF信息, 允许分片. MTU信息也会有超时, 如果超时了, 那么又会恢复到之前的默认状态.

ARP和分片

历史问题:

• 每一个分片都会产生一个ARP? -> 限制ARP生成速率, 比如1s一个

• 相同的未被解析的地址, 应该拥有更大的队列来保存还未发送的数据报

IPv6地址转换和分片

对于无状态的地址转化, 原来被分片后带有零校验和的IPv4-UDP不能转换, 因为变成IPv6之后没法计算(IPv6没有首部校验)

最大UDP

虽然字段上能设置成65535 - 8 = 65527Byte, 但是应用程序不一定能接受这么大, 或者系统不接受这么大

系统会API截断, 丢弃这个数据报中超出的部分 or 超出的部分留到下一次读取中 or 通知上层有多少被丢弃了. (取决于系统实现). 这被称为消息边界. TCP没有消息边界, 以"流"的形式传输.

UDP服务器的实现

要注意IPv6和IPv4的地址长度不同, 使用不同的数据结构.
IPv6的程序端口可能会同时占用Ipv4的端口

如果想让重用同样的端口给不同的地址, 需要显式的通知系统.(e.g. 监听两个网卡的80端口).

每一个端点都会收到一个拷贝. (端点的概念同时包含了防止多线程的进程多次读取)

本机地址	远端地址	描述
local_IP : local_port	foreign_IP : foreign_port	限制只有一个远端设备可用
local_IP: local_port	.	对所有远端开放
* : local_port	.	只限制自己端口

互联网和分片

虽然只有<0.1%的流量是分片的, 但是70%左右的分片都是UDP的

分片出现的可能因素:

• 粗糙的封装
• MTU发现的缺失
• 要经过VPN隧道的流量, 会被加上更多的头部, 但是内部IPv4流量禁止分片, 外部加上的头部允许分片. (浪费)