跳到主要内容

1. 简介 (INTRODUCTION)

本文档是定义和讨论互联网协议套件主机系统实现要求的一对文档之一。本 RFC 涵盖通信协议层: 链路层、IP 层和传输层。其配套 RFC "互联网主机要求 -- 应用层和支持" [INTRO:1] 涵盖应用层协议。本文档还应与"互联网网关要求" [INTRO:2] 结合阅读。

这些文档旨在为互联网通信软件的供应商、实现者和用户提供指导。它们代表了互联网研究和供应商社区成员贡献的大量技术经验和智慧的共识。

本 RFC 列举了连接到互联网的主机必须使用的标准协议, 并通过引用描述这些协议当前规范的 RFC 和其他文档。它纠正了引用文档中的错误, 并为实现者添加了额外的讨论和指导。

对于每个协议, 本文档还包含一套明确的要求、建议和选项。读者必须理解, 本文档中的要求列表本身是不完整的; 互联网主机的完整要求集主要在标准协议规范文档中定义, 本 RFC 中包含了更正、修订和补充。

在仔细阅读 RFC 并与互联网技术社区进行一些交流后, 遵循良好通信软件工程实践而产生的协议的善意实现, 应该只在细微方面与本文档的要求有所不同。因此, 在许多情况下, 本 RFC 中的"要求"已经在标准协议文档中陈述或暗示, 因此在这里包含它们在某种意义上是多余的。然而, 它们被包含在内是因为过去的某些实现做出了错误的选择, 导致了互操作性、性能和/或健壮性方面的问题。

本文档包含对许多要求和建议的讨论和解释。简单的要求列表是危险的, 因为:

  • 某些必需功能比其他功能更重要, 某些功能是可选的。
  • 可能存在有效的理由, 使得为受限上下文设计的特定供应商产品可能选择使用不同的规范。

然而, 必须遵循本文档的规范, 以满足在互联网系统的多样性和复杂性中实现任意主机互操作的总体目标。尽管大多数当前实现在各种方面未能满足这些要求 (有些是次要的, 有些是主要的), 但本规范是我们需要努力达到的理想。

这些要求基于互联网架构的当前水平。本文档将根据需要更新, 以提供额外的澄清或在规范仍在演进的领域包含额外信息。

本引言部分首先简要概述了与主机相关的互联网架构, 然后给出了一些对主机软件供应商的一般建议。最后, 提供了一些关于阅读文档其余部分的指导和一些术语。

1.1 互联网架构 (The Internet Architecture)​

关于互联网架构和支持协议套件的一般背景和讨论可以在 DDN 协议手册 [INTRO:3] 中找到。

1.1.1 互联网主机 (Internet Hosts)​

主机计算机, 或简称"主机", 是通信服务的最终消费者。主机通常代表用户执行应用程序, 使用网络和/或互联网通信服务来支持此功能。互联网主机对应于 OSI 协议套件 [INTRO:13] 中使用的"终端系统 (End-System)"概念。

互联网通信系统由互联的分组网络组成, 支持使用互联网协议的主机计算机之间的通信。这些网络使用称为"网关 (gateways)"或"IP 路由器"的分组交换计算机互联。RFC "互联网网关要求" [INTRO:2] 包含互联网网关的官方规范。该 RFC 与本文档及其配套文档 [INTRO:1] 一起定义了互联网架构当前实现的规则。

互联网主机在大小、速度和功能方面跨度很大。它们的大小从小型微处理器到工作站再到大型机和超级计算机不等。在功能上, 它们从单一用途主机 (如终端服务器) 到支持各种在线网络服务的全功能主机不等, 通常包括远程登录、文件传输和电子邮件。

如果主机有多个接口连接到相同或不同的网络, 通常称为多宿主 (multihomed)。参见第 3.3.4 节关于多宿主的讨论。

1.1.2 架构假设 (Architectural Assumptions)​

当前互联网架构基于一组关于通信系统的假设。与主机最相关的假设如下:

(a) 互联网是网络的网络。

每台主机直接连接到某个特定网络; 它与互联网的连接只是概念上的。同一网络上的两台主机使用与它们与远程网络上的主机通信时相同的协议集相互通信。

(b) 网关不保存连接状态信息。

为了提高通信系统的健壮性, 网关被设计为无状态的, 独立地转发每个 IP 数据报。因此, 可以利用冗余路径在中间网关和网络发生故障时提供健壮的服务。

端到端流量控制和可靠性所需的所有状态信息都在主机中实现, 在传输层或应用程序中。所有连接控制信息因此与通信的端点共同定位, 因此只有在端点发生故障时才会丢失。

(c) 路由复杂性应在网关中。

