#1 楼
答案在draft-ietf-isis-ext-eth-01，第3-5节中。以太网在以太网II（DIX）和802.3封装中使用相同的两个字节，但方式不同：以太网II在类型为802.3在“长度”字段中使用了相同的两个字节。 >
RFC 894（通常称为以太网II帧）将这些字节用于Type
+----+----+------+------+-----+
| DA | SA | Type | Data | FCS |
+----+----+------+------+-----+
^^^^^^^^
DA Destination MAC Address (6 bytes)
SA Source MAC Address (6 bytes)
Type Protocol Type (2 bytes: >= 0x0600 or 1536 decimal) <---
Data Protocol Data (46 - 1500 bytes)
FCS Frame Checksum (4 bytes)
IEEE带有802.2 LLC / SNAP的802.3（由Spanning-Tree，ISIS使用）将这些字节用于Length
存在于同一链接上。如果IEEE允许以太网有效载荷超过1536字节（0x600十六进制），则不可能将大型802.3 LLC或SNAP帧与以太网II帧区分开；以太网的类型值从0x600十六进制开始。
编辑：有兴趣...
评论
顺便说一句，在以太网标准中未定义maxValidFrame（1500）和“ 1536十进制”之间的值。未指定这些值下设备的行为，并且不能依赖于
–迈克·彭宁顿
13年8月24日在17:44
好吧，以太网II帧的类型字段始于0x0600（来自IEEE 802.3x-1997规范），因为802.3的最大最大长度恰好在其下方。因此，这只是一个结果，而不是原因。
–不
13年8月27日在8:09
@否，要断言这是结果而不是原因，就可以证明原因...可以为您提出的原因提供权威证据吗？ 1980年发布的原始以太网版本1规范已经使用“类型”字段，并且在1984年，使用Ethertype 0x0800指定了IP协议。
–迈克·彭宁顿
13年8月27日在9:11
实际上，以太网I和II规范已经具有类型字段（当时没有任何限制），并且已经指定最大数据长度1500-那时没有802.3帧。因此，不能断定由于类型字段而在以后的规范中增加了1500的限制。
–不
13年8月27日在10:45
@不，我不同意，以太网II必须与先前存在的标准共存。它还定义了使用相同的字段作为既有标准中的类型字段和新标准中的长度字段。鉴于两个标准之间必须不存在混淆的可能性，而这两个标准必须共存于同一网络中，因此不允许任何看起来像现有类型的长度。由于现有类型列表从0x600开始，因此必须选择的数字要少一些。为了不允许进一步扩展到该标准，必须保留一些可用的频段。
–user3104
13-10-31在0:12
#2 楼
在范围的另一端-1500字节，有两个因素导致引入此限制。首先，如果数据包太长，它们会使用以太网电缆给其他流量带来额外的延迟。另一个因素是早期共享电缆收发器中内置的安全设备。该安全装置是防ba系统。如果连接到收发器的设备出现故障并开始连续传输，则它将有效地阻止任何其他流量使用该以太网电缆段。为了避免这种情况的发生，早期的收发器被设计为在传输超过约1.25毫秒时自动关闭。这等于刚刚超过1500个字节的数据内容。但是，由于收发器使用一个简单的模拟计时器来关闭传输（如果检测到冒泡），因此选择了1500极限作为对不会触发安全设备的最大数据大小的安全近似值。
来源：http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1
评论
@ user1171，您好：StackExchange的首选样式是在此处包括答案材料，并链接出作为参考。这样，当链接最终消失时，答案仍然有用。
–克雷格·康斯坦丁（Craig Constantine）
13年8月25日在12:02
jabber功能要求MAU在20到150毫秒后关闭10 Mbit / s（IEEE 802.3条款8.2.1.5），在40到75 kbit时关闭快速以太网（条款27.3.2.1.4），而千兆以太网则关闭两倍。远远超过帧长度。 Yahoo帖子是错误的。
– Zac67
18年7月20日在13:50
#3 楼
当以太网最初被开发为与10Base5和10Base2共享的介质或总线时，帧冲突频繁发生（在连接中，您会通过在电缆上钻一个抽头来分叉信号）会发生什么？ 。与今天相比，大多数情况下，所有事物都通过单独的冲突域进行切换并运行全双工，而没人希望看到冲突。共享“醚”的机制采用了CSMA / CD（载波侦听多路访问/冲突检测）
载波侦听意味着要发送的站点必须收听电线-感知载波信号-确保没有人在说话，因为那是该介质上的多路访问。
Allowing 1500 bytes (though an arbitrary number as far as I can tell) was a compromise that meant a station could not capitalize the wire too long by talking too much at one time.帧中发送的字节越多，所有其他站必须等待更长的时间才能完成该传输。换句话说，较短的突发次数或较小的MTU意味着其他站点获得了更多的传输机会并获得了公平的份额。传输介质的速度较慢（10Mb / s），随着MTU的增加（如果允许超过1500），站点将具有更长的传输延迟。一个有趣的推论性问题是为什么最小值帧大小为64字节？帧在512位的“时隙”中传输，并花费51.2微秒用于介质中的往返信号传播。电台不仅必须通过感测IFG（96位的帧间间隙）来监听何时开始通话，还必须监听与其他帧的冲突。碰撞检测假设最大传播延迟，并将其加倍（为安全起见），因此当有人忘记电缆末端的电阻时，它不会错过从电线另一端开始的大约同一时间的传输或自身传输的信号反射。电缆的两端。该站必须在感测到冲突之前不完成其数据的发送，因此等待512位或64字节可以保证这一点。
#4 楼
最初，最高有效负载在802.3中定义为1500字节。以太网v2支持> = 1536的帧长，这就是IP实现所使用的。如今，大多数电信级供应商都支持大约9000字节（“巨型帧”）。由于1500字节是所有以太网实现必须支持的标准，因此通常将其设置为所有接口的默认设置。 >
评论
您应该google maxValidFrame，它是由IEEE定义的；因此，今天很常见的9KB巨型帧实现尚未正式与以太网兼容，但是它们对于以太网II负载非常有效
–迈克·彭宁顿
13年8月24日在18:00
严格来说，不符合802.3。 IP虽然使用了以太网v2，所以我什至没有想到802.3 ...
–user661
13年8月24日在18:19
在批准802.3x之后，Jumbos不符合以太网II或802.3。 802.3x条款4.2.7.1在1500B有效负载处定义了maxValidFrame。因此，在1997年之后，任何超过1500字节的有效负载都不符合要求。有关此问题，请参见IEEE 802.3主席致IETF的信。简而言之，802.3不仅仅是框架标准……它定义了帧和硬件要求。这意味着硬件实现取决于帧格式的符合性。带CSMA-CD的半双工需要<= 1500B有效负载。
–迈克·彭宁顿
13年8月24日在18:42
#5 楼
最小以太网帧基于以太网时隙时间，对于10M以太网，它是512位长度（64字节）。在为以太网报头和CRC减去18个字节后，您将获得46个字节的有效负载。必须确保最小框架尺寸不超过电缆的最大可能长度。如果确实做到了确定性碰撞检测将是不可能的。在最大电缆长度处进行冲突检测后，您需要冲突检测信号才能返回到发送方。评论
我很难理解确定最小以太网帧大小的机制与当前1500字节的最大实际标准有什么关系。请详细说明！
– Stuggi
16-10-23在8:43
@Stuggi没有。
–肯·夏普
17年7月17日在2:21
评论
IEEE的人们一直反对在标准中添加9k，因为数学上的保证FCS如今以1.5k带来的结果在9k时就不再适用。@ytti，这只是反对认可1500帧以上的论点之一。杰夫·汤姆森（Geoff Thomson）的信的全文（包含IEEE对巨型帧进行标准化的反对意见）在draft-ietf-isis-ext-eth-01附录1中。
有什么答案对您有帮助吗？如果是这样，您应该接受答案，这样问题就不会永远弹出来寻找答案。或者，您可以提供并接受自己的答案。