网络工作组                                B. Carpenter 编辑

征求意见：1958                        IAB

分类：信息化                            1996年6月

Internet体系结构原理

该备忘录状态

本备忘录为Internet社区提供信息。 本备忘录未指定任何类型的Internet标准。 该备忘录的分发是不受限的。

摘要

互联网及其架构从开始逐渐演变发展而成，而不是规划出来的。 尽管这种演进过程是该技术成功的主要原因之一，但是记录一下Internet体系结构当前原理的快照似乎还是有用的。 这仅是为了一般指导和一般兴趣，决不是正式或不变的参考模型。

目录

1持续变化

2有没有Internet体系结构？

3一般设计问题

4名称和地址问题

5另外的问题

6保密性和认证相关内容

致谢

参考文献

安全注意事项

编辑的地址

1. 持续变化

在寻找Internet架构原则时，我们必须记住，信息技术行业中的技术变革是持续不断的。 互联网反映了这一点。 自ARPANET启动以来的25年间，各种衡量Internet大小的指标增加了1000（主干网速度）到1000000（主机数）之间的倍数。 在这种环境下，某些架构原则不可避免地会发生变化。 几年前似乎不可侵犯的原则如今已被弃用。 今天看来神圣的原则明天将被弃用。 不断变化的原则也许是互联网上应该无限期生存的唯一原则。

因此，本文档的目的不是就如何设计Internet协议，甚至如何将它们组合在一起制定教条。 相反，它传达的是过去发现有用的各种指南，这些指南可能对设计新协议或评估此类设计的人有用。

  互联网发展有一个很好的类比，它就像不断更新城市的各个街道和建筑物，而不是夷为平地并重建城市。 因此，架构原则旨在为建立合作关系和标准提供框架，作为小的包含规则的“生成集”，产生大量，变化和不断发展的技术空间。

  当前一些技术上的变化触发因素包括IPv4扩展的限制，千兆网和多媒体从根本上提出了新的挑战，以及对商用Internet服务质量和安全性保证的需求。

  正如Lord Kelvin在1895年所说的那样，“不可能有比空气更重的飞行器。” 如果我们认为下面列出的原则不仅仅是我们当前理解的一个快照，那我们就太傻了。

2. 有没有Internet体系结构？

2.1互联网社区的许多成员会争辩说，在没有记载的前25年中，没有架构，只有一种传统，（或至少IAB并未写下来）。 但是，从一般意义上讲，社区认为目标是连通性，工具是Internet协议，智能是端到端的，而不是隐藏在网络中。

   当前网络的指数增长似乎表明，连接是它自己的回报，并且比任何单独的应用程序（例如邮件或万维网）更有价值。 这种连通性需要服务提供商之间的技术合作，并在日益开放和竞争日益激烈的商业电信环境中蓬勃发展。

   全局连通性的关键是网络接口层。 在提供全局连通性的各种硬件上利用这一层的关键是“端到端论点”。

2.2 通常认为，在理想情况下，Internet级别应该只有一个协议。 这允许在竞争的，多供应商，多提供商的公共网络中进行统一且相对无缝的操作。 当然，可以有多种协议来满足其他级别的不同要求，并且有许多使用多个网络层协议的大型专用网络的成功实例。

在实践中，至少有两个原因导致公共Internet上可能使用多个网络层协议。 首先，可能需要从一种IP版本逐步过渡到另一种IP版本。 其次，从根本上讲新的要求可能会导致全新的协议。

   Internet级别协议必须独立于硬件介质和硬件寻址。 这种方法允许Internet利用任何种类的任何新数字传输技术，并将其寻址机制与硬件分离。 它使Internet成为连接根本不同的传输媒体的简便方法，并为多种信息基础结构应用程序和服务提供了一个平台。 在[Clark]中很好地阐述了该模型以及其他重要的基本问题。

2.3 通常还认为，端到端功能最好通过端到端协议来实现。

   [Saltzer]中详细讨论了端到端参数。 基本论点是，作为第一原则，某些必需的端到端功能只能由端系统本身正确执行。 一个特殊的情况是，无论如何精心设计，任何网络都将以某种统计确定的速率传输失败。 解决此问题的最佳方法是接受它，并对与终端系统的通信完整性负责。 另一特定情况是端到端安全性。

   引用[Saltzer]的话，“只有在通信系统端点的应用程序有知识和帮助的情况下，所讨论的功能才能完全正确地实现。因此，不可能将该质疑功能作为通信系统本身的特征来提供。（有时，通信系统提供的功能的不完整版本可能有助于提高性能。”）

如果我们要求应用程序能够承受部分网络故障，则此原则将产生重要后果。端对端协议设计不应依赖于网络内部的状态维护（即有关端到端通信状态的信息）。这种状态应仅在端点中维护，以使状态只有在端点本身断开时才能被破坏）这样做的直接后果是数据报比传统的虚拟电路更好，网络的工作是尽可能高效，灵活地传输数据报。其他一切都应该在边缘进行。

   为了执行其服务，网络需要维护一些状态信息：路由，保证其服务质量的QoS，在报头压缩中使用的会话信息，数据压缩的压缩历史记录等。 此状态必须是自我修复的； 必须存在自适应过程或协议才能派生和维护该状态，并在网络的拓扑或活动发生变化时对其进行更改。 在存在连接的情况下，必须最小化此状态的数量，并且状态的丢失不得导致暂时的拒绝服务。 手动配置的状态必须保持在绝对最小值。

2.4 幸运的是，互联网不属于任何人，没有集中控制，也没有人可以关闭它。 它的发展取决于对技术方案和运行代码的大致共识。

  来自实际实现的工程反馈比任何体系结构原理都重要。

