系统设计的端到端原则

本文提出了一个旨在帮助指导设计分布式计算系统各模块功能的原则，称之为端到端原则。该原则表明，考虑到在底层提供功能的成本，这些实现在系统底层的功能可能是多余的或没有提供什么价值。本文讨论的例子包括比特错误恢复、基于加密的安全、重复信息抑制、系统崩溃恢复以及交付确认，性能是当前在底层支持这些功能的唯一理由。

简介

定义功能之间的适当界限也许是系统设计师的主要活动，为功能实现选择合适位置的指导原则是系统设计者最重要的工具之一。本文讨论的这组原则已经用了很多年，但既没有被明确识别，也没有有力的论证。然而，数据通信网络作为计算机系统的组成部分的出现，使该原则的论点更加鲜明，其适用情况和理由更加明显。本文明确阐述了这一原则，以便研究其性质，看看到底有多普遍。该原则诉诸于应用需求，并提供了在分层系统中在上层实现功能的理由，使其更接近使用该功能的应用。接下来我们首先考虑这一原则的通信网络版本。

在一个包括通信的系统中，通常在通信子系统周围定义模块边界，并在其和系统其他部分之间定义牢固的接口。这么做的时候，会发现一个功能列表，其中每个功能都可能以几种方式中的任何一种来实现: 由通信子系统实现，由其调用者实现，联合实现，或者也许这个功能是多余的，又或者每个人都做自己的版本。在考虑不同选择时，应用需求为一类原则提供了基础，其内容如下:

