RFC 1122A

时间 2020-01-25

标签 rfc 1122a 繁體版

原文原文链接

网络工做组互联网工程任务组
征求意见：1122 R. Braden，编辑
1989年10月算法

Internet主机的要求 - 通讯层

本备忘录的状态缓存

此RFC是Internet社区的官方规范。它
经过引用，修改，纠正和补充
与主机相关的主协议标准文档。分配
这份文件是无限的。安全

概要服务器

这是定义和讨论需求的一对RFC
用于Internet主机软件。该RFC涵盖了通讯
协议层：链路层，IP层和传输层; 它的
配套RFC-1123涵盖了应用程序和支持协议。网络

目录

1.介绍...............................................五
1.1互联网架构.............................. 6
1.1.1互联网主机.................................... 6
1.1.2建筑假设......................... 7
1.1.3互联网协议套件........................... 8
1.1.4嵌入式网关代码............................. 10
1.2通常考虑因素................................. 12
1.2.1继续互联网发展..................... 12
1.2.2稳健性原则.............................. 12
1.2.3错误记录..................................... 13
1.2.4配置..................................... 14
1.3阅读本文件.................................. 15
1.3.1组织...................................... 15
1.3.2要求...................................... 16
1.3.3术语....................................... 17
1.4致谢........................................ 20数据结构

LINK LAYER .............................................. .... 21
2.1引言........................................... 21

互联网工程任务组[第1页]
架构

RFC1122引言1989年10月app

2.2议定书步行.................................. 21
  2.3具体问题........................................ 21
     2.3.1预告片协议谈判...................... 21
     2.3.2地址解析协议 -  ARP ................ 22
        2.3.2.1 ARP缓存验证......................... 22
        2.3.2.2 ARP包队列............................. 24
     2.3.3以太网和IEEE 802封装............... 24
  2.4 LINK / INTERNET LAYER INTERFACE .......................... 25
  2.5连接层要求摘要........................ 26

INTERNET LAYER PROTOCOLS .................................... 27
3.1引言............................................ 27
3.2协议步行.................................. 29
3.2.1互联网协议 - IP ............................ 29
3.2.1.1版本号............................... 29
3.2.1.2校验和..................................... 29
3.2.1.3寻址................................... 29
3.2.1.4碎片和重组................. 32
3.2.1.5识别................................ 32
3.2.1.6服务类型.............................. 33
3.2.1.7生存时间................................. 34
3.2.1.8选项...................................... 35
3.2.2互联网控制消息协议 - ICMP .......... 38
3.2.2.1目的地没法到达...................... 39
3.2.2.2重定向..................................... 40
3.2.2.3源淬火................................ 41
3.2.2.4超过期间................................ 41
3.2.2.5参数问题............................ 42
3.2.2.6回应请求/回复........................... 42
3.2.2.7信息请求/回复.................... 43
3.2.2.8时间戳和时间戳回复................ 43
3.2.2.9地址掩码请求/回复................... 45
3.2.3互联网组管理协议IGMP ........... 47
3.3具体问题........................................ 47
3.3.1路由出站数据报........................ 47
3.3.1.1本地/远程决策........................ 47
3.3.1.2网关选择............................ 48
3.3.1.3路由缓存.................................. 49
3.3.1.4死网关检测....................... 51
3.3.1.5新网关选择........................ 55
3.3.1.6初始化............................... 56
3.3.2从新组装........................................ 56
3.3.3碎片..................................... 58
3.3.4本地多宿主................................. 60
3.3.4.1简介................................. 60
3.3.4.2多宿主要求..................... 61
3.3.4.3选择源地址.................... 64
3.3.5源路由转发........................... 65

互联网工程专责小组[第2页]
异步

RFC1122引言1989年10月ide

3.3.6广播........................................ 66
     3.3.7 IP组播................................... 67
     3.3.8错误报告................................... 69
  3.4互联网/传输层接口..................... 69
  3.5互联网层要求摘要.................... 72

4.运输协议......................................... 77
4.1用户数据协议 - UDP .......................... 77
4.1.1引言...................................... 77
4.1.2协议步行............................. 77
4.1.3具体问题................................... 77
4.1.3.1港口........................................ 77
4.1.3.2 IP选项................................... 77
4.1.3.3 ICMP消息................................ 78
4.1.3.4 UDP校验和................................ 78
4.1.3.5 UDP多宿主.............................. 79
4.1.3.6无效地址............................ 79
4.1.4 UDP /应用层接口................... 79
4.1.5 UDP要求摘要.......................... 80
4.2传输控制协议 - TCP ................... 82
4.2.1引言...................................... 82
4.2.2协议步行............................. 82
4.2.2.1众所周知的端口............................. 82
4.2.2.2使用Push .................................. 82
4.2.2.3窗口尺寸.................................. 83
4.2.2.4紧急指针............................... 84
4.2.2.5 TCP选项.................................. 85
4.2.2.6最大段大小选项.................. 85
4.2.2.7 TCP校验和................................. 86
4.2.2.8 TCP链接状态图................. 86
4.2.2.9初始序列号选择............ 87
4.2.2.10同时开放尝试.................. 87
4.2.2.11从旧的重复SYN中恢复.....................
4.2.2.12 RST段................................. 87
4.2.2.13关闭链接........................ 87
4.2.2.14数据通讯.......................... 89
4.2.2.15重传超时...................... 90
4.2.2.16管理窗口......................... 91
4.2.2.17探测零窗口........................ 92
4.2.2.18被动OPEN呼叫.......................... 92
4.2.2.19生存时间................................ 93
4.2.2.20事件处理............................ 93
4.2.2.21确认排队的段............... 94
4.2.3具体问题................................... 95
4.2.3.1重传超时计算........... 95
4.2.3.2什么时候发送ACK段.................. 96
4.2.3.3什么时候发送窗口更新................. 97
4.2.3.4什么时候发送数据............................ 98