路由是一个复杂而困难的问题, 应该由网关而不是主机来执行。一个重要目标是将主机软件与互联网路由架构不可避免的演进所引起的变化隔离开来。

(d) 系统必须容忍广泛的网络变化。

互联网设计的基本目标是容忍广泛的网络特性 —— 例如带宽、延迟、数据包丢失、数据包重排序和最大数据包大小。另一个目标是对单个网络、网关和主机故障的健壮性, 使用任何仍然可用的带宽。最后, 目标是完全的"开放系统互连": 互联网主机必须能够通过多样化的互联网路径与任何其他互联网主机健壮而有效地互操作。

1.1.3 互联网协议套件 (Internet Protocol Suite)​

要使用互联网系统进行通信, 主机必须实现构成互联网协议套件的分层协议集。主机通常必须至少实现每层的一个协议。

互联网架构中使用的协议层如下 [INTRO:4]:

应用层 (Application Layer)

应用层是互联网协议套件的顶层。互联网套件不进一步细分应用层, 尽管某些互联网应用层协议确实包含一些内部子层。互联网套件的应用层本质上结合了 OSI 参考模型的顶两层 —— 表示层和应用层 —— 的功能。

我们区分两类应用层协议: 直接向用户提供服务的用户协议, 以及提供公共系统功能的支持协议。用户和支持协议的要求将在配套 RFC [INTRO:1] 中找到。

最常见的互联网用户协议是:

  • Telnet (远程登录)
  • FTP (文件传输)
  • SMTP (电子邮件传递)

还有许多其他标准化用户协议 [INTRO:4] 和许多私有用户协议。

用于主机名映射、引导和管理的支持协议包括 SNMP、BOOTP、RARP 和域名系统 (DNS) 协议。

传输层 (Transport Layer)

传输层为应用程序提供端到端通信服务。目前有两种主要的传输层协议:

  • 传输控制协议 (Transmission Control Protocol, TCP)
  • 用户数据报协议 (User Datagram Protocol, UDP)

TCP 是一种可靠的面向连接的传输服务, 提供端到端可靠性、重新排序和流量控制。UDP 是一种无连接 ("数据报") 传输服务。

互联网层 (Internet Layer)

所有互联网传输协议都使用互联网协议 (IP) 将数据从源主机传送到目的主机。IP 是一种无连接或数据报互联网服务, 不提供端到端传递保证。因此, IP 数据报可能以损坏、重复、乱序或根本不到达的方式到达目的主机。IP 之上的层负责在需要时提供可靠的传递服务。IP 协议包括寻址、服务类型规范、分片和重组以及安全信息的规定。

ICMP 是一种控制协议, 被认为是 IP 不可分割的组成部分, 尽管它在架构上分层于 IP 之上。ICMP 提供错误报告、拥塞报告和第一跳网关重定向。

IGMP 是一种互联网层协议, 用于建立 IP 组播的动态主机组。

链路层 (Link Layer)

要在其直接连接的网络上通信, 主机必须实现用于与该网络接口的通信协议。我们称之为链路层或媒体访问层协议。

链路层协议种类繁多, 对应于许多不同类型的网络。参见第 2 章。

1.1.4 嵌入式网关代码 (Embedded Gateway Code)​

某些互联网主机软件包含嵌入式网关功能, 使这些主机可以像网关一样转发数据包, 同时仍然执行主机的应用层功能。

此类双用途系统在其网关功能方面必须遵循网关要求 RFC [INTRO:2], 在其主机功能方面必须遵循本文档。在所有重叠情况下, 两个规范应该一致。

1.2 一般考量 (General Considerations)​

互联网主机软件的供应商已经学到了两个重要教训, 新供应商应该认真考虑。

1.2.1 互联网的持续演进 (Continuing Internet Evolution)​

互联网的巨大增长揭示了大型基于数据报的分组通信系统中管理和扩展方面的问题。这些问题正在得到解决, 因此本文档中描述的规范将持续演进。这些变化将被仔细规划和控制, 因为供应商和负责网络运营的组织广泛参与了这一规划。

1.2.2 健壮性原则 (Robustness Principle)​

在协议的每一层, 都有一条通用规则, 其应用可以在健壮性和互操作性方面带来巨大好处 [IP:1]:

"在你接受的方面要宽容, 在你发送的方面要保守" (Be liberal in what you accept, and conservative in what you send)

软件应该被编写为处理每一种可能的错误, 无论多么不可能; 迟早会有一个数据包带着那种特定的错误和属性组合出现, 除非软件做好了准备, 否则可能会造成混乱。一般来说, 最好假设网络充满了恶意实体, 它们会发送设计为产生最坏可能效果的数据包。这种假设将导致适当的保护性设计。

