在计算机网络考试里，经常会碰到这样一道看起来只需要背两个数字的题。

在以太网标准中，为了检测冲突而规定的最小帧长是 64 字节，以太网标准中最大帧长是 1518 字节。

所以这道题的答案很明确，两个空分别填写

64 字节，1518 字节。

IEEE 802.3 的相关资料中明确给出了基本 Ethernet MAC 帧的尺寸范围，最小基本 MAC 帧为 64 octets，最大基本 MAC 帧为 1518 octets。这里的 octet 在现代计算机网络语境中就是 8 bit，也就是通常所说的 1 byte。

单纯把 64 和 1518 背下来并不困难，真正容易在考试里出问题的是另一件事。为什么为了检测冲突，偏偏要求至少 64 字节，而不是 32 字节或者 128 字节。1518 又是怎么加出来的。为什么平时经常看到 MTU 1500，但题目问最大帧长时答案却不是 1500。再往后还会碰到 1522、Jumbo Frame、512 bit time、46 字节最小数据字段，这些数字很容易混成一团。

把这些数字背后的逻辑串起来之后，这一类题基本就不需要死记了。

经典共享式 Ethernet 使用 CSMA/CD，也就是 Carrier Sense Multiple Access with Collision Detection，中文通常译为载波侦听多路访问和冲突检测。

这里最关键的词并不是 Carrier Sense，而是 Collision Detection。

早期 Ethernet 并不像今天交换机组成的全双工局域网。典型的 10BASE5、10BASE2，以及后来通过 Hub 连接的 10BASE-T，都可能让多台主机共享同一个冲突域。多台设备可能同时判断线路空闲，也可能几乎在同一个时间开始发送数据。

于是冲突就产生了。

可以把早期 Ethernet 想成一条很长的公共走廊，两端各站着一个人。走廊的一端开始讲话时，声音需要一段时间才能传播到另一端。另一端的人在声音到达之前，也可能认为走廊里没人讲话，于是同时开口。

网络中的电信号也是如此。

假设站点 A 位于冲突域的一端，站点 B 位于另一端。A 在时刻 $t_0$ 开始发送 Ethernet 帧。由于电磁信号在铜缆中的传播速度有限，A 发出的第一个 bit 不可能瞬间出现在 B 所在位置。

在 A 的信号抵达 B 之前，B 仍然可能认为介质空闲。

如果 B 恰好在这个临界时刻开始发送，A 和 B 的信号就会发生冲突。

问题随之出现。

A 必须能够知道这个冲突发生了。

如果 A 发送的帧实在太短，可能出现一种危险情况。A 已经把整个帧发送完毕，甚至已经认为发送成功，而远端产生的冲突信号还没有传播回来。

这时 CSMA/CD 的 Collision Detection 就失去了作用。

因此 Ethernet 需要制定一个规则，发送站发送一帧所持续的时间，至少要足够覆盖冲突域最坏情况下的往返传播时间。

这个思想正是 64 字节最小帧长背后的关键。

经典 Ethernet 规定了一个非常重要的时间参数，slot time，也就是时隙时间。

对于经典 10 Mb/s 和 100 Mb/s Ethernet，slot time 对应 512 bit time。

512 bit 恰好是多少字节。

计算非常直接。

$$
512 \div 8 = 64
$$

也就是 64 字节。

所以看到 Ethernet、CSMA/CD、冲突检测、最小帧长这一组关键词时，可以马上建立下面这条关系。

$$
64\ bytes \times 8 = 512\ bits
$$

64 字节并不是某个设计者随手选出的整数，而是和 Ethernet 的冲突检测时间模型联系在一起的。

以最经典的 10 Mb/s Ethernet 为例，发送一个 bit 所需要的时间为

$$
\frac{1}{10\,000\,000}
$$

秒，也就是 $0.1\ \mu s$。

发送 512 bit 所需时间为

$$
512 \times 0.1\ \mu s = 51.2\ \mu s
$$

因此经典 10 Mb/s Ethernet 的 512 bit time 对应 51.2 微秒。

