BGP 消息长度，以 2 个字节为单位。那么为什么最大 bgp 消息大小不能为 65535？为什么是 4096？

官方答复

引用 Tony Li在IDR List上回答这个问题时的话：

1a) 固定大小很好，因为它使协议实现变得容易。如果实现没有任何好处，那么复杂性就毫无意义。大消息并没有带来什么好处，因为它们需要足够大以承载路径属性和相关的前缀。为此，迄今为止 4k 可能就足够了。

1b) 从历史上看，4k 被认为有点浪费。当然，与使用分段数据包的 EGP 相比，它非常简单。小心解析一个 16k 的巨型字符？关心调试吗？相信我，这不好玩。

2) 4k 消息大小完全独立于 TCP 窗口大小。一个实现可以完全自由地组合任意数量的消息，每条消息都在 4k 限制内。然后，实现可以将任意数量的消息塞入其 TCP 套接字，直至达到该 TCP 的缓冲限制。

2a) 因此，消息大小不是性能限制，除非实现实际上可能使消息溢出。维护当前实现的人们可能会在此处提出他们是否看到这一点。

所以，总而言之，是的，4k 消息大小限制对于 BGP 来说是一个很好的情况，因为它的行为方式和它所做的工作。但这不必然推广到其他协议（如OSPF），其中超过4K最常见的MTU。在这些情况下，您最终会出现碎片化，这很糟糕。

其他想法

65536 / 4096 = 16

我们真的希望 BGP 的瞬态 RAM 要求乘以 16 吗？请记住，在幕后，许多 BGP 实现是用 C 编写的，这意味着 BGP 可能需要malloc为每个消息留出最大消息大小的空间。

必答题...

• 为什么我们在软件中有任何可变大小限制？
• 为什么不是每个 C 整数 a long long？

假设我们有 100,000 个 BGP 前缀和 15,000 个唯一属性组合；我们还假设我们的 BGP 实现BGP UPDATE以 100% 的效率将前缀打包到消息中。因此我们需要 15,000 条BGP UPDATE消息。

15000 条消息 * 4096 字节/消息 = 58MB 使用的聚合 BGP 消息缓冲

15000 条消息 * 65536 字节/消息 = 937MB 使用的聚合 BGP 消息缓冲

因为RFC4271是这么说的？该限制也存在于BGP 3中。考虑到在传奇餐巾纸上创建 BGP 时的小型互联网，我想说它的选择方式与 IPv4 中的位数完全相同。