对变化的适应性必须设计到互联网主机软件的所有级别中。作为一个简单的例子, 考虑一个包含特定头部字段值枚举的协议规范 —— 例如类型字段、端口号或错误代码; 必须假设此枚举是不完整的。因此, 如果协议规范定义了四种可能的错误代码, 当出现第五种代码时软件不得崩溃。未定义的代码可以被记录 (见下文), 但不得导致失败。

1.2.3 错误日志 (Error Logging)​

互联网包含各种各样的主机和网关系统, 每个系统实现许多协议和协议层, 其中一些在其互联网协议软件中包含错误和缺陷。由于复杂性、多样性和功能分布, 互联网问题的诊断通常非常困难。

如果主机实现包含精心设计的记录错误或"奇怪"协议事件的设施, 问题诊断将得到帮助。在记录错误时包含尽可能多的诊断信息非常重要。特别是, 记录导致错误的数据包的头部通常很有用。但是, 必须注意确保错误日志不会消耗过多资源或以其他方式干扰主机的操作。

1.2.4 配置 (Configuration)​

理想情况下, 互联网协议套件的主机实现可以完全自配置。这将允许整个套件在 ROM 中实现或铸入硅片, 它将简化无盘工作站, 并且对于忙碌的 LAN 管理员以及系统供应商来说将是一个巨大的福音。我们还没有达到这个理想; 事实上, 我们甚至还没有接近。

在本文档的许多地方, 你会发现要求某个参数是可配置选项的要求。此类要求背后有几个不同的原因。在少数情况下, 目前存在不确定性或关于最佳值的分歧, 将来可能需要更新推荐值。在其他情况下, 该值确实取决于外部因素, 自调整算法不可用且可能不足。在某些情况下, 可配置性是由于管理要求而需要的。

1.3 阅读本文档 (Reading this Document)​

1.3.1 组织结构 (Organization)​

协议分层通常用作实现网络软件的组织原则, 也用于组织本文档。在描述规则时, 我们假设实现严格反映协议的分层。因此, 以下三个主要部分分别规定了链路层、互联网层和传输层的要求。配套 RFC [INTRO:1] 涵盖应用级软件。

1.3.2 要求 (Requirements)​

在本文档中, 用于定义每个特定要求重要性的词语均大写。这些词语是:

"MUST" (必须)

此词或形容词"REQUIRED (必需)"意味着该项目是规范的绝对要求。

"SHOULD" (应该)

此词或形容词"RECOMMENDED (推荐)"意味着在特定情况下可能存在忽略此项目的有效理由, 但在选择不同方案之前应充分理解其全部含义并仔细权衡。

"MAY" (可以)

此词或形容词"OPTIONAL (可选)"意味着该项目是真正可选的。一个供应商可能选择包含该项目, 因为特定市场需要它或因为它增强了产品; 另一个供应商可能省略同一项目。

如果实现未能满足其实现的协议的一个或多个 MUST 要求, 则该实现不合规。满足其协议的所有 MUST 和所有 SHOULD 要求的实现被称为"无条件合规"; 满足所有 MUST 要求但不满足所有 SHOULD 要求的实现被称为"有条件合规"。

1.3.3 术语 (Terminology)​

本文档使用以下技术术语:

段 (Segment)

段是 TCP 协议中端到端传输的单位。段由 TCP 头部后跟应用数据组成。段通过封装在 IP 数据报内传输。

消息 (Message)

在对下层协议的描述中, 消息是传输层协议中传输的单位。特别是, TCP 段是一条消息。消息由传输协议头部后跟应用协议数据组成。

IP 数据报 (IP Datagram)

IP 数据报是 IP 协议中端到端传输的单位。IP 数据报由 IP 头部后跟传输层数据组成。

数据包 (Packet)

数据包是在互联网层和链路层之间的接口上传递的数据单位。它包括 IP 头部和数据。数据包可以是完整的 IP 数据报或 IP 数据报的片段。

帧 (Frame)

帧是链路层协议中传输的单位, 由链路层头部后跟数据包组成。

连接网络 (Connected Network)

主机接口连接的网络通常称为相对于该主机的"本地网络"或"子网络"。但是, 这些术语可能引起混淆, 因此我们在本文档中使用术语"连接网络"。

多宿主 (Multihomed)

如果主机有多个 IP 地址, 则称该主机为多宿主。

MTU

最大传输单元, 即可以传输的最大数据包的大小。

1.4 致谢 (Acknowledgments)​

本文档吸收了大量互联网协议专家的贡献和意见, 包括大学和研究实验室、供应商和政府机构的代表。它主要由互联网工程任务组 (IETF) 的主机要求工作组汇编。

最后于 更新