End-to-end arguments in system design翻译

设计系统中的端到端原则

这篇论文提出了分布式系统中各模块间功能定位的设计原理，称为端到端原则，与底层内置的功能相比，那些系统低层提供的功能也许是冗余的或是无价值的。例如在这篇论文中讨论过的位错误恢复、安全加密、复制消息抑制、系统崩溃恢复、交付确认等。底层机制支持一些想性能增强这样合理的功能。 1. 介绍

确定功能间的边界对于计算机系统设计者来说可能是基本的行为。对于系统设计者来说，最重要的工具是能够为功能定位决策提供指导的设计原则。这篇论文讨论了多年使用却并没有明确定义的一类功能定位观点。然而，随着数据通信网作为计算机系统组成成分的出现，通过其更清晰的应用环境和得以应用的原因形成了行功能布局。该论文明确表述了这一论点，以便观察其本质并理解它实际上是怎样的。这一观点吸引着应用需求，并为分层系统中的功能上移来靠近应用提供了基本原理，我们从通信网络版本开始思考。 在一个能够通信的系统中，通常会定义一个通信子系统的模块化边界和边界与系统之间的接口。当这样做时，很显然存在一个通过多种方式可能实现的功能列表：通过通信子系统或是通过他们的客户，作为一种冒险，或者是冗余的，每次运行它们各自的版本。之所以这样做，是因为应用需求为以下各类的观点提供的一个基础：

考虑中的功能能够完全并正确的由常识在通信系统的端程序的帮助下实现，所以，将提供不确定的功能作为通信系统的特点是不可能的。（有时一个不完整版本的通信系统提供的功能对于性能能够增强是有用的）

这一系列的原因反对低层功能实现的端到端论点，以下部分来详细考察端到端论点，首先通过一个使用端到端的例子来研究——可靠的数据传输是考虑中的功能——并且通过展示功能的范围使得相同的论点可以得以应用。在数据通信系统中，这个范围包括加密、重传信息检测、消息序列、有保证的消息传输、主机错误检测和交付回单。在广阔的环境下，这一论点被应用于很多其他功能的计算机操作系统，包括自身的文件系统。然而，如果我们首先考虑的是更为特定的通信环境，这种检测是容易的。 2. 仔细的文件传输

2.1 端到端看管

思考一下仔细的文件传输的问题。计算机A的硬盘的文件系统存储了一个文件，通过数据通信网络与计算机B相连，B也有相同的文件系统和硬盘存储。目标是无损坏的将文件从A的存储空间移动到B的存储空间上，应当记住的是损坏可能出现在传输路径上的任何一点。这种情况下的应用程序是一部分运行在A上一部分运行在B上的文件传输程序。为了讨论在传输过程中影响文件完整性可能存在的威胁，让我们假设会涉及到以下的几个步奏：

（1）主机A的文件传输程序请求文件系统从硬盘上的许多磁道上读取文件，然后以固定大小的块传输给文件传输程序。

（2）在主机A，文件传输程序询问数据通信系统所使用的传输协议，包括将数据分离为数据包。数据包的大小与文件块的大小和磁道大小完全不同。 （3）数据通信网将数据包从主机A移动到主机B.

（4）在主机B，数据通信程序移除数据通信协议中移除数据包并向主机B中的文件传输应用的第二部分提交包含的数据。

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

在包含这些步奏的模型下，以下这些事物的威胁是一个细心地设计者应当注意到的： （1）尽管文件最初正确的写到主机A的硬盘上，如果读出一些包含不正确的数据，也许是由于磁盘存储的硬件错误。

（2）文件系统的软件，文件传输程序，或者是数据传输系统可能在缓冲或复制文件数据的时候出现错误，可能是主机A也可能是主机B。

（3）硬件处理器或是它的本地存储可能在缓冲或复制的时候产生一个瞬时错误，可能是主机A也可能是主机B。

（4）通信系统可能丢弃或改变数据包中的一个比特或不仅一次的传递一个数据包。 （5）并不是所有的主句会在执行一些布确认的事件后破坏部分事件。

那么一个精细地文件传输系统应该如何应对这些威胁呢？一种可能的途径是在使用副本的时候加强每一步的超时和重传，仔细的为错误检测定位冗余，故障恢复等等。目标是减少每个个体威胁的可能性直到一个可以接受的不大的数值。不幸的是，威胁的系统计数器要求写正确的程序，这有些困难。当然，并不是所有的文件传输应用程序要求正确的写程序。我们做一个长远的假设，如果所有的威胁程度都相对较低—低到系统允许完成有用的工作—强力的决策，比如将每件事情做三次，这是不经济的。

另一种可能的途径是端到端确认和重传。假设这是作为应对威胁的一种帮助，在每个文件里存储一个校验和，有足够的冗余来减少文件中不可探测性错误的可能性到一个可接受和忽略的值。在把文件从A传输到B的文应用程序遵循这些基本的步奏。然后，最为一个最后的附加步奏，文件传输应用的一部分驻留在主机B，将传输的文件从磁盘存储系统拷贝到它自己的内存。重新计算校验和，然后将这个值发回给主机A，与原来的校验和进行比较。只有当两个校验和相同的情况下，文件传输应用才会宣称事件被提交。如果比较失败，会出错，并试图从一开始进行重传。

