跳转到内容
Jason's Study

Clark 1988 — TCP/IP 七大目标的优先级，决定了 Internet 长成今天这样

是什么

Clark 1988 是 Internet 架构师 David Clark 写的一篇回顾性论文——他不是在设计新协议，而是在事后讲清楚一件事：

TCP/IP 当年是按七条目标排序设计的，第一条是「网络炸了也要能通信」，最后一条才是「能不能算清楚谁用了多少」。今天 Internet 那些不舒服的地方（计费难、QoS 难、安全弱），不是 bug，是当年清醒选了排序的结果。

日常类比：盖一栋房子之前先排一份「我最在乎什么」的清单——抗震 > 通风 > 采光 > 漂亮 > 便宜。后来住进去发现夏天有点热，不是设计错了，是「凉快」当初就排在第 6 位。Internet 是一栋为「核战时还能打电话」设计的房子，今天我们想让它兼营「精准计费的电信运营商」，自然处处不顺手。

为什么重要

不读这篇，下面这些事都解释不通：

  • 为什么 Internet 按流量精准计费这么难——状态根本没在中间节点上
  • 为什么视频会议的 QoS 总是靠端点自己想办法（QUIC、BBR），而不是靠路由器排队保障
  • 为什么 NAT、CDN、防火墙、SDN controller 这些「往中间塞状态」的东西，本质上都是在违背原设计打补丁
  • 为什么数据中心网络（RDMA、SDN）反而把状态放回中心——它们的优先级排序已经不是 Clark 那七条了

这篇文章是理解 Internet 架构原则的入门钥匙，也是一篇罕见的「设计者亲口讲为什么这样设计」的元论文。

核心要点

Clark 列的七条目标，按优先级从高到低：

  1. 生存性 (survivability) — 即使丢掉网络或网关，已经建立的通信也要继续。这是 DARPA 的核心军用需求。
  2. 多种服务类型 — 不只是文件传输，还要支持远程登录、实时语音等。
  3. 多种网络 — 能跑在以太网、无线、卫星、专线等异构介质上。
  4. 分布式管理 — 不能有一个中央机构管整个网。
  5. 成本可控 — 实现要便宜。
  6. 接入容易 — 加新主机要简单。
  7. 资源问责 (accountability) — 能算清楚谁用了多少资源。

这个顺序推出三个关键技术选择：

  • datagram 作基本构件：每个包独立路由，不依赖中间节点保存连接状态。这样路径切换/节点炸掉时，包还能绕过去——直接为目标 1 服务。
  • fate-sharing 把状态推到端点：连接的关键状态（序号、窗口、密钥）只存在两个端主机里。中间节点炸了无所谓，只要两个端主机活着，连接就活着。
  • gateway 无状态：路由器不保存任何连接级状态。这让加路由器、换路由器都很容易（目标 3、6），但天然导致目标 7 难以实现——中间不知道一个包属于谁的会话，怎么计费？

Clark 在文章里反复强调：这三个选择是「目标 1 + 目标 3」联手推出来的，不是单一目标的产物。理解架构必须看「多个目标怎么互动」，而不是把每个特性归给一条目标。

实践案例

案例 1：为什么 Internet 计费这么难

打电话：电信运营商在交换机里为每通电话开一条记录，挂断时就知道你打了多久。

上网：你下一部 4K 电影时，IP 包从你家路由器、ISP、骨干网、CDN 流过，每一跳都不知道这些包属于「你正在下的这部电影」——它只看目的 IP，转发，丢掉。要算账只能在端点（你家光猫 / ISP 出口）按字节计数，颗粒度只到 IP 不到「会话」。

这不是技术做不到，是目标 7 当年排在最后，整个架构都没为它优化过。

案例 2：fate-sharing 在 QUIC 里的回响

TCP 的连接被五元组绑定（源 IP、源端口、目的 IP、目的端口、协议）。手机从 WiFi 切到 4G，源 IP 一变，连接立刻死。

