End-to-End Argument 一种系统设计指南

Twilight-pending

已于 2024-08-01 11:50:13 修改

阅读量720

点赞数 15

分类专栏：知识点分布式系统计算机网络文章标签：系统架构信息与通信团队开发

于 2024-08-01 11:49:32 首次发布

本文链接：https://blog.csdn.net/weixin_45770491/article/details/140843864

版权

知识点同时被 3 个专栏收录

8 篇文章 0 订阅

订阅专栏

计算机网络

6 篇文章 0 订阅

订阅专栏

分布式系统

5 篇文章 0 订阅

订阅专栏

End-to-End Argument

一些说明
End-to-End Argument 端到端论证
参考

J. H. Saltzer, D. P. Reed, and D. D. Clark. 1984. End-to-end arguments in system design. ACM Transactions on Computer Systems 2, 4 (Nov. 1984), 277–288.

一些说明

functions：指的是functionality，而非编程中某一具体函数
modules：指的是layers，而非编程语言中的组织架构或库
分层架构 a layered architectural style
- 基本思想
  组件（components）以分层的方式从上到下排列，在层 Lₙ 的组件可以向层 Lₘ 的组件发起downcall（n < m）（即上层可以对下层进行调用），通常 Lₙ 会期待从 Lₘ 获得一个响应。
  此外，通过之前注册的callback，层 Lₘ 的组件可以向层 Lₙ 的组件发起upcall。

End-to-End Argument 端到端论证

内容

End-to-End：从一个端点到另一个端点的完整过程，通常涉及整个系统或网络的多个层级。
End-to-End Argument：有些功能只能在应用层“完全且正确地实现”，而在平台层（中间节点或底层系统）实现这些功能则是不可能的。
这种不可能性源于平台层可能只有部分信息——通俗说，平台层缺乏上下文，不像应用层可以拥有完整的信息。
目的是为了优化。

Some functions may “completely and correctly be implemented only” on an application level, implementing said functions completely and correctly on a platform level is not possible.
if low levels of the communication system try to accomplish bit-perfect communication, they will probably introduce uncontrolled delays in packet delivery.

主要观点

关键观念是，底层并不需要提供“完美”的可靠性。
某些功能应该由需要它的应用程序来实现，而不是由底层系统提供。
中间系统应该保持简单，只提供最基本的服务。
复杂的功能应该放在端点（即应用程序）中实现。

End-to-End Argument 在选择平台层/下层中要提供的功能时，类似于“奥卡姆剃刀”。因为平台层/下层往往在尚未确定调用改平台层/下层的应用之前就被指定，设计师可能会因而倾向于“帮助”用户承担过多的功能。意识到End-to-End Argument可以帮助减少这种想法。

由于下层系统/平台层是许多应用程序共有的，那些不需要该功能的应用程序也会为此买单。
下层系统/平台层可能没有像上层/应用层那样多的信息，因此无法高效地完成工作。

It is probably not important to strive for a negligible error rate at any point below the application level.

奥卡姆剃刀：“如无必要，勿增实体”，提倡在解释任何事情时，应当尽量采用最简单、最直接的假设或实体。

End-to-End Argument 适用于数据包排序packet ordering和循环抑制duplicate suppression。
End-to-End Argument 并不是一个绝对的规则，而是一种guide，有助于应用和协议设计分析。在确定该原则应当应用于哪些端点时，需要小心谨慎。

例子

TCP错误检测

TCP的错误检测和纠正机制就是End-to-End原则的一个典型应用。尽管底层网络可能提供一些错误检测功能，但TCP在端点实现了更全面的错误处理机制。

可靠文件传输

目的：从机器A传输一个文件到机器B，并且不造成损坏
方法：以chunk形式传输
- 发送方在应用层将数据分割成多个chunks，然后将每个 data chunk 交给平台层传输
- 接收方在平台层接收chunks，然后上交给应用层进行组装
问题：能否只在平台层通过将failure detection和failure mitigation就能“完全且正确”地实现文件传输，还是在应用层也需要进行故障检测和故障缓解？
现实：
- 平台层通过校验chunk来检测传输情况，通过chunk重传减少失败
- 应用层通过校验文件并检验文件组装情况，通过文件重传减少失败
- 如果平台层没有重传限制/超时机制或没有应用层介入判断，平台层在每次失败后继续chunk重传就可能陷入无限循环
- 为了避免无限循环，平台层需要将多次传输失败的情况告诉应用层
- 只有应用层能实现有意义，完整且全面的故障检测，确定文件传输是否成功并且如何处理

所以，文件传输的failure detection和failure mitigation可以(也应该)在应用层和平台层进行，但只有应用层能确保传输的完整性和正确性。

优化类型：
- 性能优化：如果应用层检测到文件传输失败，可以重新传输整个文件。而平台层如果检测到某个数据块传输失败，只需重传该数据块，从而避免重传整个文件。
- 成熟度优化：虽然某些功能只能在应用层完全正确实现,但在平台层重复实现这些功能可以帮助提高正确性。一些复杂且容易出错的功能封装在平台层，可以利用其成熟度，并在应用层"填补空白"。