目录

论文笔记——The Design Philosophy of the DARPA Internet Protocols


The Design Philosophy of the DARPA Internet Protocols

DARPA网络协议的设计哲学

论文概况

SIGCOMM ‘88: Symposium proceedings on Communications architectures and protocols

August 1988 Pages 106–114

自翻:https://github.com/leeshy-tech/PaperTranslate/blob/main/Design_philosophy_of_DARPA.md

摘要

Internet 协议套件 TCP/IP 于 15 年前(1973)首次提出。 它由国防高级研究计划局 (DARPA) 开发,并已广泛用于军事和商业系统。 虽然有描述协议如何工作的论文和规范,但有时很难从中推断出协议为何是现在的样子。 例如,Internet 协议基于无连接或数据报服务模式。 这样做的动机被大大误解了。 本文试图捕捉形成 Internet 协议的一些早期原因。

1 引言

在过去的 15 年中,美国国防部高级研究计划局一直在开发一套用于分组交换网络的协议。 这些协议,包括 Internet 协议 (IP) 和传输控制协议 (TCP),现在是美国国防部的互联网络标准,并在商业网络环境中广泛使用。 在这项工作中开发的想法也影响了其他协议套件,最重要的是 ISO 协议的无连接配置。

事实上,设计理念已经从最初的提案发展到目前的标准。 例如,数据报或无连接服务的概念在第一篇论文中并未得到特别强调,但已成为协议的定义特征。 另一个例子是将架构分层到 IP 和 TCP 层。 这似乎是设计的基础,但也不是最初提案的一部分。 互联网设计的这些变化是通过在标准制定之前发生的重复实施和测试模式而产生的。

互联网架构仍在不断发展。 有时新的扩展会挑战设计原则之一,但无论如何,对设计历史的理解为当前的设计扩展提供了必要的背景。 本文对互联网体系结构的最初目标进行了分类,并讨论了这些目标与协议的重要特征之间的关系。

2 基本目标

DARPA 互联网架构的最高目标是开发一种有效的技术,以复用现有的互连网络。 需要有一些适当的详细说明,来明确该目标的含义。

最初的目标是将原始 ARPANET 与 ARPA 分组无线电网络连接在一起,以便使分组无线电网络上的用户能够访问 ARPANET 上的大型服务机器。 当时假设会有其他类型的网络可以互连,尽管局域网尚未出现。互连现有网络的一种替代方法是设计一个统一的系统,该系统结合了各种不同的传输媒体,即多媒体网络。该项目的目标是解决将多个单独管理的实体整合到一个公共设施中的问题。

多路复用技术:分组交换。支持的应用程序(例如远程登录)自然由分组交换范式提供服务,并且将在该项目中集成在一起的网络是分组交换网络。 因此,分组交换被接受为 Internet 体系结构的基本组成部分。

互联网络技术:网络将通过称为网关的 Internet 数据包交换机层互连。

从这些假设中得出了互联网的基本结构:一种分组交换通信设施,其中许多可区分的网络使用称为网关的分组通信处理器连接在一起,网关实现存储和转发分组算法。

3 二层目标

以下列表总结了为 Internet 体系结构建立的一组更详细的目标:

  1. 尽管网络或网关丢失,互联网通信仍必须继续。
  2. 互联网必须支持多种通信服务。
  3. Internet 架构必须适应各种网络。
  4. Internet 架构必须允许对其资源进行分布式管理。
  5. 互联网架构必须具有成本效益。
  6. Internet 体系结构必须允许以较低的工作量连接主机。
  7. 互联网架构中使用的资源必须负责。

这些目标是按重要性顺序排列的,如果顺序改变,就会产生完全不同的网络架构。 例如,由于该网络旨在在军事环境中运行,这意味着可能存在敌对环境,因此将生存能力作为首要目标,将问责制作为最后目标。

上面的目标列表,并不是一个“母性”列表,而是一组优先级,它们强烈地影响了 Internet 架构中的设计决策。

4 面对失败时的生存能力

清单上最重要的目标是互联网应该继续提供通信服务,即使网络和网关出现故障。特别是,这个目标被解释为如果两个实体正在通过 Internet 进行通信,并且某些故障导致 Internet 暂时中断并重新配置以重建服务,那么通信的实体应该能够继续进行通信,而无需重新建立或重置他们对话的高级状态。更具体地说,在传输层的服务接口上,这种架构没有提供任何设施来与传输服务的客户端进行通信,即发送方和接收方之间的同步可能已经丢失。该架构中的一个假设是,除非没有可以实现任何类型通信的物理路径,否则同步永远不会丢失。