相关功能只有站在通信系统终端的应用知识的帮助下才能完整正确的实施。因此，提供该功能作为通信系统本身的特征是不可能的。(有时，通信系统提供的不完整版本的功能可能有用，可以提高性能）。

我们将这种反对在底层实现功能的原则称为"端到端原则"，下面几节将详细研究该原则。首先介绍一个使用该原则的典型案例研究(可靠数据传输)，然后展示同一论点可以应用于哪些功能的范围。就数据通信系统而言，这个范围包括加密、重复信息检测、信息排序、保证信息交付、检测主机崩溃和送达保证。在更广泛的背景下，该原则似乎适用于计算机操作系统的许多其他功能，包括文件系统。然而，为了使研究跟容易，我们只考虑更具体的数据通信背景。

端到端考量

考虑"可靠文件传输"问题。文件通过文件系统存储在计算机A的磁盘存储器中，主机A通过数据通信网络与主机B相连，后者也有文件系统和磁盘存储器，目标是将文件无损的从主机A的存储空间转移到主机B的存储空间。在这种情况下，应用程序是文件传输程序，一部分在主机A运行，一部分在主机B运行。为了讨论这个过程中对文件完整性的可能威胁，我们假设涉及以下具体步骤:

在主机A上，文件传输程序调用文件系统从磁盘上读取文件，文件驻留在若干个轨道上，文件系统以独立于磁盘格式的固定大小的块将其传递给文件传输程序。

同样在主机A上，文件传输程序要求数据通信系统使用某种通信协议传输文件，该协议将数据分割成包，数据包大小通常与文件块大小和磁盘轨道大小不同。

数据通信网将数据包从计算机A传送到计算机B。

在主机B上，数据通信程序将数据包从数据通信协议中取出来，并将所含数据交给文件传输应用程序的第二部分，即在主机B内操作的部分。

在主机B上，文件传输程序要求文件系统将接收到的数据写到主机B的磁盘上。

基于该模型所涉及的步骤，细心的设计者可能会关注以下一些事务威胁:

该文件虽然最初正确写入到主机A的磁盘上，但由于由于磁盘存储系统中的硬件故障，现在读取可能包含不正确的数据。

文件系统、文件传输程序或数据通信系统可能在主机A或主机B上缓冲和复制文件数据时出错。

硬件处理器或其本地内存在主机A或主机B进行缓冲和复制时可能会出现短暂错误。

通信系统可能会丢失或改变包中的位，或者丢失整个包，或者多次传送某个包。

任何一个主机在执行未知数量(可能是全部)的事务后，都可能在事务执行的中途崩溃。

那么，一个可靠文件传输应用程序将如何应对这一系列威胁？一种方法可能是使用重复拷贝、超时和重试、仔细定位错误检测的冗余、崩溃恢复等来强化每个步骤，目标是将单独威胁的概率降低到一个可接受的小概率。不幸的是，系统对抗第二个威胁需要编写正确的程序，这项任务相当困难，而且并非所有必须考虑的程序都是由文件传输应用的开发者编写的。如果进一步假设所有这些威胁的概率相对较低，低到允许系统完成有用的工作，那么非要采取把所有事情做三遍这样的蛮力反制措施就显得不太经济了。

另一种方法可被称为"端到端检查和重试"。假设作为应对第一种威胁的辅助手段，每个文件都存储一个校验和，该校验和具有足够的冗余度，可以将文件中未被发现的错误的机会减少到一个可接受的概率。然后，作为最后的附加步骤，主机B中的文件传输应用程序将文件副本从磁盘存储系统中读回内存，重新计算校验和，并将此值送回主机A，在那里与原始文件校验和进行比较。只有当两个校验和一致时，文件传输应用程序才会宣布该事务已提交。如果比较失败，则说明出了问题，可以尝试重试。

如果故障真的相当罕见，这种技术通常会在第一次尝试时发挥作用，偶尔可能需要第二次甚至第三次尝试。人们可能会认为在同一个文件传输尝试中出现两次或更多故障，表明系统的某些部分需要修复。

现在我们考虑一个常见建议，即通信系统在内部提供可靠数据传输保证。通信系统可以通过提供可选择的冗余来实现，例如数据包校验、序列号检查和内部重试机制等。在大部分情况下，未检测到的比特错误的概率可以减少到理想水平。问题是，通信系统方面的这种尝试是否对可靠文件传输应用有帮助。

答案是，第四种威胁可能已经被消除了，但可靠文件传输应用程序仍然必须对抗其余的威胁，所以仍应根据文件的端到端校验提供重试。而如果这样做了，在通信系统中为提供可靠数据传输保证所花费的额外努力只是减少了文件传输应用的重试频率，对结果的必然性或正确性没有影响，因为无论数据传输系统是否特别可靠，端到端校验和重试都能保证文件的正确传输。

因此，结论是: 为了实现可靠文件传输，执行传输的应用程序必须提供针对文件传输的、端到端的可靠性保证，在这种情况下，要有检测故障的校验和以及重试/提交计划。对于数据通信系统来说，不遗余力的做到特别可靠，并不能减少应用程序确保可靠性的负担。

一个过于真实的例子

最近MIT出现了一个有趣的例子，说明人们可能遇到的陷阱。一个网络系统涉及几个由网关连接的本地网络，从一个网关到下一个网关的每一跳都使用了数据包校验，其假设是对正确通信的主要威胁是传输过程中的比特损坏。应用开发者知道这种校验，认为网络提供了可靠的传输，而没有意识到传输的数据在存储在每个网关时是不受保护的。一台网关计算机出现了某个瞬时错误，当把数据从输入缓冲区复制到输出缓冲区时，一个字节对被交换了，其频率大约为每百万字节中有一个这样的交换。在一段时间内，一个操作系统的许多源文件反复通过有缺陷的网关传输。其中一些源文件被字节交换破坏了，文件所有者被迫进行最终的端到端错误检查，即与旧文件进行手工比较和纠正。

性能方面

然而，如果得出结论说较低层级不应该在可靠性方面发挥任何作用，那就太简单了。考虑一个不太可靠的网络，每发送一百条信息就会丢掉一条，那么上述简单策略(即传输文件，然后检查文件是否正确到达)随着文件长度的增加，表现会更差。文件的所有数据包正确到达的概率随着文件长度的增加而呈指数级下降，因此传输文件的预期时间随着文件长度的增加而呈指数级增长。显然，在较低层级上做出一些努力来提高网络可靠性，可以对应用性能产生重大影响。但是，这里的关键思想是，较低层级不需要提供"完美"的可靠性。

因此，在数据通信系统内投入可靠性措施的工作量被认为是基于性能的工程权衡，而不是对正确性的要求。请注意，性能在这里有几个方面。如果通信系统太不可靠，文件传输应用的性能就会受到影响，因为端到端校验失败后要经常重试。如果通信系统用内部可靠性措施来加强，这些措施也有性能成本，其形式是冗余数据所损失的带宽，以及在传送数据之前等待内部一致性检查所增加的延迟。如果考虑到无论通信系统变得多么可靠，文件传输应用的端到端检查仍然必须实施，那么就没有理由在这个方向上走得太远。适当"权衡"需要仔细思考，例如可以从设计通信系统开始，以提供很少的成本和工程努力所带来的可靠性，然后评估其错误水平，以确保与文件传输层面可接受的重试频率一致。在应用层以下的任何一点上，争取实现可以忽略不计的错误率可能并不重要。

基于性能来证明将功能放在低级子系统中的合理性，必须谨慎行事。有时，通过对问题的彻底研究，在高层级上也可以实现同样或更好的性能提升。如果在低级子系统中执行某个功能，只需对已经包含在低级子系统中的机器进行最小的扰动，那么在低级子系统中执行这个功能可能更有效率，但相反的情况也会发生，也就是说，在低级子系统中执行这个功能可能会花费更多。原因有两个，首先，由于低级子系统是许多应用所共有的，那些不需要该功能的应用无论如何都会为其付出代价。第二，低级子系统可能没有高层级的信息，所以无法有效完成工作。

性能权衡通常相当复杂。再次考虑在不可靠网络上进行可靠文件传输的问题，提高数据包可靠性的技术通常是某种带有重试机制的协议，并且对每个包进行错误检查，这种机制既可以在通信子系统中实现，也可以在可靠文件传输应用中实现。例如，可靠文件传输中的接收器可以定期计算迄今为止收到的文件部分的校验和，并将其传回给发送者，发送方可以重新传输任何错误部分。

端到端原则并没有告诉我们应该把早期检查放在哪里，任何一层都可以做这个性能增强的工作。将早期重试协议放在文件传输应用中可以简化通信子系统，但可能会增加总体成本，因为通信子系统是在应用之间共享的，现在每个应用都必须提供自己的可靠性增强机制。将早期重试协议放在通信子系统中可能更有效，因为可以在网络内部逐跳执行，减少纠正故障的延迟。同时，可能有些应用会发现自己实现增强的成本太高，但却没有选择余地。为了做出明智选择，需要大量和系统实现相关的信息。

其他端到端原则案例

送达保证

在低级子系统支持分布式应用，提供本质上必须在应用层实现的功能，可能是在浪费精力，这个基本论点适用于除可靠数据传输之外的各种功能。这个观点最古老也许也是最广为人知的案例是传输确认，数据通信网络可以很容易的将传递给接收者的每条信息所对应的确认返回给发送者。例如，ARPANET，每当传递一个信息，都会返回一个称为"请求下一个信息"(RFNM, Request For Next Message)[1]的包。尽管这种确认在网络中作为某种拥塞控制机制可能有用(早期的ARPANET会在收到RFNM之前拒绝接收来自同一个发送端的新消息)，但ARPANET的应用程序从来没有觉得该机制有多大用处，因为知道信息是否被送达目标主机并不十分重要，应用程序真正想知道的是目标主机是否对消息进行了处理，在消息送达后但在被处理之前可能会发生各种问题，真正需要的确认是端到端的确认，这只能由目标应用发起，告诉发送端"我完成了"，或者"我没做"。

另一个获得即时确认的策略是使目标主机足够完善，当它收到消息时，同时肩负起保证消息被目标应用所处理的责任，这种方法可以消除某些(但不是所有)应用对端到端确认的需求。对于那些要求目标主机完成的处理只有在其他主机完成类似处理后才能进行的应用，仍然需要端到端确认，这种应用需要两阶段提交协议[5,10,15]，这是一种更复杂的端到端确认机制。另外，如果目标应用可能会失败或拒绝进行要求的处理，可能结果是产生一个失败确认，那么仍然需要实现端到端确认机制。

数据安全传输

另一个可以应用端到端原则的领域是数据加密，有三点原因。首先，如果数据传输系统执行加密和解密，就必须相信它能安全的管理所需的加密密钥。其次，数据是透明的，因此，当数据进入目标节点并被传送到目标应用时，容易受到影响。最后，消息的真实性仍然必须由应用程序检查。如果应用程序执行端到端加密，就可以获得所需的认证检查，可以按照需求管理密钥，而且数据永远不会暴露在应用程序之外。

因此，为了满足应用需求，通信子系统没有必要对所有流量进行自动加密。然而，通信子系统对所有流量的自动加密可能是为了确保其他事情: 防止行为不端的用户或应用程序故意传输不应暴露的信息。所有数据在进入网络时自动加密是系统设计者用来确保信息不会泄漏到系统外的另一个防火墙。然而请注意，这与系统对用户进行验证从而保证对特定数据的访问权是不同的需求。这种网络级加密可以相当简单，所有主机都可以用相同的密钥，并经常改变密钥。没有用户级密钥，从而简化了密钥管理问题。该技术与应用级认证及加密是互补的，两种机制都不能完全满足所有需求。

重复消息抑制

一个更复杂的场景是重复信息的抑制。某些通信网络被设计为消息或消息的一部分可能会被传递两次，这通常是由于网络内的超时触发故障检测和重试机制的结果。网络可以提供监控和抑制此类重复消息的能力，或者只是简单的传递这些消息。人们可能会想到，应用程序会发现处理这种可能会传递两次相同消息的网络是非常麻烦的事情。这的确很麻烦，不幸的是，即使网络抑制了重复消息，应用程序本身也可能在自己的失败/重试程序中意外的产生重复请求。这些应用层的重复消息在通信系统看来是不同的消息，所以无法抑制。抑制必须由应用本身来完成，应用需要知道如何检测自己造成的重复消息。

一个必须在高层处理的重复抑制的常见例子是，当远程系统没有对用户操作做出相应，用户对此感到困惑时，会发起一次新的操作。另一个例子是，大多数通信应用涉及到应对多站点事务中某一端的系统崩溃的规定: 当崩溃的系统再次启动时，重新建立事务。不幸的是，对系统崩溃的可靠检测是有问题的，因为可能只是丢了一个包或确认消息被延迟了。如果是这样，重试的请求就是一个重复的请求，只有应用程序才可以发现。因此，端到端论点再次出现: 如果应用层无论如何都要有一个抑制重复的机制，该机制也可以抑制通信网络内部产生的任何重复，所以该功能不需要在底层实现，同样的基本推理也适用于可以被完全忽略的信息以及重复信息。

保证FIFO消息传递

确保消息以相同顺序发送通常是通信子系统的另一项功能，实现这种先进先出(FIFO)行为的机制保证了在同一虚拟链路上发送的消息的顺序。沿着独立的虚拟链路发送的消息，或通过通信子系统外的中间进程发送的消息，可能会以不同于发送顺序的顺序到达。分布式应用中，某个节点可以发起请求，在几个不同的目的地点发起某个操作，这就无法利用先进先出的排序特性来保证请求的操作以正确的顺序发生。相反，必须通过一个比通信子系统更高层的独立机制控制操作的顺序。

事务管理

现在，我们已经将端到端原则应用于SWALLOW分布式数据存储系统的构建中[15]，显著减少了开销。SWALLOW提供了被称为存储库的数据存储服务器，可用于远程存储和检索数据。访问存储库的数据通过向其发送消息来完成，该消息指定了要访问的对象、版本和访问类型(读/写)，如果是写访问，还要加上要写的值。底层消息通信并不抑制重复消息，因为: a)对象标识符加上版本信息足以检测重复的写入，b)重复的读请求消息的效果只是产生一个重复响应，调用方很容易监测并丢弃。因此可以极大简化低级别消息通信协议。

