• 协议僵化 or 协议僵化


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

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

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

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

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

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

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

    这又是端到端之争。

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

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

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

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

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

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

  • 相关阅读:
    git代码合并+解决冲突
    2024/3/11打卡管道(14届蓝桥杯省赛)——二分+区间合并
    嵌入式Linux driver开发实操(十八):Linux音频ALSA开发
    Android Theme主题属性资源定义说明及示例
    MacBook2024苹果免费mac电脑清理垃圾软件CleanMyMac X
    promise返回值多层嵌套
    量子计算新突破!来源于150年前的思想实验
    练摊吧,有能力吗,有资源吗,有地方吗
    Docker搭建私有仓库
    Himall商城文件帮助类IOHelper(1)
  • 原文地址:https://blog.csdn.net/dog250/article/details/126334201