网络协议2

IPv4与UDP详解

最新推荐文章于 2025-01-01 10:48:13 发布

pacogang

最新推荐文章于 2025-01-01 10:48:13 发布

阅读量531

点赞数

CC 4.0 BY-SA版权

分类专栏：协议 TCP/IP 文章标签：网络

本文链接：https://blog.youkuaiyun.com/pacogang/article/details/8802471

协议同时被 2 个专栏收录

6 篇文章

订阅专栏

TCP/IP

5 篇文章

订阅专栏

1、IP

IPv4报文的首部包含14个字段，其中13个是必须的，第14个是可选的（在表中用红色标出），并贴切地命名为：“选项”。首部中的字段均以大端序包装，在以下的图表和讨论中，最高有效位被标记为0，因此例如版本字段实际上可在第一个字节的前四高有效位中被找到。

位偏移	0–3	4–7	8–13	14-15	16–18	19–31
0	版本	首部长度	DSCP	显式拥塞通告	全长
32	标识符				标志	分片偏移
64	存活时间		协议		首部检验和
96	源IP地址
128	目的IP地址
160	选项（如首部长度>5）
160 or 192+	数据

版本

IP报文首部的第一个字段是4位版本字段。对IPv4来说，这个字段的值是4。

首部长度（IHL）

第二个字段是4位首部长度，说明首部有多少32位字长。由于IPv4首部可能包含数目不定的选项，这个字段也用来确定数据的偏移量。这个字段的最小值是5（ RFC 791），最大值是15。

DiffServ（DSCP）

最初被定义为服务类型字段，但被 RFC 2474重定义为 DiffServ。新的需要实时数据流的技术会应用这个字段，一个例子是 VoIP。

显式拥塞通告（ECN）

在 RFC 3168中定义，允许在不丢弃报文的同时通知对方网络拥塞的发生。ECN是一种可选的功能，仅当两端都支持并希望使用，且底层网络支持时才被使用。

全长

这个16位字段定义了报文总长，包含首部和数据，单位为字节。这个字段的最小值是20（20字节首部+0字节数据），最大值是65,535。所有主机都必须支持最小576字节的报文，但大多数现代主机支持更大的报文。有时候子网会限制报文的大小，这时报文就必须被分片。

标识符

这个字段主要被用来唯一地标识一个报文的所有分片。一些实验性的工作建议将此字段用于其它目的，例如增加报文跟踪信息以协助探测伪造的源地址。 ^[5]

标志

这个3位字段用于控制和识别分片，它们是：

位0：保留，必须为0；
位1：禁止分片（DF）；
位2：更多分片（MF）。

如果DF标志被设置但路由要求必须分片报文，此报文会被丢弃。这个标志可被用于发往没有能力组装分片的主机。

当一个报文被分片，除了最后一片外的所有分片都设置MF标志。不被分片的报文不设置MF标志：它是它自己的最后一片。

分片偏移

这个13位字段指明了每个分片相对于原始报文开头的偏移量，以8字节作单位。

存活时间（TTL）

这个8位字段避免报文在互联网中永远存在（例如陷入路由环路）。存活时间以秒为单位，但小于一秒的时间均向上取整到一秒。在现实中，这实际上成了一个跳数计数器：报文经过的每个路由器都将此字段减一，当此字段等于0时，报文不再向下一跳传送并被丢弃。常规地，一份 ICMP报文被发回报文发送端说明其发送的报文已被丢弃。这也是 traceroute的核心原理。

协议

这个字段定义了该报文数据区使用的协议。 IANA维护着一份协议列表（最初由 RFC 790定义）。

首部检验和

这个16位检验和字段用于对首部查错。在每一跳，计算出的首部检验和必须与此字段进行比对，如果不一致，此报文被丢弃。值得注意的是，数据区的错误留待上层协议处理—— 用户数据报协议和传输控制协议都有检验和字段。

因为生存时间字段在每一跳都会发生变化，意味着检验和必须被重新计算， RFC 1071这样定义计算检验和的方法：

The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.

源地址

一个IPv4地址由四个字节共32位构成，此字段的值是将每个字节转为二进制并拼在一起所得到的32位值。

例如，10.9.8.7是00001010000010010000100000000111。