互联网工程专责小组[第3页]

RFC1122引言1989年10月

4.2.3.5 TCP链接失败...................... 100
        4.2.3.6 TCP保持活动.............................. 101
        4.2.3.7 TCP多宿主.............................. 103
        4.2.3.8 IP选项................................... 103
        4.2.3.9 ICMP消息................................ 103
        4.2.3.10远程地址验证................... 104
        4.2.3.11 TCP流量模式........................ 104
        4.2.3.12效率.................................. 105
     4.2.4 TCP /应用层接口................... 106
        4.2.4.1异步报告......................... 106
        4.2.4.2服务类型.............................. 107
        4.2.4.3冲洗呼叫................................... 107
        4.2.4.4多宿主.................................. 108
     4.2.5 TCP要求摘要........................... 108

5.参考............................................... .. 112

本文档定义并讨论了主机系统实现IP协议簇的要求,涵盖了链路层、IP层和传输层三个通讯协议层。与之相应的RFC文档“因特网主机要求--应用与支持”[INTR：1]阐述了应用层的协议，同时参阅“因特网网关要求”[INTRO：2]。

这些文档旨在为因特网通讯软件的开发者、实现者及用户提供指导。这些文档凝聚了Internet研究和开发组织的相关人员的许多技术经验与智慧。

本文档列举了主机连上因特网所必须的标准协议参照了相关的RFC文档和其余文档中关于这些协议最新的描述。修正了参考文档中的一些错误并为实现者增长了额外的讨论和指导。

对于每一个协议，文档中包含了详细的必需要求、推荐要求和可选要求。读者们应当明确文档中所述的必需要求并不完备，对于因特网主机完整的要求主要是在标准协议文档中定义。本RFC只是对其进行修改、修正和完善。

若是一个协议是在认真阅读了RFC的标准并与因特网技术社团有了必定的交互，同时按照软件工程要求进行良好的沟通的基础上完成的，那么这个协议于本文档的要求应该基本吻合。对于协议较好的实现是同时，本RFC中所述的“要求”已经在标准文档中阐述过了，所以，在不少状况下，本RFC中的“要求”已在陈述中暗示或暗示标准协议文件，所以它们包含在这里，在一个感受，多余。然而，他们被包括在内是由于有些过去实施作出了错误的选择，形成了问题互操做性，性能和/或健壮性问题。
本文档包括了许多的要求和推荐项。简单地列出全部的要求是很危险的，由于： 1. 有些要求比其余的更重要，而还有一部分是可选的内容。

有一些产品因为设计在严格的上下文环境中所以可能选择使用一些不一样的规程。

但对于面向通常需求的主机为了在交互中适应因特网的多样性和复杂性，必需要听从本文档的规程规定。虽然在实际上有许多的实现并无彻底按照本文档所述的要求，但这些规程是理想的模式，也是咱们努力的方向。

这些要求是基于现行的因特网体系结构的层次设计的。随着其余的规程的不断发展，文档所述的内容也须要更新，加以辨别或者添加新的信息。

介绍部分由与主机相关的因特网体系结构的概貌开始，并给主机软件生产商一些总体的意见。最后会有一些阅读文档的剩余部分和术语的一些指导。
1.1 因特网体系结构

因特网的体系结构和支持协议簇可参照DDN协议手册[INTRO：3]，背景

资料举例参照[INTRO：9][INTRO：10][INTRO：11]。[INTRO：5]的参考描述了得到因特网协议文档的过程；[INTRO：6]包含了IP协议分配的一系列序号。 1.1.1 Internet主机

一个主机电脑，也就是常说的“主机”是通讯服务的最后客户端。主机经过网络和/或使用因特网通讯服务表明用户执行应用层程序。而因特网主机就是OSI协议簇[INTRO：13]中“端系统(end-system)”的概念。

