UDP和IP的首部结构

## 1 TCP 报文段的首部格式

> TCP 报文段首部的**前 20 个字节是固定的**，**后面有**$ 4n$**字节是根据需要而增加的选项**（$n$ 是整数），因此**TCP 首部的最小长度是 20 字节**。

![](https://notebook.ricear.com/media/202206/2022-06-19_210707_320980.png)

### 1.1 固定部分

1. **源端口**和**目的端口**：

1. 各占**2 个字节**，分别写入源端口号和目的端口号，用于**寻找发端和收端应用进程**，这两个值**加上 IP 首部中的源端 IP 地址和目的端 IP 地址唯一确定一个 TCP 连接**。
   2. TCP 基于端口的分用原理如下图所示：
      ![](https://notebook.ricear.com/media/202206/2022-06-20_212737_495665.png)
      1. 当**传输层从 IP 层收到 TCP 报文段**时，就**根据首部中的目的端口**，**把 TCP 报文段通过相应的端口**，**上交最后的终点**-**应用进程**。
      2. 如果**接收方 TCP 发现收到的报文中的目的端口号不正确**（即不存在对应于该端口号的应用进程），**就丢弃该报文**，并**由网际控制报文协议 ICMP 发送端口不可达差错报文给发送方**。
2. **序号**：

1. 占**4 个字节**，序号范围是 $[0, 2^32 - 1]$，共 $ 2^32$ 个序号，**序号增加到 $ 2^32 - 1$ 后**，**下一个序号就又回到 0**，也就是说，**序号使用**$mod \; 2^32$**运算**。
   2. TCP 是面向字节流的，在一个 TCP 连接中传送的字节流中的**每一个字节都按顺序编号**，**整个要传送的字节流的起始序号必须在连接建立时设置**，首部中的序号字段值则指的是**本报文段所发送的数据的第一个字节的序号**，例如，一报文段的序号字段值是 301，而携带的数据共有 100 字节，这就表明，本报文段的数据的第一个字节的序号是 301，最后一个字节的序号是 400，显然，下一个报文段的数据序号应当从 401 开始，即下一个报文段的序号字段值应为 401，这个字段的名称也叫做**报文段序号**。
3. **确认号**：

1. 占**4 个字节**，是**期望收到对方下一个报文段的第一个数据字节的序号**，例如，$B$ 正确收到了 $A$ 发送过来的一个报文段，其序号字段值是 501，而数据长度是 200 字节，这表明 $B$ 正确收到了 $A$ 发送的到序号 700 为止的数据，因此，$B$ 期望收到 $A$ 的下一个数据序号是 701，于是 $B$ 在发送给 $A$ 的确认报文段中把确认号置为 701。

> 若**确认号为**$N$，则表明**到序号**$N - 1$**为止的所有数据都已正确收到**。
      >

> 由于**序号字段有 32 位长**，**可对 4GB**（即 4 千兆字节）**的数据进行编号**，**在一般情况下可保证当序号重复使用时**，**旧序号的数据早已通过网络到达终点了**。
      >
4. **数据偏移**：

1. 占**4 位**，他指出**TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远**，这个字段实际上指出**TCP 报文段的首部长度**。
   2. 由于**首部中还有长度不确定的选项字段**，因此**数据偏移字段是必要的**，但需要注意的是**数据偏移的单位是 32 位字**（即以 4 字节长的字为计算单位），由于**4 位二进制数能够表示的最大十进制数字是 15**，因此**数据偏移的最大值是 60 字节**，这也是**TCP 首部的最大长度**（即选项长度不能超过 40 字节）。
5. **保留**：

1. 占**6 位**，**保留为今后使用**，但**目前应置为 0**。
6. **紧急 URG**(URGent)：

1. 当 $URG = 1$ 时，**表明紧急指针字段有效**，他告诉系统**此报文段中有紧急数据**，**应尽快传送**（相当于高优先级的数据），而**不要按原来的排队顺序来传送**：
      1. 例如，已经发送了很长的一个程序要在远地的主机上运行，但后来发现了一些问题，需要取消该程序的运行，因此用户从键盘发出中断命令（`Ctrol + C`），如果不使用紧急数据，那么这两个字符将存储在接收 TCP 的缓存末尾，只有在所有的数据被处理完毕之后这两个字符才被交付接收方的应用进程，这样做就浪费了许多时间。
      2. 当 $URG$**置 1 时**，**发送应用进程就告诉发送方的 TCP 有紧急数据要传送**，于是**发送方 TCP 就把紧急数据插入到本报文段数据的最前面**，而在**紧急数据后面的数据仍是普通数据**，这时**要与首部中紧急指针**（Urgent Pointer）**字段配合使用**。
7. **确认 ACK**（ACKnowledgement）：

1. **仅当 ACK = 1 时确认号字段才有效**，**当 ACK = 0 时确认号无效**。
   2. TCP 规定，**在连接建立后所有传送的报文段都必须把 ACK 置 1**。
8. **推送 PSH**（PuSH）：

1. 当**两个应用进程进行交互式通信**时，有时**在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应**，在这种情况下，TCP 就可以使用推送（push）操作。
   2. 这时，**发送方 TCP 把**$PSH$**置 1**，并**立即创建一个报文段发送出去**，**接收方 TCP 收到**PSH = 1**的报文段**，就**尽快地**（即推送向前）**交付接收应用进程**，而**不再等到整个缓存都填满了后再向上交付**。
   3. 虽然应用程序可以选择推送操作，但推送操作**很少使用**。
9. **复位 RST**（ReSeT）：

1. 当 $RST = 1$**时**，表明**TCP 连接中出现严重差错**（如由于主机崩溃或其他原因），**必须释放连接**，**然后再重新建立传输连接**。
   2. $RST$**置 1 还用来拒绝一个非法的报文段或拒绝打开一个连接**，因此也可称为**重建位**或**重置位**。
10. **同步 SYN**（SYNchronization）：

1. **在[连接建立](https://notebook.ricear.com/project-26/doc-301)时用来同步序号**：

1. **当**$SYN = 1$**而**$ACK = 0$**时**，**表明这是一个连接请求报文段**。
       2. **对方若同意建立连接**，**则应在响应的报文段中使**$SYN = 1$**和**$ACK = 1$。
    2. 因此，$SYN$**置为 1 就表示这是一个连接请求或连接接受报文**。
11. **终止 FIN**（FINis）：

1. 用来[释放一个连接](https://notebook.ricear.com/project-26/doc-302)。
    2. 当 $FIN = 1$**时**，表明**此报文段的发送方的数据已发送完毕**，并**要求释放传输连接**。
12. **[窗口](https://notebook.ricear.com/project-26/doc-930/#1-2-%E6%BB%91%E5%8A%A8%E7%AA%97%E5%8F%A3%E5%8D%8F%E8%AE%AE)**：

1. 占**2 字节**，**窗口值是**$[0, 2^{16} - 1]$**之间的整数**。
    2. 窗口指的是**发送本报文段的一方的接收窗口**（而不是自己的发送窗口），**窗口值告诉对方**，**从本报文段首部中的确认号算起**，**接收方目前允许对方发送的数据量**（以字节为单位），之所以要有这个限制，是因为**接收方的数据缓存空间是有限的**。
    3. 总之，**窗口值作为接收方让发送方设置其发送窗口的依据**，而且**经常在动态变化着**。
13. **[校验和](https://notebook.ricear.com/project-26/doc-930/#2-4-%E6%A0%A1%E9%AA%8C%E5%92%8C)**：

1. 占**2 字节**，校验和字段校验的范围包括**首部**和**数据**这两部分。
    2. 和 UDP 用户数据报一样，在计算校验和时，要**在 TCP 报文段前面加上 12 字节的伪首部**，具体可参考[校验和](https://notebook.ricear.com/project-26/doc-930/#2-4-%E6%A0%A1%E9%AA%8C%E5%92%8C)。
14. **紧急指针**：

1. 占**2 字节**，紧急指针**仅在**$URG = 1$**时才有意义**，他指出**本报文段中的紧急数据的字节数**（紧急数据结束后就是普通数据），因此，紧急指针指出了**紧急数据的末尾在报文段中的位置**。
    2. **当所有紧急数据都处理完时**，**TCP 就告诉应用程序恢复到正常操作**。
    3. 值得注意的是，即使**窗口为零时也可发送紧急数据**。

### 1.2 选项部分

1. **长度可变**，**最长可达 40 字节**，**当没有使用选项时**，**TCP 的首部长度是 20 字节**。
2. **TCP 最初只规定了一种选项**，即**最大报文段长度**（Maximum Segment Size, MSS），后来随着互联网的发展，又陆续增加了几个选项，如**窗口扩大**选项、**时间戳**选项和**选择确认**选项。

> 什么是 MSS？
   > MSS 是**每一个 TCP 报文段中的数据字段的最大长度**，因为**数据字段加上 TCP 首部才等于整个的 TCP 报文段**，所以 MSS 并**不是整个 TCP 报文段的最大长度**，**而是 TCP 报文段长度减去 TCP 首部长度**。
   >

> 为什么要规定一个 MSS？
   >
   > 1. 这并不是考虑接收方的接收缓存可能放不下 TCP 报文段中的数据，实际上，MSS 与接收窗口值没有关系。
   > 2. 我们知道，**TCP 报文段的数据部分**，**至少要加上 40 字节的首部**（TCP 首部 20 字节和 IP 首部 20 字节），**才能组装成一个 IP 数据报**：
   > 3. **若选择较小的 MSS 长度**，**网络的利用率就降低**：
   >    1. 设想在极端的情况下，当 TCP 报文段中只含有 1 字节的数据时，在 IP 层传输的数据报的开销至少有 40 字节（包括 TCP 报文段的首部和 IP 数据报的首部），这样，对网络的利用率就不会超过 $\frac{1}{40}$，到了数据链路层还要加上一些开销。
   >    2. 但反过来，若 TCP 报文段非常长，那么在 IP 层传输时就有可能要分解成多个短数据报片，在终点要把收到的各个短数据报片装配成原来的 TCP 报文段，当传输出错时还要进行重传，这些也都会使开销增大。
   > 4. 因此，**MSS 应尽可能大些**，**只要在 IP 层传输时不需要再[分片](https://notebook.ricear.com/project-26/doc-930/#2-1-1-IP-%E5%8D%8F%E8%AE%AE%E5%88%86%E7%89%87)就行**，由于**IP 数据报所经历的路径是动态变化的**，因此**在这条路径上确定的不需要分片的 MSS**，**如果改走另一条路径就可能需要进行分片**，因此**最佳的 MSS 是很难确定的**。
   > 5. **在连接建立的过程中**，**双方都把自己能够支持的 MSS 写入这一字段**，**以后就按照这个数值传送数据**，**两个传送方向可以有不同的 MSS 值**，**若主机未填写这一项**，**则 MSS 的默认值是 536 字节长**，**因此**，**所有在互联网上的主机都应该能接受的报文段长度是 536 + 20**（固定首部长度）**= 556 字节**。
   >

> 什么是窗口扩大选项？
   >
   > 1. 窗口扩大选项是为了**扩大窗口**，我们知道，TCP 首部中窗口字段值是 16 位，因此最大的窗口为 64K 字节，虽然这对早期的网络是足够用的，但对于包含卫星信道的网络，传播时延和带宽都很大，**要获得高吞吐率需要更大的窗口大小**。
   > 2. 窗口扩大选项占**3 字节**，其中**有一个字节表示移位值**$S$，**新的窗口值等于 TCP 首部中的窗口位数从 16 增大到**$(16 + S)$，**移位值允许使用的最大值是 14**，**相当于窗口最大值增大到**$(2^{16 + 14} - 1 = 2^{30} - 1)$。
   > 3. 窗口扩大选项可以**在双方初始建立 TCP 连接时进行协商**，**如果连接的某一端实现了窗口扩大**，**当他不再需要扩大其窗口时**，**可发送**$S = 0$**的选项**，**使窗口大小回到 16**。
   >

> 什么是时间戳选项？
   >
   > 1. 时间戳选项占**10 字节**，其中最主要的字段是**时间戳值**字段（4 字节）和**时间戳回送回答**字段（4 字节）。
   > 2. 时间戳选项有以下两个功能：
   > 3. 第一，用来**计算[往返时间 RTT](https://notebook.ricear.com/project-26/doc-930/#2-2-1-%E5%BE%80%E8%BF%94%E6%97%B6%E9%97%B4%E6%B5%8B%E9%87%8F)**，**发送方在发送报文段时把当前时钟的时间值放入时间戳字段**，**接收方在确认该报文段时把时间戳字段值复制到时间戳回送回答字段**，因此，**发送方在收到确认报文后**，**可以准确地计算出 RTT 来**。
   > 4. 第二，用于**处理 TCP 序号超过**$ 2^{32}$**的情况**，这又称为**防止序号绕回**（Protect Against Wrapper Sequence numbers, PAWS），我们知道，**TCP 报文段的序号只有 32 位**，而**每增加**$2^{32}$**个序号就会重复使用原来用过的序号**，**当使用高速网络时**，**在一次 TCP 连接的数据传送中序号很可能会被重复使用**，例如，当使用 1.5Mbit/s 的速率发送报文段时，序号重复要 6 小时以上，但若用 2.5Gbit/s 的速率发送报文段，则不到 14 秒钟序号就会重复，为了**使接收方能够把新的报文段和迟到很久的报文段区分开**，可以**在报文段中加上这种时间戳**。
   >

> 什么是选择确认选项？
   > 选择确认选项相关的内容详见[带选择确认的重传](https://notebook.ricear.com/project-26/doc-930/#2-2-2-3-%E5%B8%A6%E9%80%89%E6%8B%A9%E7%A1%AE%E8%AE%A4%E7%9A%84%E9%87%8D%E4%BC%A0)。
   >

## 2 UDP 的首部格式

![](https://notebook.ricear.com/media/202206/2022-06-20_210935_514997.png)

1. 用户数据报 UDP 有两个字段，分别为**数据字段**和**首部字段**。
2. 首部字段很简单，只有**8 个字节**，由**4 个字段**组成，**每个字段的长度都是两个字节**，各字段的意义如下：
   1. **源端口**：
      1. **源端口号**，**在需要对方回信时选用**，**不需要时可用全 0**。
   2. **目的端口**：
      1. **目的端口号**，**在终点交付报文时必须使用**。
      2. **UDP 基于端口分用的原理和 TCP 类似**，**具体可参考 TCP 基于端口分用的原理**。
   3. **长度**：
      1. **UDP 用户数据报的长度**，其**最小值是 8**（仅有首部）。
   4. **校验和**：
      1. **检测 UDP 用户数据报在传输中是否有错**，**有错就丢弃**。
      2. UDP 计算校验和的方法和计算 IP 数据报首部校验和的方法相似，但不同的是**IP 数据报的校验和只检验 IP 数据报的首部**，但**UDP 的校验和是把首部和数据部分一起都检验**。
      3. UDP 校验和的计算方法如下：
         1. 在**发送方**，首先是**先把全零放入检验和字段**，**再把伪首部以及 UDP 用户数据报看成是由许多 16 位的字串接起来的**，**若用户数据报的数据部分不是偶数个字节**，**则要填入一个全零字节**（但此字节不发送），**然后按二进制反码计算出这些 16 位字的和**，**将此和的二进制反码写入检验和字段后**，**就发送这样的数据报**。

> 什么是反码求和？
            > 反码求和的规则是**从地位到高位逐列进行计算**，**0 和 0 相加是 0**，**0 和 1 相加是 1**，**1 和 1 相加是 0 但要产生一个进位 1**，**加到下一列**，**若最高位相加后产生进位**，**则最后得到的结果要加 1**。
            >
         2. 在**接收方**，**把收到的 UDP 用户数据报连同伪首部**（以及可能的填充全零字节）**一起**，**按二进制反码求这些 16 位字的和**，**当无差错时其结果应全为 1**，**否则就表明有差错出现**，**接收方就应丢弃这个用户数据报**（也可以**上交给应用层**，但**附上出现了差错的警告**）。
      4. UDP 校验和的计算实例如下图所示：
         ![](https://notebook.ricear.com/media/202206/2022-06-04_213705_225227.png)
         > 1. 上图中假定用户数据报的长度是 15 字节，因此需要添加一个全 0 的字节。
         > 2. 上图中伪首部第 3 字段是全零，第 4 字段是 IP 首部中的协议字段的值，对于 UDP，此协议字段的值为 17，第 5 字段是 UDP 用户数据报的长度。
         > 3. 因此，这样的校验和，**既检查了 UDP 用户数据报的源端口号和目的端口号以及 UDP 用户数据报的数据部分**，**又检查了 IP 数据报的源 IP 地址和目的地址**。
         >

## 3 IP 数据报的格式

1. IP 数据报的格式能够说明 IP 协议都具有什么功能，在 TCP/IP 标准中，各种数据格式常常**以 32 位**（即 4 字节）**为单位来描述**，IP 数据报的完整格式如下图所示。

![](https://notebook.ricear.com/media/202206/2022-06-21_204136_235588.png)
   2. 从上图中可以看出，一个 IP 数据报由**首部**和**数据**两部分组成，首部的前一部分是**固定长度**，共**20 字节**，是**所有 IP 数据报必须具有的**，在首部的固定部分的后面是一些**可选字段**，其长度是可变的，下面介绍首部各字段的意义。

### 3.1 固定部分

1. **版本**：
   1. 占**4 位**，指**IP 协议的版本**，**通信双方使用的 IP 协议的版本必须一致**，**目前广泛使用的 IP 协议版本号为 4**（即 IPv4）。
2. **首部长度**：
   1. 占**4 位**，**可表示的最大十进制数值是 15**。
   2. 需要注意的是：
      1. **首部长度字段所表示数的单位是 32 位字**（1 个 32 位字长是 4 字节），因为**首部的固定长度是 20 字节**，因此**首部长度的最小值是 5**（即二进制表示的首部长度是 0101），而**当首部长度为最大值 1111 时**（即十进制数的 15），就**表明首部长度达到最大值 15 个 32 位字长**，即**60 字节**。
      2. **当 IP 分组的首部长度不是 4 字节的整数倍时**，**必须利用最后的填充字段加以填充**，因此**IP 数据报的数据部分永远在 4 字节的整数倍时开始**，这样**在实现 IP 协议时较为方便**。
      3. 首部长度限制为 60 字节的缺点是有时可能不够用，但这样做是希望用户尽量减少开销，最常用的首部长度是 20 字节（即首部长度为 0101），这时不使用任何选项。
3. **区分服务**：
   1. 占**8 位**，**用来获得更好的服务**。
   2. 只有在使用区分服务时，这个字段才起作用，在一般的情况下都不使用这个字段。
4. **总长度**：
   1. 总长度指**首部和数据之和的长度**，单位为**字节**。
   2. 总长度字段为**16 位**，因此**数据报的最大长度为**$2^{16} - 1 = 65535$**字节**，然而实际上传送这样长的数据报在现实中是极少遇到的。
   3. IP 层下面的**每一种数据链路层协议都规定了一个数据帧中的数据字段的最大长度**，这称为**最大传送单元**（Maximum Transfer Unit, MTU），当一个 IP 数据报封装成链路层的帧时，此**数据报的总长度**（即首部加上数据部分）**一定不能超过下面的数据链路层所规定的的 MTU 值**，否则将进行分片，分片的相关内容详见[IP 协议分片](https://notebook.ricear.com/project-26/doc-930/#2-1-1-IP-%E5%8D%8F%E8%AE%AE%E5%88%86%E7%89%87)。
5. **标识**（identification）：
   1. 占**16 位**。
   2. IP 软件在存储器中维持一个计数器，**每产生一个数据报**，**计数器就加 1**，并**将此值赋给标识字段**，但这个标识并不是序号，因为 IP 是无连接服务，数据报不存在按序接收的问题，当数据报由于长度超过网络的 MTU 而必须分片时，这个标识字段的值就被**复制到所有的数据报片的标识字段中**，**相同的标识字段的值使分片后的各数据报片最后能正确地重装成为原来的数据报**。
6. **标志**（flag）：
   1. 占**3 位**，但**目前只有两位有意义**：
      1. 标志字段的**最低位**记为**MF**（More Fragment）：
         1. $MF = 1$ 表示**后面还有分片的数据报**。
         2. $MF = 0$ 表示**这已是若干数据报片中的最后一个**。
      2. 标志字段**中间的一位**记为**DF**（Don't Fragment）：
         1. $DF = 1$ 表示**不能分片**。
         2. $DF = 0$ 表示**可以分片**。
7. **片偏移**：
   1. 占**13 位**。
   2. 片偏移指出**较长的分组在分片后**，**某片在分组中的相对位置**，也就是说，**相对于用户数据字段的起点**，**该片从何处开始**。
   3. 片偏移**以 8 个字节为偏移单位**，也就是说，**每个分片的长度一定是 8 字节的整数倍**。
   4. 具体实例如下：
      1. 一数据报的总长度为 3820 字节，其数据部分为 3800 字节（使用固定首部），需要分片为长度不超过 1420 字节的数据报片，因固定首部长度为 20 字节，因此每个数据报片的数据部分长度不能超过 1400 字节，于是分为 3 个数据报片，其数据部分的长度分别为 1400、1400 和 1000 字节，原始数据报首部被复制为各数据报片的首部，但必须修改有关字段的值，分片的最后结果如下图所示（请注意片偏移的数值）：
         ![](https://notebook.ricear.com/media/202206/2022-06-22_195703_542613.png)
      2. 本例中数据报首部与分片有关的字段中的数值如下表所示，其中标识字段的值（12345）是任意给定的，**具有相同标识的数据报片在目的站就可无误地重装成原来的数据报**。
         ![](https://notebook.ricear.com/media/202206/2022-06-22_200442_363582.png)
      3. 现在假定数据报片 2 经过某个网络时还需要再进行分片，即划分为数据报片 2-1（携带数据 800 字节）和数据报片 2-2（携带数据 600 字节），那么这两个数据报片与分片有关的字段中的数值如下表所示。
         ![](https://notebook.ricear.com/media/202206/2022-06-22_201158_960011.png)
8. **生存时间**：
   1. 占**8 位**，生存时间字段常用的英文缩写是 TTL（Time To Live），表名这是**数据报在网络中的寿命**，**由发出数据报的源点设置这个字段**，其目的是**防止无法交付的数据报无限制地在互联网中兜圈子**（例如从路由器 $R_1$ 转发到 $R_2$，再转发到 $R_3$，然后又转发到 $R_1$），因而**白白消耗网络资源**。
   2. 最初的设计是**以秒作为 TTL 值的单位**，**每经过一个路由器时**，**就把 TTL 减去数据报在路由器所消耗掉的一段时间**，**若数据报在路由器消耗的时间小于 1 秒**，**就把 TTL 值减 1**，**当 TTL 值减为零时**，**就丢弃这个数据报**。
   3. 然而随着技术的进步，**路由器处理数据报所需的时间在不断缩短**，**一般都远远小于 1 秒**，后来就把 TTL 字段的功能改为**跳数限制**（但名称不变），**路由器在每次转发数据报之前就把 TTL 值减 1**，**若 TTL 值减小到零**，**就丢弃这个数据报**，**不再转发**，因此，现在 TTL 的单位不再是秒，而是**跳数**。
   4. TTL 的意义是**指明数据报在互联网中至多可经过多少个路由器**，显然，**数据报能在互联网中经过的路由器的最大数值是 255**，**若把 TTL 的初始值设置为 1**，**就表示这个数据报只能在本局域网中传送**，**因为这个数据报一传送到局域网上的某个路由器**，**在被转发之前 TTL 值就减小到零**，**因而就会被这个路由器丢弃**。
9. **协议**：
   1. 占**8 位**，协议字段指出**此数据报携带的数据是使用何种协议**，以便**使目的主机的 IP 层知道应将数据部分上交给哪个协议进行处理**。
   2. 常用的一些协议和相应的协议字段值如下表所示。
      ![](https://notebook.ricear.com/media/202206/2022-06-22_203114_640134.png)
10. **首部校验和**：
    1. 占**16 位**，这个字段**只检验数据报的首部**，**不检验数据部分**，这是因为**数据报每经过一个路由器**，**路由器都要重新计算一下首部校验和**（一些字段，如生存时间、标志、片偏移等都有可能发生变化），不检验数据部分可**减少计算的工作量**。
    2. 为了进一步减小计算检验和的工作量，IP 首部的检验和不采用复杂的 CRC 检验码而采用下面的简单计算方法：
       1. **在发送方**，**先把 IP 数据报首部划分为许多 16 位字的序列**，**并把检验和字段置零**，**用反码算术运算把所有 16 位字相加后**，**将得到的和的反码写入检验和字段**。
       2. **接收方收到数据报后**，**将首部的所有 16 位字再使用反码算术运算相加一次**，**将得到的和取反码**，**即得出接收方检验和的计算结果**，**若首部未发生任何变化**，**则此结果必为 0**，**于是就保留这个数据报**，**否咋即认为出差错**，**并将此数据报丢弃**。
          ![](https://notebook.ricear.com/media/202206/2022-06-22_204234_555126.png)
11. **源地址**：
    1. 占**32 位**。
12. **目的地址**：
    1. 占**32 位**。

### 3.2 可变部分

1. IP 数据部首部的可变部分就是一个**选项字段**，主要用来支持排错、测量以及安全等措施，内容很丰富。
2. 此字段的**长度可变**，**从 1 个字节到 40 个字节不等**，**取决于所选择的项目**，这些选项一个一个**拼接起来**，中间**不需要有分隔符**，最后**用全 0 的填充字段补齐成为 4 个字节的整数倍**。
3. 增加首部的可变部分是为了**增加 IP 数据报的功能**，但这同时也**使得 IP 数据报的长度成为可变的**，这就**增加了每一个路由器处理数据报的开销**，实际上这些选项**很少被使用**，很多路由器都不考虑 IP 首部的选项字段，因此新的 IP 版本**IPv6 就把 IP 数据报的首部长度做成固定的**，这里就不讨论这些选项的细节了。

## 参考文献

1. 《计算机网络-第 7 版-谢希仁》。