注：本文为 “以太网帧、IP数据报”图解相关合辑。
图片清晰度受引文原图所限。
略作重排，未整理去重，部分段落有改增。
如有内容异常，请看原文。
以太网帧、IP 数据报的图解格式（包含相关例题讲解）
jueyuanfengsheng 2023-08-07 11:49
一、基础知识
UDP 段、IP 数据包，以太网帧图示
通信过程中，每层协议都要加上一个数据首部（header），称为封装（Encapsulation），如下图所示。
不同的协议层对数据包有不同的称谓：在传输层叫做段（segment），在网络层叫做数据包（datagram），在链路层叫做帧（frame）。数据封装成帧后发到传输介质上，到达目的主机后每层协议再剥掉相应的首部，最后将应用层数据交给应用程序处理。
第三行是以太网帧数据包的基本格式。
测试环境
| 机器名 | mac | ip | port |
|---|---|---|---|
| tcp_server | 00:0c:29:8b:37:da | 10.1.2.7 | 9502 |
| tcp_client | 00:50:56:c0:00:08 | 10.1.2.1 | 12345 |
抓包：客户端向服务端发送 'hello world’
原始数据帧
00 0c 29 8b 37 da 00 50 56 c0 00 08 08 00# Ethernet_II 格式数据帧首部45 00 00 33 28 5b 40 00 80 06 ba 80 0a 01 02 01 0a 01 02 07# ip 协议头30 39 25 1e 84 a4 e6 82 cf f2 ea 28 50 18 10 0a 7b 45 00 00# tcp 协议头68 65 6c 6c 6f 20 77 6f 72 6c 64# data
以太网数据帧构成
Ethernet_II 格式、数据帧首部（链路层）
总长度 14 B
以太网帧图示
其中，以太网首部占用 14 字节、FCS（Frame Check Sequence，帧校验码）长 4 个字节，用于检验数据在传输过程中是否出现错误，为 CRC32 校验码。
以太网首部占用 14 字节，首位为目的地址（6 字节），其次是源地址（6 字节），最后是类型（2 字节）。以太网帧除去首部 14 字节和尾部 FCS 4 字节（共 18 字节），剩余中间部分即为 IP 数据报。
以太网帧首部字段说明
| 字段名称 | 长度（byte） | 含义 |
|---|---|---|
| D.MAC | 6 | 接收方 MAC 地址，网络包接收方的 MAC 地址，在局域网中通过该地址传输网络包 |
| S.MAC | 6 | 网络包发送方 MAC 地址，接收方通过它判断包的发送来源 |
| Type | 2 | 使用的协议类型（TCP 通信中 IP 协议与 ARP 协议较常见） - 0000-05DC：IEEE 802.3 - 0800：IP 协议 - 0806：ARP 协议 - 86DD：IPv6 |
以太网帧格式（按承载数据类型分类）
-
承载 IP 数据报的以太网帧
目的 MAC 地址（6 B） 源 MAC 地址（6 B） 类型 0x0800 IP 数据包 CRC -
承载 ARP 请求/应答的以太网帧
目的 MAC 地址（6 B） 源 MAC 地址（6 B） 类型 0x0806 ARP 请求应答（28 B） CRC -
承载 RARP 请求/应答的以太网帧
目的 MAC 地址（6 B） 源 MAC 地址（6 B） 类型 0x0835 RARP 请求应答 CRC
补充协议说明：
- ICMP 协议：差错控制协议（网络层辅助协议）
- ARP 协议：地址解析协议（实现 IP 地址到 MAC 地址的映射）
实例（Ethernet_II 格式数据帧首部 14 bytes）
00 0c 29 8b 37 da# 目标 MAC 地址 00:0c:29:8b:37:da00 50 56 c0 00 08# 源 MAC 地址 00:50:56:c0:00:0808 00# 协议类型：IP 协议
IP 协议数据包首部（网络层）
总长度 20 B+
IP 数据报由首部（报头） 和数据两部分组成。首部前 20 字节为固定长度（如图前五行为 IP 首部固定部分），是所有 IP 数据报必须包含的；固定部分后为可选字段，长度可变。
实例（ip 协议头 20 字节）
4# 协议版本：IPv4（4 位，对应十六进制高位 4）5# IP 协议头长度：5 × 4 = 20 字节（4 位，单位为 4 字节）00# 服务类型：000-0-0-0-0-0（8 位，优先级+延迟/吞吐量/可靠性/成本+保留位）00 33# IP 包总长度：十六进制 0033 转换为十进制为 51 字节（16 位，含首部+数据）28 5b# ID 号（16 位，用于分片重组）40 00# 标志与分片偏移量：二进制 0100 0000 0000 0000，DF 位为 1（不允许分包），偏移量为 0（13 位偏移量）80# 生存时间（TTL）：十进制 128（8 位，每经过一个路由器减 1，为 0 则丢弃）06# 协议号：TCP 协议（8 位，1=ICMP、6=TCP、17=UDP）ba 80# 头部校验和（16 位，仅校验 IP 首部）0a 01 02 01# 发送方 IP：10.1.2.1（32 位，点分十进制转换：0a=10、01=1、02=2、01=1）0a 01 02 07# 接收方 IP：10.1.2.7（32 位，同理：0a=10、01=1、02=2、07=7）
IP 协议头头部校验和计算方法
- 将头部校验和字段置 0；
- 对 IP 头部中每 16 bit 进行二进制求和（无进位加法）；
- 若和的高 16 bit 不为 0，将高 16 bit 与低 16 bit 反复相加，直到高 16 bit 为 0，得到 16 bit 结果；
- 将该 16 bit 结果取反，存入校验和字段。
TCP 协议头（传输层）
图示
总长度 20 B+
实例（tcp 协议头 20 字节）
30 39# 源端口：十进制 12345（16 位，十六进制 3039 转换：3×16³+0×16²+3×16+9=12345）25 1e# 目的端口：十进制 9502（16 位，251e 转换：2×16³+5×16²+1×16+14=9502）84 a4 e6 82# 序列号（32 位，用于标记发送数据的字节位置）cf f2 ea 28# 确认序列号（32 位，期待接收的下一字节位置，仅 ACK=1 时有效）5# 首部长度：5 × 32/8 = 20 bytes（4 位，单位为 32 位字）0 1 8# 保留位（6 位，000000）+ 控制位（6 位，011000）：ACK=1（确认）、PSH=1（推送）10 0a# 窗口大小：十进制 4106（16 位，接收方告知发送方可连续发送的字节数）7b 45# 校验和（16 位，校验 TCP 首部+数据+伪首部）00 00# 紧急指针：URG=0 时无效（16 位，仅 URG=1 时指示紧急数据位置）
传输的数据
- 十六进制：
68 65 6c 6c 6f 20 77 6f 72 6c 64 - ASCII 码：
hello world
附录：TCP 重传机制
每个数据包携带序列号，接收方通过 ACK 确认已接收的数据：
- 若未收到下一个数据包（如收到 4 号包，未收到 5 号包），ACK 编号保持为“期待 5 号包”；
- 若后续收到 5 号包，ACK 编号更新为“期待 6 号包”；
- 若始终未收到 5 号包（但收到 6/7 号包），ACK 编号仍为“期待 5 号包”，导致重复 ACK；
- 发送方检测到3 个连续重复 ACK 或 超时未收到 ACK，判定 5 号包丢失，触发重传，确保数据不丢失。
UDP 协议
UDP 协议为无连接、不可靠传输协议，首部仅 8 字节（源端口 2 字节、目的端口 2 字节、长度 2 字节、校验和 2 字节），无序列号、确认号等字段，适用于对实时性要求高（如语音、视频）但可容忍少量丢包的场景。
例题讲解
填空题（20 分）
现获取 3 个以太网帧 Frame₁、Frame₂、Frame₃（已通过错误检测），十六进制内容如下：
Frame#1（Server → Client）
00 80 c8 5a e3 88 00 60 2f 87 01 03 08 00 45 08
00 2c d1 22 40 00 3f 06 8a 27 8c 80 63 05 8c 80
64 74 00 14 02 66 aa a1 20 8d 00 00 00 00 60 02
40 00 5e 3c 00 00 02 04 05 b4
Frame#2（Client → Server）
00 60 2f 87 01 03 00 80 c8 5a e3 88 08 00 45 00
00 2c 81 0e 40 00 80 06 99 43 8c 80 64 74 8c 80
63 05 02 66 00 14 12 38 bb 3e aa a1 20 8e 60 12
22 38 c0 7c 00 00 02 04 05 b4
Frame#3（Server → Client）
00 80 c8 5a e3 88 00 60 2f 87 01 03 08 00 45 08
00 28 d1 23 40 00 3f 06 8a 2a 8c 80 63 05 8c 80
64 74 00 14 02 66 aa a1 19 8e 12 38 bb 3f 50 10
44 70 b6 01 00 00
3 个数据包用于建立 TCP 连接，根据协议封装关系及各层格式，回答以下问题：
(1) Client 端和 Server 端的以太网网卡 48 位地址是〔填空 1〕和〔填空 2〕
(2) Frame#1 帧中封装的 IP 分组的总长度〔填空 3〕、首部长度〔填空 4〕、IP 数据长度〔填空 5〕
(3) Client 端和 Server 端的 32 位 IP 地址（点分十进制）〔填空 6〕和〔填空 7〕
(4) Frame#1 帧中封装的 IP 分组的生存时间值是〔填空 8〕、协议字段值是〔填空 9〕
(5) IP 分组中封装的是〔填空 10〕的数据
答案
- 填空 1：
00-80-c8-5a-e3-88 - 填空 2：
00-60-2f-87-01-03 - 填空 3：
44字节 - 填空 4：
20字节 - 填空 5：
24字节 - 填空 6：
140.128.100.116 - 填空 7：
140.128.99.5 - 填空 8：
63 - 填空 9：
6 - 填空 10：
TCP
解析（文字版）
(1) Client/Server 端 MAC 地址（以太网帧首部字段）
以太网帧首部前 12 字节为 MAC 地址（目的 6 字节 + 源 6 字节）：
- Frame#1 方向为“Server → Client”，因此目的 MAC 为 Client 地址（前 6 字节：
00 80 c8 5a e3 88），格式化为00-80-c8-5a-e3-88（填空 1）； - 源 MAC 为 Server 地址（中间 6 字节：
00 60 2f 87 01 03），格式化为00-60-2f-87-01-03（填空 2）。
(2) Frame#1 中 IP 分组的长度计算
- Frame#1 总长度：统计十六进制字节数，共 58 字节（题干说明“已通过错误检测”，故不含 FCS 4 字节）；
- IP 分组总长度 = 以太网帧总长度 - 以太网首部长度 = 58 B - 14 B = 44 B（填空 3）；
- IP 首部长度：IPv4 首部固定 20 B（无可选字段时），故为 20 B（填空 4）；
- IP 数据长度 = IP 分组总长度 - IP 首部长度 = 44 B - 20 B = 24 B（填空 5）。
(3) Client/Server 端 IP 地址（IP 首部字段）
IP 首部后 8 字节为 IP 地址（源 4 字节 + 目的 4 字节）：
- Frame#1 中 IP 首部起始于第 15 字节（以太网首部 14 字节后），IP 首部第 13-16 字节为源 IP（Server IP）：
8c 80 63 05； - 十六进制转十进制：
8c=140、80=128、63=99、05=5→ 点分十进制140.128.99.5（填空 7）； - IP 首部第 17-20 字节为目的 IP（Client IP）：
8c 80 64 74； - 十六进制转十进制：
8c=140、80=128、64=100、74=116→ 点分十进制140.128.100.116（填空 6）。
(4) IP 分组的 TTL 与协议字段
- TTL（生存时间）：IP 首部第 9 字节（以太网首部 14 字节 + IP 首部前 8 字节 = 第 23 字节），Frame#1 中该字节为
3f； - 十六进制
3f转十进制：3×16 + 15 = 63（填空 8）； - 协议字段：IP 首部第 10 字节，Frame#1 中该字节为
06； - 协议号定义：
6=TCP（填空 9）。
(5) IP 分组封装的数据类型
题干明确“3 个数据包用于建立 TCP 连接”，且 Frame#1 中 TCP 首部字段（如端口、序列号）完整，故 IP 分组封装的是 TCP 数据（填空 10）。
解析（图版）
(1) MAC 地址定位
如图红色部分为以太网帧首部，前 6 字节 00 80 c8 5a e3 88 为 Client（目的）MAC，中间 6 字节 00 60 2f 87 01 03 为 Server（源）MAC。
(2) IP 分组长度验证
Frame#1 总长度 58 字节（无 FCS），IP 分组长度 = 58 B - 14 B（以太网首部）= 44 B；
IP 首部固定 20 B，故 IP 数据长度 = 44 B - 20 B = 24 B。
(3) IP 地址转换
如图蓝色部分为 IP 首部，
第 13-16 字节 8c 80 63 05 为 Server IP（140.128.99.5），
第 17-20 字节 8c 80 64 74 为 Client IP（140.128.100.116）。
(4) TTL 与协议字段定位
如图绿色部分 3f 为 TTL（十进制 63），黄色部分 06 为协议号（TCP）。
(5) 封装数据类型
因题干说明“建立 TCP 连接”，且 IP 分组后 24 字节包含 TCP 首部（20 B），故封装 TCP 数据。
以太网数据帧详细解析：逐字节分析
Qazink 于 2020-08-25 21:18:49 发布
详细解析以太网通信数据帧
测试环境
| 机器名 | mac | ip | port |
|---|---|---|---|
| tcp_server | 00:0c:29:8b:37:da | 10.1.2.7 | 9502 |
| tcp_client | 00:50:56:c0:00:08 | 10.1.2.1 | 12345 |
抓包：客户端向服务端发送 'hello world’
原始数据帧
00 0c 29 8b 37 da 00 50 56 c0 00 08 08 00# Ethernet_II 格式数据帧首部45 00 00 33 28 5b 40 00 80 06 ba 80 0a 01 02 01 0a 01 02 07# ip 协议头30 39 25 1e 84 a4 e6 82 cf f2 ea 28 50 18 10 0a 7b 45 00 00# tcp 协议头68 65 6c 6c 6f 20 77 6f 72 6c 64# data
以太网数据帧构成
Ethernet_II 格式数据帧首部（链路层）
总长度 14 B
| 字段名称 | 长度 (byte) | 含义 |
|---|---|---|
| D.MAC | 6 | 接收方 MAC 地址，网络包接收方的 MAC 地址，在局域网中通过该地址传输网络包 |
| S.MAC | 6 | 网络包发送方 MAC 地址，接收方通过它判断包的发送来源 |
| Type | 2 | 使用的协议类型（TCP 通信中 IP 协议与 ARP 协议较常见） - 0000-05DC：IEEE 802.3 - 0800：IP 协议 - 0806：ARP 协议 - 86DD：IPv6 |
实例（Ethernet_II 格式数据帧首部 14 bytes）
00 0c 29 8b 37 da# 目标 MAC 地址 00:0c:29:8b:37:da00 50 56 c0 00 08# 源 MAC 地址 00:50:56:c0:00:0808 00# 协议类型：IP 协议
IP 协议数据包首部（网络层）
总长度 20 B+
| 字段名称 | 长度 (bit) | 含义 |
|---|---|---|
| 版本号 (Version) | 4 | 协议版本：0100（IPv4）、0110（IPv6） |
| 头部长度（IHL） | 4 | 描述 IP 包头长度（含可选字段），单位为 4 字节； 取值范围 0101（5）~1111（15），对应包头长度 20~60 字节 |
| 服务类型（ToS） | 8 | 字段定义：PPP DTRC0（3 位优先级+4 位服务属性+1 位保留）- PPP（优先级）：000（常规）~111（网络控制），数值越大优先级越高； - D（延迟）：0（常规）、1（低延迟）； - T（吞吐量）：0（常规）、1（高吞吐量）； - R（可靠性）：0（常规）、1（高可靠性）； - C（成本）：0（常规）、1（低成本）； - 0（保留位）：固定为 0 |
| 总长度 | 16 | IP 包总长度（首部+数据），单位为字节； 最大值 65535 字节（2¹⁶-1） |
| ID 号 | 16 | 用于分片重组，同一分片的包 ID 相同 |
| 标志（Flags） | 3 | 位 0（保留）：0； 位 1（DF）：1=不允许分片、0=允许分片； 位 2（MF）：1=非最后分片、0=最后分片 |
| 分片偏移量 | 13 | 表示分片在原包中的位置，单位为 8 字节； 仅 MF=1 时有效，用于接收方重组 |
| 生存时间（TTL） | 8 | 防止包在网络中无限循环； 每经过一个路由器减 1，为 0 则丢弃，默认值 32/64/128 |
| 协议号 | 8 | 标识上层协议：1=ICMP、2=IGMP、6=TCP、17=UDP、88=IGRP、89=OSPF |
| 头部校验和 | 16 | 仅校验 IP 首部（不含数据），路由器转发时需重新计算 |
| 发送方 IP 地址 | 32 | 源 IP 地址，除非经过 NAT，否则全程不变 |
| 接收方 IP 地址 | 32 | 目的 IP 地址，除非经过 NAT，否则全程不变 |
| 可选字段 | 不定 | 用于测试/扩展（如记录路由、时间戳），长度为 4 字节的整数倍 |
实例（ip 协议头 20 字节）
4# 协议版本：IPv4（4 位，对应十六进制高位 4）5# IP 协议头长度：5 × 4 = 20 字节（无可选字段）00# 服务类型：000（优先级）+0000（服务属性）+0（保留）00 33# IP 包总长度：十六进制 0033 → 十进制 51 字节28 5b# ID 号：十六进制 285b → 十进制 1033140 00# 标志与偏移：二进制 0100 0000 0000 0000 → DF=1（不允许分片）、偏移=080# 生存时间：十进制 12806# 协议号：TCP 协议ba 80# 头部校验和0a 01 02 01# 发送方 IP：10.1.2.1（0a=10、01=1、02=2、01=1）0a 01 02 07# 接收方 IP：10.1.2.7（0a=10、01=1、02=2、07=7）
IP 协议头头部校验和计算方法
- 将头部校验和字段置 0；
- 对 IP 头部中每 16 bit 进行二进制求和（无进位加法）；
- 若和的高 16 bit 不为 0，将高 16 bit 与低 16 bit 反复相加，直到高 16 bit 为 0，得到 16 bit 结果；
- 将该 16 bit 结果取反，存入校验和字段。
TCP 协议头（传输层）
图示
总长度 20 B+
| 字段名 | 长度 (bit) | 含义 |
|---|---|---|
| 源端口号 | 16 | 发送方应用程序的端口号（0~1023 为知名端口，1024~49151 为注册端口） |
| 目的端口号 | 16 | 接收方应用程序的端口号，与源端口配合标识端到端连接 |
| 序列号 seq | 32 | 标记发送数据的字节位置（如发送 100 字节，seq=1000，则下一个 seq=1100） |
| 确认序列号 ack | 32 | 期待接收的下一字节位置，仅 ACK=1 时有效； 如 ack=200，表示已接收前 199 字节 |
| 首部长度 (数据偏移量) | 4 | 表示 TCP 首部长度（含选项字段），单位为 32 位字； 取值范围 0101（5）~1111（15），对应首部长度 20~60 字节 |
| 保留 | 6 | 预留字段，固定为 000000 |
| 控制位 | 6 | 6 个标志位，分别为： - URG：1=紧急指针有效； - ACK：1=确认号有效（连接建立后默认 1）； - PSH：1=推送数据（接收方立即交给应用层）； - RST：1=重置连接（异常中断）； - SYN：1=同步序列号（建立连接时使用）； - FIN：1=关闭连接（无数据发送） |
| 窗口 | 16 | 接收方的接收窗口大小（单位：字节），用于流量控制； 发送方可连续发送不超过窗口大小的数据 |
| 校验和 | 16 | 校验范围：TCP 首部+数据+伪首部（含 IP 源/目的地址、协议号、TCP 长度） |
| 紧急指针 | 16 | 仅 URG=1 时有效，指示紧急数据在 TCP 段中的结束位置（相对于 seq 的偏移） |
| 选项和填充 | 不定 | 常见选项：MSS（最大段大小，连接建立时协商）、窗口扩大因子等； 填充位用于确保 TCP 首部为 32 位字的整数倍 |
| 数据 | 可选 | 上层应用数据，长度 = TCP 段总长度 - TCP 首部长度 |
实例（tcp 协议头 20 字节）
30 39# 源端口：十六进制 3039 → 十进制 1234525 1e# 目的端口：十六进制 251e → 十进制 950284 a4 e6 82# 序列号：十六进制 84a4e682 → 十进制 2227545730cf f2 ea 28# 确认序列号：十六进制 cff2ea28 → 十进制 34950169925# 首部长度：5 × 32/8 = 20 bytes（无选项字段）0 1 8# 保留位（000000）+ 控制位（011000）→ ACK=1、PSH=110 0a# 窗口大小：十六进制 100a → 十进制 4106 字节7b 45# 校验和：十六进制 7b4500 00# 紧急指针：URG=0，无效
传输的数据
- 十六进制：
68 65 6c 6c 6f 20 77 6f 72 6c 64 - ASCII 码：
hello world
附录：TCP 重传机制
每个数据包携带序列号，接收方通过 ACK 确认已接收的数据：
- 若未收到下一个数据包（如收到 4 号包，未收到 5 号包），ACK 编号保持为“期待 5 号包”；
- 若后续收到 5 号包，ACK 编号更新为“期待 6 号包”；
- 若始终未收到 5 号包（但收到 6/7 号包），ACK 编号仍为“期待 5 号包”，导致重复 ACK；
- 发送方检测到3 个连续重复 ACK 或 超时未收到 ACK，判定 5 号包丢失，触发重传，确保数据不丢失。
UDP 协议
UDP 头部中的控制信息 g
| UDP 头部（8 字节） | 字段名称 | 长度（比特） | 含义 |
|---|---|---|---|
| 发送方端口号 | 16 | 网络包发送方的端口号 | |
| 接收方端口号 | 16 | 网络包接收方的端口号 | |
| 数据长度 | 16 | UDP 头部后面数据的长度 | |
| 校验和 | 16 | 用于校验错误 |
UDP 协议为无连接、不可靠传输协议，首部仅 8 字节（源端口 2 字节、目的端口 2 字节、长度 2 字节、校验和 2 字节），无序列号、确认号等字段，适用于对实时性要求高（如语音、视频）但可容忍少量丢包的场景。
IPv4 数据报中的 DS、ECN 字段
原创 菜籽爱编程 2022-11-25 11:30:33
在讲解 DS 字段和 ECN 字段前，首先回顾原始的 服务类型（ToS）字段 [RFC0791]，其结构如下图所示：
服务类型字段用于表示数据报所需的服务质量参数，这些参数在数据报通过网络时，指导路由器选择实际的转发策略。部分网络支持服务优先级，高优先级流量会被优先处理，关键是在低延迟、高可靠性、高吞吐量三者间做权衡。
一、原始 ToS 字段结构（RFC0791）
1. 优先级（Precedence）子字段（3 位）
用于表示分组的优先级，取值范围 000~111，数值越大优先级越高，具体定义如下表：
| 优先级子字段值 | 优先级名称 | 说明 |
|---|---|---|
| 000 | 常规 (Routine) | 普通数据（如网页浏览、文件下载） |
| 001 | 优先 (Priority) | 优先处理的数据（如重要业务数据） |
| 010 | 立即 (Immediate) | 需立即转发的数据 |
| 011 | 瞬间 (Flash) | 紧急数据（如实时指令） |
| 100 | 瞬间覆盖 (Flash Override) | 优先级高于“瞬间”，如关键控制指令 |
| 101 | 严重 (CRITIC/ECP) | 紧急/加密数据（如安全告警） |
| 110 | 网间控制 (Internetwork Control) | 网络间控制数据（如路由协议报文） |
| 111 | 网络控制 (Network Control) | 最高优先级，网络自身控制数据（如设备配置指令） |
2. D、T、R 子字段（各 1 位）
分别对应 延迟（Delay）、吞吐量（Throughput）、可靠性（Reliability），值为 1 时表示对应属性优化，具体定义如下：
| 子字段 | 值为 0 时 | 值为 1 时 | 应用场景举例 |
|---|---|---|---|
| D | 正常延迟 | 低延迟 | 语音通话、视频会议 |
| T | 正常吞吐量 | 高吞吐量 | 大文件传输（如 FTP） |
| R | 正常可靠性 | 高可靠性 | 数据库同步、金融交易 |
3. 保留位（2 位）
固定为 00，预留用于未来扩展。
二、DS 与 ECN 字段（RFC2474、RFC3168、RFC3260）
随着网络对服务质量（QoS）需求的提升，原始 8 位 ToS 字段被重新划分为：
- 6 位区分服务（Differentiated Services, DS）字段：用于标记数据报的服务类别；
- 2 位显式拥塞通知（Explicit Congestion Notification, ECN）字段：用于路由器通知拥塞状态。
其结构如下图所示：
1. 区分服务（DS）字段
作用
通过 区分服务代码点（DSCP） 标记数据报，指导路由器应用不同的 每跳行为（Per-Hop Behavior, PHB）（如队列调度、带宽分配），实现差异化服务。
DSCP 编码规则
DS 字段的 6 位为 DSCP，默认值为 000000（尽力而为服务）。根据编码末尾两位，DSCP 分为 3 个“池”（Pool），用于不同用途：
| 池 (Pool) | 代码点前缀 (Codepoint space) | 分配策略 (Assignment Policy) | 说明 |
|---|---|---|---|
| 1 | xxxxx0 | 标准用途 (Standards Action) | 由 IETF 标准化，全网统一使用（如 CS、AF、EF 系列） |
| 2 | xxxx11 | 实验/本地用途 (EXP/LU) | 仅用于实验或本地网络，不对外网传输 |
| 3 | xxxx01 | 实验/本地用途 (*) | 暂用于实验/本地，未来可能标准化 |
常见 DSCP 值及含义
DSCP 设计兼容原始 ToS 优先级，前 3 位对应“类别选择器（CS）”，后 2 位对应“丢弃概率”，常见值如下表：
| 名称 | DSCP 值（二进制） | 十进制 | 参考文献 | 描述 | 应用场景 |
|---|---|---|---|---|---|
| CS0 | 000000 | 0 | [RFC2474] | 类别选择（尽力而为/常规） | 普通网页、文件下载 |
| CS1 | 001000 | 8 | [RFC2474] | 类别选择（优先） | 低优先级业务数据 |
| CS2 | 010000 | 16 | [RFC2474] | 类别选择（立即） | 中等优先级数据 |
| CS3 | 011000 | 24 | [RFC2474] | 类别选择（瞬间） | 较高优先级数据 |
| CS4 | 100000 | 32 | [RFC2474] | 类别选择（瞬间覆盖） | 高优先级控制数据 |
| CS5 | 101000 | 40 | [RFC2474] | 类别选择（CRITIC/ECP） | 紧急/加密数据 |
| CS6 | 110000 | 48 | [RFC2474] | 类别选择（网间控制） | 路由协议报文 |
| CS7 | 111000 | 56 | [RFC2474] | 类别选择（网络控制） | 设备配置指令 |
| AF11 | 001010 | 10 | [RFC2597] | 保证转发（1 类，低丢弃） | 低丢包需求的普通数据 |
| AF12 | 001100 | 12 | [RFC2597] | 保证转发（1 类，中丢弃） | 中等丢包需求的普通数据 |
| AF13 | 001110 | 14 | [RFC2597] | 保证转发（1 类，高丢弃） | 高丢包容忍的普通数据 |
| AF21 | 010010 | 18 | [RFC2597] | 保证转发（2 类，低丢弃） | 低丢包需求的业务数据 |
| AF22 | 010100 | 20 | [RFC2597] | 保证转发（2 类，中丢弃） | 中等丢包需求的业务数据 |
| AF23 | 010110 | 22 | [RFC2597] | 保证转发（2 类，高丢弃） | 高丢包容忍的业务数据 |
| AF31 | 011010 | 26 | [RFC2597] | 保证转发（3 类，低丢弃） | 低丢包需求的重要数据 |
| AF32 | 011100 | 28 | [RFC2597] | 保证转发（3 类，中丢弃） | 中等丢包需求的重要数据 |
| AF33 | 011110 | 30 | [RFC2597] | 保证转发（3 类，高丢弃） | 高丢包容忍的重要数据 |
| AF41 | 100010 | 34 | [RFC2597] | 保证转发（4 类，低丢弃） | 低丢包需求的关键数据 |
| AF42 | 100100 | 36 | [RFC2597] | 保证转发（4 类，中丢弃） | 中等丢包需求的关键数据 |
| AF43 | 100110 | 38 | [RFC2597] | 保证转发（4 类，高丢弃） | 高丢包容忍的关键数据 |
| EF PHB | 101110 | 46 | [RFC3246] | 加速转发 | 语音、视频等实时业务 |
| VOICE-ADMIT | 101100 | 44 | [RFC5865] | 容量许可的语音流量 | 需带宽许可的语音业务 |
-
加速转发（EF）技术特性与调度逻辑
一、加速转发（EF）的服务定位与目标
加速转发（Expedited Forwarding，EF）是网络区分服务模型（Differentiated Services，DiffServ） 中定义的一种 每跳行为（Per-Hop Behavior，PHB） ，其目标是为特定流量提供 近似“无拥塞”的传输保障 。这类流量通常承载对实时性、稳定性要求极高的业务（如语音通话、视频会议），因此 EF 流量需满足 低延时（Low Latency）、低抖动（Low Jitter）、低丢包率（Low Packet Loss Rate） 的传输质量标准。
二、EF 流量的传输速率约束
为实现“非拥塞”目标，EF 流量对路由器的 速率匹配逻辑（Rate Matching Logic） 提出明确要求：路由器针对 EF 流量的输出速率（Output Rate），需至少不低于其输入速率（Input Rate） 。该约束的本质是避免 EF 流量因“入向速率持续高于出向速率”，在路由器队列中堆积并引发拥塞，最终破坏实时业务的服务质量（Quality of Service，QoS）。
三、EF 流量的队列调度规则
在路由器的多类型流量调度场景中，EF 流量的排队逻辑呈现以下特征：
-
专属队列与高优先级：路由器为 EF 流量分配 独立队列（Independent Queue） ，且该队列的调度优先级 高于普通流量（如“尽力而为”服务的 Best-Effort，BE 流量） ，确保 EF 流量优先于非 EF 流量被处理。
-
EF 流量内部的公平性：在 EF 队列内部，流量遵循 “先到先服务（First-Come, First-Served，FCFS）” 原则排队。即 EF 流量仅会排在其他先到达的 EF 流量之后，队列内不额外区分 EF 流量的子优先级。这种设计既保障了实时业务的整体优先级，也维护了同类高优先级流量间的相对公平性。
说明：
“服务定位→速率约束→队列规则” -
2. 显式拥塞通知（ECN）字段
作用
由支持 ECN 的路由器在拥塞时标记数据报，接收方将拥塞状态反馈给发送方，发送方降低发送速率，避免路由器因过载丢弃数据，实现“拥塞预警”而非“拥塞后丢弃”。
ECN 位定义（2 位）
ECN 字段有 4 种组合，含义如下：
00：非 ECN 能力（发送方/接收方不支持 ECN）；01/10：ECN 能力（发送方/接收方支持 ECN，但未检测到拥塞）；11：拥塞标记（路由器检测到拥塞，通知发送方降速）。
工作流程
- 发送方发送 ECN 能力标记（
01/10）的数据包； - 路由器检测到拥塞时，将 ECN 位改为
11； - 接收方收到
11标记的数据包，通过 TCP ACK 报文告知发送方； - 发送方收到拥塞通知，降低发送窗口大小，缓解拥塞。
参考文献：
[1] Fall, K. R., and Stevens, W. R. TCP/IP详解 卷1：协议. Translated by 吴英, 张玉 and 许昱玮, 2nd ed., 机械工业出版社, 2016.
[2] J. Postel, “Internet Protocol” RFC 0791, September 1981.
[3] K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers” RFC 2474, December 1998.
[4] K. Ramakrishnan, S. Floyd, D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP” RFC 3168, September 2001.
[5] D. Grossman, “New Terminology and Clarifications for Diffserv” RFC 3260, April 2002.
via:
-
以太网数据帧详细解析 逐字节分析 - jueyuanfengsheng - 博客园 posted on 2023-08-07 11:49 jueyuanfengsheng
https://www.cnblogs.com/zccoming/p/17611080.html -
以太网帧、IP数据报的图解格式（包含相关例题讲解）_以太网帧格式-优快云博客 Rebecca.Yan 已于 2023-05-27 14:13:19 修改
https://blog.youkuaiyun.com/weixin_45440484/article/details/129667838 -
以太网数据帧详细解析 逐字节分析_以太网帧包括哪些字段?-优快云博客 Qazink 于 2020-08-25 21:18:49 发布
https://blog.youkuaiyun.com/weixin_43197795/article/details/108229234 -
IPv4 数据报中的 DS、ECN 字段_菜籽爱编程的技术博客_51CTO博客
https://blog.51cto.com/u_15891283/5886110
扫一扫
4907
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