因特网通讯系统由互联的网络构成，这些网络支持了经过IP协议相互通讯的主机电脑。网络间的互联是经过使用分组交换的电脑即因特网社区里所说的“网关(gateway)”或“IP路由器(IProute)”，也就是OSI中的“媒介系统(intermeida system)”。RFC“因特网网关要求[INTRO：2]”包含了因特网网关的官方规程。那篇RFC、本文档和[INTRO：1]定义了现行的因特网体系结构的实现规则。

因特网主机有不少不一样的大小，速度和功能。在大小上，主机的虽然能够小到工做站的微处理器大到大型机和超级计算机。在功能上，主机小到单目标主机(譬如服务器终端)大到支持许多线上网络服务，尤为是包括远程登陆，文件传输和电子邮件的服务齐全的主机。
若是主机有多个接口，或不一样的网络，那么它就会被称为多主宿主，见术语1.1.3节。

1.1.2 体系结构设想

现行的因特网体系结构是基于通讯系统的设想。之中与主机相关的设想以下：

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

每一个主机都与某个特定的网络直接相连，但这种链接只是概念上的。处于同一网络的两台主机只有在对远程网络的通讯中采用一组相同协议的条件下才能进行通讯
理解：主机与主机链接是逻辑上的，而且二者都须要用同种协议进行通信。
(b) 网关不能保存链接状态信息

为了加强通讯系统的健壮性，网关旨在独立于其余数据报来转发每一个IP数据报。结果，虽然中间网关和网络有可能失败，为了保证服务的健壮性能够找出其余的通路。
理解：网关不处理网络层以上的信息，保证服务的健壮性。
全部端到端的流控制和可靠性所需的状态信息是在主机传输层或应用层实现的。而全部的链接控制信息是在通讯的端点产生的，故仅当端点失败时信息会丢失。
理解：流控和可靠性由传输层或者应用层实现，例如TCP/IP的流控以及可靠性，QOS，都是在传输层实现；链接信息在端点产生。
(c) 路由的复杂性由网关处理

路由是一个复杂又困难的问题必须有网关而不是主机来处理。一个重要的目标就是使主机软件能屏蔽不可避免的因特网路由体系发展带来的变化。
理解：路由功能交由网关处理，避免internet技术的变化对于主机的影响。

(d) 系统必须可以适应普遍的网络变化

因特网设计的根本目标是适应各类网络的状况--譬如带宽、延时、分组丢失、分组重排和最大分组大小。另外一个目标是在面对使用各类不一样带宽的网络、网关和主机时，能够保持健壮性。最后的目标是达到保全的“开放系统互连(OSI)”：使得每一个因特网主机能够同多不一样的因特网通路与其余因特网主机健壮地有效地合做。
有时主机实现者的设计目标较为模糊，好比，局域网环境显然要比整个因特网状况更好，局域网的丢包率较低，时延较少并且不进行分组重传。有些生产商在简单的局域网上较好地实现了主机系统，但在总体的互联上状况很糟糕。生产上判断一件产品是否经济可行实在有限的局域网市场上试验的。可是被隔离的局域网并不一直是孤立的，它们经过网关相互相连，链接到某个组织内的网络，最终链接到整个因特网。最后顾客和生产者都是用的是彻底的标准的因特网主机软件。

本文档中指出的要求是为能完成完备的功能的因特网主机而设计的，可以经过任意的因特网通路达到完备的互用性。
理解：广域网具备的网络特征：带宽，延迟，包丢失，包重排序，以及包过小，，有些主机软件，系统，服务器在局域网能很好的运行，可是在广域网上却很糟糕，所以生产者都会用彻底符合标准的软件。
1.1.3 互联网协议簇
互联网系统进行通讯，主机必须包含互联网协议的一套分层协议，一个主机必须在每一层上至少实现一个协议。协议层以下描述

应用层

应用层是互联网协议簇中的最高层。虽然有一些因特网应用层协议确实包含了一些内部的子层划分，但基于因特网的软件集并无再把应用层再划分子层。因特网软件集中的应用层协议必须包含最高两层--表示层和应用层--根据OSI参考模型的规定。

咱们将应用层协议分为两类：直接为用户提供服务的用户协议和提供系统功能的支持协议。对于用户和支持协议的要求将在相关的RFC文档中找到[INTRO：1]。

最常使用的因特网用户协议包括： a)Telnet(用于远程登陆) b)FTP(用于文件传输) c)SMTP(电子邮件发送) 同时还有许多标准化的用户协议[INTRO：4]和许多私有用户协议。

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

传输层

传输层为应用层提供了端到端的通讯服务。如今主要有两种传输层协议：

a)传输控制协议()TCP0 b)用户数据报协议(UDP)

TCP是面向链接的传输服务提供端到端的可靠传输，从新排序和流控制。UDP是一个面向非链接的传输服务。

传输层协议将在第四章中进行讨论。 3. 网络层

全部的因特网传输层协议都使用了IP协议将数据由源主机传送至目的主机。IP指一个面向非链接的网络服务，不提供端到端的保证。
这样，IP数据报有可能在到达目的主机时就已经被破坏、重传、乱序或安全到达。IP以上的各层在须要时负责服务的可靠性。IP协议包括了寻址、服务类型、分片、重组和安全信息的规定。