这个地址是报文的发送端。但请注意，因为NAT的存在，这个地址并不总是报文的真实发送端，因此发往此地址的报文会被送往NAT设备，并由它被翻译为真实的地址。

目的地址

与源地址格式相同，但指出报文的接收端。

选项

附加的首部字段可能跟在目的地址之后，但这并不被经常使用。请注意首部长度字段必须包括足够的32位字来放下所有的选项（包括任何必须的填充以使首部长度能够被32位整除）。当选项列表的结尾不是首部的结尾时，EOL（选项列表结束，0x00）选项被插入列表末尾。下表列出了可能的选项：

字段	长度（位）	描述
备份	1	当此选项需要被备份到所有分片中时，设为1。
类	2	常规的选项类别，0为“控制”，2为“查错和措施”，1和3保留。
数字	5	指明一个选项。
长度	8	指明整个选项的长度，对于简单的选项此字段可能不存在。
数据	可变	选项相关数据，对于简单的选项此字段可能不存在。

注：如果首部长度大于5，那么选项字段必然存在并必须被考虑。
注：备份、类和数字经常被一并称呼为“类型”。

宽松的源站选路（LSRR）和严格的源站选路（SSRR）选项不被推荐使用，因其可能带来安全问题。许多路由器会拒绝带有这些选项的报文。

数据

数据字段不是首部的一部分，因此并不被包含在检验和中。数据的格式在协议首部字段中被指明，并可以是任意的传输层协议。

一些常见协议的协议字段值被列在下面：

协议字段值	协议名	缩写
1	互联网控制消息协议	ICMP
2	互联网组管理协议	IGMP
6	传输控制协议	TCP
17	用户数据报协议	UDP
41	IPv6封装	-
89	开放式最短路径优先	OSPF
132	流控制传输协议	SCTP

2、UDP

用户数据报协议（User Datagram Protocol, UDP）是一个简单的面向数据报的传输层协议，正式规范为RFC 768。

在TCP/IP模型中，UDP为网络层以上和应用层以下提供了一个简单的接口。UDP只提供数据的不可靠传递，它一但把应用程序发给网络层的数据发送出去，就不保留数据备份（所以UDP有时候也被认为是不可靠的数据报协议）。UDP在IP数据报的头部仅仅加入了复用和数据校验（字段）。

UDP首部字段由4个部分组成，其中两个是可选的。各16bit的来源端口和目的端口用来标记发送和接受的应用进程。因为UDP不需要应答，所以来源端口是可选的，如果来源端口不用，那么置为零。在目的端口后面是长度固定的以字节为单位的长度域，用来指定UDP数据报包括数据部分的长度,长度最小值为8byte。首部剩下地16bit是用来对首部和数据部分一起做校验和（Checksum）的，这部分是可选的，但在实际应用中一般都使用这一功能。

由于缺乏可靠性且属于非连接导向协定，UDP应用一般必须允许一定量的丢包包、出错和复制贴上。但有些应用，比如TFTP，如果需要则必须在应用层增加根本的可靠机制。但是绝大多数UDP应用都不需要可靠机制，甚至可能因为引入可靠机制而降低性能。流媒体(串流技术)、即时多媒体游戏和IP电话 (VoIP)一定就是典型的UDP应用。如果某个应用需要很高的可靠性，那么可以用传输控制协议(TCP协议)来代替UDP。

由于缺乏拥塞控制（congestion control），需要基于网络的机制来减少因失控和高速UDP流量负荷而导致的拥塞崩溃效应。换句话说，因为UDP发送者不能够检测拥塞，所以像使用包队列和丢弃技术的路由器这样的网络基本设备往往就成为降低UDP过大通信量的有效工具。数据报拥塞控制协议(DCCP)设计成通过在诸如流媒体类型的高速率UDP流中，增加主机拥塞控制，来减小这个潜在的问题。

UDP的分组结构

UDP报头
偏移	字节	0								1								2								3
字节	`位`	`0`	`1`	`2`	`3`	`4`	`5`	`6`	`7`	`8`	`9`	`10`	`11`	`12`	`13`	`14`	`15`	`16`	`17`	`18`	`19`	`20`	`21`	`22`	`23`	`24`	`25`	`26`	`27`	`28`	`29`	`30`	`31`
0	`0`	来源连接端口																目的连接端口
4	`32`	报长																检查码