QUIC 改用 Connection ID——连接状态完全在端点上，IP 换了无所谓，把 Connection ID 报上去就续上。这就是 fate-sharing 的现代版：状态跟着两个端点走，不跟着任何中间节点或地址绑死。Clark 1988 的设计原则在 QUIC 里被重新强调了一次。

案例 3：数据中心反向的设计

数据中心常见 SDN：流表由中心 controller 下发，所有交换机听 controller 指挥。这完全违背 Clark 的「分布式管理 + 无状态 gateway」。

为什么敢这么做？因为它们的优先级排序是另一套：性能 > 可控性 > 故障隔离 > 生存性。数据中心不需要扛核打击，反而需要厘秒级延迟和精准带宽分配——目标排序变了，架构就跟着翻。

读 Clark 这篇最大的收获不是「记住这七条」，而是学会一种思维：看到一个架构选择，问「它在为哪条目标的优先级服务」。

案例 4：端到端加密为什么是后加的

Clark 的七条目标里没有「安全」。这不是疏忽，是因为 ARPANET 当年是封闭的、参与者互相认识的研究网络，威胁模型主要是物理破坏（被炸），不是恶意主机。

后果是：1990 年代 Internet 商业化、人人能接入之后，安全只能作为补丁加在原栈上——TLS 套在 TCP 外、IPSec 套在 IP 外、DNSSEC 套在 DNS 外。每一层都是「在不改原协议的前提下，把加密塞进端到端通道里」。这又一次印证了 fate-sharing：端点持有密钥，中间节点看不见明文，状态严格在端点上。安全的实现方式被原架构的优先级间接限定了——这就是「目标排序的长尾效应」。

踩过的坑

  1. 把这七条当成「所有网络都该这样」——Clark 自己强调过：换一种优先级（商业网络把「问责」放第一），架构会长得完全不一样。不要照抄，要先问「我的优先级是什么」。

  2. 误读 fate-sharing 为「路由器不能有任何状态」——其实是关键的端到端连接状态不放在中间节点。今天的 NAT、防火墙、SDN controller 都有状态，只是不放连接级状态，区别要清楚。

  3. 把 datagram 当成性能选择——它首先是为生存性服务的政治选择（无连接 → 路径切换不丢状态）。性能（带宽利用率）反而是副作用。把因果搞反了，就理解不了为什么虚电路网络（如早期 X.25）在性能上其实可以更好。

  4. 用今天的痛点倒推「当年设计错了」——目标 7「问责」被明确排在最后，是清醒的取舍，不是疏忽。Clark 写这篇时已经看到商业化在路上，他承认会有麻烦但拒绝改优先级，因为生存性不能让位。

适用 vs 不适用场景

适用（这套优先级合身的场景）：

  • 跨广域、异构链路、对故障容忍要求极高的网络（公网骨干、应急通信）
  • 不需要精准计费的开放系统（学术网、开源协作）

不适用（需要换优先级重设计）：

  • 数据中心网络（性能/可控性优先）→ SDN、RDMA
  • 电信运营级网络（计费/QoS 优先）→ MPLS、IMS
  • 安全敏感的封闭网络（问责/审计优先）→ 零信任架构

历史小故事（可跳过）

  • 1973 年：Cerf-Kahn 写下 TCP 雏形，那时 TCP 和 IP 还粘在一起。
  • 1978 年左右：TCP 和 IP 被刻意拆开——IP 负责尽力而为的包转发，TCP 负责端到端可靠性。这次拆分是 fate-sharing 思想成形的关键。
  • 1983 年 1 月 1 日：ARPANET 一夜之间从老协议 NCP 切换到 TCP/IP，史称 flag day。这是 Internet 的生日。
  • 1988 年：Clark 在 SIGCOMM 上讲这篇——TCP/IP 已经跑了 5 年，但 WWW 还没出生（1990 才有）。这是「为军方设计的网络偶然变成民用基础设施」之前最后一次清晰的目标自述。
  • 之后：Internet 商业化，目标 7 的缺失变成持续工程债，催生了 NAT、CDN、QUIC 这些「往中间塞状态」的补丁。