IP协议的面向非链接是因特网体系结构的一项根本的典型的特征。因特网IP是OSI面向非链接的网络协议的模型[INTRO：12]。

ICMP是IP不可分割的一个控制协议，虽然在体系结构上，它位于IP层，但它像传输层协议TCP或UDP协议同样使用IP分组来携带数据。ICMP包括错误报告，拥塞报告和第一跳网关重定向。 IGMP是用于创建可以进行IP多播的动态主机组的网络层协议。 IP、ICMP、IGMP这些网络层协议将在第三章中进行讨论。 4. 链路层

主机为了在直接相连的网络中进行通讯必须实现接口与网络相连的通讯协议。咱们称之为链路层或媒体介入层协议。

在许多不一样类型的网络上有许多链路层的协议与之相适应，请参照第二章。

嵌入式网关代码

有些因特网主机软件包含了嵌入式的网关功能，那么这些主机在执行主机的应用层功能时就能够像王冠同样转发分组。

这样双目的的系统必须既按照网关要求的RFC规定[INTRO：2]又按照针对其主机功能的文档规定。在全部相交迭的状况中这两个规定必须达成一致。

对于主机中嵌入网关的功能因特网社区内有许多不一样的意见。主要的争议以下：

1.优势：

在网络不太规范的独立的本地网络中，是主机具备网关的功能多是方便又经济的。

但也有许多对于嵌入式网关功能的体系结构上的争议：多宿主的应用比早期的碰见要广泛得多而多宿主的功能uaoxiu 主机箱王冠同样作出路由选择。若是多宿主主机包含了一个嵌入式的网关，它就能够很好地进行路由并做出理想的路由选择。

2.缺点：

网关算法和协议一直不断改变并将随着因特网系统的发展而继续改变。在主机IP层中加入网关的功能的尝试将会迫使主机系统跟随着这些改变而不断更新。最后网关IP层一般比主机的更复杂，这就使得这一实现和操做更加复杂。

这两种观点都各有优势，从中能够得出一个结论：主机管理员必须对因而否使主机扮演网关的角色有明确的控制。参照3.1节的详细说明。

1.2 总体设计

因特网主机软件的生产商已经认识到的和新的生产商们必须认真考虑的有两个重要的方面。 1.2.1 Internet的可持续性发展

1.1.4
因特网爆炸性的增加揭示了管理和在给予大数据报分组通讯系统中规模控制的问题。这些问题已经被提出来了，那么本文档中所描述的规程也将会有持续的发展。既然生产商和相关组织已经进行了大规模的划分，那么这些改变也将会谨慎的规划并加以控制。

发展、演化和修订是今天计算机网络协议的特色，这一状况还将持续多年。若是为IP协议簇设计的计算机通讯网络软件的生产商没有随着要求的变化而进行维护和更新，那么将会有一大批很不高兴的顾客。因特网是一个巨大的通讯网络而用户将不停地与之接触。经验代表某个软件的不足将很快在整个因特网社区里传开。 1.2.2 健壮性(鲁棒性)要求

每层的协议都有一个总体的规则，这一规则的应用将为健壮性和互用性带来巨大的好处[IP：1]。 “对于收到的信息要放宽要求，而对于发出的信息要严格规定。”

软件应该能共处理每个有可能发生的错误不管其发生的可能性大小，迟早会接收到一个处于某种错误或属性的状况下的分组，那么只有软件在设计前考虑到这一点，才能够避免混乱的发生。总的说来，最好在设计时假设网络充满了旨在传送会带来最糟糕的影响的恶意的实体。基于这样的假设，虽然因特网上最严重的问题是由小几率事件引发的没有被重视机制致使的，设计出来的产品才具备可靠的保护性。但人们的第一每每不会经历如此曲折的过程。

面对改变的适应性应该是因特网主机软件各层设计的要点，举一个简单的例子，假设某个协议规定列举了某个特定的首部字段的值--好比，类型字段，断口字段或错误号。这个列举值一般不是彻底的。这样，若是协议规定了四种可能的错误代码，那么这个软件不该该在第五种取值出现时就瘫痪了。这个违背定义的编号应该写入日志(见下文)但他不该该引发故障。

第二个关键原则也很重要：其余主机上的软件可能包含了一些缺陷，很不明智地使用了了一些合法但很模糊的协议特征。不使用明确的简单的部分来避免麻烦的结果是不明智的。这样作的必然结果就是“当心提防这些行为不正常的主机”，主机软件应该预先考虑到这个问题，不只仅是不要成为行为不正常的主机，还要合做来减小此类主机对于共享的通讯设备的损害。 1.2.3 错误日志

因特网有不少的主机和网关系统，每个系统都实现了许多的协议和协议层，有些包含了漏洞了与相应的因特网协议软件不相符的部分。因为其复杂性、多样性和功能的分布性，要诊断因特网的问题常常比较困难。