如果失败相对比较少，这种技术将会第一次尝试工作，偶尔的两三次重传是被允许的。有人可能会认为在一次文件传输中两次或者更多次的失败就意味着这个系统的某些部分需要维修了。

现在让我们想一下共同目标的有效性，那就是通信系统内部提供有保证的可靠的数据传输。它可能是通过包校验和的形式来实现这种保证的，例如选择性冗余、序列号确认、和内部重试机制。在足够的关注下，不可探测的比特错误有可能降低到令人满意的级别。但问题是这种尝试是否有助于部分通信系统对仔细的文件传输应用是有用的。

答案是这些威胁可能消除，但文件传输应用必须要回击剩余的威胁，所以他应该继续提供基于端到端文件校验和的重试。如果这样做了，那么通信系统为提供可靠数据传输延伸的额外尝试就是通过文件传输应用减少重传的频率。将致力于结果的正确性和必然性，而校验文件传输是通过端到端校验和重传来保证的，无论数据传输系统是否可靠。 因此，这个论点：为了实现可靠的文件传输，执行文件传输所指定传输的应用程序必须提供端到端可靠性的保证，在这种情况下，用校验和探测错误和重传交付计划。数据通信系统不采用这种方法提供可靠性，这样并不会减少应用程序保障可靠性的负担。 2.2一个过于现实的例子

近期麻省理工学院就遇到了这样一个有趣的例子。一个包含多个局域网的网络系统与使用每跳都是用校验和的网关连接在一起，假设在无差错传输中最主要的威胁是比特冲突。应用程序设计员意识到校验和，假设网络能提供可靠传输，在每个网关存储时没有意识到传输的数据是不被保护的。一个网关计算机产生了暂态误差：从输入到输出缓冲区拷贝数据时，一个字节对发生了互换，以每百万字节这样一个交换频率。在一定时间内，操作系统的许多资源文件在有缺陷的网关中被重复传输。一些这样的资源文件由于比特交换而损坏，他们的所有者被迫做最终的端到端的错误检验：手动的与旧列表比较与改正。

2.3性能部分

然而，简单的推断低层不应该参与在确保可靠性中。思考一下，一个网络多少有点不可

靠，每发送100个信息就会丢失一个。用简单的方法来解决，就是传输文件然后检查这个文件是否正确到达，像文件长度增加一样表现差劲。文件的所有数据包正确到达减少文件长度以指数形式增长的可能性存在，因此传输文件的期望时间随着文件长度也以指数增长。清楚的是，低层为提高网络可靠性所做的努力对应用程序的性能有很大的影响。但是关键点是低层不需要提供完美的可靠性。

因此，在数据通信系统中可靠性措施的付出的努力被视作为基于性能的工程交易，而不是对正确性的需求。在这里性能是多方面的备注。如果通信系统十分不可靠，文件传输应用性能将会受损坏，因为按序重传会跟随端到端校验的错误。如果通信系统添加了内部可靠性机制，这些机制也存在性能开销，以失去带宽的形式，在数据传输之前冗余数据增加延迟来等待内部一致性校验的完成。有小部分原因与这个方向相关，在认为无论通信系统多么可靠，文件传输应用的端到端校验一定要实现。合适的交易要求仔细的思考。例如，会以设计通信系统为开始，来提供伴随低开销和小工作量所产生的可靠性，然后在文件传输级别，评估漏检故障的级别来确保与可接受的重传频率保持一致。在应用层以下的任一点争取可忽略误差率可能不是很重要。

在低级的子系统中用性能来判断功能定位一定要很小心。有时，通过彻底的检查问题，可能会达到更高级别的性能加强。在低级执行这一功能可能会更有效，如果包括在低级子系统中的功能可以以最小的机械扰动执行。但相反的情况可能会发生—那就是，在低级执行这一功能会有更大的开销，原因有二，第一，低级子系统对一些有用来说是共同的，这些应用不需要功能为他们支付什么。第二，低级子系统并不像高级那样有很多信息，所以他们并不是那么有效率的工作。

常常，交易性能有些复杂，再想一下在不可靠网络中的文件传输。增加包可靠性通常的方法是重传协议的包错误检测。这种机制可以在通信子系统或是文件传输应用中被实现。例如，文件传输的接受者会定期检查文件的部分校验和所以会接受并返回给发送者。然后发送者会重新开始传输错误的部分。

端到端论点并没有告诉我们从哪里设置早期的检查，也没有指出哪一层可以做这种增强性能的工作，将早期的重传协议放置到文件传输应用中简化了通信系统但是却可能增加总成本，而通信系统有其他应用程序共享，每个应用程序必须提供自身的可靠性改进。将早期的重传协议放置到通信系统中可能会更加有效，他可能在逐跳的基础上在网络内部执行，以减少涉及到失败确认的延迟。同时有些应用程序发现改进的开销并不值得，但现在没有选择的余地。做出这个决定需要大量的关于系统实现的信息。

本文来源：https://www.bwwdw.com/article/vurt.html