在这个时间窗口内，如果网络拓扑、线缆长度、中继器数量等都满足 Ethernet 标准约束，那么最远端发生的冲突应该能够传播回来，使发送端在仍然发送这一帧的时候检测到冲突。

于是考试里的那句「为了检测冲突而规定的最小帧长」就很好理解了。

关键并不是 64 这个数字本身，而是

$$
最小帧发送时间 \ge 冲突域最坏情况下的往返传播时间
$$

这才是设计思想。

回到 Ethernet MAC 帧结构，64 字节又是怎样凑出来的。

一个普通、未添加 VLAN Tag 的 Ethernet 帧，从 Destination MAC Address 开始，到 FCS 结束，可以看成下面这些部分。

Destination MAC Address 占 6 字节。

Source MAC Address 占 6 字节。

Type 或 Length 字段占 2 字节。

Data 加 Padding 字段至少占 46 字节。

FCS 占 4 字节。

把这些数字加起来。

$$
6 + 6 + 2 + 46 + 4 = 64
$$

所以最小 Ethernet MAC 帧正好是 64 字节。

这里的 46 字节非常重要。

如果上层交给 Ethernet 的数据不足 46 字节，MAC 层不能直接发送一个不足 64 字节的帧，而是需要通过 Padding 补齐，让整个 MAC 帧至少达到 64 字节。Cisco 的 Ethernet 故障排查文档也说明，当数据不足以填满 64 字节最小帧时，需要加入 padding bytes，使帧满足最低长度要求。

这也解释了另一类经常出现的题。

如果题目问 Ethernet 的最小数据字段长度是多少，答案不是 64，而是 46 字节。

如果题目问 Ethernet 的最小帧长是多少，答案才是 64 字节。

两者关系就是

$$
14\ 字节\ MAC\ Header + 46\ 字节\ Data + 4\ 字节\ FCS = 64\ 字节
$$

这里所谓的 14 字节 MAC Header，就是

$$
6 + 6 + 2 = 14
$$

也就是目的 MAC 地址、源 MAC 地址以及 Type 或 Length 字段。

考试中还有一个非常典型的陷阱，Preamble 和 SFD 到底算不算在这 64 字节里。

答案是不算。

Ethernet 在线路上真正传输一个帧之前，还会发送 7 字节 Preamble，也就是前导码，以及 1 字节 SFD，也就是 Start Frame Delimiter。

两者合起来一共 8 字节。

它们用于帮助接收端建立时钟同步并识别 Ethernet 帧真正开始的位置，但通常讨论 IEEE 802.3 MAC 帧长度时，并不把这 8 字节计入所谓的 64 字节最小帧长度。

因此线路上可以观察到

$$
8 + 64 = 72
$$

字节的相关传输内容，但标准意义上的最小 MAC 帧依然是 64 字节。

如果再把 Ethernet 帧之间的 Interpacket Gap，也就是 IFG，计算进去，还会出现更多数字。IFG 相当于 96 bit time，也就是 12 字节时间，但它根本不是 Ethernet 帧的一部分。

所以考试里只要看到「帧长」两个字，不应该把 Preamble、SFD、IFG 随意加进去。

说到最大帧长，1518 的来源比 64 更容易计算。

普通 Ethernet 帧最大数据字段，也就是我们经常在 IP 网络里接触到的 Ethernet MTU，通常是 1500 字节。

在它前面仍然存在 14 字节 Ethernet MAC Header，后面还有 4 字节 FCS。

于是

$$
14 + 1500 + 4 = 1518
$$

这就是标准基本 Ethernet MAC 帧的最大长度。

进一步展开就是

$$
6 + 6 + 2 + 1500 + 4 = 1518
$$

目的 MAC 地址 6 字节，源 MAC 地址 6 字节，Type 或 Length 2 字节，Payload 最大 1500 字节，FCS 4 字节。

所以看到 1500 和 1518 时，不需要把它们看成两个独立的死记数字。

1500 是最常见的 Ethernet Payload 上限，也就是 IP 层经常讨论的 Ethernet MTU。