若是主机在实现时包括了一个仔细设计记录错误或“奇怪的”协议时间的工具，那么对于因特网问题的解决会有所帮助。当错误被记录时应该尽量多地记录诊断信息。尤为记录发生错误的分组的首部一般是比较有用的。可是应该注意错误日志不该该占用过多的资源，不然将影响主机的工做。
如今异常但无害的协议事件倾向于在错误日志文件上溢出，这一点能够经过使用“循环”日志来避免。这对于过滤和计算重复报文是颇有用的。有一种看起来还不错的策略是：(1) 老是计算异常的数量而且可管理协议[INTRO：1]随时获取(2) 所要记录的事件应该能够进行选择。好比应该容许是记录“全部的事件”仍是“记录主机X的全部事件”。

要注意不一样的管理下对于主机内正常的错误记录策略是有所不一样的。有时的处理方式是“若是这个信息不会伤害我，那么我不想知道”，而有时是抱着更激进的更警戒的态度来检测和屏蔽协议异常。 1.2.4 设置

若是主机在实现因特网协议时可以彻底地自我配置是最理想的。这将彻底在ROM完成，将简化了无盘工做站，对局域网管理员和系统生产上来时也是极大的福音。但咱们尚未那么理想，事实上还远着呢。

本文档中的任何一点都有一个可配置选项的参数。这是有缘由的，有时最优值仍存在着不肯定性，有可能在从此须要更新使用新的推荐值。同时，还有一些值取决于全局因子--好比主机的大小，或通讯载荷的分布，或临近网络的速度和拓扑结构--而自适应算法可能不可行或无效。有时可配置性是管理方面的须要。最后有些配置选项须要与陈旧的或者不正确的协议实现相配合，这些状况在因特网的某些区域仍然存在。为了是正确的系统能够与这些有问题的系统共存，管理员经常不得不将正确的系统进行“错误配置”。这个问题将在这些有问题的系统退出使用舞台后才能够逐步改善，但这个问题生产商是不能够忽略的。当咱们说一个参数必须被配置，这并非须要在每一次启动时都从配置文件中准确地读出。咱们推荐实现者为每个参数设立一个默认值，因此配置文件只有在那些默认值在特定的安装状况下是不合适的才要进行重载。这样的配置要求保证了在必要时能够进行重载，即便是在只支持二进制或基于ROM的产品。本文档要求在某些状况下给默认值设定特定值。默认值的选择在配置项控制与存在的有缺陷的系统相适应时是一个敏感的问题。若是因特网成功地聚合了完整的互操做，那么这些植入实现中的默认值也必须实现官方的协议，而不是进行“误配置”以配合原来有问题的实现。咱们要求生产者按照标准来选择默认值。
RFC1122-A(中文版)

最后咱们提醒生产者必须为全部的配置参数提供相应的文档，包括其限制和效果。

组织

1.3 阅读文档

1.3.1

做为实现网络软件的组织原则的协议分层一样也用于妥当的组

织。在描述这些规则之，咱们假定是实现严格意义上对于协议分层的反映。这些接下来的三个部分分别阐述了链路层，网络层和传输层的要求。相关的RFC[INTRO：1]包含了应用层软件的部分。这个分层组织方法是为了简洁性所选择的。可是对于协议簇和推荐的实现方法来讲，严格的分层是一个并不完美的模型。处在不一样层的协议间的交互是复杂的优点是微妙的，而有些特定的功能经常须要涉及多个层次。在实现中有许多涉及选择，而其中许多须要闯脏性的“打破”严格的分层界限。每一个实现这都应该仔细阅读[INTRO：7]和[INTRO：8]的参考。本文档描述了层之间经过使用功能符号(好比例程调用)的概念服务接口，就像在TCP[TCP：！]中使用的那样。主机的实现必须支持这些调用的逻辑信息流，但宾不是须要竹子的有调用自己是咸。好比许多实现反映了传输层和IP层之间经过使用相同的数据结构来实现合做。这些数据结构并非明确的例程调用，而是传递许多须要的信息的代理。总的来讲，每一个文档中的主要部分都是从以下的子部分组成的： (1) 介绍

(2) 协议概要--逐部分考虑了协议规格文档，改正错误，陈述了可能模糊或定义不完备的要求，而且提供了进一步的说明和解释。 (3) 关键问题--讨论了协议的设计和实现问题，这些在概要里没有涉及到。 (4) 接口--讨论了对于之相邻的更高地服务接口。 (5) 概要--包括了这个部分的要求的小结。本文档的许多独立主题标记为“讨论”或“实现”的附加说明的材料。这一材料旨在对以前的要求进行解释和说明。它也包括了一些针对未来有可能的方向或发展的建议。实现的材料包括了实现者可能考虑到的建议的方法。

概要小结部分旨在给文章提供指导和索引，但并非很完整的。这些小结不会单独于整个RFC文档而被独立引用。
1.3.2 需求
2.在本文档中，下列用于定义每一个要求的z重要性的词语将使用大写字母。

