Philosophy of the DARPA Internet Protocols” 论文翻译.pdf

DARPA 互联网协议簇的设计理念 David D. Clark Massachusetts Institute of Technology Laboratory for Computer Science Cambridge, Ma. 02139 （声明：本文内容是翻译 David D. Clark 于 Proceedings of ACM SIGCOMM 88, Aug. 1988 发表的论文： “The Design Philosophy of the DARPA Internet Protocols”，请将它用于学习等公益用途，而非盈利。谢谢！ 翻译：weiwenwewin。翻译不当之处，望指正。 ） 梗概 互联网协议簇互联网协议簇，TCP/IP，是在 15 年前被提出的。它被研发自美国国防部高级研究计划局美国国防部高级研究计划局 （DARPA） ，目前已被广泛应用于军方与商业系统中。尽管已经存在很多描述此协议簇的论 文与规范说明，我们有时仍感觉很难根据它们推想出，为何协议是它现在存在的这个样子。 比如，互联网协议是基于一个无连接传输模式无连接传输模式，或数据报文模式数据报文模式的服务。而这个动机如今已 被大大地误解了。 本文希望能够捕捉到一些初期的推理，正是它们塑造了互联网协议簇。 1. 介绍 在最近的 15 年中，美国国防部高级研究计划局美国国防部高级研究计划局一直在开发用于包交换网络包交换网络的协议簇，其中 包括互联网协议互联网协议（IP） ，与传输控制协议传输控制协议（TCP） ，它们现在是美国国防部美国国防部网络互连标准，并 且被广泛应用于商业网络环境中。在这个成果中产生的想法，也已影响了其他的协议簇，特 别是 ISO 无连接传输模式构型的协议。 尽管这个美国国防部协议簇的详细信息已被完全普遍地公开， 想要确定如此构思与设计的动 机和原因仍有些困难。 事实上，从最初的提议，到如今的标准，它的设计理念已经逐步进化演变了相当多。例如数 据报文的想法，或无连接传输服务，在第一版论文中并没有作为重点得到特别的强调，而它 们当今已是协议中最典型最突出的特征。另一个例子是将结构分层为 IP 层与 TCP 层。现在 看来这是设计的基础，但它并未出现于最初想法中。所有这些在互联网设计的转变，都是通 过不断地重复实现与测试过程产生的，直至最终标准的确定。 互联网结构仍在发展。有时一个新的扩展会挑战传统的设计法则。但无论如何，对设计发展 历史的了解，使我们对如今设计扩展产生的来龙去脉，有必要的知晓。ISO 的无连接配置协 议簇，已被互联网发展的历史染上传奇色彩。所以，对于互联网设计理念的理解，或许会对 与 ISO 打交道的人们有益。 2. 基本目标 DARPA 互联网架构的首要目标是发展一个有效的技术， 用来对现有的互相连通的网络进行多 样而充分的利用。一些更详细的阐述会有助于弄清这个目标的具体含义。 互联网的组成部分是网络， 它们被连通起来以提供一些更大的服务。 原本的打算是将原来的 ARPANET 与 ARPA 分组无线网络联通，目的是使分组无线网络上的用户们可以访问 ARPANET 上的大型服务机器。 当时已经推断将会有其他种类的网络联通进来， 尽管那时连局域网还没 有出现。 将现有的网络联通是一个选择， 另一个选择是设计一个统一标准的系统， 使它包容多种不同 的传输媒介，这将组成一个多媒体网络。尽管这个方案可能提供了更高等级的集成综合，并 会因此拥有更好的表现， 但人们仍觉得将已存在的网络结构包含进互联网是必要的， 如果互 联网想要有实际意义上的作用的话。更进一步，网络范围描绘出控制的管理边界，因此这个 计划的雄心是能够处理这个问题：将分离管理的实体们整合为一个实用的公共的设施。 为实现多路复用而选用的技术是分组交换技术。其他供选方案，如线路交换，是本可以被考 虑的，但是那些被支持的应用程序，比如远程登录，原本就使用分组交换规范提供的服务， 而且那些即将被整合为一体的网络， 本身就是分组交换网络。 分组交换就这样被采纳为互联 网结构的基础组成部分。 基本目标的最后一个方面是对于这些网络互连的具体技术的推断。 因为， 存储并转发分组交 换技术，正如在先前的 DARPA 工程即 ARPANET 之中已表现出的那样，可以被很好地理解， 最上层的设想是，网络们会被联通于互联网分组交换层，即被称作网关。 从这些假定出发，即可得出互联网的基本构造：一个分组交换通讯设施，在它内部，许多可 区分的网络， 通过被称作网关的通讯处理机连接在一起， 网关实现存储并转发分组交换算法。 3. 次级目标 在前一段首要目标的叙述中包含了一个词“有效的” ，而没有给出任何定义来说明一个有效 的网络互连应达到何种标准。 下面的列表概述了一组更详细的目标， 它们被制定用于互联网 结构。 1. 互联网通讯必须继续进行，即使在失去网络与网关的情况下。 2. 互联网必须支持多种类的通讯服务。 3. 互联网结构必须可包容多种网络。 4. 互联网结构必须允许分布式资源管理。 5. 互联网结构必须是划算的。 6. 互联网结构必须允许主机连接，而且代价要小。 7. 互联网结构中使用的资源必须是可解释，有说明的。 这一系列目标也许看来不过是一个清单， 列出了所有网络理想的特性。 非常重要的一点是要 理解这些目标是按其重要性排列的， 如果顺序有些变化， 导致产生的将是一个完全不同的网 络架构。比如，由于这个网络的设计目标是运行在军事环境中，这意味着有可能是在敌方领 域中，存活能力被放在首要目标的位置，而把可说明性作为最后考虑的目标。在战时，一个 士兵不会过于关心资源的详细说明， 他更急于查阅任何可使用的资源， 并使用某种操作方式 迅速配置部署它们。 尽管互联网的架构中留心了解释性， 这个问题在设计的早期仅仅受到很 微小的考虑，直到如今才被重视。而一个主要为商业使用的架构，则会完全将这些目标的顺 序颠倒。 同样的，结构要划算这个目标毫无疑问会在清单上，但是会次于一些其他目标，比如分布式 管理，或者广泛支持多种网络。其他协议簇，包括一些更普及的用于商业的架构，已经被充 分优化为一种特别的网络， 例如使用中速电话线构成的长距离存储转发网络， 为这个环境实 现了一个很划算的解决方案。 而如果使用其他类型的网络比如局域网来实现， 就会有些糟糕。 读者应仔细思考上述的目标清单，要认识到，这并不是一个“母亲般的关爱”那样的单子， 而是一组严格根据优先级排列的指标，它们完全决定了在互联网架构内的设计策略。 4. 面对故障时的存活能力 清单上最重要的目标是，互联网应该继续提供通讯服务，即使在网络与网关出现故障时。特 别的，具体的，这个目标的意义可以解释为，如果两个实体正在通过互联网进行通讯，这时 某个故障导致互联网被临时中断，之后它重新配置，以重新建立服务，这时那两个实体之间 的通讯应该有能够继续， 而不会不得不重建连接或者重新设定他们会话的高层状态， 更加具 体的，在传输层的服务接口处，此种架构没有提供与传输服务客户端通讯的设备，这导致消 息发送者与接受者之间的同步可能已经丢失。此种架构的一个假设是，同步永远不会丢失， 除非不存在任何一条原本可以取得任何种类通讯的物理通路。换句话说，在传输顶层，只存 在一种故障，就是完完全全地分割开。这个结构的目的是完全掩盖住任何瞬时的故障。 为了实现这个目标，描述正在进行会话的状态信息必须被保护好。状态信息的具体的例子， 如被传送的数据包的数目，已被确认的数据包数目，或是未到达的流控制许可数目。如果网 络结构中的下层失去了这些信息， 它们将无法分辨是否已有数据丢失， 那么应用层就不得不 面对失去同步这个问题。 此种结构要确保这种破坏不出现， 也就是说那些状态信息必须被保 护好不致丢失。 在某些网络结构中，状态被保存在网络中间的分组交换节点中。这样，为了保护状态信息不 丢失，信息必须被备份，因为备份本身的分散特性，用来确保备份健壮性的算法自身就很难 构造。鲜有分布式保存状态信息的网络，提供任何种类的应对故障的保护机制。结构的另一 个可选择的方案是， 在网络的末端获取并收集这些信息， 这实际上是在利用网络提供的服务。 我把这种手段称为可信任的“命运共担” （一条绳上的蚂蚱？） 。命运共担模型的内容是，如 果实体本身被丢失了，那么失去与一个实体相关的状态信息是可忍受的。特别的，关于传输 层同步的信息被储存在主机中，主机连接在网络上并且使用网络的通讯服务。 与信息备份相较，命运共担有两个重大优点。一是它能够防护任何数目的中间媒介故障，然 而信息备份仅能应付一定数目的故障（少于备份信息的份数） 。二是，命运共担比信息备份 容易建造得多。 命运共担有很高存活能力的同时带来两个后果。首先，中间的分组交换节点，亦称网关，不 能保有任何正在进行的连接的基本状态信息。相反，它们是无状态的分组交换机。这一类网 络设计也被称为“数据报”网络。其次，与确保数据可靠送达的网络架构相比，主机被赋予 了更多的信任。如果贮存于主机的，用来维持秩序并且管理数据的算法出现故障，那么那台 机器上的应用将无法运行。 诚然，存活能力是清单上的第一个目标，但它仍要次于联通现有的网络这个顶级目标。或许 某个具体的多媒体网络设计中可以给出一个存活能力更强的技术。 例如， 互联网对于网络报 告自己出现故障的能力做出很低的估计。 这样， 互联网就被迫使用互联网层面的机制来检测 故障。这可能是一个更缓慢的，不很具体的错误检测。 5. 服务类型 互联网结构的第二个目标是它应该，在传输服务层，支持多种类型的服务。根据如速度，延 迟，可靠性等不同方面的需求，不同种类的服务被加以区分。传统类型的服务是数据的双向 可靠送达。这个服务，有时被称为“虚拟线路”服务，它适用于于如远程登录或文件传输之 类的应用。它是互联网架构中最先被提供的服务，使用的是传输控制协议传输控制协议（TCP） 。人们很早 就意识到，就连这个服务也有不同的变型，因为远程登录需要低延迟传输的服务，但对于带 宽要求不高，而文件传输不大担心延迟，却非常在意高吞吐率。TCP 在试图同时提供这两种 服务。 TCP 最初的概念是，它基本能够足以支持任何所需的服务类型。然而，随着所需服务类型全 部浮出水面，人们发现仅以一个协议，去为它们全体都提供支持，太困难了。 第一个超出 TCP 提供支持范围的服务的例子是 XNET，它是一个跨互联网的调试器。因为几 个理由，TCP 看来不适合为 XNET 提供传输。首先，一个调试器协议不应是可靠的。这个结 论也许看来奇怪，但是在有压力或出现故障的情况下（这可能正是需要一个调试器的时候） 要求可靠的通讯，会阻止一切通讯。如果能建立一个可以处理所有传输内容的服务，而不是 坚持每个字节都被状态良好地传送，那将会好得多。其次，如果 TCP 要基本足够应对范围广 阔的客户们，可以想象那会有些复杂。再次，在一个调试环境中期望为这些复杂的东西提供 服务，看来是错误的，因为调试环境中可能连在操作系统中应提供的服务都缺少（例如对计 时器的支持） 。所以 XNET 被设计为直接运行在，由互联网提供的数据报服务层。 另一个无法与 TCP 相适应的服务是数字化语音的实时传送， 此服务被需求用于支持电话会议 的命令与应用控制。在实时数字化语音（传送）中，最初级的需求不是服务的可靠，而是在 传送时令延迟最小化，让传输顺畅化。应用层将模拟信号的语音数字化，将得到的二进制数 字分包，并将数据包定期通过网络送出。这些数据包必须同样定期地抵达接受者，这样才能 被转换回模拟信号。如果数据包并未按期望的那样到达，就不可能实时重建出信号。通过对 于延迟波动控制观察得出的一个惊人结果是， 网络中产生延迟最严重的源头， 竟然是确保传 输可靠性的机制。一个典型的可靠传输协议对丢失一个数据包的应答是，请求重新传输，并 推迟传输任何后续的数据包， 直到丢失的数据包被重传。 之后它按顺序送出这个与之后剩余 的数据包。出现上述情况时产生的延迟，可能是循环网络传送时间的数倍之多，并可能完全 地破坏语音建立过程。相反，它很容易对付偶然的数据包丢失。失去的语音可以简单地被一 小段静音替代， 这在大多情况下并不损害语音对于听者的可理解性。 但如果的确造成了影响， 高层的修正可以派上用场，而且听者可以请求演讲者重述那段被损坏的片段。 因此，在互联网架构开发的极早时期，人们就肯定不止一种传输服务会被需求，并决定架构 必须准备好至少同时应付分别对可靠性，延迟，带宽有要求的传输。 这个目标导致 TCP 与 IP 的产生，它们最初仅仅是架构中的一个协议，后来被区分入两层。 TCP 提供了一类特别的服务，即可靠的顺序数据流，而 IP 试图提供一个基础构件，这个构件 是很多其他类型的服务无法提供的。 这个构件就是数据报文， 它同时已被采用于维持存活能 力。既然一个数据报文的送达以及它的可靠性未被保证，但是“尽力而为” ，使用数据报文 构造一个可靠的服务是可能的（通过在高层的确认与重传） ，或者一个以牺牲可靠性换得网 络底层的原始延迟特性的服务。用户数据报文协议用户数据报文协议（UDP）被创造出，以在应用层提供互联 网基本数据报文服务的接口。 此种架构并不希望假定下层网络自身能提供多种类型的服务， 因为这样就会违背使用现有网 络的初衷。 而实际上希望的情形是， 可以由基本的数据报文构件并使用主机与网关内部的算 法实现多种类型的服务。例如， （尽管这并未在大多数当前实现中被完成）下面所述做法是 可行的。 对于与某个延迟可控但是服务不可靠的服务相关的数据报文， 我们获得此数据报并 把它们放在传输队列的队首，除非它们的生命期大限已过，那么它们会被丢弃；而与可靠数 据流相关的数据包会被放置在队列后部， 但永远不会被丢弃， 无论它们已经待在网络里多久 了。 没有下层基础网络明确的支持， 而希望提供多种类型的服务， 这被证明实现起来比预想的要 困难。最严重的问题是，一心想要提供某种特定服务而设计出的网络，却不足够灵活来支持 其他服务。最普遍的，一个网络将会在这个假定下被设计，这个假定是，这个网络应该提供 可靠的服务，并将延迟纳入为可靠服务的一部分，无论这种可靠性是否被要求。例如 X.25 定义的接口属性，包含可靠的传送，并且这个属性无法去除。因此，尽管互联网在 X.25 网 络上成功运行， 但在此环境下它无法如希望的那样提供多种类型的服务。 其他的本身固有数 据报服务的网络，在所能提供的服务类型方面要灵活的多，不过这类的网络也要罕见得多， 特别是在长程网络长程网络环境中。 6. 网络的种类 对于互联网结构的成功起到非常重要作用的一点是， 它能够包容和利用相当广泛的类型的网 络技术，包括军事和商业设备。互联网结构在达到这个目标方面已经非常成功：它运行于广 泛类型的网络中，包括长程网络长程网络（如 ARPNET 自身与各种 X.25 网络） ，局域网络局域网络（以太网以太网， 环形网络环形网络等等） ，广播卫星网络广播卫星网络（DARPA 大西洋卫星网络大西洋卫星网络，以 64kb/s 运行，以及 DARPA 实实 验宽带卫星网络验宽带卫星网络，以 3mb/s 运行于美国） ，分组无线网络分组无线网络（DARPA 分组无线网络分组无线网络，还有一个 又业余无线电报员开发的实验性的英国分组无线网络） ，各种的串行连接，包括从 1200b/s 的异步连接异步连接，到 T1 连接，以及各种其他自组织自组织点对点点对点网络网络设备，包括计算机之间总线还有 由 IBM 的 HASP 等其他网络套件的更高层提供的传输服务。 互联网结构达到如此灵活性的方法是， 对于网络将会提供的功能做出最小化的一组假设。 基 本假定是网络能够传输数据包或者数据报文。数据包的大小必须合理，也许最小 100 字节， 并且被传输时要有适当而非苛刻要求的可靠性。这个网络必须有某种适当形式的寻址方式， 如果它不仅仅是简单的点对点连接。 存在一些明确未被网络的假定涉及的服务。 其中包括可靠的或顺序的传送， 网络层广播网络层广播或多多 播播（组播组播） ，传送数据包的优先级排列，对于多种类服务的支持，以及对于故障，速度或者 延迟的内部信息。如果这些服务已被需求，那么为了使一个网络与互联网相容，要么这个网 络必须直接提供这些服务， 要么网络的接口软件提供增强功能， 以在网络末端模拟这些服务。 这种解决方法无法令人满意， 因为对于每一个网络和每个网络的每一台主机， 这些服务将不 得不被重新设计，重新实现。而如果在传输层设计这些服务，例如通过 TCP 构建可靠传输， 则仅需要一次构建，而且仅需对每台主机做一次实现。在此基础上，对于一个新接入网络的 接口软件的实现通常会很简单。 7. 其他目标 到现在已经讨论了三个目标，它们对互联网架构设计产生了最深远影响。剩余的目标，因为 它们的重要性相对较低，也许实际上更少遇到，或未被很完整的设计过。允许对互联网分布 式管理的目标已经确实在某些方面遇到过。例如，互联网中并不是所有的网关，都被同一代 理管理着。在铺展的互联网中，存在一些不同的管理中心，每个中心运营全部网关的一个子 集， 而且， 存在着两层路由选择算法， 它们允许被运营于不同管理者的网关修改路由选择表， 尽管这些网关之间彼此互不信任， 而且各种各样的私有路由选择算法被应用于被单独统管的 网关中。类似的，管理网关的各个机构，不必恰恰是管理着网关所连接网络的机构。 另一个方面，如今关于互联网的一些最重大的问题，是缺少充足的用于分布式管理的工具， 特别是在路由选择方面。 在正在运行中的大互联网中， 路由判定应该相关于数据源的利用策 略。如今这仅能以很有限的方式实现，此方式需要手工设置路由选择表。这易于出错并且不 是充分强有力的。未来几年，互联网架构方面最重要的转变可能会是新一代工具的发展，这 种工具被用于在多方拥有管理权的环境中管理数据源。 显然，某一特定环境中，互联网架构不像（根据实际情况）量身定做结构的网络世界那样有 成本效益，那样能利用昂贵的通讯资源。比如互联网数据包的头部非常之长（标准头部长为 40 字节） ，而且如果被发送的是短数据包，开销显然很大。更糟糕的情况，当然就是单字符 的远程登录数据包， 它携带了 40 字节大小的头部， 和 1 字节的数据。 事实上， 任何协议簇， 都很难宣称，能够以较合理的功效完成这种信息交换。走另一个极端，文件传输产生的大型 数据包，携带着可能达到 1000 字节的数据，头部仅仅是 4%的开销。 另一个可能的低效率来源是对丢失数据包的重传。 因为互联网并不确保丢失的数据包会在网 络层被弥补上，从互联网的一端向另一端重传丢失的数据包将会是必要的。这意味着，被重 传的数据包可能要再次通过一些中介网络， 然而， 在网络层的恢复不会产生这样的重复传输。 上述的是一个在终端提供服务方面，在决策中权衡的例子。网络接口的代码变得简单得多， 但是整体效能潜在地降低了。然而，如果重传频率足够低（比如 1%） ，那么增加的代价是可 以忍受的。一般原则大致是，对于合并入互联网结构的网络，每一百个数据包中丢失其中一 个是很正常的，但是如果每十个就丢失一个，那么这个网络的可靠性就得增强了，如果必须 提供这类服务的话。 将一个主机接入互联网的代价或许要比在其他结构中要大， 因为对于所有提供被期望种类服 务的机制，比如提供确认与重传策略，必须在主机上而不是在网络中被实现。起初，对于对 协议实现不熟悉的程序员来说， 做这件事令人望而却步。 实现者试着将传输协议移植到前端 处理器，他们希望通过这种方式，使协议只需被实现一次，而不是对于每种类型的主机重新 实现。然而，这又依赖于发明一个主机与前端间的协议，这个协议的复杂程度被认为，几乎 与直接以原先的传输协议实现同样复杂。 随着对协议的经验认识的增加， 对于在主机内实现 协议簇的焦虑似乎减小了， 而且已经在相当广泛类型的机器上完成了实现， 包括个人电脑等 其他计算资源很有限的机器。 一个由主机常驻机制的应用引发的相关问题是， 对此机制拙劣的实现， 会同时伤害主机与网 络。这个问题被忍受了，因为最初的实验包含有限的主机实现，而且那些实现可以被管理。 然而，随着互联网的应用的增长，这个问题已经不时地显露出它的严重性。在这个方面，以 健壮性为目标，而产生的命运共担方法和主机常驻算法，会在主机举止不当时损害健壮性。 最后一个目标是可说明性。事实上，可说明性在 Cerf 与 Kahn 的第一篇论文中，被作为协议 与网关的一个重要功能讨论过。 但是目前， 互联网结构中几乎不存在对数据包流进行说明的 工具。这个问题直到如今才被意识到，此时互联网结构包含的范围已经被扩展，以能够容纳 非军方用户，这些用户对于知晓与监控互联网中资源的使用，是非常在意的。 8. 架构与实现 先前的论述清楚地提到， 互联网架构的一个目标是提供有相当大灵活性的服务。 不同的传输 协议被应用于提供不同类别的服务，而且不同的网络可以被容纳进互联网。换句话说，此结 构尽力避免限制互联网可以被设计并提供的服务的范围。 这反过来意味着， 想要知晓互联网 的某种特定实现所能提供的服务， 我们应关注的不是它的结构， 而是在那些主机与网关中软 件的具体设计，还有已经被包括的那些网络。我会使用“具体具体实现实现”这个词来描述一组特定 的，已经在互联网结构的环境中被连接起来的，网络，网关，和主机。具体实现可以根据它 提供的服务量级的大小区分。具体实现可以使用 1200b/s 的电话线与速度仅略大于 1mb/s 的网络构造，很明显，对这些具体实现的吞吐率的预期也有不同的数量级。相似的，某些互 联网具体实现测得有数毫秒的延迟，而另一些则测出数秒的延迟。某些应用如实时语音，在 这两种实现上的运行效果完全不同。 某些互联网被设计的有许多网关和通路的冗余。 这些互 联网的存活性很强， 因为出故障后， 存留的资源可以被重新配置。 另一些互联网的具体实现， 为了节约成本， 将一些节点作为联通整个网络的唯一桥梁， 那么故障很有可能将互联网割裂 为两半。 互联网架构许可了这么多种的具体实现设计。 但是， 这留给具体实现的设计者一大堆工作去 做。此种架构开发的一个主要难题是，如何为具体实现的设计者提供指导，这个指导应能将 具体实现的构建与能够提供的服务种类联系起来。例如，一个设计者必须回答如下问题。如 果整个服务就是提供稳定的传输吞吐率， 那么下层网络一定要拥有哪类带宽？对于这个具体 实现中可能发生故障的某个模型，应将哪类冗余设计进具体实现中？ 大多已知的网络设计方案看来对回答这些问题没什么帮助。例如，协议校验器，有助于确认 协议满足规格。但是，这些工具无法处理性能问题。而是处理有限的多的，对于规格遵守的 逻辑正确性问题。的确，验证逻辑正确性的工具是有用的，无论在规划还是实现阶段。但是 他们无法为经常与性能相关的服务问题提供帮助。 实现中一个典型的经验是， 即使逻辑正确 性已经被验证， 可能造成性能退降于需求量级的设计缺陷也会被发现。 对于这个问题的研究 得出的结论是，困难不在于协议本身，而在于协议运行的操作系统中。如此情况下，则在架 构规范内部找到问题十分困难。然而，我们仍强烈地感觉到向实现者提供指导的需要。时至 今日，我们仍在与这个问题斗争着。 另一种设计工具是模拟器， 对于某个具体实现， 模拟器检验在各种负载情况下能够提供的服 务。没有人尝试过建立这种模拟器，它能够考虑进多种网关实现，主机实现，网络性能这些 在可能出现于互联网实现中的东西。 在此情况下， 对于大多数互联网实现的分析都是粗略的 估算。 对于互联网架构的目标结构的一个评论是， 粗略分析如果由一个有充分专业知识的人 来做，结果是足够的。互联网的设计者通常不大关心线路利用中谋求最后 5%的可能，相比 之下他们更关心，使用手中现有的资源，能否获得完成类型的服务。 架构与性能之间的关系是一个很有挑战性的问题。 互联网结构的设计者强烈地认为， 仅仅重 视逻辑正确性而忽视性能是一个重大错误。 但是， 他们在提升受到架构限制的任何方面的性 能的尝试中遇到了很大困难。 这些困难产生的原因有二， 首先这个架构的目标不是保证性能， 而是提供多样性，其次（也许更基本） ，因为看来不存在正式的工具来描述性能。 这个问题非常严重， 因为互联网计划的目标就是要产生规格文档并作为军方标准。 政府合同 有个众所周知的问题， 就是不能指望承包者在采购标准之外达到任何其他标准。 如果互联网 关心性能，那么，性能参数必须被强制写入采购规格中。制定受约束于性能参数的采购规格 是琐碎的事情，比如指明实现必须有能力每秒传输 1000 个数据包。然而，这种约束不能成 为架构的一部分，因此，直到要演示这些采购的性能时，才意识到这些性能要求必须被加入 到规格之中， 并且应该对它们详细地说明， 使得那些被提供的， 真正就是被要求类型的服务。 对于履行这个职责的人，我们不知如何提供架构方面的指导。 9. 数据报 互联网架构的基本特征是对数据报的使用， 数据报被看作通过下层网络传输的实体。 正如本 文所述，数据报在此架构中很重要的原因有几个。首先，它们消除了对于中间转换节点储存 连接状态的需要，这意味着互联网在故障后可以重新建立而不必关心从前的状态。其次，数 据报提供了一个基本构件，有了这个构件，很多种类的服务可以被实现。与通常提供固定类 型的服务的虚拟线路虚拟线路相反，数据报提供更原子化的服务，使用这个服务，末端可以视情况而 定被适当地连接起来，来提供适当的服务。再次，数据报描绘了对网络服务最小化的假定， 这使得很多种类型的网络， 可以被合并入不同的互联网实现中。 使用数据报是个极其成功的 决定，这个决定使得互联网成功地达到了它最重要的目标。 存在一个与数据报相关的，被误解的假定，它的内容是，数据报的动机是提供一个高层服务 的支持，而这个高层服务本质上等价于数据报。也就是说，提供数据报，被认为是因为应用 所需的传输服务就是数据报服务。实际上，很少有这种情况。互联网上的某些应用，比如简 单的日期查询服务或者姓名服务，使用基于不可靠数据报的方法实现。而其他大多数服务， 使用比简单的数据报更加复杂的传输模型。 一些服务希望增强可靠性， 另一些则希望舒缓和 减轻延迟， 但是几乎所有服务的期望都比数据报更加复杂。 数据报在这方面的任务是作为一 个构件，而不是自身成为一个服务，认识到这一点很重要。 10. TCP 在开发 TCP 的过程中出现了几个有趣的和有争议的设计决策， 并且 TCP 在成为合理的稳定的 标准之前， 经历了几个主要版本的变化。 一些设计决策， 如窗口管理和端口地址结构的性质， 在作为 TCP 协议手册一部分而发布的一系列的实现记录中被讨论过。 但是同时， 决策的动机 是缺失的。在本段中，我试图捕获一些形成 TCP 的早期原因。本段是必要的，但不完整的。 完整回顾 TCP 的历史本身就再需要一篇与本文长度类似的文章。 原始的 ARPANET 主机对主机协议提供了两种流控制，基于字节与基于数据包的。这看来过 于复杂，TCP 的设计者认为，仅一种形式的管理就足够。他们选择了基于字节的传输控制， 而不是基于数据包。TCP 中的流控制与确认因此基于字节数而不是数据包数。的确，在 TCP 中没有将数据分包的重要性。 这个决定产生于几个考虑，其中一些已变得关系不大，而其他的则比预期变得更重要。使用 字节的一个原因是想允许将控制信息插入到字节流中一系列空间中， 这样控制信息与数据能 够同时被认知。 对于一系列空间的利用被舍弃了， 来支持点对点自组织网络点对点自组织网络处理每条控制信 息。但是这个方法已经普遍应用，这造成实际应用中的复杂情况。 选择字节的第二个原因是， 想要允许 TCP 数据包在必要时被分割成更小的包， 来适合包尺寸 更小的网络。但是随着 IP 被从 TCP 分割出来，这个功能被移到了 IP 层，并且 IP 被强制发 展一种不同的包分割方法。 选择字节而不是数据包的第三个原因是，如果重传数据是必须的，希望允许在传送主机中， 将一些小数据包合并为一个大数据包。 当时尚不清楚这个便捷是否重要， 如今证明这是关键 的。像 UNIX 那样的系统有一个基于单字符的内部通讯模型，交流会经常发送很多仅包含 1 字节数据的数据包。 （也许从网络的视角来看，有人会认为这个做法很愚蠢，但对于交互式 远程登录，这的确是真实的，而且是必须的。 ）这种主机，被观察到产生数据包的洪流，这 些数据包仅仅包含 1 字节的数据， 这股洪流的到达速度远远超出一个缓慢的主机的处理速度。 结果就是丢包，重传。 如果重传的是仍是原先的数据包， 同样的问题会在每次重传过程中出现， 这会对性能有无法 忍受的冲击，所以这种运作方式不被接受。但是如果那些字节被归并入一个数据包，并进行 重传，那么重传将会有效得多，这种方式被允许在实际运作中。 另一个方面，既然对字节方式的认可能够造成这些问题，这个事实已经被认识到了。如果流 控制的基础是数据包，而不是字节，那么可能永远不会出现这种数据包洪流的问题。然而， 选择数据包层面的控制， 有一个效果， 就是在小数据包被发送时， 对吞吐率设置严格的上限。 如果接收方主机指定数据包的数目， 而不管每个包中的字节数， 那么它实际接收的数据量变 化范围可达 1000 倍，这取决于发送方主机像一个数据包中装入 1 字节还是 1000 字节。 回顾过去，正确的设计决策可能应是这样的，TCP 提供多种服务的有效支持，其中必须既包 括数据包类型的，也包括字节类型的，正如原先的 ARPANET 协议那样。 另一个与字节流相关的设计策略是信尾标志位信尾标志位，亦称 EOL。现在已经被推进标志位推进标志位或称 PSH 取代，从协议中消失，EOL 的原先构想是，将字节流分割装入记录记录，具体实现是将分离的记 录中的数据放入分离的数据包中，而这与在重传时合并数据包的想法不相匹配。所以 EOL 的语义被转换为较弱的形式，内容仅仅是，流中的数据到目前为止，是一个或多个完整的应 用层单元，它们会引起 TCP 或者网络中缓存的一次冲刷冲刷。措辞之所以是“一个或多个”而不 是“就一个” ，是因为可能会合并起几个单元，来实现通过重组压缩数据的目标。但是较弱 的语义意味着各样的应用不得不建立点对点自组织网络机制， 以在数据流的顶部清楚地说明 记录。 在 EOL 语义的演化过程中，曾有过一个不为人知的中间样式，它引发了激烈的争论。取决 于主机的缓冲策略，在一个不大可能发生的情况下，TCP 的字节流模型可能导致很大问题。 考虑一台主机，它的输入数据被装入一组固定大小的缓存中，每个缓存在被装满或收到 EOL 时返回给用户。现在想象这个情况，数据包的到达是无序的，它的无序性超出了当前缓存的 能力。再进一步考虑，在接收这些无序的数据包后，一个包含 EO