1518 是把 Ethernet 二层头部和 FCS 一并计算之后得到的基本 MAC 帧最大长度。

这也是实际网络故障排查中非常有用的一组关系。

例如 Windows 或 Linux 系统配置普通 Ethernet 接口时，经常看到 MTU 1500。这里的 1500 并没有把目的 MAC、源 MAC、EtherType 和 FCS 算进去。网卡真正在线路上生成 Ethernet 帧时，二层结构还需要在这个 Payload 外面添加相应字段。

因此不能看到系统显示 MTU 1500，就认为 Ethernet 最大帧长也是 1500。

它们讨论的是不同层次上的数据长度。

如果 IPv4 数据报正好达到 1500 字节，同时又没有 VLAN Tag，那么 Ethernet MAC 帧可以达到经典的 1518 字节。

如果继续考虑 Preamble 和 SFD，线路上的相关字节数量又会变成

$$
8 + 1518 = 1526
$$

但考试所问的标准 Ethernet 最大帧长仍然是 1518 字节，因为那 8 字节并不属于这里讨论的基本 MAC 帧长度。

这里又会碰到一个特别容易混淆的数字，1522。

1522 通常和 IEEE 802.1Q VLAN 有关。

普通 Ethernet Header 为 14 字节，引入 802.1Q VLAN Tag 后增加 4 字节，因此带 VLAN Tag 的 Ethernet 帧最大长度可以从 1518 增加到 1522 字节。

计算关系为

$$
1518 + 4 = 1522
$$

IEEE 相关资料中也明确区分了基本未标记 MAC 帧和带 Tag 的 MAC 帧，经典基本帧最大值为 1518 octets，而 tagged MAC frame 可以达到 1522 octets。

因此面对考试题时，需要观察题目是否明确提到了 IEEE 802.1Q、VLAN、Tagged Frame。

如果什么额外条件都没有，只说「以太网标准中最大帧长」，传统教材和网络工程类考试通常采用经典基本 Ethernet Frame 的答案，也就是 1518 字节。

如果明确说带 802.1Q Tag，则需要考虑额外的 4 字节。

再回头看 64 字节，它和冲突检测的关系还可以从真实 Ethernet 的工作过程继续深入。

假设共享式 Ethernet 中有两台计算机 A 和 B，分别处于冲突域的两个远端。

A 开始发送。

信号沿介质向 B 传播。

在 A 的信号刚刚抵达 B 之前，B 也检测到自己这一侧介质暂时没有载波，于是 B 开始发送。

此时两组信号在介质中发生冲突。

冲突产生后，这个异常电气状态仍然需要一定时间才能传播回 A。

如果 A 的帧足够长，A 此时仍处于发送状态，就可以检测到冲突。

A 检测到冲突后，并不会假装什么都没发生，而会执行 CSMA/CD 对冲突的处理逻辑，其中包括发送 Jam Signal，使冲突能够被相关站点可靠识别，停止当前传输，再经过 Binary Exponential Backoff，也就是二进制指数退避，随机等待之后重新竞争介质。

如果 A 只发送一个极短的帧，甚至在冲突信息返回之前已经停止发送，就可能出现 late collision 相关问题，正常的 CSMA/CD 时间假设也就被破坏了。

从网络工程角度看，64 字节实际上是在空间距离、传播速度、发送速率和冲突检测能力之间做出来的一套时间约束。

这一点和现代交换式 Ethernet 的工作环境差异很大。

今天企业机房里常见的 PC、服务器、交换机之间，大多工作在 Full Duplex 模式。

一条交换式全双工链路的发送方向和接收方向可以独立工作，并不存在早期共享介质那种多台设备争抢同一条信道的问题。

因此 Full Duplex Ethernet 实际上不需要 CSMA/CD 来解决共享介质冲突。

现代千兆、万兆乃至更高速率的交换网络中，工程人员平时几乎不会遇到正常意义上的 Ethernet collision。