包括：

(1) "MUST"

这个词或者形容词“REQUIRED”表示这个项市规定是必须有的部分。（必须）必须）

(2) "SHOULD"

这个词或者形容词“RECOMMENDED”表示在特定的状况下若是有正当的理由能够忽略这个项，但应该充分了解其含义而且在选择一个不一样的过程当中要谨慎地权衡。（应该）应该）

(3) "MAY"

这个词或者形容词“OPTIONAL”编者这个乡是个彻底的可选项。生产商能够选择包含这个项，由于某个特定的市场环境可能须要它或者由于它对产品有帮助，好比另外一个生产者忽略了这个项。能够）（能够）

若是实现没有知足一个或多个“MUST”的协议要求，那么这个实现就是不合适的。若是一个实现知足协议全部的“MUST”和“SHOULD”要求，那么这个实现就能够叫作“不管何种状况都是合适的”。若是知足了全部的“MUST”项但不是全部的“SHOULD”项那么就称做“在必定条件下是合适的”。 1.3.3 术语本文档使用了以下的专有名词： Segment报文段

报文段是TCP协议中的端到端的传输单元。报文段是

TCP首部和应用层数据构成。报文段封装成了IP数据报进行传输。

Message报文

在更低层的协议描述中，报文是传输层的传输单元。特别的，一个TCP报文段就是一个报文。一个报文由传输层协议首部和应用层数据组成。为了在因特网上进行端到端传输，报文必须封装在一个数据报中。

IP Datagram IP数据报

一个IP数据报是IP协议中的端到端的传输单元。IP数据报时有一个IP首部和传输层数据，好比一个IP首部和一个报文。
在网络层(第三部分)的描述中，“datagram”应该被理解成是IP数据报。

Package 分组

一个分组是经过网络层和链路层之间的接口的数据单元。包括了IP首部和数据。分组多是完整的IP数据报或者是一个IP数据报的分片。

Frame 帧

帧是连路层协议的传输单元，包括了链路层的首部和一个分组。

Connected Network 互联网络

一个主机链接着的网络一般称做“本地网络”或这个主机的子网络。可是这些术语会引发混乱，所以咱们在本文档中使用“Connected Network(互联网络)”。

Multihomed 多宿主

若是一台主机有多个IP地址咱们就说这个主机是多宿主的。对于多宿主的讨论，下见3.3.4。

Physical network interface物理网络接口

物理网络接口是指链接到互联网络并拥有一个链路层地址(多是惟一的)的物理接口。若是一台主机上有多个物理网络接口，它们能够共享链路层地址，但不一样的主机在相同的物理网络中的地址必须是惟一的。

Logical [network] interface逻辑[网络]接口

咱们定义了一个逻辑网络接口，做为区别于惟一的IP地址，而链接在互联网络中的逻辑通路，见3.3.4。

Specific-destination address特定目的地址

这是一个数据报的有效目的地址，即便在广播或多播时仍然有效，见3.2.1.3。

Path 路径

在某个给定的时刻，有一个特定的援助激发像一个特定的目的主机的全部IP数据报会按相同的顺序通过网关。路径之一一个方向。在一对主机间的两个方向上有多条不一样的路径是正常的状况。

MTU 最大传输单元 MTU是可被传输的最大分组的大小。
frame, packet, datagram, message, 和segment在数据报中以下图所示：

A. 互联网络上的传输:

___ | LL hdr | IP hdr | (data) |

|____|____|_____|

<---------- Frame -----------------------------> <----------Packet -------------------->

B. IP分片前或IP重组后的状况:

__ | IP hdr | transport| Application Data |

|____|_hdr|__|

<-------- Datagram ------------------> <-------- Message -----------> TCP的状况:

__ | IP hdr | TCP hdr | Application Data |

|____|__|__|

<-------- Datagram ------------------> <-------- Segment -----------> 1.4 感谢

本文档集成了许多因特网协议的专家的贡献和意见，包括大学和研究实验室的表明，生产商以及政府部门。主要由IETF组织完成。

编者主要感谢下列孜孜不倦的同仁，他们为了本文档在过去的18个月中参加了许多会议，阅览了3百万字节的电子邮件，他们是：Philip Almquist, Dave

Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).

此外，下属的同仁也作出了很大的贡献：Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia

(BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), and Mike StJohns (DCA).

如下人员也在特定的领域内做出了巨大贡献: Eric Allman

(Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen (Toronto).

咱们十分感谢上述的全部人，还有那些被咱们不注意间忘了加在名册中的同仁。

---------------------------------------------------------------------------------------------------------------------- 2. 链路层 2.1 介绍

全部的因特网系统，包括主机和网关，都对链路层协议有着相同的要求。这些要求在“因特网网关要求”[INTRO：2]的第三章中详细给出，本文中只是作了添补的工做。

2.2 协议概要无 2.3 关键问题 2.3.1 追踪协议协商Trailer Protocol Negotiation

追踪协议[LINK：1] 能够封装链路层，但仅当通讯双方都确认使能够用这个协议。若是系统不是对每一个目的主机都动态地协商使用追踪协议，那么默认配置必须必须禁止这个协议。必须

讨论：

追踪协议从新封装了发送给物理网络的分组的数据内容。有时候，追踪者经过减小操做系统中数据的复制量来提升高层协议的性能。高层协议并无感受到追踪者的做用，但收发双方的主机必须必须了解这个协议是否启用。必须

对于追踪着不恰当的使用会致使很混乱的局面。只有大小属性明确的分组可使用追踪者封装，而一般交换的分组只有不多一部分有这样的属性。所以，若是一个系统使用追踪者，而另外一个系统没有使用，那么就会有一些分组成功到达而另外一部分消失在了黑洞里的状况出现。实现：

以太网中，用追踪者封装的分组使用远程以太网类型[LINK：1]而且追踪者协商是在ARP寻找目的系统的链路层地址时工做的。

特别地，ARP交换一般使用通常的IP协议类型完成，但主机若想使用追踪者会发送一个额外的”追踪者ARP应答”分组，好比一个ARP应答知名类型是追踪者封装协议类型，不然就是用正常的ARP应答格式。若是主机配置成使用追踪者来接收一个远端机器的追踪者ARP应答报文，那么主机就能够把这个远端机器加入使用追踪者的名册中，好比经过在ARP Cache中做一个标记。

想要接收追踪者封装的主机在其完成了正常的ARP报文交换后要发送追踪者ARP应答。这样，一台主机若是收到了对于其IP协议地址的ARP请求，那么它能够在正常的针对IP的 ARP应答报文后追加发送一个追踪者ARP应答报文。那么发送针对IP的ARP请求的主机在收到正常的ARP应答时还会收到一个追踪者ARP应答/这样在针对IP的ARP交换过程当中，收发双方均可以应答它所收到的追踪者封装。

这种使用额外的追踪者ARP应答保温而不是发送追踪者协议类型的ARP应答的机制是为了不ARP报文的连续交换而设计的，为了防止工做不正常的主机不按照规程或常规，使用其它ARP应答类型来应答追踪者ARP应答的状况发生。若是一个请求IP解析的ARP应答是对一个特别的请求而作出的，那么发送追踪者ARP应答来响应市能够避免以上的问题的。当收到了ARP应答，但主机地址仍然不知道的状况是存在的。追踪者ARP应答通常都是追加在一个应答ARP请求的应答包中。

2.3.2 地址解析协议--ARP 2.3.2.1 ARP缓冲区的有效期

地址解析协议(ARP)[LINK：2]的实现必须必须提供超时高速缓存记录必须

的刷新机制。若是这一机制须要一个超时值，那么配置时应该应该给出。应该

也必须必须包括防止ARP洪水(高速地向某个相同的IP地址接二连三必须

的发送ARP请求)的机制。推荐的最大速率是每秒钟向每一个目的地址发送一个ARP请求。

讨论：

ARP规程[LINK：2]建议但并非强行规定当主机以太网地址发生变化时可以保持缓冲记录的有效性的超时机制。随着ARP代理的流行(见[INTRO：2]的2.4部分)，主机中的ARP缓冲项可能会无效的状况的大大增多，所以主机就须要了一些确认ARP-Cache有效性的机制。即便没有ARP代理，较长时间的ARP有效时间对于自动修正可能错误的ARP记录也是有帮助的。实现：下列四种机制可用于刷新旧的缓冲记录。 (1) 超时—即便缓冲内的记录仍在使用也要定时地更新。超时应该在”更新”(检查广播的ARP的源地址字段，忽略目的地址字段)时进行。对于ARP代理的状况，每分钟要进行一次超时检查。

(2) 单播轮询—定时地发送点到点的ARP请求来主动地轮询远程主机，而且在N次尝试后都没有收到ARP应答时删除缓冲中的记录。一样，超时值应该约为1分钟，一般N值取2。

(3) 链路层建议—若是链路层驱动检测到了一个发送问题，则刷去ARP缓冲区中的记录。

(4) 高层建议—从网络层到链路层若是有发送问题就提请一个调用。这个调用的做用是使相应的缓冲记录无效。这个调用应该相似于传输层到网络层的调用"ADVISE_DELIVPROB()"的形式(见3.4部分)而且实际上"ADVISE_DELIVPROB()"例程可能会调用链路层建议来使ARP缓冲记录无效。

对于处理ARP超时时用的方法(1)和(2)设定的时间应该应该约一分钟应该

或更短的时间。若是没有ARP代理，没有时延控制在很大的以太网上会出现高负荷的状况。所以对主机进行ARP缓冲进行超时设置是必要的。 2.3.2.2 ARP分组队列

链路层应该保留(而不是丢弃)至少一个(根据最新的研究状况来看) IP地址未解析的目的地相同的分组，并在地址已经被解析后发送这个分组。

讨论：没有按照这个推荐会使得每次交换中第一个分组的丢失。虽然高层协议能够经过重传来处理分组丢失的状况，可是分组丢失影响了工做的性能。好比一个TCP打开请求的丢失将会致使往返时间的初始值的膨胀。像域名系统此类的基于UDP的应用程序会有更严重的影响。 2.3.3 以太网和IEEE802封装

对于以太网的IP封装在RFC894中进行了描述[LINK：4]，RFC1042[LINK：4]描述了IEEE802网络的IP封装。RFC1042 [INTRO：2]的3.4部分进行了详细的阐述。

每一个因特网主机链接到10Mbps的以太网网络： 1. 必须使用RFC894的封装来发送和接收分组必须

应该可以接收RFC1042分组，并与RFC894分组混合，而且应该3. 能够可使用RFC1042封装来发送分组

实现了发送RFC894和RFC1042封装的因特网主机必须必须提供一个配置必须选择要发送哪个，这个可选择的必须必须的默认值在RFC894里描述了。必须

RFC1042的标准IP封装并无使用IEEE为IP保留的协议ID值(K1=6)，而是使用了在拓展的 “SNAP”中指出了用以填充以太网字段的值(K1=170)。因特网系统必定不可使用802分组中的值 (K1=6)。

将因特网地址转换成以太网或者IEEE802网络的链路层地址必须必须由地必须址转换协议(ARP)。

以太网的MTU是1500字节而802.3是1492。讨论：

IEEE802.3的规程提供了10Mbps的以太网的操做，这样以太网和IEEE802.3帧能够在物理层混合。接收者能够经过802.3的长度字段来区分以太网和802.3的帧。这两个字节的字段与以太网帧的以太网类型字段相同。特别地，802.3的长度字段必须不大于1500，而全部的以太网类型有效值应该大于1500。

另外一个兼容性问题是在链路层广播出现的。仅发送一种帧的广播可能不会被只接受另外一种帧的主机接收。
对于这个部分设计的建议是在相同的网络中实现支持894和支持1042的系统间最大程度的直接合做。现今的状况是894系统占统治地位，但支持1042的系统有可能在未来普及开来，所以也要提供一个简单的转变。

应该认识到只支持894的系统并不能直接与支持1042的系统交互工做。若是两种系统类型在相同的网络中是使哟了可以两种不一样的逻辑网络，那么它们只能经过IP网关来通讯。进一步看，想要一台双格式的主机自动地选择发送格式是不可行的甚至是不可能的，由于在链路层上存在广播问题。

2.4 链路层与网络层的接口

IP层和链路层之间的分组接收接口必须指出接收的分组是否一个链路层广播。讨论：

虽然IP曾并不知道链路层的地址(由于每种不一样的网络媒介有不一样的地址格式)，广播地址在容许广播的媒介上是一个重要的问题。参见3.2.2关于广播风暴的讨论内容。

IP层和链路层之间的分组发送接口必须必须包括一个5比特的TOS字段(见必须3.2.1.6)。

链路层必定不能必定不能仅向IP层发送一个目的地不可达的错误，由于目的地没必定不能有ARP缓存记录。
2.5 链路层要求概要

|       | | | |S| |
                                              |       | | | |H| |F
                                              |       | | | |O|M|o
                                              |       | |S| |U|U|o
                                              |       | |H| |L|S|t
                                              |       |M|O| |D|T|n
                                              |       |U|U|M| | |o
                                              |       |S|L|A|N|N|t
                                              |       |T|D|Y|O|O|t

FEATURE	SECTION				T

Trailer encapsulation	2.3.1			x
Send Trailers by default without negotiation	2.3.1				x
ARP	2.3.2
Flush out-of-date ARP cache entries	2.3.2.1	x
Prevent ARP floods	2.3.2.1	x
Cache timeout configurable	2.3.2.1		x
Save at least one (latest) unresolved pkt	2.3.2.2		x
Ethernet and IEEE 802 Encapsulation	2.3.3
Host able to:	2.3.3
Send & receive RFC-894 encapsulation	2.3.3	x
Receive RFC-1042 encapsulation	2.3.3		x
Send RFC-1042 encapsulation	2.3.3			x
Then config. sw. to select, RFC-894 dflt	2.3.3	x
Send K1=6 encapsulation	2.3.3				x
Use ARP on Ethernet and IEEE 802 nets	2.3.3	x
Link layer report b'casts to IP layer	2.4	x
IP layer pass TOS to link layer	2.4	x
No ARP cache entry treated as Dest. Unreach.	2.4				x

1. RFC
2. RFC 综合指南（RFC Sourcebook）
3. About RFC
4. RFC 2616
5. ARP RFC
6. The valid characters are defined in RFC 7230and RFC 3986
7. characters are defined in RFC 7230 and RFC 3986
8. RFC知识和RFC debug技巧
9. RFC 2046 三
10. jBPM5 RFC译
更多相关文章...
• PHP gmdate() 函数 - PHP参考手册
• PHP date() 函数 - PHP参考手册