为了实现这一目标,描述正在进行的对话的状态信息必须受到保护。 状态信息的具体示例将是传输的数据包数量、确认的数据包数量或未完成的流控制权限的数量。 如果架构的较低层丢失了这些信息,他们将无法判断数据是否丢失,应用程序层将不得不应对同步的丢失。 该架构坚持不会发生这种中断,这意味着必须保护状态信息不丢失。

在某些网络架构中,此状态存储在网络的中间分组交换节点中。 在这种情况下,为了保护信息不丢失,必须对其进行复制。 由于复制的分布式特性,确保稳健复制的算法本身很难构建。它的替代方案是获取此信息并将其收集到网络的端点,即使用网络服务的实体处。将这种可靠性方法称为“命运共享”。

命运共享有两个重要的优势。首先,命运共享可以防止任何数量的中间故障。其次,命运共享更容易设计。

对于生存能力的命运共享方法有两个结果。首先,中间分组交换节点或网关不能有任何关于正在进行的连接的基本状态信息。 也就是说,它们是无状态分组交换机,被称为“数据报”网络。 其次,它对主机的信任度更高。 如果确保数据排序和确认的主机驻留算法失败,则该机器上的应用程序将无法运行。

尽管生存能力是列表中的首要目标,但它仍然次于顶级目标——现有网络互连。 单一的多媒体网络设计可能会产生一种更具生存能力的技术。 例如,互联网对网络报告故障的能力做出了非常微弱的假设。因此,互联网被迫使用网络级别的机制来检测网络故障,可能会出现速度较慢且不太具体的错误检测。

5 服务类型

互联网架构的第二个目标是它应该在传输服务级别支持多种类型的服务。 不同类型的服务通过对速度、延迟和可靠性等方面的不同要求来区分。传统的服务类型是双向可靠的数据传输。 该服务有时称为“虚拟电路”服务,适用于远程登录或文件传输等应用程序。 它是 Internet 架构中提供的第一个服务,使用传输控制协议 (TCP) 。很早就认识到即使是此服务也有多种变体,例如远程登录和文件传输,分别对延迟和带宽敏感。 TCP 试图提供这两种类型的服务。

TCP 的最初概念是它可以足够通用以支持任何需要的服务类型。 然而,随着所需服务的全部范围变得清晰,似乎很难将对所有这些服务的支持构建到一个协议中。

TCP 范围之外的服务的第一个示例是对跨 Internet 调试器 XNET 12 的支持。 另一个不适合 TCP 的服务是数字化语音的实时传送。在实时数字语音中,主要要求不是可靠性,而是最小化和平滑传输延迟。一个重要的发现是网络中最严重的延迟来源是可靠传输机制。典型的可靠传输协议通过请求重新传输,延迟所有后续数据包的传递,直到丢失的数据包被重新传输来响应丢失的数据包。然后它按顺序传递该数据包和所有剩余的数据包。发生这种情况时的延迟可能是网络往返传递时间的许多倍,并且可能会完全破坏语音重组算法。相比之下,处理偶尔丢失的数据包非常容易。丢失的语音可以简单地用短时间的沉默代替,这在大多数情况下不会影响听者对语音的可理解性。

因此,在 Internet 架构开发的相当早的时候,就决定需要多种传输服务,并且架构必须至少能够实现限制可靠性、延迟或带宽的传输。

这个目标导致 TCP 和 IP,原本是架构中的单一协议,被分成两层。 TCP 提供了一种特定类型的服务,即可靠数据传输,而 IP 提供一个基本的构建块,可以从中构建各种类型的服务。因此可以从数据报中构建可靠的服务(通过在更高级别上进行确认和重传),或另一种牺牲可靠性换取低延迟的服务。 于是 UDP(用户数据报协议)产生了。

该架构不希望底层网络本身支持多种类型的服务,因为这将违反使用现有网络的目标。 相反,它希望可以使用主机和网关内的算法从基本数据报构建块构建多种类型的服务。事实证明,在没有底层网络明确支持的情况下,提供多种类型的服务比最初希望的要困难得多。 最严重的问题是,为一种特定类型的服务设计的网络不够灵活,无法支持其他服务。

6 各种网络

互联网架构在实现这一目标方面非常成功;它在各种各样的网络上运行,包括长途网络、局域网、广播卫星网络,分组无线电网络,各种串行链路,以及各种其他自组织设施,包括计算机间总线和其他网络套件的更高层提供的传输服务,例如作为 IBM 的 HASP。

