一、为什么是 53

这个数是谈判谈出来的，不是算出来的：

第一行和第二行是「延迟 vs 效率」的经典冲突：载荷越小，一个语音样本能越早发出去，延迟越低； 载荷越大，5 字节头摊得越薄，效率越高。 两者不可兼得。 第三行那个 48 是「专家组投票」的结果：有意思的是，后来有人算过「32 字节载荷最平衡」， 但当年两边都不肯让，最后取了中间值。 所以「5 加 48 等于 53」这个数是历史的产物，不是技术上的最优解。 这也说明一件事：标准里的数字不都是「算出来的」，很多是「谈出来的」。 看到奇怪的常数时，先想想「当年有哪几方在争论」。

二、效率的天花板

不管数据多大，ATM 都到不了 91%：

48 除以 53 等于 90.6%，这就是天花板：不管数据多大，5 字节头是必须的。 而以太网 1518 字节的帧效率是 98.8%——相差八个百分点，在骨干网上就是一整条链路的价格。 第一行那个 1.9% 是 ATM 的死穴：它的开销是「按信元数」算的，不是「按比例」算的。 数据越小，摊在每份上的 5 字节头越贵。 而互联网流量恰恰以「大量小包」为主——TCP 的确认包只有 40 字节头、零载荷。 一个 40 字节的确认包，在 ATM 上要占 53 字节（一个信元里塞不满）。

三、它输在哪

三个原因：

第三条最容易被忽略：ATM 想做「端到端的统一传输」，所以它自带 QoS、信令、流量整形。 这套东西很强大，但也很重——设备要实现一大堆协议，成本自然下不来。 而以太网的做法是「尽力而为」：不保证延迟、不保证带宽，只保证「尽力送」。 这套做法看起来简陋，但它让设备可以做得极便宜——最后赢的就是这个「便宜」。 所以 ATM 的教训不是「技术不好」：它的 QoS 思想后来被 IP 网络学走了（DiffServ、 MPLS 都有影子）。输的是「整个体系太重」——用户要的不是「完美保证」，是「够用且便宜」。

四、动手 Demo：ATM 的 53 字节信元，赢在固定、输在固定

算不同大小的数据要几个信元、线上占多少、效率多少。 注意 9180 字节时效率也只有 90.2%，永远到不了 91%。

import math

print('理论最高效率 48/53 = %.1f%%' % (48 * 100.0 / 53))
for pay in (1, 40, 64, 512, 1500, 9180):
    n = int(math.ceil((pay + 8) / 48.0))
    total = n * 53
    print('%5d 字节 -> %3d 信元 %6d 字节 占比 %.1f%%'
          % (pay, n, total, pay * 100.0 / total))

实跑输出：

--------------------------------------------------------------------
ATM 的 53 字节信元，赢在固定、输在固定
--------------------------------------------------------------------
**ATM 把一切切成 53 字节的小方块：5 字节头 + 48 字节载荷。**
**固定长度让硬件做得极快，但小方块对小数据极不友好。**
**下面这组数把「为什么它输给以太网」算清楚。**

**53 分之 48 等于 90.6%，这是理论上的最高效率。**

  应用数据 字节     需要信元数     线上一共 字节     载荷占比
  ------------------------------------------------------------
  1                 1              53                1.9%
  40                1              53                75.5%
  64                2              106               60.4%
  512               11             583               87.8%
  1500              32             1696              88.4%
  9180              192            10176             90.2%

**第一行最刺眼：1 个字节要占 53 字节，效率 1.9%。**
**最后一行 9180 字节时效率 90.2%，已经逼近 90.6% 的天花板**——
**也就是说，不管数据多大，ATM 的效率永远到不了 91%。**
**这个天花板是一道硬墙，跟实现无关**：**因为每个信元的 5 字节头是必须的，48 除以 53 就是上限。**
**以太网那边，1518 字节的帧效率是 98.8%**——**相差八个百分点，在骨干网上就是一整条链路的价格。**
**这就是 ATM 的死穴**：**它的开销是「按信元数」算的，不是「按比例」算的。**
**数据越小，摊在每份上的 5 字节头越贵。**
**而互联网的流量恰恰以「大量小包」为主**——**TCP 的确认包只有 40 字节的 IP+TCP 头、零载荷。**
**那个 48 是怎么定的，有一段著名的争论**：
**48 字节是美国提的（语音延迟小），64 字节是欧洲提的（效率高）。**
**折中成 32 字节载荷会更好，但两边都不肯让，最后取了 48。**
**所以「5 加 48 等于 53」这个数，是谈判的产物，不是算出来的最优解。**
**ATM 真正输掉的原因不是效率，是「贵」**：
**每一段都要重组、每一跳都要排队，而且设备比以太网贵一个数量级。**
**以太网用「可变长 + 尽力而为」换来了便宜，也就赢了。**

(pay + 8) / 48 那个 8 是 AAL5 的尾部：ATM 在最后要加 8 字节的「长度 + 校验」， 所以实际载荷不是 pay 而是 pay + 8。 这个细节决定了「64 字节要 2 个信元」而不是 2 个刚刚好。 9180 字节那行效率 90.2%，逼近 90.6% 的上限：这说明「数据再大也超不过 91%」。 而以太网 1518 字节就有 98.8%——这 8 个百分点在骨干网上是致命的。 1 字节那行最刺眼：1.9%：但真实网络里没有「1 字节的数据包」， 最小的 TCP 确认包是 40 字节（IP + TCP 头），在 ATM 上占 53 字节，效率 75.5%。 所以 ATM 的问题不是「极端情况差」，是「常见情况也不好」。

30 秒实验

1. 算一下：1500 字节的数据，ATM 要占多少字节？以太网呢？差多少？
2. 想一下：为什么 ATM 要把载荷定成「固定长度」，而不是「可变长度」？
3. 查一下 MPLS 和 ATM 的关系，看它继承了什么、丢掉了什么。

常见误区

1. 以为 48 是算出来的最优值。 是谈判折中的结果，后来有人算出 32 更平衡。
2. 以为 ATM 效率能到 95% 以上。 上限就是 90.6%，因为 5 字节头躲不掉。
3. 以为 ATM 输在「技术落后」。 它的 QoS 思想被 IP 学走了，输在「整套体系太贵」。

下一节看 POS：把 IP 包塞进 SDH 的管道里。

• ☐ （本节完，下一节 3.6.2 POS）

相关笔记

• PPPoE
• POS
• 📚 图解TCP／IP · 索引