但 64 字节这个历史规则并没有因此从 Ethernet MAC 帧格式中消失。

协议标准具有很强的兼容性约束。现代 Ethernet 仍然继承了经典 Ethernet 的帧格式规则，所以考试依旧会考 64 字节，也依旧会把它与 CSMA/CD 和碰撞检测联系起来。

理解这段历史很重要，因为只看今天的交换网络，很容易产生疑问。

既然现代交换机端口几乎都采用 Full Duplex，为什么还需要学习冲突检测。

原因就在于很多 Ethernet 帧格式和参数，是在共享介质时代建立起来的。现代网络虽然已经发生巨大变化，但这些设计痕迹仍然留在协议体系中。

这里还可以顺手解决一个常见疑惑。

为什么 Fast Ethernet 从 10 Mb/s 提升到 100 Mb/s 后，最小帧没有简单扩大十倍。

因为 Ethernet 标准并不是只改变线路速度，而完全不调整其他物理层限制。为了保持 64 字节最小帧等重要 MAC 层兼容性，更高速率 Ethernet 会对允许的网络直径、中继器模型、物理层实现等作出新的约束。

发送速率提高十倍之后，同样 64 字节只需要原来的十分之一时间就可以发送完成。为了仍然满足冲突检测要求，冲突域允许的物理尺度自然不能照搬原来的 10 Mb/s Ethernet。

所以从 10BASE5、10BASE2、10BASE-T 到 100BASE-TX，不能单纯拿相同距离模型直接套用。

这里反映的是网络协议设计里一个非常典型的思路，协议参数彼此之间不是孤立存在的。

帧长、传输速率、传播时延、网络直径、中继器数量、物理层特性共同构成一套约束。

512 bit time 也是如此。

很多考试会把「最小 Ethernet 帧长度 64 字节」和「Ethernet slot time 为 512 bit time」分成两道题，其实它们几乎是同一个知识点的两个观察角度。

一个从空间和时间角度讨论冲突检测。

一个从帧格式角度讨论最小 MAC 帧。

把

$$
64\ bytes = 512\ bits
$$

牢牢记住，这两块知识就连起来了。

最大帧长 1518 也可以采用类似思路记忆，而不是机械背数字。

只需要记住普通 Ethernet 中最常见的 MTU 是 1500。

Ethernet Header 是 14。

FCS 是 4。

于是

$$
1500 + 14 + 4 = 1518
$$

而最小帧也可以使用同一套结构。

Header 14。

最小 Data 加 Padding 为 46。

FCS 为 4。

于是

$$
14 + 46 + 4 = 64
$$

这样一来，最小和最大正好形成很漂亮的一组对应关系。

$$
14 + 46 + 4 = 64
$$

$$
14 + 1500 + 4 = 1518
$$

从这里还能看出一个容易忽略的规律。

普通 Ethernet 帧的 Header 和 FCS 没有随着 Payload 大小改变。

真正变化的是中间的数据字段。

最小时数据部分至少填充到 46 字节。

最大时经典数据部分达到 1500 字节。

所以 Ethernet 基本帧长度范围自然就是

$$
64 \le FrameSize \le 1518
$$

如果抓包工具里看到一个小于 64 字节的 Ethernet 帧，也不能立刻认为标准被推翻了。

真实抓包环境中，网卡硬件、驱动、抓包位置以及 FCS 是否由网卡剥离都会影响 Wireshark 最终显示出来的长度。有些网卡在把数据交给操作系统之前已经处理掉 FCS，因此软件看到的帧长度可能与线缆上的实际 MAC 帧长度不同。

这也是实验环境与教材数字偶尔看起来不一致的原因之一。

Jumbo Frame 则属于另一套工程实践。

很多数据中心、存储网络以及高性能计算环境会配置 9000 左右的 MTU，从而减少单位数据量需要处理的帧数量，降低 Header 开销以及一定程度上的 CPU 处理负担。

不过 Jumbo Frame 并不是这道基础题所说的经典标准 Ethernet 最大帧长。