底层消息通信系统也不提供交付确认。写入请求的调用方需要的确认是数据被安全的存储，这种确认只能由SWALLOW系统的高层提供。对于读请求，交付确认是多余的，因为包含读取值的响应已经足够了。通过消除交付确认，传输的消息数量减少了一半，从而对主机负载和网络负载都产生了很大影响，提高了性能。这个思路也被用于开发远程访问磁盘记录的实验性协议[6]，减少低级协议中的路径长度对于保持远程磁盘访问的良好性能非常重要。

确定目标

使用端到端原则有时需要对应用需求进行微妙的分析。例如，考虑一个承载分组语音连接(即数字电话会话)的计算机通信网络，对于那些传输语音包的连接，端到端原则的一个适用版本是: 如果通信系统的低层试图在比特级完成完美的通信，可能会在数据包交付中引入不受控制的延迟，例如，要求重传损坏的数据包，并在早期数据包被正确重传之前推迟交付。这种延迟对需要以恒定速率向接收方提供数据的语音应用来说是一种干扰。最好的办法是接受轻微损坏的数据包，甚至用静音、前一个数据包的复制品或噪音来取代。语音的自然冗余，加上高水平纠错程序，甚至其中一个对话着说一声"对不起，有人掉了一个杯子。请你再说一遍好吗？"(如果这种情况比较少的话)，都可以处理这种丢包的情况。