3. 一般设计问题

3.1 异质性是不可避免的，必须得到设计的支持。

  必须允许多种类型的硬件，例如 传输速度至少相差7个数量级，各种计算机字长以及从内存不足的微处理器到大规模并行超级计算机的主机。 必须允许多种类型的应用程序协议，从最简单的诸如远程登录到最复杂的诸如分布式数据库。

3.2 如果有多种方法可以执行相同的操作，请选择一种。

  如果以前的设计在Internet上下文中或其他地方成功解决了相同的问题，请选择相同的解决方案，除非有很好的技术理由不这样做。 应尽可能避免相同协议功能的重复，当然不要使用此原则来拒绝改进。

3.3 所有设计必须易于扩展到每个站点很多节点以及数百万个站点。

3.4必须同时考虑性能和成本以及功能。

3.5保持简单。在设计过程中如有疑问，请选择最简单的解决方案。

3.6模块化是好的。如果可以分开放置，应当这样做。

3.7在许多情况下，最好立即采用几乎完整的解决方案，而不是等到找到完美的解决方案。

3.8尽可能避免使用选项和参数。 任何选项和参数都应动态配置或协商，而不要手动配置。

3.9发送时要严格，接收时要宽容。

   在发送到网络时，实现必须严格遵循规范，并容忍来自网络的错误输入。如有疑问，除非规范要求，否则请静默丢弃错误的输入，而不返回错误消息。

3.10与未经请求的数据包保持一致，尤其是多播和广播。

3.11必须避免循环依赖。

   例如，路由必须不依赖于域名系统（DNS）中的查找，因为DNS服务器的更新取决于成功的路由。

3.12对象应在合理范围内自我描述（包括类型和大小）。 只能使用Internet号码分配机构（IANA）分配的类型代码和其他数字。

3.13所有规范应使用相同的术语和符号，以及相同的位和字节顺序约定。

3.14也许是最重要的一点：只有在有多个正在运行的代码实例之前，一切都没有标准。

4. 名称和地址问题

4.1避免进行任何需要对地址进行硬编码或将其存储在非易失性存储中的设计（当然，这是必不可少的要求，例如在名称服务器或配置服务器中）。

   通常，用户应用程序应使用名称而不是地址。

4.2应该使用单个命名结构。

4.3公共（即广泛可见）名称应使用不区分大小写的ASCII。 具体来说，这指的是DNS名称，以及以文本格式传输的协议元素。

4.4地址必须是明确的（在可能出现的任何范围内都是唯一的）。

4.5上层协议必须能够明确标识端点。 在今天的实践中，这意味着在传输的开始和结束时地址必须相同。

5. 另外的问题

5.1首选无专利技术，但是如果最好的技术已获得专利并且可以合理的条件提供给所有人，则可以并入专利技术。

5.2互联网技术某些方面的出口管制仅在选择将哪种技术纳入标准中具有次要重要性。 实施Internet标准所需的所有技术都可以在每个国家/地区制造，因此Internet技术的全球部署并不取决于其从任何特定国家/地区的可出口性。

5.3任何不包括所有必需组件的实施都不能要求符合标准。

5.4设计应完全国际化，并支持本地化（适应本地字符集）。 特别地，应该有一种统一的方法来标记信息内容的字符集。

6. 保密性和安全性相关内容

6.1所有设计都必须适合IP安全体系结构。

6.2非常需要互联网运营商保护所有流量的隐私和真实性，但这不是体系结构的要求。 机密性和身份验证是最终用户的责任，必须在最终用户使用的协议中实现。 端点不应取决于运营商的机密性或完整性。 运营商可以选择提供某种程度的保护，但这仅次于最终用户保护自己的主要责任。

6.3在协议中要求使用密码算法的任何地方，都应将该协议设计为允许使用替代算法，并且应明确标记在特定实现中采用的特定算法。 算法的正式标签应由IANA记录。（该原理可以推广到安全领域之外，这样说有争议。）

6.4在选择算法时，该算法应被广泛认为足以满足该目的。 在所有这些都足够强大的替代方案中，应该优先考虑那些经过时间考验并且并非不必要地效率低下的算法。

6.5为确保使用安全服务的端点之间的互操作，应强制要求一种算法（或算法套件）以确保在实现之间协商安全上下文的能力。 否则，实现可能没有共同的算法，也无法安全通信。

致谢

本文档是Internet社区委员会的集体工作，由Internet体系结构委员会发布。 特别感谢Fred Baker，Noel Chiappa，Donald Eastlake，Frank Kastenholz，Neal McBurnett，Masataka Ohta，Jeff Schiller和Lansing Sloan。

参考文献

请注意，这些参考文献被故意限制为有关Internet体系结构的两篇基本论文。

[Clark] The Design Philosophy of the DARPA Internet Protocols,D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988,pages 106-114 (reprinted in ACM CCR Vol 25, Number 1, January 1995,pages 102-111).

[Saltzer] End-To-End Arguments in System Design, J.H. Saltzer,D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp277-288.

安全注意事项

   本备忘录中讨论了安全问题。

编辑的地址

Brian E. Carpenter

Group Leader, Communications Systems

Computing and Networks Division

CERN

European Laboratory for Particle Physics

1211 Geneva 23, Switzerland

Phone: +41 22 767-4967

Fax: +41 22 767-7155

EMail: brian@dxcoms.cern.ch

最后

以上就是娇气铃铛为你收集整理的[译]RFC1958——Architectural Principles of the InternetInternet体系结构原理的全部内容，希望文章能够帮你解决[译]RFC1958——Architectural Principles of the InternetInternet体系结构原理所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。