协议僵化 or 协议僵化

中间节点对传输协议行为的最小化固定假设可避免协议僵化。具体做法是：

• 传输协议使用 TLV 格式自解释，避免采用固定报文头。

TLV 格式具有自解释特征，中间节点若要对其行为特征进行假设，处理起来会非常棘手且低效，从而不得不放弃深度解析。

固定的报文头对中间节点理解传输协议反而助力。一旦中间节点以固定的方式理解并假设传输协议，就与传输协议发生了耦合，后面传输协议升级时，中间节点必须同步升级自己的理解和假设，这便是协议僵化的根源。

协议僵化确实阻碍了 TCP 的升级，“僵化”是个贬义词，但它就一定不好吗？

没有中间节点和传输协议的耦合，NAT 就很难实现。 如果网关认不得端口，又如何做 NAT？如果中间节点不理解 TCP/UDP，针对业务的限速，整形又如何来做？ 当然，有种说法是，所有涉及中间节点识别

传输层以上协议的任何行为的目的都怀有不良的恶意，但如果是善意呢？

这又是端到端之争。

如果快递没有安检，你可能会收到陌生人寄来的炭疽或者屎，但安检显然违反了端到端原则。

QUIC 尽可能将信息加密，中间节点再也无法识别并作出哪怕最弱的假设，从此 QUIC 的进化与中间节点完全无关，这完全避免了 QUIC 协议的僵化。好事还是坏事？

总之，TLV 会让解析变得顺畅，但没法预设，我建议端系统采用这种格式避免中间节点的预设。但中间节点则相反，处理传输层以下层协议，只有固定，定长格式才能便于快速处理以及硬件卸载。

QUIC 和 IPv6 代表了这两者，QUIC 让中间节点无能力处理，IPv6 让中间节点快速处理。

端到端协议首选TLV，尽可能加密就对了，让中间节点处理起来很麻烦很棘手就对了。
网络层以及以下层协议就应该定长，字段固定，便于转发节点硬件加速。
别的花活儿都是瞎几把扯淡故弄玄虚

浙江温州皮鞋湿，下雨进水不会胖。