本文是 *End-to-End arguments in system design. ACM Transactions on Computer Systems* 的阅读报告

文章主要论证的观点是，在设计系统、尤其是通信系统时，需要做到“End-to-End”。即，将功能实现在真正需要它们的“终端”上。这类似于自然科学中常见的“奥卡姆剃刀”原理。

基于这一点，文中列举了诸多例子。例如文件传输系统、消息重复抑制、加密传输等。这些例子所反映的共同情境是，在一个高度复杂和层次化的系统中，在底层实现额外的功能（如自动重传、重复检测等），所带来的效用将十分有限，以至于使用他们的上层应用（或终端应用）不得不将之重复实现。这样的错误设计，不仅会带来性能上的额外损失，更有可能会使得上层程序的设计者“错误地信任”底层系统，从而设计出不可靠的系统。

我认为，在底层设计原应有高层承担的功能之不实际之处在于，多层次系统引入的问题是复杂而多种多样的（例如文中提到，一个文件传输系统的问题可能发生在硬盘、网络、软件等多个环节），这些问题是无法在底层去将其作区分识别并价值解决的（或者，只能相当有限地解决）。

前几日崔勇教授在计算机创新思维课上问到我们，重传机制应当在哪一层实现？当时他对其在 TCP 协议上而非网络层或链路层上实现的理由是，路由器和交换机有相当大的性能需求，而在硬件上实现重传是复杂且不切实际的。今天的文章又进一步丰富了论据，同时也还有文章此外提到的一点：一个底层系统应当将足够多的选择权交手至上层程序。“底层程序可以选择提供一个功能，但总应该容许程序去将其替换为特定的实现”。例如，如今常用的传输协议，TCP 和 UDP，前者具有重传和较好的稳定性，后者不具有重传，但提供给上层程序更大的自由度。如果在底层就实现了重传机制，就难以提供这种自由度。

这让我想起一个编程中常常遇到的例子。一般在多个线程对同一个 HashMap 之类的复杂结构进行同步的修改和访问时，为了追求性能可能会采取一些无锁的高级实现（如 Rust 中的 `DashMap` 等）。但常常很快就会发现，最终一把上层的锁依旧无法避免，进而下层的无锁就反而毫无意义、甚至相较于默认的 `HashMp` 有性能损失。因为仅仅在底层保证并发修改的正确性，并无法在上层的意义上做到程序的一致性（consistency）。程序为了维护其高级逻辑上的同步仍然需要自己实现相关的同步机制。这就是一个很恰切的 End-to-end 的例子。

这篇文章使我收获颇丰。一方面，其将 End-to-end arguments 这样一个在计算机领域中常见但模糊的概念给抽离了出来并具体表述，使得我对系统设计背后的一个更根本的哲学有了理解；另一方面，这也使我对系统设计理念、相较于表层结构外更高层次规则的重要性有了把握，为我往后可能的系统设计有了基本的导引和教条。