网络架构

设计范式

到目前为止，我们已经从自底向上的视角了解了互联网，从基本组件开始逐步构建出整体图景。在本节中，我们将从自顶向下的视角审视互联网，分析其设计中最重要的架构选择。

这些互联网设计范式影响着互联网的运作方式，也影响着我们在互联网之上构建的应用。这些范式与历史上系统的构建方式有着根本的不同。

这些设计只是众多可能设计中的一种，许多设计选择是多年前做出的，远在互联网发展到如今规模之前。还存在其他设计，关于最佳设计的争论也一直存在。

例如，互联网的构建采用了联邦式架构（由独立运营商合作），但近年来，软件定义网络（SDN）作为一种更集中化的网络管理方法逐渐兴起。

在最初的互联网中，交换机被有意设计得功能简单，仅负责转发数据而不解析数据。然而，在现代互联网中，攻击者可能会通过发送大量无用数据来淹没交换机，因此交换机可能需要一种检测此类攻击的方法。提出这种简单基础设施范式的早期互联网设计者并未考虑到这种安全隐患。

窄腰

在特定的网络层可以存在多种协议。例如，在第 7 层，我们可以使用 HTTP 来提供网站服务，或者使用 NTP 来同步系统时钟，这两种协议都构建在相同的互联网基础设施之上。再比如，在第 2 层，我们可以在有线网络中使用以太网，在无线网络中使用 Wi-Fi。

需要注意的是，尽管在某一层存在多种协议，但你可以为自己的应用确定一套特定的协议栈。例如，你可以确定使用 HTTP over TCP over IP（HTTP 基于 TCP，TCP 基于 IP），而无需使用第 7 层或第 4 层的其他协议。这样，所有使用你的应用的用户都会采用相同的协议栈。

观察这张图，你会发现第 3 层只有一种协议。这就是实现互联网连接的 “窄腰”。归根结底，互联网上的所有设备都必须同意使用 IP 协议，这样数据包才能在互联网上传输。

解复用

TODO：撰写关于解复用的内容。

注意名称的区分。在网络领域，有两种不同的事物都被称为 “端口”。物理端口是你将链路插入交换机的实际物理接口。逻辑端口是第 4 层报头中的一个数字，用于区分数据包属于哪个应用。

注意：套接字指的是操作系统中一种将应用程序与操作系统网络栈连接起来的机制。当应用程序打开一个套接字时，该套接字会与一个逻辑端口号相关联。当操作系统接收到一个数据包时，它会使用端口号将该数据包定向到相关联的套接字。

端到端原则

我们为什么要以这样的分层结构设计互联网？为什么只有主机才理解第 4 层和第 7 层，而路由器不理解呢？

端到端原则为互联网设计提供了智慧和指导。麻省理工学院的科学家、互联网架构委员会成员 David D. Clark 是这一原则的主要贡献者。他的两篇论文 ——《系统设计中的端到端论点》（1981 年）和《DARPA 互联网协议的设计哲学》（1988 年）—— 对互联网设计的理念产生了巨大影响。

端到端原则指导着关于网络应该实现哪些功能、不应该实现哪些功能的争论。这一原则范围很广，有很多应用场景，但我们将重点关注一个问题：可靠性（第 4 层）应该在网络中实现，还是只在终端主机中实现？

现在，让我们考虑一个简单的可靠性协议。主机 A 想要向主机 B 发送 10 个数据包，于是它发送编号为 1 到 10 的数据包通过网络传输。目标是让 B 要么收到所有数据包，要么意识到有些数据包丢失并报错（我们暂不考虑从错误中恢复的情况）。

如果我们在网络中实现可靠性，互联网会是什么样子？与我们之前的图景不同，每个路由器现在除了理解第 1、2、3 层之外，还必须理解第 4 层。

在这种新图景中，中间路由器必须可靠地将数据包发送到下一跳。它必须确保下一跳收到了所有数据包，如果没有，路由器必须重发任何丢失的数据包。主机不会检查是否收到了所有数据包，而是依赖网络来确保所有数据包都能被收到。

在这种方法中，主机必须信任网络。如果某个路由器有故障并丢弃了数据包，主机实际上无能为力。

另一种方法是端到端方法，即不在网络中实现可靠性，而是让两个终端主机来保证可靠性。路由器可能会丢弃数据包，而由终端主机负责验证是否收到了所有数据包。

在端到端方法中，可靠性由终端主机实现，控制权在主机手中。主机可能也会出故障并丢弃数据包，但此时主机有能力自行修复故障。更一般地说，当你编写代码时，如果能自己控制功能的正确性，而不是依赖可能出错（且你无法修复其错误）的其他人，会更好。

通过这种对比，如果我们采用第一种方法，即依赖网络的正确性，那么当网络出现故障时，我们实际上无法保证完全的可靠性。终端主机最终可能还是会像第二种方案那样进行端到端的检查。

在早期的互联网中，每条链路确实都实现了可靠性。然而，如我们所见，现代互联网在网络中只实现尽力而为的服务，而强制终端主机实现可靠性，这与端到端原则是一致的。

总结来说：有些应用需求必须通过端到端的方式实现才能确保正确性。此外，端到端的实现已经足够，不需要网络提供额外的支持。因为仅靠端到端的实现就足够了，在网络中添加相关功能会引入不必要的额外复杂性（和成本），而无助于我们实际达成需求。

需要注意的是，端到端原则并非总是正确的证明或定理。它是一种指导原则和哲学观点，不同的设计者可能会对这一原则有不同的支持或反对论据。

这里有一个端到端原则并非严格规则的例子。尽管端到端原则认为只应在终端主机中实现可靠性，但我们仍然可以在网络中添加一些额外的可靠性机制，作为端到端检查的补充。这在链路极不可靠的情况下可能很有用。假设在 A 和 B 之间有 10 条链路，每条链路的失败率为 10%。那么，每次发送数据包，其被丢弃的概率为 65%。然而，如果每个路由器都被修改为发送两个数据包副本以保证可靠性，那么每条链路的失败率就只有 0.1%，数据包被丢弃的概率也降至 1%。无线网络有时会实现可靠性机制，以降低错误率并提高终端主机的性能。

端到端原则也适用于其他领域。例如，在安全领域，端到端原则可能意味着两个通信的终端主机应该在终端进行消息加密，而不是在网络的中间节点进行。

用 Clark 的话来说，端到端论点是：“所讨论的功能只有在端点的应用程序提供知识和帮助的情况下，才能完全且正确地实现。因此，将该功能作为通信系统本身的一个特性是不可能的。有时，由通信系统提供该功能的不完整版本可能有助于提升性能。”

（注：文档部分内容可能由 AI 生成）