然而，这种强端到端原则适合于特定应用(两个人的实时对话)，而不是通用原则(例如一般语音)。如果考虑语音信息系统，在该系统中，语音包被存储在文件中，以便接收者以后收听，那么情况就不一样了。将数据包传送到存储介质中的短暂延迟并不具有特别的破坏性，因此在低层实现可靠性而引入延迟就是可接受的选项。更重要的是，在录音信息中获得尽可能多的准确性，实际上对应用是有帮助的，因为收件人在听录音的时候，不可能要求发件人重复某个句子。另一方面，在存储系统作为语音通信的接收端时，端到端原则确实适用于数据包排序和重复抑制。因此，端到端原则并不是绝对的，而是有助于应用和协议设计分析的准则，人们必须谨慎确定该原则适用于哪些场景。

历史，以及在其他系统领域的应用

本文引用的个别端到端案例并非原创，而是多年积累下来的。第一个案例中的有问题的中间传递确认案例是M.I.T.兼容时间共享系统(M.I.T. Compatible Time-Sharing System)的"wait"信息，每当用户输入一个命令时，系统就会在用户终端上打印出来[3]。(该信息在系统早期有一定价值，当时崩溃和通信故障非常频繁，中间确认提供了一些需要的保证，即一切都很好）。

与加密有关的端到端原则是由Branstad在1973年的一篇论文[2]中首次公开讨论的，估计军事安全界在那之前就进行了保密讨论。Diffie和Hellman[4]以及Kent[8]更深入地发展了这些观点，Needham和Schroeder[11]为此设计了改进的协议。

Gray[5]、Lampson和Sturgis[10]以及Reed[13]的两阶段提交协议使用了一种端到端的论证方式来证明其有效性。它们是端到端的协议，其正确性不依赖于通信系统内的可靠性、FIFO排序或重复抑制，任何可能的问题也可能由其他系统组件故障引入。Reed在关于去中心化原子操作的博士论文的第二章中明确提出了这个论点[14]。

端到端原则常被应用于系统的错误控制和纠错。例如，根据政策和法律要求，银行系统通常提供高级别审计程序，这些高层次审计程序不仅会发现高层次错误(如对错误的账户进行提款)，还会发现低层次的错误(如基础数据管理系统中的协调错误)。因此，相对于绝对消除这种协调错误的昂贵算法，可能某种只是该错误出现频率较低的低成本算法要更合适。在航空预订系统中，可以依靠代理人不断尝试，忍受系统崩溃和延迟，直到预订被确认或被拒绝。因此，保证未确认的预订请求在系统崩溃后仍然可以恢复的较低级别的恢复程序并不重要。在电话交换机中，可能导致单个呼叫掉线的故障被认为不值得提供明确的恢复，因为如果有必要，呼叫者可能会再次发起呼叫[7]。所有这些设计方法都是端到端原则被应用于自动恢复的例子。

网络协议界关于数据报、虚拟链路和无连接协议的辩论，大部分是关于端到端的争论。模块化论点推崇可靠的、FIFO排序的、重复抑制的数据流，认为这是一个容易构建的系统组件，该观点有利于虚拟链路。端到端论点声称，集中提供这些功能的每个版本对某些应用来说是没有意义的，这些应用会发现从数据报开始构建自己版本的功能会更容易。

20世纪50年代，系统分析员开发了一个非通信应用中的端到端原则版本，他们的职责包括在大量磁带卷上读写文件。屡次试图定义和实现"可靠的磁带子系统"的努力屡屡失败，因为不稳定的磁带机，不可靠的系统操作者，以及系统崩溃，都对任何狭隘的可靠性措施产生了影响。最终，每个应用都提供了自己的应用相关的检查和恢复策略，并假定低级别的错误检测机制最多只能减少高级别检查失败的频率，这已经成为标准做法。Multics文件备份系统[17]就是这样的例子，它建立在磁带子系统格式的基础上，提供了非常强大的错误检测和纠正功能，并以记录标签和每个文件的多个副本的形式提供了自己的错误控制。

用于支持精简指令集计算机(RISC)架构的论点与端到端观点类似。RISC的论点是，架构的客户将通过准确实现原始工具所需的指令来获得更好的性能。计算机设计者如果试图预测客户对某一深奥功能的要求，很可能无法100%满足目标需求，客户最终还是会重新实现该功能。(感谢M. Satyanarayanan提供了这个例子）。

Lampson在支持"开放操作系统"[9]的论点中使用了一个类似于端到端原则的论据作为理由。Lampson反对将任何功能作为下层模块的永久实现，而是认为该功能可以由下层模块提供，但应该总是可以被应用程序的特殊版本所替代。其理由是，对于你能想到的任何功能，至少有些应用程序会发现，为了正确满足自己的需求，必须自己实现这个功能。这种推理导致Lampson提出了"开放"系统，整个操作系统由一个库中的可替换例程组成，这种方法直到最近才在专用于单一应用的计算机中变得可行。可能的情况是，大规模操作系统中大量典型的功能确定的管理功能只是经济压力的产物，因为要求对昂贵的硬件进行复用，因此需要受控的管理功能。事实上，最近大多数系统"内核化"项目，部分的集中于将功能从低级系统中解耦[16,12]。尽管其灵感来自于不同的正确性论证，但副作用是产生了一个对应用程序来说更加灵活的操作系统，而这正是端到端原则的主旨所在。

结论

在选择通信子系统所提供的功能时，端到端原则是一种"奥卡姆剃刀"。因为通信子系统经常在使用该子系统的应用被知道之前就被指定，设计者可能会被诱惑通过承担更多功能来"帮助"用户，对端到端原则的认识可以帮助减少这种诱惑。

如今，谈论"分层"的通信协议很时髦，但没有明确标准来分配各层功能。这种分层对于提高模块化程度是可取的。端到端的争论可以被看作是组织这种分层系统的合理原则的一部分。我们希望本文的讨论有助于为"适当的"分层的争论增加实质内容。

审核编辑：郭婷