学到什么

  1. 架构是优先级的产物，不是技术的产物——同样的硬件能力，目标顺序不同，会长出完全不同的架构。
  2. fate-sharing 是 Internet 的灵魂：状态跟主机走，不跟链路走。理解这条比记住七条目标更重要。
  3. 目标 7 (问责) 被排到最后，是 Internet 今天计费难、安全弱、QoS 难的根因。不是疏忽，是取舍。
  4. 元论文的价值：设计者亲口讲「我当时怎么想」，比任何后人解读都精准。这种文章一年看一次，每次都能多看出一层。
  5. 学会问「优先级」而不是「对错」：以后看到一个让你不舒服的设计，先别急着说它「错了」，先去找它当年的优先级清单。多数情况下，你会发现它没错，只是不为你的需求服务。

进一步思考的问题（自留）

读完后值得自己回答的几个问题（不必现在答，写在这里当锚点）：

  • 如果让我今天为「物联网 (IoT)」重新排一份七条目标，我会怎么排？为什么？
  • 区块链 / P2P 网络的目标排序是不是和 Clark 的不一样？分歧在哪几条？
  • 我自己写的小服务/小协议，有没有过「优先级没想清楚 → 后期补丁不断」的经历？

这些问题不是论文里的，是读这篇文章时最值得带走的副产物——把「目标排序」这个思维工具用到自己的项目上。

一句话总结

Internet 的形状是七条目标的优先级排序投影出来的，第一条是「炸了也要通」，最后一条才是「算清楚谁用了多少」——所以今天计费难、QoS 难、安全弱不是 bug，是清醒的取舍。fate-sharing 把状态推到端点，是这套优先级最直接的技术后果，也是后来 QUIC、TLS、CDN 一切「补丁」的共同祖宗。

读这篇最好的方式：

  1. 先看完七条目标和顺序，停下来自己想一遍「为什么是这个顺序」
  2. 再回去对照 Clark 的论证
  3. 你会发现很多「直觉上奇怪」的选择突然全部说得通了

延伸阅读

  • 论文 PDF：Clark 1988 — The Design Philosophy of the DARPA Internet Protocols（10 页，几乎不带数学，强烈推荐通读）
  • 配套读：Saltzer-Reed-Clark 1984「End-to-End Arguments in System Design」——和 Clark 1988 是同一组思想的两个面，前者讲技术原则，后者讲目标排序
  • RFC 1958「Architectural Principles of the Internet」——把 Clark 这套哲学落成 IETF 官方原则
  • Blumenthal-Clark 2001「Rethinking the Design of the Internet」——Clark 自己 13 年后回头反思「端到端原则在新形势下还成立吗」
  • Handley 2006「Why the Internet Only Just Works」——批判性视角：补丁打太多，原架构已经跟不上

关联

  • tcp —— Clark 文章里 TCP 是 fate-sharing 的最具体载体
  • dns —— 同样是「把状态推到端点 + 分布式」哲学的产物
  • http-2 —— HTTP/2 多路复用是在受限的 TCP 上重新逼近原始设计目标
  • quic —— Connection ID 是 fate-sharing 思想的现代复刻
  • [[tls-1.3]] —— 安全（目标外）后补，靠 TLS 把端到端加密叠在原栈之上

反向链接

  • bbr-2017 —— BBR 2017 — 用瓶颈带宽和最小 RTT 替代丢包当拥塞信号
  • dns —— DNS — 把全球域名解析切成一棵可分布维护的树
  • http-2 —— HTTP/2 — 把 HTTP 从文本协议改造成二进制多路复用
  • mockapetris-1988-dns —— Mockapetris 1988 DNS — 设计者亲口讲为什么 DNS 长这样
  • quic —— QUIC — 把可靠传输从内核搬到用户空间
  • tcp —— TCP — 在不可靠的 IP 上凿出一条 reliable 字节流
  • tcp-vegas-1995 —— TCP Vegas 1995 — 不等丢包，靠 RTT 早一步看见拥塞