看到 Jumbo Frame 时，不能反过来得出 Ethernet 的基础考试答案已经不是 1518。

题目没有附加 VLAN、Envelope Frame、Jumbo Frame 等条件时，应当回到最经典的 Ethernet 基本帧模型。

64 和 1518。

这道题如果只需要填写答案，到这里已经结束。

但从整个计算机网络知识体系来看，更值得记住的是两个等式。

$$
64\ bytes = 512\ bits
$$

它对应的是 CSMA/CD 的冲突检测时间约束。

以及

$$
1518 = 14 + 1500 + 4
$$

它对应的是 Ethernet Header、Payload 与 FCS 的组合。

再把最小情况补上。

$$
64 = 14 + 46 + 4
$$

三个式子放在一起，很多容易混淆的数字马上就有了各自的位置。

64 是基本 Ethernet MAC 帧最小长度。

46 是普通 Ethernet 数据字段的经典最小长度。

512 bit time 是和冲突检测密切相关的 slot time。

1500 是最常见的 Ethernet Payload 或 IP MTU 上限。

1518 是普通未标记 Ethernet 基本 MAC 帧最大长度。

1522 常见于增加 4 字节 IEEE 802.1Q VLAN Tag 后的情况。

8 字节 Preamble 加 SFD 不计入经典的 64 到 1518 字节 MAC 帧长度范围。

12 字节时间对应常说的 Interpacket Gap，它同样不是 MAC 帧内容。

这样再遇到类似选择题，即使选项故意放入 46、64、1500、1518、1522 等几个很接近的数字，也不会只依赖模糊记忆。

真正需要在脑中留下的一幅图，是一帧普通 Ethernet 数据从左到右展开。

6 字节 Destination MAC，6 字节 Source MAC，2 字节 Type 或 Length，中间 Data 从 46 到 1500 字节，末尾 4 字节 FCS。

最小时

$$
6 + 6 + 2 + 46 + 4 = 64
$$

最大时

$$
6 + 6 + 2 + 1500 + 4 = 1518
$$

而 64 字节之所以不能再短，又回到了 CSMA/CD 的那条核心约束，发送端必须给最坏情况下的冲突足够的传播和返回时间，让冲突发生时，发送端仍然处于发送状态，从而能够把 Collision 真正 Detection 出来。

所以，这道题最适合记成一句很短的话。

以太网冲突检测记 64，标准基本帧上限记 1518。

题目两个空的标准答案就是

**64 字节，1518 字节。**

## 参考资料

IEEE 802.3 Working Group 关于 Frame Size 的资料给出了基本 MAC 帧最小 64 octets、最大 1518 octets，以及 Tagged MAC Frame 最大 1522 octets 等数据。

Cisco 的 Ethernet 故障排查资料说明了 Ethernet 帧的数据字段、FCS，以及数据不足时通过 Padding 保证最小 64 字节帧长的处理方式。

IEEE 关于 802.3 MAC Frame Size 的解释资料进一步确认了未标记帧 1518 字节以及带 Tag 帧 1522 字节的传统限制。

在以太网标准中，为了检测冲突而规定的最小帧长是 64 字节，以太网标准中最大帧长是 1518 字节。

为什么以太网最小帧长是 64 字节，最大帧长又是 1518 字节

紫薇堂堂主

网络与通信

编程语言

新闻资讯

以太网最小帧长64字节源于CSMA/CD冲突检测需覆盖512bit时间往返传播；最大帧长1518字节由14字节MAC头+1500字节数据+4字节FCS组成。46字节是最小数据字段，VLAN Tag额外增加4字节至1522。MTU 1500不包含二层开销，Preamble和SFD不计入帧长。

数据中心

大数据

服务器

Windows

Linux

2026上云采购 | AI焕新·智启新局

thpc

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

为什么以太网最小帧长是 64 字节，最大帧长又是 1518 字节-腾讯云开发者社区-腾讯云

为什么以太网最小帧长是 64 字节，最大帧长又是 1518 字节

为什么以太网最小帧长是 64 字节，最大帧长又是 1518 字节

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