Internet 体系结构通过对网络将提供的功能做出最少的假设来实现这种灵活性。 基本假设是网络可以传输数据包或数据报。 数据包必须具有合理的大小,并且应该以合理但不完美的可靠性交付。 如果网络不仅仅是点对点链接,则网络必须具有某种合适的寻址形式。

有许多服务明确没有从网络中假设。这些包括可靠或有序的交付、网络级广播或多播、传输数据包的优先级排序、对多种服务的支持以及故障、速度或延迟的内部感知。如果需要这些服务,那么为了适应 Internet 中的网络,网络必须直接支持这些服务,或者网络接口软件提供增强功能以在网络端点模拟这些服务。人们认为这是一种不受欢迎的方法,因为必须为每个网络和每个网络的每个主机接口重新设计和重新实现这些服务。通过在传输过程中设计这些服务,例如通过 TCP 进行可靠交付,工程必须只完成一次,并且每个主机必须只完成一次实施。之后,新网络的接口软件的实现通常非常简单。

7 其他目标

到目前为止讨论的三个目标是对架构设计产生最深远影响的目标。其余的目标,因为它们的重要性较低,可能不太有效地实现,或者没有完全设计。允许对 Internet 进行分布式管理的目标在某些方面肯定已经实现。

另一方面,当今互联网的一些最重要的问题与缺乏足够的分布式管理工具有关,尤其是在路由领域。 在当前运营的大型互联网中,路由决策需要受到资源使用策略的约束。 今天,这只能以非常有限的方式完成,这需要手动设置路由表。 这很容易出错,同时也不够强大。 未来几年互联网架构中最重要的变化可能是开发新一代的多部门资源管理工具。

很明显,在某些情况下,Internet 架构在使用昂贵的通信资源方面的成本效益不如更量身定制的架构。 Internet 数据包的报头相当长(典型的报头为 40 字节),如果发送短数据包,这种开销是显而易见的。当然,更糟糕的情况是单字符远程登录数据包,它携带 40 字节的报头和 1 字节的数据。实际上,任何协议套件都很难声称这些交换以合理的效率进行。在另一个极端,用于文件传输的大数据包(可能包含 1,000 字节数据)的报头开销仅为 4%。

效率低下的另一个可能原因是丢失数据包的重传。由于 Internet 不坚持在网络级别恢复丢失的数据包,因此可能需要将丢失的数据包从 Internet 的一端重新传输到另一端。这意味着重新传输的数据包可能会再次穿过几个中间网络,而网络级别的恢复不会产生这种重复流量。如果重传率足够低(例如,1%),那么增量成本是可以容忍的。

将主机连接到 Internet 的成本可能略高于其他架构,因为提供所需服务类型的所有机制,例如确认和重传策略,都必须在主机中而不是在网络中实现。

使用主机驻留机制引起的一个相关问题是该机制的不良实施可能会损害网络以及主机。这个问题是可以容忍的,因为最初的实验涉及有限数量的可以控制的主机实现。然而,随着互联网使用的增长,这个问题偶尔会以严重的方式浮出水面。在这方面,鲁棒性目标导致命运共享方法导致主机驻留算法,如果主机行为不端,则会导致鲁棒性损失。

最后一个目标是问责制。事实上,Cerf 和 Kahn 在第一篇论文中将记账作为协议和网关的一项重要功能进行了讨论。然而,目前,互联网架构包含很少的工具来计算数据包流。这个问题现在才被研究,因为架构的范围正在扩大到包括非军事消费者,他们非常关心理解和监控互联网内资源的使用情况。

8 架构和实现

前面的讨论清楚地表明,互联网架构的目标之一是在所提供的服务中提供广泛的灵活性。可以使用不同的传输协议来提供不同类型的服务,并且可以合并不同的网络。该体系结构非常努力地不限制互联网可以提供的服务范围,这意味着要理解 Internet 可以提供的服务,不能看架构,而要看特定主机和网关内软件的实际工程,以及特定的已纳入的网络。

Internet 体系结构通过设计来容忍这种多样性的实现。 然而,它给特定实现的设计者留下了大量的工程工作要做。 这种架构开发的主要挑战之一是了解如何为实现的设计者提供指导,指导将实现的工程与将产生的服务类型联系起来。 大多数已知的网络设计辅助工具似乎对回答这类问题没有帮助。例如,协议验证器有助于确认协议符合规范。然而,这些工具几乎从不处理性能问题。一个典型的实施经验是,即使在证明了逻辑正确性之后,仍会发现可能导致性能下降一个数量级的设计错误。对这个问题的探索得出的结论是,困难通常不是出现在协议本身,而是出现在协议运行的操作系统上。在这种情况下,很难在架构规范的上下文中解决该问题。但是,我们仍然强烈认为有必要给予实施者指导。我们今天继续与这个问题作斗争。

