• DARPA互联网协议的设计(一)


    在之前的博客中,已经多次对MIT6.829这门课程的资源进行过解释和说明,链接如下:
    https://www.cnblogs.com/lionelgeng/p/14322444.html
    https://www.cnblogs.com/lionelgeng/p/14351786.html
    https://www.cnblogs.com/lionelgeng/p/14403587.html
    https://www.cnblogs.com/lionelgeng/p/14395219.html
    本博客不想直接将这些资源进行英文到中文的翻译,原因有二:
    一是因为作为IT技术人员,具有一定的阅读英文资料的能力是基本项,比如阅读RFC;
    二是因为本博客想表达一些网络的设计过程,只有自己真正的理解,这门课程才算是有所收获。

    该课程的第一章标题是History of the Internet Architecture,也就是研究互联网架构的历史。
    The Design Philosophy of the DARPA Internet Protocols这篇论文发表于1988年,MIT网站的是2013年的修订版本,但是基本内容和重要思想是没有变的。

    TCP/IP协议是DARPA于1973开始设计和开发的,最开始在军事领域使用,后来发展为商业化的互联网络。IP协议被正式标准化为RFC791在1981年,TCP协议被正式标准化为RFC793也是1981年。
    就像该文所说,有时候很难判断,是什么动力或者原因导致协议被设计为这个样子,也就是协议为什么是这样。

    it is sometimes difficult to determine the motivation and reasoning which led to the design.

    首要目标:
    根据DARPA当时面对的情况,他们想要设计的网络是:一个包交换网络设施,这个网络可以连接很多不同类型的网络,使用的是包交换处理器,它们被称之为网关,网关的角色是执行存储并转发数据包的算法。

    次级目标:
    这个网络还应该是有如下性质的:
    1.如果网络有丢包或者网关故障,网络通信还可以继续可用。
    2.网络必须可以支持不同类型的通信服务。
    3.网络架构必须可以承载在不同的网络上。
    4.网络架构必须允许分布式管理它的网络资源。
    5.网络架构必须是成本可接受的。
    6.网络架构必须降低主机的接入成本。
    7.网络架构中使用的资源必须是可以有限数量的。

    上面的顺序是重要的,因为这表示了网络的设计宗旨。如果顺序不一样,那么可能设计出来的网络就不是现在这个样子的了。这涉及到网络设计中的取舍和折中问题。比如说这个网络因为是被设计为军事领域,因为系统可用性就是最重要的;而如果是商业网络,那么网络资源数量,部署成本就是重要的考量了。本质来说,上述目标就是网络设计的顶层需求,但是需求是有优先级的,只有最重要的特性满足了,低优先级的特性才被加以考虑。

    面对故障的可靠性
    需要说明的是,上面的目标中的第一点,当发送者和接受者之间有丢包或者网关故障的时候,如果他们之间还存在可用的链路,他们之间的通信就可以继续,只有他们的物理连通链路都中断的时候,他们之间才无法通信。注意,对于业务层来说,在他们之间的物理链路断开之前,他们都应该不感知网络故障,不需要重新建立连接,也即可以正常通信。根据这一点要求,我们大概可以猜出,网络需要分层设计,这样才可以隔离网络中间故障问题,是传输层不感知。

    为了实现这个目的,网络可以有两种形式,一种是由网络中间设备实现可靠性,而这需要将状态信息复制多份,以便其中一个设备故障,其他设备可以正常工作;另一种是中间设备不做要求,两端设备负责维护状态信息,而这种方法被作者称之为fate-sharing,可以译成“命运共享”。互联网设计者采用了后一种设计,原因有两个:一是因为这种方式可以提供任意节点故障的保护;二是因为相对于状态复制的方法,它更容易实现。

    其实想一想,MPLS技术就是一种状态复制实现。MPLS状态由每个中间设备保存,所以如果实现保护,需要实现各种FRR功能,不可谓不复杂,而且还不一定100%覆盖。为此,LSP的端到端保护被使用,但是需要额外占用很多的节点和链路资源。SRV6因为可以指定显示路径,支持了100%场景的FRR,也是以牺牲简单性换来的。

    IP网络被设计成一种无连接的网络,正是为了将端到端的保护放到更上层的传输层TCP处理,而这正体现了TCP/IP在设计之初的高明之道。

    参考文档:
    该论文的1995年版本:http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.pdf
    https://www.cs.princeton.edu/~jrex/teaching/spring2005/reading/clark88.pdf
    fate-sharing的解释:
    https://www.cnblogs.com/uniquebby/p/12176047.html
    https://niem.es/2008/04/23/term-fate-sharing/

    <未完待续>

  • 相关阅读:
    2w字 + 40张图带你参透并发编程!
    完了,这个硬件成精了,它竟然绕过了 CPU...
    一文详解 Java 并发模型
    详解匈牙利算法与二分图匹配
    机器学习 | 详解GBDT在分类场景中的应用原理与公式推导
    Python | 浅谈并发锁与死锁问题
    LeetCode 91,点赞和反对五五开,这题是好是坏由你来评判
    LeetCode 90 | 经典递归问题,求出所有不重复的子集II
    【Azure DevOps系列】什么是Azure DevOps
    MSIL入门(四)之委托delegate
  • 原文地址:https://www.cnblogs.com/lionelgeng/p/15144040.html
Copyright © 2020-2023  润新知