Lec 1 互联网架构的演进
阅读资料
- 互联网简史 A brief history of the internet, 2009，这篇论文被发布了两次，因为其有历史的重要性
- DARPA互联网协议的设计哲学 The Design Philosophy of the DARPA Internet Protocols, 1988
- 端到端原则 End-to-End Arguments in System Design
回顾了我们为什么互联网是当下这个样子。
论文阅读：互联网简史
1. 介绍
互联网是对信息基础设施进行持续投资和研发所带来的好处的最成功例子之一。在这篇论文中，几位参与互联网发展和演变的作者分享了他们对其起源和历史的看法。这段历史围绕四个不同的方面展开。第一个是技术演变，从早期的分组交换（packet switching）和ARPANET研究开始。第二个是全球复杂的操作基础设施的运营和管理方面。第三个是社会方面，形成了一个广泛的互联网用户社区。第四个是商业化方面，使研究成果有效地转化为广泛部署和可用的信息基础设施。
2. 因特网的起源
Licklider 在1962年8月撰写的一系列备忘录，讨论了他的“银河网络”概念。他设想了一组全球互联的计算机，任何人都可以迅速从任何地点访问数据和程序。并在同年称为DARPA（国防高级研究项目局）计算机研究项目的第一任负责人，在前一年发表过分组交换理论的第一篇文章。论证了使用分组而不是电路进行通信的理论可行性，这是实现计算机网络的一个重大步骤。后来的继任者Roberts等进一步完善了分组交换网络的理论和实践， 在1968年发布了分组交换机（当时称接口消息处理器IMP）的RFQ。所有这些工作在1969年9月汇聚在一起，Kleinrock在加州大学洛杉矶分校（UCLA）准备了网络测量系统，称为ARPANET的第一个节点，并安装了IMP，并连接了第一个主机计算机。 斯坦福研究所（SRI）成为第二个节点，并进行了， 从Kleinrock的实验室向SRI发送了第一条主机对主机消息。
在ARPANET的节点不断增加的同时，功能完善的主机对主机协议和其他网络软件也在迅速发展。1970年12月，由S. Crocker领导的网络工作组（Network Working Group, NWG）完成了首个主机对主机协议，称为网络控制协议（Network Control Protocol, NCP）
1972年10月，Kahn在国际计算机通信大会（ICCC）上组织了一场大型的ARPANET展示，这是新网络技术的首次公开展示。同年，电子邮件作为首个“热门”应用被引入。BBN公司的Ray Tomlinson在3月编写了基本的邮件发送和读取软件，满足了ARPANET开发人员协调工作的需求。
3. 互联网概念起源
最初的ARPANET逐渐发展为互联网。互联网基于多种独立网络的概念，这些网络具有不同的设计方式，从最初的ARPANET分组交换网络开始，逐渐涵盖了卫星分组网络、地面分组无线电网络等。现代互联网体现了“开放式架构网络”的关键技术理念。在这种架构下，各个网络技术的选择不受特定网络架构的限制，供应商可以自由选择，并通过一个高级别的“互联网架构”使不同的网络相互兼容。早期，唯一的一般性网络联通方式是电路交换法，即网络通过电路级互连，在两端位置之间的端到端电路上同步传输数据。而早在1961年，Kleinrock就已证明分组交换是一种更高效的交换方式。
开放式架构网络的一个关键特点是每个网络可以独立设计并开发，具有自己独特的接口，提供给用户或其他网络供应商。每个网络都可以根据其环境和用户需求进行特定设计，而对网络类型或地理范围几乎没有限制。1972年，Kahn提出了开放式架构网络的理念，最初是为分组无线电（radio network）计划提出的，后来成为独立项目，并被称为“互联网工作（Internetting）”。使数据包无线电系统正常工作的关键在于建立一种可靠的端到端协议，这种协议可以在受到干扰和其他无线电干扰而导致的间歇性信号中断的情况下维持有效的通信。卡恩最初考虑开发一个仅用于数据包无线电网络的协议，这样可以避免处理多种操作系统，并继续使用NCP。然而，NCP无法寻址到ARPANET中目的IMP以外的其他网络（和设备），因此NCP也需要进行一些修改。（当时的假设是ARPANET在这方面是不可更改的）。NCP依赖ARPANET提供端到端的可靠性，如果数据包丢失，协议（以及假定它支持的所有应用）将完全停滞。在这种模式下，NCP没有端到端的主机错误控制，因为ARPANET是唯一存在的网络，并且可靠到主机无需进行错误控制。
为支持开放式架构环境，Kahn决定开发新的协议版本，称为传输控制协议/互联网协议（TCP/IP）。Kahn的早期思路包含四条原则：
- 每个独立网络应当能够独立运行，不必为连接到互联网而进行内部更改。
- 通信为“尽力而为”，即若数据包未能到达目的地，则将从源重新传输。
- 使用黑盒设备连接网络，这些设备后来被称为网关或路由器。网关不保留通过的数据流信息，以保持简单并避免复杂的故障恢复。
- 操作层面不设全球控制。
其他需要解决的关键问题包括：
- 防止丢包算法，以确保丢失的包不会永久性地阻断通信，并能够从源端成功重传
- 支持主机到主机的“流水线”传输，以便在中间网络允许的情况下，多个包可以从源端发送到目标端
- 网关功能，用于适当地转发数据包，包括解析IP头以实现路由、处理接口、在必要时将包分片等
- 需要端到端校验和、包从分片中重新组装，以及检测重复包
- 需要全球地址分配
- 主机到主机的流量控制技术
- 与不同操作系统的接口问题
- 还存在其他关注点，比如实现效率、互联网络性能，但这些在初期属于次要考虑
卡恩在BBN工作时开始制定一套以通信为导向的操作系统原则。在此时，他意识到要有效地嵌入新协议，必须学习每个操作系统的实现细节。因此，1973年，Kahn邀请了在斯坦福的Vint Cerf共同设计该协议。Cerf对NCP的深入的了解，与Kahn的架构方法相结合，详细制定了TCP/IP协议。
卡恩和瑟夫的合作产生了一些基本思路：
两个进程之间的通信在逻辑上是一个非常长的字节流（称为八位字节）。
字节流中的位置可以用来标识任意字节。 •
流量控制采用滑动窗口和确认机制。目标端可以选择何时确认，每次返回的确认都是累积的，涵盖到该点为止接收到的所有数据包。
至于源端和目标端如何协商窗口参数，这部分最初是开放的，默认参数被使用
当时并没有预料到局域网的大量普及，因此，使用了32位IP地址，其中前8位表示网络，剩余24位指定该网络中的主机。但随着1970年代末局域网的出现，这一假设显然需要重新评估。
初始的TCP协议仅支持虚拟电路模式（virtual circuits），这种模型适用于文件传输和远程登录等应用，但在1970年代初期的某些高级网络应用（尤其是分组语音）中，人们逐渐认识到，某些情况下不应由TCP来纠正数据包丢失，而应由应用程序自行处理。 这一需求促使原有的TCP被重新划分为两个协议：一个是简单的IP协议，仅负责单个数据包的寻址和转发；另一个是独立的TCP协议，专注于诸如流量控制和数据包丢失恢复等服务功能。对于不需要TCP服务的应用，引入了一个替代协议，即用户数据报协议（UDP），以便直接访问IP的基础服务。
在互联网的早期，还提出了其他应用程序，例如基于分组的语音通信（互联网电话的前身）、各种文件和磁盘共享模型，以及展示代理概念的早期“蠕虫”程序（当然也包括病毒）。互联网的一个关键理念是它并非为单一应用设计，而是一个通用的基础设施，能够支持新的应用出现，这一点后来通过万维网的出现得到了证明。
4. 验证理念
DARPA与斯坦福（Cerf领导）、BBN（Ray Tomlinson）和UCL（Peter Kirstein）签订了三项合同来实施TCP/IP（在Cerf和Kahn的论文中仅称为TCP，但包含了这两部分）。大约一年后，出现了三个可以互操作的独立TCP实现。这标志着长期实验和开发的开始，以推动和完善互联网的概念和技术。从最初的三个网络（ARPANET、Packet Radio和Packet Satellite）开始，实验环境逐步扩大。
1980年代LAN、PC和工作站的广泛发展使得新兴的互联网蓬勃发展。Bob Metcalfe于1973年在Xerox PARC开发的以太网技术，如今成为互联网的主导网络技术。这一转变从最初少数拥有较少主机的网络（ARPANET的模型）演变为拥有大量网络，从而引入了许多新的概念和技术变更。首先，为了适应不同规模的网络，定义了三个网络类别（A、B和C）：A类代表全国范围的大型网络（少量网络但主机众多）；B类代表区域范围的网络；C类代表局域网络（大量网络但主机较少）。
互联网规模的增长及其管理问题引发了重大变化。为了便于人们使用网络，主机被分配了名称，因此无需记住数字地址。最初，主机数量相对有限，维护一张所有主机及其名称和地址的单一表格是可行的。随着大量独立管理的网络（如LAN）的出现，单一主机表格变得不切实际。Paul Mockapetris在USC/ISI发明了域名系统（DNS），这为将层级主机名称（例如www.acm.org）解析为互联网地址提供了一种可扩展的分布式机制。
互联网规模的增长也对路由器的能力提出了挑战。最初，所有互联网路由器都统一实现了一个分布式路由算法。随着网络数量的急剧增加，这种初始设计难以扩展，因此被分层路由模型取代，内部网关协议（IGP）用于互联网的每个区域，而外部网关协议（EGP）用于将各区域连接起来。该设计允许不同区域使用不同的IGP，以适应不同的成本、快速重配置、鲁棒性和规模要求。路由算法及其寻址表的大小也对路由器的容量构成了压力。为了控制路由器表的大小，最近引入了新的地址聚合方法，特别是无类别域间路由（CIDR）。
CIDR 的核心是通过可变长度的子网掩码来分配IP地址，而不是限制在A、B、C类的固定大小范围内。CIDR 表示法将IP地址与一个斜杠后面的数字（称为前缀长度）结合使用，例如
192.168.0.0/24，其中/24表示子网掩码有24位用于网络部分，剩余的部分用于主机部分。这样可以更灵活地指定网络的大小，也更有效地分配和使用IP地址空间
随着互联网的发展，软件更新，特别是主机软件的传播，成为一个主要挑战。DARPA支持加州大学伯克利分校对Unix操作系统进行修改，包括将BBN开发的TCP/IP集成到Unix中。计算机科学研究界的大部分人开始将Unix BSD作为其日常计算环境，回顾来看，将互联网协议整合到支持研究社区的操作系统中的策略，是互联网成功广泛采用的关键因素之一。
其中一个有趣的挑战是ARPANET主机协议从NCP向TCP/IP的过渡，该过渡于1983年1月1日实施。这是一次“标志日”式的转变，要求所有主机同时转换，否则只能通过临时方法进行通信。该过渡在实际执行前经过了数年的细致规划，并出奇顺利地完成了。并直接促成了军用和非军用社区的最终分离。
5. 向广泛的基础设施过渡
1970 年代中期，计算机网络开始在有资助的地方涌现，为各种学术，研究团体建立了各种各样 局域网，1981 年，Ira Fuchs 和 Greydon Freeman 开创了 BITNET，这个网络将学术界的大型主机连接在一起，采用“将电子邮件作为卡片图像”这种传输模式。1984 年，英国的 JANET 以及 1985 年美国的 NSFNET 计划明确表示，它们旨在为整个高等教育界服务，不论学科差异。事实上，获得 NSF 互联网连接资助的美国大学必须满足一个条件：“……该连接必须对校园内所有合格用户开放。”
NSF 的私有化政策在 1995 年 4 月达到了高潮，NSFNET 骨干网络的资助被撤销。收回的资金通过竞争方式重新分配给各区域网络，用于从当时众多的私人长途网络购买国家级互联网连接服务。NSFNET 骨干网经历了从研究社区开发的路由器（David Mills 的“Fuzzball”路由器）过渡到商业设备的过程。在其八年半的运营期间，骨干网从 6 个节点的 56 kbps 链路发展到 21 个节点的多条 45 Mbps 链路。期间，互联网扩展到遍及七大洲及外层空间的超过 50,000 个网络，其中美国拥有大约 29,000 个网络。
6. 文档的角色
互联网快速增长的一个关键在于对基本文档的免费和开放访问，特别是协议的规范。ARPANET 和互联网在大学研究社区的起步促进了开放发表思想和成果的学术传统。然而，传统学术出版的正常周期对动态的思想交流来说过于正式和缓慢，这对于创建网络至关重要。最初，RFC（请求评论）以纸质形式打印并通过传统邮寄方式分发。RFC 的影响在于形成了一个正反馈循环，RFC 中提出的想法或提案触发了另一个 RFC，提出了额外的想法，以此类推。当一些共识（或至少是一致的思想集合）形成时，将准备一份规范文档。这种规范随后将作为各研究团队实施的基础。
随着时间的推移，RFC 变得更加专注于协议标准（“官方”规范），尽管仍然存在描述替代方法或提供协议和工程问题背景信息的信息性 RFC。RFC 现在被视为互联网工程和标准社区的“记录文件”。随着互联网的当前快速扩展，互联网展示了促进信息共享的能力，我们应理解网络在信息共享中的首要角色是通过 RFC 文档共享关于自身设计和操作的信息。这种独特的方法用于网络中新能力的演变，将继续对互联网的未来演变至关重要。
7. 广泛社区的形成
从早期的 ARPANET 开始，研究人员通过网络工作组合作开发了分组交换技术。随着互联网规模的扩大，DARPA 的 Vint Cerf 成立了多个协调组织，以促进国际合作和技术交流。1983 年，互联网活动委员会（IAB）和互联网工程任务组（IETF）等组织相继成立，以应对日益增加的技术需求和社区规模。到 1990 年代，IETF、IAB 和新成立的互联网协会（Internet Society）形成了合作关系，共同推动互联网的标准化和开放发展。随着万维网的发展，万维网联盟（W3C）也成立以规范 Web 技术。这一系列组织结构的演变和合作支持了互联网的持续增长和社区的多样化
8. 互联网技术的商业化
互联网的商业化不仅涉及私有网络服务的开发，还包括实施互联网技术的商业产品的开发。20世纪80年代初，大量厂商开始将TCP/IP整合到其产品中，但缺乏技术信息和用户需求的了解。1985年，Dan Lynch与IAB合作，组织了一个三天的研讨会，为厂商提供TCP/IP技术培训。研讨会促进了厂商与研究者之间的双向沟通，达成了技术共识。
在经过两年会议、教程、设计讨论会和研讨会之后，一个特别活动应运而生，邀请那些具备可靠TCP/IP技术的厂商在同一个房间里展示他们的产品如何良好地互相配合以及在互联网环境下的运行效果。1988年9月，第一个Interop贸易展会诞生了。50家公司入围。来自潜在客户组织的5000名工程师前来验证产品是否如承诺般可靠运行。结果证明它确实如此，原因在于厂商们极其努力，确保每个产品都能与其他产品（即使是竞争对手的产品）无缝互操作。此后，Interop贸易展会不断壮大，如今每年在全球7个地方举行，吸引超过25万人次的观众前来了解兼容性产品、最新产品及讨论前沿技术。
与Interop活动所展现的商业化努力相并行的是，厂商们开始参加每年3到4次的IETF（互联网工程任务组）会议，讨论TCP/IP协议套件的新扩展想法。最初参会者主要来自学术界，由政府资助，现在这些会议的参会人数经常超过千人，且多来自厂商社区，并由参会者自费。这个自选的群体以互相合作的方式推动TCP/IP协议套件的发展。它之所以如此有用，是因为它包含了所有利益相关者：研究人员、终端用户和厂商。
随着网络的扩展，网络管理的重要性增加，1987年提出了几种网络管理协议，包括SNMP、HEMS和CMIP。最终决定优先推广SNMP作为短期解决方案，CMIP作为长期解决方案。如今，SNMP已成为几乎通用的网络管理协议。
近年来，互联网的商业化进入了新阶段，互联网服务成为“通用商品”，最新的技术关注点是借助万维网支持全球范围内的信息服务。这一转变由浏览器的广泛使用推动，互联网不再仅仅是基础设施，而成为支持其他商业服务的全球信息平台。
9. 未来的历史
1995年10月24日，联邦网络委员会（FNC）一致通过了一项决议，定义了“互联网（Internet）”一词。该定义是在与互联网和知识产权社区成员的协商中制定的。
互联网未来最紧迫的问题并不是技术如何变化，而是如何管理变化和演变的过程。正如本文所述，互联网的架构一直由一个核心设计小组推动，但随着利益相关者的增加，这个小组的形式也发生了变化。随着互联网的成功，利益相关者越来越多——这些利益相关者不仅在知识上投入，也在经济上投资于网络。如今，我们在域名空间控制和下一代IP地址形式的讨论中看到，正在努力寻找未来引导互联网的新社会结构。考虑到众多关心的利益相关者，要找到这种结构的形式将更加困难。同时，行业也在努力寻找未来增长所需的大量投资的经济理由，例如升级住宅接入到更适合的技术。如果互联网出现停滞，那将不是因为缺乏技术、远见或动力，而是因为我们无法设定一个共同的方向并集体迈向未来。
最初的设计者并不知道在互联网上会跑什么应用，也不知道有哪些网络会被互联。因此，设计的目标要足够通用，因此最终的互联网架构是足够通用的，且对于大部分网络而言是足够好的。
分层如何与通用性相关？
每一层都允许在该层内使用多种协议、应用、通信技术、线缆类型或算法，只要该层遵守与相邻层的接口。换句话说，通过不在一层内施加过多限制，互联网促进了实现的多样性，并作为一个通用平台来应对未预料的使用情况。
- 应用层只需要使用sockets接口来发送和接收数据（我们将在下次讲座中讨论），以尊重其与传输层的接口。除此之外，它们可以自由使用自己的应用逻辑来决定何时发送和接收数据，发送或接收多少数据，以及这些数据在另一端如何解释（例如，HTML、音频、视频、虚拟现实等）。
- 传输层需要在终端主机上生成带有目标地址的数据，以尊重其与路由层的接口。除此之外，传输协议可以支持不同的抽象。可靠且按顺序的传输是一种选择。不可靠但可能更快的传输是另一种选择。这对应于两种不同的协议（TCP和UDP）
- 路由层可以自由选择任何适当的方法将数据从互联网的一端传输到另一端（即，它提供全球可达性）。此外，互联网服务提供商（ISP）内的路由完全由ISP决定，只要它能够找到连接到另一个ISP的方法来实现全球可达性。我们将在本课程后面讨论ISP内部和跨ISP的路由。
- 链路层支持多种不同的技术（以太网、WiFi、4G、蓝牙等）。它只需接受路由层传递的数据，并找到如何完成数据传输的最后和局部部分（俗称最后一公里连接）。这个最后部分可以是从接入点到你的笔记本电脑，或者从基站到手机。
- 最后，对于任何给定的链路层，都可以有许多不同的物理层实现，它们使用不同频率的电磁波（WiFi的900 MHz、2.4 GHz、3.6 GHz、4.9 GHz、5 GHz、5.9 GHz和60 GHz）或不同的线缆类型（以太网的5类、6类和7类线缆）。
互联网设计时的非目标
由于低成本的互连和基本的全球连接是首要目标，许多其他目标被搁置。特别是，尽管这听起来有些难以置信，成本效益在优先事项列表中很低，而良好的网络性能和网络安全根本不在列表上。
重要的是要记住，这些都不是互联网的目标，如果它们是目标，互联网的整体设计可能会完全不同。事实上，当前网络研究的一个活跃领域是开发不同于互联网的专用网络设计，他们的网络的需求不同于互联网的原始需求（例如，数据中心网络的设计）。
为什么互联网会选择分组交换而非电路交换？
历史上，电话网络围绕电路交换的概念运作。在电话网络中，在对话开始之前，会有一个呼叫建立阶段，建立起从呼叫者电话到被叫者电话的电连接。这个连接会通过多个电话交换机。这一过程最初是由电话接线员手动完成的，他们通过将不同的电缆插入插座并打开不同的开关来连接不同的电话交换机。这个过程被称为交换，后来这一过程变成了数字化操作。
对于互联网来说，分组交换的优点超过了其缺点，这与互联网关心的内容有关。互联网并非为性能或性能可预测性而设计；它是一个尽力而为的网络，本质上意味着“没有任何保证”。另一方面，通过重新路由来应对路由器故障的能力是很重要的。使路由器足够可靠（电话公司非常成功地做到了这一点）的电路交换替代方案会增加对路由器的要求，这反过来会提高现有网络进入互联网的门槛。
重要的是要重申，在开发互联网时，目标是实现互联网主机之间的最低限度连接，并通过使加入互联网尽可能容易来扩大互联网的覆盖范围。其他一切都是次要的。专注于一组不同的目标可能会导致不同的设计。但同样，如果进入互联网的门槛比实际情况更高，互联网可能永远不会起飞。有时候，创建一些东西，使其尽可能容易使用，然后根据需要进行迭代是有意义的
论文阅读： DARPA互联网协议的设计哲学
这篇论文首先介绍了DARPA（美国国防部高级计划署）互联网络架构设计的最初目标，这个架构最初是为了在已有的网络上有效地实现多路复用网络。论文开头直接指出，DARPA互联网络选用的多路复用技术是分组交换（packet switching）技术而不是与之对应的电路交换（circuit switching）技术，并指出了互联网的基础架构是分组交换和网关存储—转发。
然后，论文进一步细化了互联网的设计理念，也是本文的核心，总结为如下几点：
- 互联网在（某些）子网或网关失效时仍然能够继续工作；
- 互联网必须支撑多种类型的通信服务；
- 互联网架构必须能够适应各种各样的网络；
- 互联网架构必须允许资源的分布式管理；
- 互联网架构必须经济实惠；
- 互联网架构必须使得主机易于接入；
- 互联网架构使用的资源必须可以问责。
注意，它们的重要性依次减弱。根据这些目标，就可以设计出互联网。顺便指出，通过调节这几条的重要性，可以设计出来完全不同的网络。
失效的容忍
第一条也是最重要的一条，即对失效的容忍。
为了能够实现这个目标，互联网只能采用分组交换技术。如果采用电路交换技术，那么虚电路（virtual circuit）信息必须要存储于网络中的某些中间节点，而这些中间节点在虚电路创建的时候就已经确定。同时，由于虚电路的状态信息存储于这些中间节点中，之后通过虚电路的通信就只能通过这些中间节点来转发。倘若任一有关的中间节点突然失效，那么这条虚电路将断开，源主机发送的数据将无法到达目的主机，除非重新建立连接。即使失效节点恢复，如果无法恢复虚电路状态信息，虚电路连接也无法继续。
反观分组交换，在分组交换技术中，每一个经过网络传输的分组都携带了完全的源主机和目标主机的地址等信息，可以单独进行转发，也不需要中间节点保存任何状态信息（这里不考虑用于分组过滤的防火墙）。假设在某一个分组进行转发的时候，已经有一条确定的路径（即路由，route），但是这条路径中的某一个中间节点突然失效。该失效节点的邻居节点感觉到这一情况后会立即重新运行路由算法，计算一条新的（可能很大程度上不同的）连通的路径。由于每个分组携带的信息足够进行转发，源主机和目标主机的通信立即恢复。这样，就实现了单个节点或某些节点的失效而网络可以继续工作。其实，这里所说的节点，就是路由器（router）。
然而在一些时候，每个分组都要携带的地址等信息也可能反而成为累赘。考虑经典的例子，远程终端，每一次传输很可能只发送一个字节，却要包含完整的地址等信息。
支撑不同的通信服务
其次，对多种类型的通信服务的支撑，这一点要求互联网的灵活性非常强。
通信的需求大致可以分为可靠性、顺序性、高传输速率和低传输延迟几点。可靠性的意思是，网络和协议需要确保源主机能够确定发出的分组被目标主机接收到。顺序性指的是目标主机接收到的分组的顺序和源主机发送的顺序一致。顾名思义，高传输速率就是说单位时间内传输的数据量尽可能多。而低延迟是要求分组尽快到达目标主机。这几点构成了矛盾的辩证体，似乎不太可能同时实现得很好。
将可靠性和顺序性组合起来，产生了TCP（Transmission Control Protocol，传输控制协议），它能够极大概率地确保数据到达，且是有序的。这个协议能够很好的满足文件传输等需求。某种意义上，TCP类似于在分组交换网络上模拟了虚电路，只不过把控制信息保存在了通信双方主机内以及每一次传输的分组当中。为实现有效的重传（因为分组一定有可能传输失败）和在可靠的前提下达到尽可能高的传输速率，TCP有重传算法以及拥塞控制算法。也正因为此，TCP比不那么可靠的协议在低传输延迟方面要逊色一些。最近提出的BBR拥塞控制算法就在尝试改善丢包率较高的网络中TCP的传输速率和传输延迟。
而另外一种协议直接使用底层提供的发送分组的方式，不提供任何可靠性和顺序性的保证，这能够大大降低延迟。这种协议的应用场景类似于VoIP（Voice over Internet Protocol，网络电话）或是实时视频。
注意，上述不同类型的服务都在同一个互联网上传输。糟糕的是，正是由于分组交换技术中每个分组都独立进行转发，流量控制、资源分配等服务质量（QoS，Quality of Service）相关问题很难从宏观上较好地调控。因为，每一个转发节点都没能很好的把握整体数据流，而是陷入了单个分组转发的泥潭中。甚至，它们所处的协议层次中，没有任何关于服务质量的字段。提升它们所处的协议层次，似乎能够改善这一问题，例如设计一种“四层路由器”。如何在支撑多种类型的通信服务的前提下，综合考虑每种服务的服务质量需求，从而使得转发分组时获得全局最优，是这个问题的关键。
适应各种各样的网络
互联网架构必须能够适应各种各样的网络。 这里典型的有哪些网络？
- 由家庭成员共享的WiFi网络（住宅网络）
- 连接大学或小公司内桌面电脑的建筑级以太网网络（企业网络）
- 在谷歌、亚马逊、脸书和微软等网络公司内部的更快、更大的建筑级以太网网络（数据中心）
- 连接多个地理位置分布的数据中心的高容量私人网络（私人广域网或私人WAN）
- 由船只使用的卫星网络提供互联网访问
互联网的历史
只有理解历史才能预测未来的发展趋势，这篇论文就是试图找出互联网协议演化 至今的背后逻辑。
这段历史围绕四个不同方面展开。
- 技术演变
- 社会方面
- 商业化方面
技术演变
1962年8月，麻省理工学院的J.C.R. 利克莱德（J.C.R. Licklider）撰写了一系列备忘录，描述了通过网络实现的社交互动概念，他称之为“银河网络”概念。他设想通过全球互联的一组计算机，每个人都能够快速访问来自任何站点的数据和程序。从精神上讲，这个概念与今天的互联网非常相似。
1968年8月，经过罗伯茨和DARPA资助社区对ARPANET整体结构和规格的进一步完善后，DARPA发布了一个关于发展关键组件之一——称为接口消息处理器（IMP）的(早期的)分组交换机的RFQ
在接下来的几年里，计算机迅速加入到ARPANET中，并且继续完善主机到主机协议和其他网络软件。1970年12月，由斯蒂芬·克罗克（S. Crocker）领导的网络工作组（NWG）完成了初始的ARPANET主机到主机协议，称为网络控制协议（NCP）。随着1971年至1972年期间ARPANET站点完成NCP的实施，网络用户最终可以开始开发应用程序1972年10月，卡恩在国际计算机通信会议（ICCC）上组织了一次大规模且非常成功的ARPANET演示。这是首次向公众展示这一新网络技术。同年，也是电子邮件这一初始的“热门”应用程序被引入的时期。1972年3月，BBN的雷·汤姆林森（Ray Tomlinson）编写了基本的电子邮件发送和阅读软件，受到ARPANET开发人员需要简单协调机制的启发。随后，罗伯茨在7月扩展了其功能，编写了第一个电子邮件实用程序程序，用于列出、选择性阅读、存档、转发和回复消息这是今天我们在全球网络（World Wide Web）上看到的活动的一个前兆，即各种类型的“人与人”流量的巨大增长
卡恩早期思考的四条关键规则是：
- 每个独立的网络必须能够独立运行，连接到互联网时不需要对任何网络进行内部更改。
- 通信将以尽力而为的方式进行。如果一个数据包未能到达最终目的地，源头将很快重新传输它。
- 使用黑匣子来连接网络；后来这些会被称为网关和路由器。网关不会保留关于通过它们传输的数据包流的任何信息，从而保持简单，并避免复杂的适应和从各种故障模式中恢复。
- 在操作层面没有全局控制。
其他需要解决的关键问题包括：
- 防止丢失数据包永久禁止通信的算法，并使其能够成功地从源头重新传输。
- 提供主机到主机的“流水线处理”，以便在参与的主机允许的情况下，多个数据包可以从源头到目的地途中。
- 网关功能，使其能够适当地转发数据包。这包括解释IP头部进行路由、处理接口、必要时将数据包分成更小的片段等。
- 端到端校验和，从片段中重新组装数据包，并检测重复的数据包（如果有）。
- 全局寻址的需求。
- 主机到主机的流量控制技术。
- 与各种操作系统的接口。
- 还有其他关注点，如实现效率、互联网性能，但这些起初是次要考虑因素
卡恩在BBN期间开始了一个以通信为导向的操作系统原则工作，并在一份名为“操作系统通信原则”的BBN内部备忘录中记录了他的一些早期想法[4]。在这一点上，他意识到有必要了解每个操作系统的实现细节，以便有机会以高效的方式嵌入任何新协议。因此，1973年春季，在启动互联网工作后，他邀请当时在斯坦福大学的文特·瑟夫与他共同详细设计协议。瑟夫曾深度参与过最初的NCP设计和开发，并且已经掌握了与现有操作系统接口的知识。因此，在卡恩的通信架构方法和瑟夫的NCP经验的基础上，他们联合起来详细阐述了后来成为TCP/IP的细节。
他们的合作非常富有成效，第一版成果的文稿在1973年9月苏塞克斯大学会议上特别会议期间分发给国际网络工作组（INWG）的成员。瑟夫受邀主持这个组，并利用这个机会召开了INWG成员的会议，这些成员在苏塞克斯会议上有很强的代表性。
这次卡恩和瑟夫之间的合作产生了一些基本方法：
- 两个进程之间的通信在逻辑上被认为是一个非常长的字节流（他们称之为八位字节）。流中任何字节的位置将用于标识它。
- 流量控制将通过使用滑动窗口和确认（ACK）来完成。目的地可以选择何时确认，每个返回的确认对到目前为止接收到的所有数据包都是累积的。
- 关于源和目的地如何就窗口使用的参数达成一致，留下了开放的空间。最初使用默认值。
- 虽然以太网当时正在施乐PARC开发，但当时并未设想到局域网（LAN）的广泛普及，更不用说个人计算机和工作站了。最初的模型是像ARPANET这样的国家级网络，预计只会存在相对少量。因此，使用了32位IP地址，其中前8位表示网络，剩下的24位指定了该网络上的主机。这种假设，即256个网络在可预见的未来足够使用，显然在20世纪70年代末LAN开始出现时需要重新考虑。
- 瑟夫/卡恩关于互联网的最初论文描述了一种名为TCP的协议，该协议在互联网中提供了所有的传输和转发服务。卡恩本打算让TCP协议支持一系列的传输服务，从完全可靠的数据顺序传递（虚拟电路模型）到数据报服务，在后者中，应用程序直接使用底层网络服务，可能会导致偶尔丢失、损坏或重新排序的数据包。
- 然而，最初实现TCP的努力导致了一个只允许虚拟电路的版本。这个模型对于文件传输和远程登录应用程序效果很好，但是20世纪70年代早期关于先进网络应用的一些工作，特别是数据包语音，表明在某些情况下，数据包丢失不应该由TCP来纠正，而应该由应用程序自行处理。这导致原始TCP的重组，分为两个协议：简单的IP仅提供单个数据包的寻址和转发，而独立的TCP关注服务特性，如流量控制和丢失数据包的恢复。对于那些不需要TCP服务的应用程序，还增加了一种名为用户数据报协议（UDP）的替代方案，以便直接访问IP的基本服务。
ARPANET和互联网最初的一个重要动机是资源共享，例如允许分组无线电网络上的用户访问连接到ARPANET的分时系统。将这两者连接在一起远比复制这些非常昂贵的计算机更经济。然而，虽然文件传输和远程登录（Telnet）是非常重要的应用程序，电子邮件可能是那个时代创新中影响最大的。电子邮件提供了人们如何彼此沟通的新模式，并改变了合作的性质，首先在互联网本身的建设中（如下文所述），后来影响了社会的大部分。
在互联网早期，还提出了其他应用程序，包括基于数据包的语音通信（互联网电话的前身）、各种文件和磁盘共享模式，以及早期的“蠕虫”程序，展示了代理概念（当然还有病毒）。互联网的一个关键概念是它不仅仅设计用于单一应用程序，而是作为一个通用基础设施，可以孕育新的应用程序，正如后来世界广泛网络的出现所证明的那样。正是TCP和IP提供的通用性质贯穿其中，使这一切成为可能。
1980年代局域网（LAN）、个人电脑（PC）和工作站的广泛发展促使新兴的互联网蓬勃发展。由施乐PARC的Bob Metcalfe在1973年开发的以太网技术，现在可能是互联网上的主导网络技术，而个人电脑和工作站则成为主导计算机。从最初的少数网络和有限数量的分时主机（原始ARPANET模型）到如今的多网络环境，这一变化带来了许多新概念和对基础技术的变革。首先，这导致了三种网络类别的定义（A、B和C类），以适应各种规模的网络。A类代表大型国家级网络（少数网络，大量主机）；B类代表地区级网络；C类代表局域网（大量网络，相对较少主机）。
随着互联网规模的增长及其相关的管理问题，发生了重大转变。为了方便人们使用网络，主机被分配了名称，这样就不必记住数字地址。最初，主机数量相对有限，因此可以维护一个包含所有主机及其关联名称和地址的单一表格。然而，随着独立管理的网络（如局域网）数量的增加，维护一个单一的主机表格已不再可行，于是由USC/ISI的Paul Mockapetris发明了域名系统（DNS）。DNS允许一种可扩展的分布式机制，用于解析分层主机名（例如 www.acm.org）到互联网地址的映射
互联网规模的增加也对路由器的能力提出了挑战。最初，互联网上所有路由器均实施统一的分布式路由算法。随着互联网中网络数量的激增，这种初始设计无法满足扩展需求，因此被分层路由模型取代，每个区域内使用内部网关协议（IGP），并使用外部网关协议（EGP）将各个区域连接起来。这种设计允许不同区域使用不同的IGP，以满足成本、快速重配置、鲁棒性和规模的不同要求。
除了路由算法外，地址表的大小也对路由器的容量构成了压力。近年来，引入了新的地址聚合方法，特别是无类别域间路由（CIDR），用于控制路由器表格的大小。
随着互联网的发展，一个主要挑战是如何将变更传播到软件，特别是主机软件。DARPA支持加州大学伯克利分校研究修改Unix操作系统，包括整合BBN开发的TCP/IP协议。尽管后来伯克利将BBN代码重新编写以更有效地适配Unix系统和内核，但TCP/IP整合到Unix BSD系统的发布，成为了互联网协议传播到研究社区的关键因素之一。大部分计算机科学研究社区开始将Unix BSD用于日常计算环境。回顾历史，将互联网协议整合到支持的操作系统中，成为促进互联网成功广泛采纳的关键因素之一。
其中一个更为有趣的挑战是ARPANET从NCP协议向TCP/IP协议的过渡，于1983年1月1日正式完成。这是一次“纪念日”式的转变，要求所有主机同时转换，否则将被迫通过相当临时的机制进行通信。这次过渡在实际执行之前经过了社区多年的精心策划，而且执行过程非常顺利（但也导致了一些人制作了“我经历了TCP/IP过渡”的纪念按钮）。
TCP/IP在1980年早已被采纳为国防标准。这使得国防开始分享DARPA互联网技术基础，并直接导致了军用和非军用社区的最终分离。到1983年，ARPANET已被许多国防研发和运营组织广泛使用。ARPANET从NCP到TCP/IP的转变使其能够分为支持操作需求的MILNET和支持研究需求的ARPANET两部分。
因此，到了1985年，互联网已经作为支持广泛研究和开发社区的技术得到了很好的建立，同时开始被其他社区用于日常计算机通信。电子邮件已经广泛应用于多个社区，通常采用不同的系统，但不同邮件系统的互联互通展示了人际电子通信的实用性
RFC的建立：1969年，S. Crocker在UCLA建立了RFC系列备忘录，旨在作为一种非正式快速分发方式，与其他网络研究人员分享想法。最初，RFC以纸质形式印刷并通过普通邮件分发，后来随着文件传输协议（FTP）的使用，转变为在线文件，现在则可以通过全球众多网站的World Wide Web轻松访问。
RFC的影响：RFC创建了一个积极的反馈循环，一个RFC中的想法或提议会触发另一个带有额外想法的RFC，逐步形成共识或一致的想法集合，并准备规范文档。现在的RFC更多地专注于协议标准，被视为互联网工程和标准社区中的“记录文件”。
自由开放的文档访问：互联网快速增长的关键之一是免费开放的基本文档访问，尤其是协议规范。
学术传统的推动：ARPANET和互联网的起步促进了开放发布思想和结果的学术传统。传统学术出版的形式和速度对于创建网络所必需的动态思想交流来说太过正式和缓慢
社会影响
互联网作为一个技术集合和社群集合的双重角色，以及其成功的关键因素。以下是主要内容的概述：
- 社区精神的历史：从早期的ARPANET开始，互联网就形成了一个紧密结合的社区，这些研究人员合作完成了分组交换技术的初步演示。Packet Satellite、Packet Radio等多个DARPA计算机科学研究项目也是多承包商协作活动，利用电子邮件、文件共享、远程访问和最终的World Wide Web能力等各种可用机制协调他们的工作。
- 协调机制的演变：1969年，S. Crocker建立了RFC备忘录系列，作为一种快速非正式的分发方式，用于与其他网络研究人员分享想法。随着时间的推移，RFC逐渐专注于协议标准，并成为互联网工程和标准社区中的重要文件。
- 组织结构的发展：互联网活动委员会（IAB）和互联网工程任务组（IETF）的形成和发展，以及它们在标准制定和技术评审中的角色。1983年后，IAB通过设立任务组重新组织了协调机制，形成了各个技术领域的工作组。
- 商业化和互联网社会的发展：从1980年代初开始，互联网不再仅限于研究领域，而是包括广泛的用户社区和增加的商业活动。因此，对标准制定过程的公开性和公平性越来越重视，互联网协会的成立（1991年）标志着社区对互联网的支持进一步加强。
- 全球网络的发展：World Wide Web的发展和广泛部署带来了新的社群，特别是那些主要从事WWW开发的人员。为此成立了World Wide Web联盟（W3C），负责发展与Web相关的各种协议和标准。
商业化影响
- 早期TCP/IP的整合：上世纪80年代初，许多厂商开始将TCP/IP集成到其产品中，因为他们看到市场对这种网络方法的需求。然而，他们缺乏关于技术如何运作以及客户如何使用这种网络方法的实际信息。
- TCP/IP的教育和推广：1985年，Dan Lynch与IAB合作组织了一个为期三天的研讨会，旨在教育所有厂商TCP/IP的工作原理和其局限性。这次研讨会促成了厂商和发明家之间的双向讨论，为未来十多年的发展奠定了基础。
- Interop贸易展会的出现：1988年，第一届Interop贸易展会举办，展示了能够良好运行TCP/IP的50家公司的产品。这展会显示出各种产品能够互操作，展示了厂商为确保其产品与竞争对手的产品无缝配合所付出的努力。
- IETF会议和TCP/IP协议的发展：与商业化同时，厂商开始参加每年举行3至4次的IETF会议，讨论TCP/IP协议套件的扩展和新想法。这些会议由自愿参加的厂商社区推动，使得TCP/IP得以在一个合作的方式下不断演进和改进。
- 网络管理的发展：随着互联网规模的扩大，传统的网络管理方法显然不再适用，因此需要开发能够远程统一管理网络元素（如路由器）的协议。SNMP等协议应运而生，最终SNMP成为了几乎普遍使用的网络管理协议。
- 互联网的商业化和服务化：最近几年，互联网不仅仅是基础网络产品和连接服务的提供者，它已经成为几乎“商品化”的服务。全球信息基础设施的广泛和快速采用，特别是浏览器和World Wide Web技术的普及，使得用户能够轻松访问全球链接的信息，并且促进了更复杂的信息服务的发展。
论文阅读： 系统设计的端到端原则
摘要
这篇论文提出了一种设计原则，用于指导在分布式计算机系统的各个模块之间如何分配功能。这个原则被称为“端到端原则”（end-to-end argument）。它指出：将某些功能放在系统的底层实现，往往是冗余的，或者与其在底层实现所付出的成本相比，其价值并不高。
论文中讨论的例子包括：比特错误恢复、基于加密的安全机制、重复消息抑制、系统崩溃后的恢复，以及消息交付确认等。这些功能如果在低层实现，其合理性主要体现在提升性能，而不是作为功能正确性的唯一保障。
正文
在计算机系统设计中，如何在不同功能之间划分合适的边界，可能是设计者最核心的工作。能够指导这种“功能放置（function placement）”决策的设计原则，是系统设计者最重要的工具之一。
为什么通过通信网络来论述这个原则来指导计算机系统设计， 是否具备普适性？首先，通信网络已经称为计算机系统的一部分，其次这个作为例子更容易看清背后的原因。
当我们开发包含通信功能的系统时，通常会将通信子系统划定一个模块边界，并在其与系统其他部分之间定义一个清晰的接口。在这个过程中，可以看到有一系列功能，每一个功能都可以通过多种方式实现：由通信子系统实现、由其客户端（上层应用）实现、双方协作实现，甚至可能是冗余实现（各自实现一套）。
要决定如何实现这些功能，需要一个依据：
IMPORTANT
某个功能只有在通信系统两端的应用程序具备相关知识并参与的情况下，才能被完整且正确地实现。因此，将这个功能作为通信系统本身的一部分来实现，是不可能做到完全正确的（有时，通信系统提供一个不完整的实现版本，可能作为性能优化是有价值的。）
我们将这种反对在低层实现功能的推理称为“端到端原则”。
首先看一个经典例子，一个文件存储在计算机 A 的文件系统中，位于磁盘存储上。计算机 A 通过数据通信网络与计算机 B 相连，计算机 B 同样拥有文件系统和磁盘存储。目标是在传输过程中可能发生各种故障的情况下，将文件从 A 的存储安全地传送到 B 的存储中而不发生损坏。
我们假设具体步骤如下：
- 在主机 A 上，文件传输程序调用文件系统从磁盘读取文件（文件分布在多个磁道上），文件系统将其以固定大小的块传递给文件传输程序，这些块的大小与磁盘格式无关。
- 同样在主机 A 上，文件传输程序请求数据通信系统按照某种通信协议传输该文件，该协议会将数据拆分为数据包。数据包的大小通常不同于文件块大小和磁道大小。
- 数据通信网络将这些数据包从计算机 A 传送到计算机 B。
- 在主机 B 上，通信程序从通信协议中取出数据包，并将其中的数据交给文件传输应用程序在主机 B 上的另一部分。
- 在主机 B 上，文件传输程序请求文件系统将接收到的数据写入磁盘。
在这个模型下，一个谨慎的系统设计者可能会关注以下潜在威胁：
- 文件最初在主机 A 的磁盘上写入是正确的，但在读取时可能出现错误数据，例如由于磁盘硬件故障。
- 文件系统、文件传输程序或通信系统的软件在缓冲和复制数据时可能出错，这种错误可能发生在主机 A 或主机 B。
- 处理器或本地内存在进行缓冲和复制时可能出现瞬时错误（软错误），同样可能发生在 A 或 B。
- 通信系统可能丢失数据包、改变数据包中的比特、重复传输数据包，或发生其他错误。
- 任一主机在传输过程中可能崩溃，此时已经完成的操作数量是不确定的（可能部分完成，也可能全部完成）。
解决方案：
- 对每一个步骤进行强化。 例如使用副本、超时与重试、用于错误检测的冗余机制、崩溃恢复等，目标是将每一种威胁发生的概率降低到可接受的水平。 这也意味着必须编写完全正确的程序
- 端到端校验与重试。 为了应对第一类威胁，每个文件都附带一个校验和，传完文件后，主机B将其校验和传递给主机A，文件传输程序才认为事务完成，如果校验失败则重传。
- 如果故障确实比较少见，这种方法通常第一次就能成功；如果经常错误，说明某个组件需要修复。
现在考虑一种常见的建议： 让通信系统在内部提供“可靠数据传输”的保证，是否可行？
答案是： 第 4 类威胁（通信错误）也许被消除了，但文件传输应用仍然必须应对其他威胁（1~3、5），因此它仍然需要基于端到端校验的重试机制。既然如此，通信系统为了提供可靠传输所付出的额外努力，只是降低了应用层重试发生的频率；它并不影响最终结果的必然性或正确性。因为无论通信系统是否可靠，文件传输的正确性最终都是由端到端的校验和与重试机制来保证的。
不过，如果因此简单地得出结论“底层不应该参与可靠性”，那就过于片面了。设想一个不太可靠的网络：每发送 100 条消息就会丢失 1 条。如果采用前面描述的简单策略（先传输整个文件，再检查是否正确），随着文件长度增加，性能会迅速变差。
原因是：文件中所有数据包都正确到达的概率，会随着文件长度呈指数级下降。因此，成功传输文件所需的期望时间，会随着文件长度呈指数级增长。
因此，在数据通信系统中投入多少精力来提高可靠性，本质上是一个基于性能的工程权衡问题，而不是正确性的必要条件。需要注意的是，性能本身也是多方面的。
端到端原则本身并不能告诉我们“早期检查（early checks）应该放在哪一层”，因为这类机制只是性能优化，两层都可以实现：
- 放在应用层：通信系统更简单，但每个应用都要自己实现，整体成本可能更高
- 放在通信系统：可能更高效（例如逐跳重试可以更快纠错），但会强制所有应用承担这一成本，即使某些应用并不需要
底层子系统为分布式应用提供某个功能，但这个功能本质上仍然必须在应用层实现，因此底层的努力可能是浪费的。 另外一个例子是，交付确认。 一个数据通信网络可以很容易地在每条消息被送达接收方时，向发送方返回一个确认。 例如， ARPANET 会在成功投递一条消息后返回一个称为“RFNM（Request For Next Message）”的数据包。虽然这种确认在网络内部作为一种拥塞控制手段是有用的（最初 ARPANET 在收到前一个 RFNM 之前不会向同一目标发送新的消息），但对于使用 ARPANET 的应用来说，这种确认并没有太大帮助。
原因在于：仅仅知道消息已经送达目标主机，其实并不重要。应用真正关心的是：目标主机是否对这条消息执行了相应的操作。因为在消息送达之后、操作完成之前，可能发生各种故障。
因此，真正有意义的确认必须是“端到端”的——只能由目标应用发出，例如：“我已经完成了”，或者“我没有完成”。
另外一个例子是，重复消息抑制。 某些通信网络设计中存在这样一种特性： 一条消息（或消息的一部分）可能会被传递两次。这通常是由于网络内部的超时触发的故障检测与重试机制造成的。
网络层可以选择：检测并抑制这些重复消息 或者直接把它们都交付给上层。直觉上，人们可能认为： 如果网络可能传递重复消息，应用程序处理起来会非常麻烦——事实确实如此。但问题在于， 即使网络层已经做了重复抑制，应用层自身仍然可能产生重复请求（例如自身的重试机制）。 这些应用层产生的重复请求，在通信系统看来是“不同的消息”，因此网络层无法识别和消除它们。 因此重复抑制最终必须由应用层完成，因为只有应用层知道如何识别“自己的重复”。 一个常见的例子是远程系统用户在没有收到响应时重新登录。
另一个例子是， 大多数通信应用都会处理这样的问题，多节点事务中某一端系统崩溃，系统恢复后重新发起事务，但问题是 系统是否真的崩溃 很难判断，可能支持ACK丢失、或者是ACK延迟，如果是这样，那么重试请求就变成了重复请求，而应用层才只识别这一点。因此，这再次说明端到端原则：既然应用层必须具备重复检测机制，那么它也可以处理网络中产生的重复消息，这个功能就可以从底层省略。同样的道理也适用于消息丢失的问题。
保证消息按发送顺序到达（FIFO）通常被认为是通信子系统的功能。实现方式一般是在同一虚拟电路上保证先进先出顺序。但在不同虚拟电路之间，或者经过通信子系统之外的中间处理时，消息的到达顺序可能会与发送顺序不同。在分布式应用中，一个节点发出的请求可能会触发多个节点的操作，这种情况下，FIFO 并不能保证这些操作按照正确顺序执行，因此必须由更高层来控制顺序。
两阶段提交（2PC）也体现了端到端原则。 这些协议的正确性并不依赖于通信系统内部的可靠性、FIFO 顺序或重复抑制，因为这些问题也可能由系统其他部分的故障引入。
精简指令集计算机（RISC）的设计思想也类似于端到端原则。RISC 认为，与其在硬件中提供复杂指令，不如提供简单原语，让应用自己组合实现需要的功能，因为硬件设计者很难准确预测应用需求，最终应用往往还是需要重新实现。