架构性能之间的关系是一个极具挑战性的关系。 互联网架构的设计者非常强烈地认为,只关注逻辑正确性而忽视性能问题是一个严重的错误。 但是,他们在将架构内性能约束的任何方面形式化时遇到了很大的困难。 之所以出现这些困难,一方面是因为架构的目标不是限制性能,而是允许可变性,其次(也许更根本的是),因为似乎没有有用的正式工具来描述性能。

9 数据包

互联网的基本架构特征是使用数据报作为跨底层网络传输的实体。正如本文所建议的,数据报在架构中很重要有几个原因。首先,它们消除了对中间交换节点内连接状态的需求,这意味着互联网可以在发生故障后重建而无需考虑状态。其次,数据报提供了一个基本的构建块,通过它可以实现各种类型的服务。与通常意味着固定类型的服务的虚拟电路相比,数据报提供了更基本的服务,端点可以适当地组合这些服务来构建所需的服务类型。第三,数据报代表了最小的网络服务假设,它允许将各种各样的网络结合到各种互联网实现中。使用数据报的决定是一个非常成功的决定,它使互联网能够非常成功地实现其最重要的目标。

通常与数据报相关的一个错误假设是,数据报的动机是支持更高级别的服务,该服务本质上等同于数据报。 换句话说,有时建议提供数据报,因为应用程序需要的传输服务是数据报服务。 事实上,这种情况很少见。 虽然 Internet 中的某些应用程序(例如对日期服务器或名称服务器的简单查询)使用基于不可靠数据报的访问方法,但 Internet 中的大多数服务都希望使用比简单数据报更复杂的传输模型。 一些服务希望提高可靠性,一些希望平滑和缓冲延迟,但几乎所有的服务都期望比数据报更复杂。 重要的是要了解数据报在这方面的作用是作为构建块,而不是作为服务本身。

10 TCP

在 TCP 的开发过程中有几个有趣和有争议的设计决策,而且 TCP 本身在成为一个相当稳定的标准之前也经历了几个主要版本。在本节中,我试图捕捉一些 TCP 部分的早期原因。 本节必然是不完整的; 完整回顾 TCP 本身的历史需要另一篇如此篇幅的论文。

最初的 ARPANET 主机到主机协议提供了基于字节和数据包的流量控制。 这似乎过于复杂,TCP 的设计者认为只有一种监管形式就足够了。 选择是规范字节的传递,而不是数据包。 因此,TCP 中的流量控制和确认基于字节数而不是数据包数。 实际上,在 TCP 中,数据的打包没有意义。

回想起来,正确的设计决策可能是,如果 TCP 要提供对各种服务的有效支持,则必须对数据包和字节进行规范,就像在原始 ARPANET 协议中所做的那样。

11 结论

就其优先事项而言,互联网架构非常成功。 这些协议广泛用于商业和军事环境,并催生了许多类似的架构。 同时,它的成功表明,在某些情况下,设计师的优先级与实际用户的需求不匹配。 需要更加关注分管地区的会计、资源管理和运营等事项。

虽然数据报在解决 Internet 最重要的目标方面发挥了很好的作用,但当我们试图解决一些在优先级列表中更靠后的目标时,它就没有那么好用了。 例如,资源管理和问责制的目标已被证明在数据报的背景下难以实现。 正如上一节所讨论的,大多数数据报是从源到目的地的某些数据包序列的一部分,而不是应用程序级别的孤立单元。 但是,网关不能直接看到这个序列的存在,因为它被迫孤立地处理每个数据包。 因此,必须对每个数据包分别进行资源管理决策或计费。 将数据报模型强加于 Internet 层已经剥夺了该层可用于实现这些目标的重要信息来源。

这表明下一代架构可能有比数据报更好的构建块。这个构建块的一般特征是它可以识别从源到目的地的一系列数据包,而无需假设该服务具有任何特定类型的服务。我用“流”这个词来描述这个构建块。网关必须具有流状态以记住通过它们的流的性质,但状态信息对于维护与流相关联的所需服务类型并不重要。相反,该类型的服务将由端点强制执行,端点将定期发送消息以确保正确类型的服务与流相关联。这样,与流相关的状态信息可能会在崩溃中丢失,而不会永久中断正在使用的服务功能。我将这个概念称为“软状态”,它很可能使我们能够实现生存性和灵活性的主要目标,同时更好地处理资源管理和问责制问题。探索替代构建块构成了 DARPA 互联网计划的当前研究方向之一。