IPv4 协议首部的最小长度是 **20 字节**。

如果只是应付一道选择题，记住 `20` 就可以了。但这类题真正容易出错的地方，并不在于数字本身，而在于 IPv4 首部里有一个很特殊的字段 `IHL`。这个字段保存的并不是字节数，而是以 `32 bit` 字为单位的首部长度。只要把这一层关系真正理解清楚，IPv4 首部的最小长度、最大长度，以及 `20`、`40`、`60`、`64` 这些经常混在一起的数字，就很难再记错。

RFC 791 对 IPv4 首部格式作出了原始定义。IPv4 首部中的 `IHL` 字段占 `4 bit`，它表示 Internet Header Length，也就是 Internet 首部长度。RFC 791 明确规定，`IHL` 使用 `32 bit word` 作为计量单位，并且一个合法 IPv4 首部的 `IHL` 最小值是 `5`。[RFC Editor](https://www.rfc-editor.org/rfc/rfc791.html?utm_source=chatgpt.com)

因此计算非常直接

```text
IHL 最小值 = 5

1 个 32 bit word = 32 bit = 4 byte

IPv4 首部最小长度
= 5 × 32 bit
= 160 bit
= 20 byte
```

所以题目

```text
IPv4 协议首部最小长度为（ ）字节
```

应填写

```text
20
```

这里最关键的一步，不是背诵 `20`，而是理解

```text
IHL = 5
```

并不代表首部只有 `5 byte`，它代表首部包含 `5` 个 `32 bit` 字。

于是

```text
5 × 4 byte = 20 byte
```

这才是 IPv4 最小首部长度的来源。

IPv4 的设计年代很早，当时协议设计者大量按照机器字和 `32 bit` 边界组织协议结构。因此 IPv4 并没有直接在 `IHL` 字段里记录 `20`，而是记录 `5`。从协议编码角度看，这样做非常节省空间。由于 `IHL` 字段只有 `4 bit`，它能够表示的无符号数范围是

```text
0000 ～ 1111
```

也就是十进制

```text
0 ～ 15
```

IPv4 又规定合法首部长度不得小于 `5`，所以正常情况下可以把它理解成

```text
5 ≤ IHL ≤ 15
```

于是最小长度自然就是

```text
5 × 4 = 20 byte
```

最大长度则是

```text
15 × 4 = 60 byte
```

因此另一个经常与本题一起出现的考试结论也可以直接得到

```text
IPv4 首部最小长度 = 20 byte

IPv4 首部最大长度 = 60 byte
```

RFC 791 在讨论数据报长度时，也直接提到 IPv4 Internet Header 的最大长度是 `60 octets`，典型首部是 `20 octets`。这里的 `octet` 就是 `8 bit`，在现代计算机语境中可以按一个字节理解。[IETF Datatracker](https://datatracker.ietf.org/doc/rfc791/?utm_source=chatgpt.com)

为什么最小值恰好是 `5`，还可以继续把 IPv4 首部拆开来看。

一个不包含任何 Options 的标准 IPv4 首部，可以画成下面这样的结构

```text
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Version|  IHL  |   DSCP/ECN   |          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Identification        |Flags|      Fragment Offset    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Time to Live |    Protocol   |         Header Checksum       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Source Address                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Destination Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

这里正好是 `5` 行，每一行 `32 bit`。

因此

```text
5 × 32 bit = 160 bit
```

再除以每字节的 `8 bit`

```text
160 ÷ 8 = 20 byte
```

从这个图上看，`IHL = 5` 就变得非常直观了。所谓 `5`，其实就是这个基本首部占用了 `5` 个 `32 bit` 块。

把各字段逐个相加，同样能得到 `20 byte`。

最前面的 Version 占 `4 bit`，IHL 占 `4 bit`，两个字段加起来刚好是

```text
4 bit + 4 bit = 8 bit = 1 byte
```

随后是原始 IPv4 规范里的 Type of Service 字段。现代 IPv4 对这里的解释已经发生演化，通常会看到 DSCP 和 ECN，但从首部长度来看，它们合起来仍然占

```text
1 byte
```

Total Length 占

```text
2 byte
```

Identification 占

```text
2 byte
```

Flags 与 Fragment Offset 合起来占

```text
2 byte
```

Time To Live，也就是熟悉的 TTL，占

```text
1 byte
```

Protocol 占

```text
1 byte
```

Header Checksum 占

```text
2 byte
```

Source Address 是 IPv4 源地址，占

```text
4 byte
```

Destination Address 是 IPv4 目的地址，同样占

```text
4 byte
```

把它们相加

```text
1
+ 1
+ 2
+ 2
+ 2
+ 1
+ 1
+ 2
+ 4
+ 4
= 20 byte
```

因此从字段长度逐项累加，同样能够严格证明 IPv4 基本首部长度是 `20 byte`。

这里还有一个很有价值的理解方式。IPv4 的 `20 byte` 并不是随意规定出来的数字，它就是所有不可缺少的基本字段累加之后的结果。Version、首部长度、数据报总长度、分片信息、TTL、上层协议类型、首部校验和、源地址和目的地址，这些都是一个标准 IPv4 数据报正常工作所需要的基础信息。

只要没有 Options，这些字段刚好需要 `20 byte`。

一旦 IPv4 数据报携带 Options，首部就可能超过 `20 byte`。

IPv4 首部在基本的 `20 byte` 之后，还允许存在 Options 和 Padding。RFC 791 给出的首部图中就明确包含 Options 和 Padding。Padding 用于让首部最终停在 `32 bit` 边界上。[RFC Editor](https://www.rfc-editor.org/rfc/rfc791.html?utm_source=chatgpt.com)

因此可以把 IPv4 首部理解成

```text
IPv4 Header
=
20 byte 固定基本部分
+
Options
+
必要的 Padding
```

没有 Options 时

```text
IHL = 5
Header Length = 20 byte
```

加入 `4 byte` Options 后

```text
IHL = 6
Header Length = 24 byte
```

再增加 `4 byte`

```text
IHL = 7
Header Length = 28 byte
```

继续增加时也是按照 `4 byte` 为一个计量单位。

到 `IHL = 15` 时已经达到字段能够表达的最大值

```text
15 × 4 byte = 60 byte
```

因此 IPv4 Options 最多可以占用

```text
60 - 20 = 40 byte
```

这里还体现出了 Padding 的作用。假如某些选项内容没有自然结束在 `32 bit` 边界，协议需要通过填充让整个 IPv4 首部仍然满足 `32 bit` 对齐。RFC 791 对 Padding 的定义就是确保 Internet Header 结束在 `32 bit` 边界，并规定填充值为零。[RFC Editor](https://www.rfc-editor.org/rfc/rfc791.html?utm_source=chatgpt.com)

这也解释了为什么不能简单认为 IPv4 首部长度可以随意出现 `21 byte`、`22 byte`、`23 byte`。

由 `IHL` 的定义可知，它按照 `32 bit` 字计数，也就是按照 `4 byte` 计数，所以可以出现的首部长度是

```text
20 byte
24 byte
28 byte
32 byte
36 byte
40 byte
44 byte
48 byte
52 byte
56 byte
60 byte
```

不会正常出现

```text
21 byte
22 byte
23 byte
```

这样的 IPv4 首部长度。

理解到这一层以后，考试里一种常见变形题也就很好处理了。

如果某个 IPv4 数据报中的 `IHL` 字段为

```text
0101
```

二进制 `0101` 就是十进制 `5`。

因此首部长度不是 `5 byte`，而是

```text
5 × 4 = 20 byte
```

如果看到

```text
IHL = 0110
```

十进制就是 `6`

```text
6 × 4 = 24 byte
```

如果看到

```text
IHL = 1111
```

十进制就是 `15`

```text
15 × 4 = 60 byte
```

这种计算题经常故意利用一个心理误区，看到首部长度字段等于 `5`，就下意识认为首部长度是 `5 byte`。但 IPv4 并不是这样定义的。

协议字段真正表达的是

```text
Header Length in 32-bit words
```

所以一定要乘以 `4 byte`。

这里还可以结合 RFC 791 中一个真实的协议示例来理解。RFC 791 的 Appendix A 给出了一个最小数据承载 Internet Datagram。这个数据报明确写着

```text
Ver = 4
IHL = 5
Total Length = 21
```

RFC 随后的解释说明，该数据报使用 IPv4，Internet Header 由 `5` 个 `32 bit word` 组成，整个数据报总长度为 `21 octets`。[RFC Editor](https://www.rfc-editor.org/rfc/rfc791.html?utm_source=chatgpt.com)

因此这个真实规范示例可以直接还原成

```text
IPv4 Header = 5 × 4 = 20 byte

Total Length = 21 byte

Payload = 21 - 20 = 1 byte
```

也就是说，这是一个首部占 `20 byte`、真正数据只有 `1 byte` 的 IPv4 数据报。

这个例子很适合帮助我们理解 Total Length 和 IHL 的区别。

`IHL` 只表示 IPv4 首部长度。

Total Length 则表示整个 IPv4 数据报的长度，其中包括

```text
IPv4 Header + IPv4 Payload
```

因此

```text
Total Length
=
Header Length
+
Data Length
```

假设在抓包中看到

```text
IHL = 5
Total Length = 1500
```

对应关系就是

```text
IPv4 Header = 20 byte

IPv4 Payload = 1500 - 20 = 1480 byte
```

这里的 `1500 byte` 又很容易让人联想到 Ethernet 中常见的 MTU `1500 byte`。这些数字属于不同概念，必须分层理解。

以典型 Ethernet 环境中的 IPv4 数据报为例，Ethernet MTU 常见为

```text
1500 byte
```

这个数通常限制的是 Ethernet Payload 中所承载的 IP 数据报大小。

当一个普通 IPv4 数据报没有 Options 时，它的 IPv4 首部为

```text
20 byte
```

于是留给 IPv4 Payload 的空间就是

```text
1500 - 20 = 1480 byte
```

如果上层使用 TCP，而 TCP 也没有 Options，那么 TCP 基本首部又占

```text
20 byte
```

真正能够留给 TCP 应用数据的空间就变成

```text
1500 - 20 - 20 = 1460 byte
```

这正是网络领域经常出现 TCP MSS `1460` 的来源之一。

整个关系可以写成

```text
Ethernet MTU = 1500 byte

IPv4 Header = 20 byte

TCP Header = 20 byte

TCP Payload
= 1500 - 20 - 20
= 1460 byte
```

这样一来，`20 byte` 就不再只是孤立的考试数字，而是会直接参与实际网络传输中的 MSS 计算。

同样的逻辑放到 UDP 中也很清晰。

UDP 首部固定为

```text
8 byte
```

因此一个没有 IPv4 Options 的 IPv4 加 UDP 组合，最基本的协议开销是

```text
IPv4 Header + UDP Header
= 20 + 8
= 28 byte
```

这里便产生了另一个考试里经常出现的数字

```text
28 byte
```

`28 byte` 不是 IPv4 首部长度。

它是

```text
20 byte IPv4 基本首部
+
8 byte UDP 首部
```

如果是最普通的 TCP，没有 TCP Options，则是

```text
20 byte IPv4
+
20 byte TCP
=
40 byte
```

因此 `40 byte` 同样不是 IPv4 首部的最小长度。

它通常来自

```text
IPv4 Minimum Header
+
TCP Minimum Header
```

也就是

```text
20 + 20 = 40 byte
```

网络考试特别喜欢把 `20`、`28`、`40`、`60` 和 `64` 放在同一组选项里，因为这些数字全部与计算机网络协议有关，却分别处在不同协议层或者代表不同概念。

看到 `20`，应当联想到

```text
IPv4 最小首部
```

看到 `60`，应当联想到

```text
IPv4 最大首部
```

看到 `28`，常见来源是

```text
IPv4 最小首部 20
+
UDP 首部 8
```

看到 `40`，常见来源之一是

```text
IPv4 最小首部 20
+
TCP 最小首部 20
```

至于 `64`，它尤其容易干扰 IPv4 首部长度题，因为经典 Ethernet 的最小帧长度正好与 `64 byte` 有关。

Ethernet 最小帧长通常说的是从 Destination MAC 开始计算到 FCS 结束的

```text
64 byte
```

这与 IPv4 首部完全是两个不同层次的概念。

Ethernet 属于数据链路层。

IPv4 属于网络层。

因此下面两个数字完全可以同时成立

```text
Ethernet 最小帧长 = 64 byte

IPv4 最小首部长度 = 20 byte
```

不能因为记得 Ethernet 有一个著名的 `64 byte`，就把它套到 IPv4 首部上。

从 OSI 或 TCP/IP 分层封装的角度观察，这种区别更加明显。

一段 TCP 应用数据经过协议栈时，大致会形成

```text
Application Data
↓
TCP Header + Application Data
↓
IPv4 Header + TCP Header + Application Data
↓
Ethernet Header + IPv4 Header + TCP Header + Application Data + FCS
```

IPv4 的那 `20 byte` 只属于其中的一层。

因此计算协议开销时必须明确正在问哪一层。

如果题目写

```text
IPv4 协议首部最小长度
```

答案就是

```text
20 byte
```

如果题目写

```text
TCP 首部最小长度
```

答案同样是

```text
20 byte
```

两个数字恰好相同，但来源完全不同。

IPv4 通过 `IHL` 字段表示首部长度。

TCP 则通过自己的 Data Offset 字段表示 TCP 首部长度。

有趣的是，两者都以 `32 bit word` 为单位，并且基本首部都恰好是 `5` 个 `32 bit word`，所以最小值都为

```text
5 × 4 = 20 byte
```

正因为 IPv4 和 TCP 最小首部都为 `20 byte`，这两个概念在网络考试中尤其容易互相干扰。

从实际抓包角度看，这个知识点也非常直观。

在 Wireshark 中观察一个普通、没有 IPv4 Options 的 IPv4 数据包时，Internet Protocol Version 4 部分通常能够看到类似

```text
Version = 4
Header Length = 20 bytes
```

从原始数据的第一个字节甚至可以直接读出来。

IPv4 首部的第一个字节由两个 `4 bit` 字段组成

```text
高 4 bit = Version

低 4 bit = IHL
```

一个最常见的普通 IPv4 数据包，第一个字节往往是十六进制

```text
0x45
```

把 `0x45` 转换成二进制

```text
0100 0101
```

拆成两个半字节

```text
0100    0101
 4       5
```

于是可以直接读出

```text
Version = 4

IHL = 5
```

再计算

```text
5 × 4 byte = 20 byte
```

所以网络抓包里极其常见的

```text
45
```

这个十六进制字节其实很有代表性。

其中前面的 `4` 表示 IPv4。

后面的 `5` 表示首部为 `5` 个 `32 bit word`。

因此看到

```text
0x45
```

脑中完全可以直接建立下面这条联系

```text
IPv4
+
IHL 5
+
20 byte Header
```

如果某个 IPv4 包携带 Options，第一个字节就可能不再是 `0x45`。

假设它是

```text
0x46
```

二进制就是

```text
0100 0110
```

Version 仍然是 `4`，说明还是 IPv4。

IHL 变成 `6`

```text
6 × 4 = 24 byte
```

于是该包包含的额外 Options 与 Padding 总长度就是

```text
24 - 20 = 4 byte
```

看到

```text
0x47
```

同理可以得到

```text
IHL = 7

Header Length = 28 byte

Options + Padding = 8 byte
```

这类分析已经从考试题直接延伸到了 Wireshark、tcpdump 和原始 Packet Hex Dump 的实际解析工作。

如果正在开发抓包程序、DPI、软件路由器、防火墙或者协议分析器，同样不能把 IPv4 Payload 的起始位置硬编码成固定偏移 `20`。

多数普通 IPv4 包确实只有 `20 byte` 首部，但协议允许 Options 存在。

正确的解析逻辑应该读取 `IHL`

```text
ihl = first_byte & 0x0F
```

再计算

```text
header_length = ihl * 4
```

Payload 起始位置应该按照这个动态计算的首部长度确定。

也就是

```text
payload_offset = ihl * 4
```

若程序永远写死

```text
payload_offset = 20
```

它只能正确处理 `IHL = 5` 的 IPv4 数据包。

一旦遇到带 Options 的报文，应用层或传输层数据的位置就会被解析错。

这也是为什么从工程视角看，掌握 `IHL` 比单纯背诵 `20 byte` 更重要。

再回到考试题，最稳妥的记忆链并不是死记一句 IPv4 首部最小长度是 `20 byte`，而是记住四个数字之间的关系

```text
IHL 占 4 bit

IHL 最小值 = 5

IHL 单位 = 32 bit = 4 byte

5 × 4 = 20 byte
```

最大长度也顺手得到了

```text
IHL 最大值 = 15

15 × 4 = 60 byte
```

所以完整的关系只有两行

```text
IPv4 Header Minimum
= 5 × 4
= 20 byte

IPv4 Header Maximum
= 15 × 4
= 60 byte
```

再进一步，可以把 `IHL` 理解成数据起点定位器。

RFC 791 在定义 `IHL` 时明确说明，它表示 Internet Header 由多少个 `32 bit word` 组成，因此也指明数据部分从哪里开始。[IETF Datatracker](https://datatracker.ietf.org/doc/html/rfc791?utm_source=chatgpt.com)

如果

```text
IHL = 5
```

数据从 IPv4 数据报偏移

```text
20 byte
```

的位置开始。

如果

```text
IHL = 6
```

数据从偏移

```text
24 byte
```

开始。

如果

```text
IHL = 15
```

数据从偏移

```text
60 byte
```

开始。

因此 IHL 并不只是一个供人阅读的长度描述，它对于接收方解析协议结构具有直接作用。接收方读取 IPv4 首部的第一个字节之后，就可以知道 IPv4 Header 在哪里结束，以及下一层数据从哪里开始。

这道题还有一个容易忽略的细节，题目问的是 IPv4 协议首部最小长度，而不是 IPv4 数据报最小长度。

首部和整个数据报一定要分开。

IPv4 数据报可以表示成

```text
IPv4 Datagram
=
IPv4 Header
+
Data
```

题目只问 Header，所以答案直接锁定

```text
20 byte
```

不能拿 Total Length 的范围来回答。

IPv4 的 Total Length 字段本身占 `16 bit`，所以传统 IPv4 Total Length 最大可以表示

```text
65535 byte
```

而这个 `65535 byte` 是整个 IPv4 数据报长度，不是首部长度。

于是三个不同概念需要彻底分开

```text
IPv4 最小首部 = 20 byte

IPv4 最大首部 = 60 byte

经典 IPv4 Total Length 最大值 = 65535 byte
```

RFC 791 也明确说明，Total Length 包含 Internet Header 和 Data，并允许数据报长度达到 `65535 octets`。[IETF Datatracker](https://datatracker.ietf.org/doc/rfc791/?utm_source=chatgpt.com)

从二进制编码角度再看一遍，会发现这些数字彼此之间有非常漂亮的对应关系。

`IHL` 是 `4 bit`

```text
最大二进制值 = 1111
```

转换成十进制

```text
15
```

每一个单位对应

```text
4 byte
```

因此

```text
15 × 4 = 60 byte
```

最低合法值规定为

```text
0101
```

也就是

```text
5
```

因此

```text
5 × 4 = 20 byte
```

整个 IPv4 首部长度范围就可以表示为

```text
20 ≤ Header Length ≤ 60
```

单位是字节，并且只能按照

```text
4 byte
```

递增。

也就是说，合法长度序列是

```text
20
24
28
32
36
40
44
48
52
56
60
```

看到这里，这道题其实已经不需要任何机械记忆了。

IPv4 首部的前 `20 byte` 是必须存在的基本首部，Options 是可选部分。没有 Options 时 `IHL = 5`，于是首部长度最小。由于一个 IHL 单位是 `32 bit`，也就是 `4 byte`，所以

```text
5 × 4 = 20 byte
```

这就是答案。

真正参加考试时，可以在草稿上只写一个极短的计算式

```text
IHLmin = 5
5 × 32 bit = 160 bit
160 ÷ 8 = 20 byte
```

也可以进一步压缩成

```text
5 × 4 = 20 B
```

只要看到 IPv4 首部最小长度，就立即想到

```text
IHL = 5
```

只要想到 `IHL`，就想到单位不是 byte，而是

```text
32 bit word
```

只要想到 `32 bit word`，就得到

```text
4 byte
```

整个推导链最终落在

```text
5 × 4 = 20 byte
```

所以这道题最终填写的数字是

```text
20
```

IPv4 首部最小长度为 **20 字节**。如果题目继续追问最大首部长度，对应答案就是 **60 字节**。这两个数字都来自同一个 `4 bit IHL` 字段，最小合法值 `5` 对应 `20 byte`，最大值 `15` 对应 `60 byte`。掌握这一条关系，比孤立记忆两个数字可靠得多。

参考资料

RFC 791，Internet Protocol，RFC Editor。[RFC Editor](https://www.rfc-editor.org/rfc/rfc791.html?utm_source=chatgpt.com)

IETF Datatracker，RFC 791 Internet Protocol。[IETF Datatracker](https://datatracker.ietf.org/doc/html/rfc791?utm_source=chatgpt.com)

如果只是应付一道选择题，记住 20 就可以了。但这类题真正容易出错的地方，并不在于数字本身，而在于 IPv4 首部里有一个很特殊的字段 IHL。这个字段保存的并不是字节数，而是以 32 bit 字为单位的首部长度。只要把这一层关系真正理解清楚，IPv4 首部的最小长度、最大长度，以及 20、40、60、64 这些经常混在一起的数字，就很难再记错。

从 IHL = 5 到 20 字节，彻底理解 IPv4 协议首部最小长度

紫薇堂堂主

网络与通信

开发工具

IPv4首部最小长度为20字节，关键在于IHL字段以32bit字为单位，最小值5对应5×4=20字节。该字段支持范围5至15，故最大首部为60字节。理解IHL与字节换算关系，可避免混淆20、40、60等协议层相关数字，并正确解析数据包偏移位置。

代码解释

路由器

防火墙

路由

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从 IHL = 5 到 20 字节，彻底理解 IPv4 协议首部最小长度-腾讯云开发者社区-腾讯云

从 IHL = 5 到 20 字节，彻底理解 IPv4 协议首部最小长度

从 IHL = 5 到 20 字节，彻底理解 IPv4 协议首部最小长度

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