null
分类： C/C++
2006-10-16 15:40:48
Vinton G. Cerf 和 Robert E. Kahn, IEEE 成员
译者声明：译者对译文不做任何担保，译者对译文不拥有任何权利并且不负担任何责任和义务。
摘要 — 本文提出支持存在于不同的分组交换网络中的资源共享协议。这个协议为单独网络的分组大小、传输失败、定序、流控、端到端错误检查和进程到进程通信的建立和破坏的差异作好了准备。考虑到了某些实现要点，暴露出某些问题比如互连网络路由、记帐和超时。
©1974 IEEE. Reprinted, with permission, from IEEE Trans on Comms, Vol Com-22, No 5 May 1974
Paper approved by the Associate Editor for Data Communications of the IEEE Communications Society for publications without oral presentation. Manuscript received November 5, 1973. The research reported in this paper was supported in part by the Advanced Research Projects Agency of the Department of Defense under Contract DAHC 15-73-C-0370. V.G. Cerf is with the Department of Computer Science and Electrical Engineering, Standford University, Stanford, Calif. R.E. Kahn is with the Information Processing Technology Office, Advanced Research Projects Agency, Department of Defense, Arlington, Va.
过去几年中在设计和实现分组交换网络上已经花费了可观的努力[1]-[7],[14],[17]。开发这种网络的根本原因是促进计算机资源的共享。分组通信网络包括在计算机之间或计算机和终端之间递送数据的一种运输机制。为了使数据有意义，计算机和终端共享公共的协议(就是说一组达成一致的约定)。为此已经开发了一些协议[8]-[12],[16]。但是，这些协议只致力于在同一个网络上通信的问题。在本文中我们提出支持存在于不同的分组交换网络中的资源共享。
在对互联网络的协议要点做简要介绍之后，我们描述作为网络之间接口的网关的功能并讨论它在协议中的角色。我们接着考虑协议的各种细节，包括寻址、缓冲、定序(sequencing)、流控、错误检查等等。我们紧密结合进程间通信机制的描述并展示互联网络协议是如何支持它的。
尽管很多不同和复杂的问题一定在单独的分组交换网络的设计中被解决掉了，当相异的网络互连接的时候就使这些问题明显的更加复杂了。出现的问题可能在单独的网络中没有直接对应者并强烈的影响互联网络通信发生的方式。
典型的分组交换网络由叫做主机的计算机资源集合、一个或多个分组交换机的集合和一组互连接分组交换机的通信介质的构成。在每个主机内，我们假定这里存在必须与在自己或其他主机中的进程通信的进程。所有当前的进程定义对于我们的用途都是适合的[13]。这些进程通常是在网络中数据的最终的来源和目的地。典型的，在单独的网络中，都存在在任何源和目的进程之间通信的协议。只有源和目的进程需要知道进行通信的这个协定。在两个不同的网络中的进程通常使用用于此目的的不同协议。分组交换机和通信介质的全体叫做分组交换子网。图 1 说明了这些概念。
在典型的分组交换子网中，从源主机接受固定最大大小的数据，加上格式化的目的地址，用它来以存储和转发方式的为数据确定路由(route)。数据的传送时间通常依赖于内部网络参数，比如通信介质的数据速率、缓冲和发信号通知(signal)策略、路由和传播延迟等。此外，一般还提供错误处理和确定网络构件状态的某些机制。
单独的分组交换网络在实现上可能有如下不同。
1) 每个网络都有寻址接收者的不同方式，所以要求建立每个单独的网络都能理解的统一的寻址方案。
2) 每个网络都接受不同的最大大小的数据，所以要求网络们以最小的最大大小为单位来运做(这可能是不实际的小)或要求跨越网络边界的数据重新格式化到更小些的片段(piece)中。
3) 在每个网络中传输的成功或失败和它的性能受在接受、递送和运输数据上的不同的时间延迟支配着。这要求仔细开发互联网络定时过程以确保数据可以成功的通过各种网络来递送。
4) 在每个网络内，通信都可能由于数据的不可复原的突变或数据缺失而被破坏。要求端到端恢复过程来从这些状况中完全恢复过来。
5) 状态信息、路由、故障检测和隔离在每个网络中典型的是不同的。所以，获得特定状况的核实，比如不可访问或死掉的目的地，必然涉及到通信着的网络间的各种协调。
如果在网络之间的所有差异可以通过在网络边界上的做适当的接口来经济的解决那将是非常方便的。对于多数的差异，这个目标是可以完成的。但是，在经济和技术二者之上的考虑致使我们更想让这个接口尽可能的简单和可靠，并主要处理在使用不同的交换策略的网络之间的数据传递。
问题上升为接口是否应该通过把源约定变换到目的约定来顾及在主机或进程级别协议上的差异。我们明确的希望允许在接口上做分组策略的转换，来允许现存的和预计中的网络的互连接。但是，主机或进程级别协议的复杂性和互异性使得避免必须在接口做它们之间的变换是值得的，即使这种变换总是可能的。当然，必须开发相容的主机和进程级别协议来完成有效的互联网络资源共享。不可接受的替代选择是让每个主机或进程实现在与其他网络通信时可能需要的所有(潜在的无限数目的)协议。所以我们假定在不同的网络中的主机或进程要使用公共的协议，网络间的接口应当在这个协议中充当尽可能小的角色。
要允许有不同所有者的网络互连接，对通过接口的流量毫无疑问需要一些记帐。用最简单的术语，这涉及到对每个网络所处理的分组的记帐，分组的费用从网络到网络传递，直到它最终停止在用户或他的代表那里。进一步，互连接必须完整无损的保留每个单独的网络的内部操作。如果两个网络互连接得好象每个都是到另一个网络的一个主机，而不用利用或真正结合任何精细的主机协议变换，这就容易完成了。
显而易见在网络间的接口必须在任何网络互连接策略的开发中扮演中心角色。我们给予进行这些功能的接口一个特殊的名字，称它为网关。
在图 2 中我们表示了标签为 A、B 和 C 的三个独立网络，它们用网关 M 和 N 连结到一起。网关 M 接口网络 A 和网络 B，而网关 N 接口网络 B 和网络 C。我们假定一个独立的网络可以有多于一个的网关(比如网络 B)，并且在一对网络之间通行可以使用多于一个的网关路径。对数据做适当的路由的责任归属于网关。
实际上，在两个网络间的网关可以由两个半体组成，每个都与自己的网络相关联。实现网关的每个半体是可行的，因此它只需要在本地分组格式中嵌入或提取互连网络分组。我们建议网关按标准格式处理互连网络分组，但不建议在网关半体之间做任何特殊的传输过程。
让我们现在跟踪通过互连接网络的数据流动。我们假定来自进程 X 的一个数据分组进入网络 A 去往在网络 C 中的进程 Y。Y 的地址最初由进程 X 指定而网关 M 的地址推导自进程 Y 的地址。我们不尝试指定网关的选择是否由进程 X、它的主机、或在网络 A 中的某个分组交换机作出的。分组穿过网络 A 直到它到达网关 M。在网关分组被重新格式化来满足网络 B 的要求，在 A 和 B 之间的流动采用这个单位记帐，网关递送分组到网络 B。再次基于目的 Y 的地址完成下一个网关地址的推导。在这个事例中，网关 N 是下一个网关。分组穿过网络 B 直到它最终到达网关 N，在这里它被格式化来满足网络 C 的要求。在网络 B 和 C 之间的流动采用这个单位来再次记账。在进入网络 C 时，分组被路由到进程 Y 驻留的主机，这是递送的最终目的地。
因为网关必须理解源和目的主机的地址，这个信息必须能在到达网关的每个分组中以标准格式获得。源主机把这个信息包含在前缀于每个分组的互联网络报头中。在图 3 中展示了分组格式，包括互联网络报头。源和目的项目一致的和唯一的标识在复合的网络中的每个主机。寻址是个相当复杂的主题，在下节中做详细讨论。在报头中下两个项目提供序列编号和字节计数，它们用来在分组被递送到目的地时完全的定序分组，并且使网关能够检测影响这个分组的故障状况。标志字段用来传达特殊的控制信息并在后面关于重新传输和重复检测章节中讨论。分组的余下部分由要递送的文本和用于端到端验证的一个尾随的校验和组成。网关不修改文本并且只沿途转发校验和而不计算或重新计算它。
在分组可以通过单独的网络之前每个网络都需要增大分组格式。我们在示意图中指出了前缀于分组开始处的本地报头。介入这个本地报头只是说明在分组必须通过的单独网络的格式中嵌入互联网络分组的概念。明显的它的实际形式从网络到网络将是各式各样的，甚至在某些情况下是不必要的。尽管在示意图中没有明确的指示，在分组的结束处填加本地报尾(trailer)也是可能的。
除非所有传送的分组都在立法上限制到了足够小，让每个单独的网络都接受，否则网关必须强行把分组分割到两个或更多小分组中。这个动作叫做分片(fragmentation)，并按目的地能够把分片之后的分组再拼凑起来的方式进行。互联网络报头格式清楚的强加所有网络都必须承载的一个最小的分组大小(所有网络都明显的希望承载大于这个最小值的分组)。基于如下原因，我们相信指定能比这个最小分组大小大多少将严重阻碍互联网络通信的长期增长和开发。
1) 如果指定了最大允许的分组大小，则不可能把一个网络的的互联网络分组大小参数同其他网络的互联网络分组大小参数完全孤立起来。
2) 为响应新技术(比如，大内存系统、更高的数据速率的通信设施等)而增加最大允许分组大小将是非常困难的，因为这将需要所有参与网络的批准和实现。
3) 联合寻址和分组加密可能要求在运输期间扩展特定分组的大小来结合新信息。提供分片(不管它在哪里进行)允许在单独网络基础上处理分组大小的变更，而不需要全局的管理，并允许主机和进程同数据必须在其间通过的任何网络在允许的分组大小上的变更隔离开来。
如果分片必须做，则最好在网关中在进入下一个网络时做，因为只有这个网关(而不是其他网络)必须知道分片成为必需的互联网络分组大小参数。
如果网关把到来的分组分片成两个或更多的分组中，它们必须最终作为片段一起传递到目的主机或为主机重组它们。你可能希望网关进行重组来简化目的主机(或进程)的任务和/或利用更大分组的好处。我们采用网关不应该进行这种功能的立场，因为网关重组可能导致严重的缓冲问题、潜在的死锁、一个分组的所有片段通过相同的网关传递的必要性、和增加传输中的延迟。进一步，网关不足以提供这个功能，因为最终的网关也可能为了传输而对分组做分片。所以目的主机必须准备好做这个任务。
让我们简要的看一下在分组可以被一个或多个网关分片的时候出现的某种不寻常的记帐效果。出于简单性，我们假定每个网络最初都收取固定的每分组费率，而不管距离，如果一个网络可以比其他网络处理更大的分组大小，则它按比例的收取更高的每分组价格。我们还假定在任何网络中的在分组大小上的后来的增加都不导致对它的用户的额外的每分组花费。所以对一个用户收取的费用通过任何必须对分组做分片的网络都保持基本恒定。不寻常的效果出现在分组被分片到更小的分组，而它们必须单独的通过有着比最初未分片的分组更大的分组大小的后续网络的时候。我们期望多数网络将自然的选择接近另一个网络的分组大小，但是在任何情况下，在一个网络中分组大小的增加，即使在它导致分片的时候，将不会增加传输的费用并可能实际上减少它。在采用了其他(不是我们建议的)分组收费策略的情况下，在费用上的区别可以用作逼近单独网络的性能最优化的经济杠杆。
我们假定进程希望同它们的通信者以全双工的方式使用无限制但有穷长度的消息进行通信。单一的字符可以构成从进程到终端的消息，反之亦然。一整页的字符可以构成从文件到进程的消息。数据流(stream)(比如持续生成的位串)可以表示为有穷长度消息的序列。我们假定在主机内存在传输控制程序(TCP)，它代表它服务的进程处理消息的发送和接收。TCP 依次由连接到 TCP 驻留的主机上的一个或多个分组交换机提供服务。想要通信的进程向 TCP 提供消息用以发送，而 TCP 递送到来的消息到正确的目的进程。我们允许 TCP 把消息分解成段(segment)，因为目的地可能限制可以接受的数据量，本地网络可能限制最大的传输大小，TCP 可能需要在很多进程之间并发的共享它的资源。进一步，我们强制段的长度为 8 位字节的整数倍。这种统一对简化在有不同字长度的主机上工作的软件是很有帮助的。在进程级别提供有利于填补(pad)不是字节的整数倍的消息，和识别哪些到达的文本字节包含对接收进程有价值的信息。
进程间段的多路复用和解多路复用是 TCP 的基本任务。在发送时，TCP 必须多路复用来自不同源进程的段，并为递送到某个提供服务的分组交换机而生成互联网络分组。在接收时，TCP 将接受来自提供服务的分组交换机的分组序列。从这个到来的分组序列中(通常来自不同的主机)，TCP 必须能够重新构造并递送消息到正确的目的进程。
我们假定每个段都增加了允许发送和接收 TCP 分别的识别目的和源进程的额外信息。在这一点上，我们必须面对一个主要问题。源 TCP 如何格式化去往相同目的 TCP 的段? 我们考虑两种情况。
情况 1): 如果我们采用的立场为段边界是非实质性的，去往相同的 TCP 的段可以形成一个字节流，那么通过把这个流任意的分割到分组中，允许很多段共享一个单一的互联网络分组报头，我们可以获得增进了的传输效率和资源共享。但是，这个立场导致需要完全的按次序的重构源 TCP 生成的文本字节流。在目的地，这个流必须首先被解析到段中，再依次使用它们来重构要递送到正确的进程的消息。
有些与这种策略有关的基本问题根源于到来的分组在目的地有失序的可能性。最关键的问题似乎是共享相同的 TCP-TCP 字节流的进程能导致在它们自身间冲突(interference)的数量。特别是在接收端。首先，TCP 要很麻烦的把流解析回到段中，并接着把它们分布到在其中重组消息的缓冲区中。如果一个段看起来还没有到齐(记住，它可能作为多个分组到来)，接收 TCP 可能必须临时的延缓分析，直到更多的分组到来。其次，如果一个分组缺失，即使后续的段是可识别的，也不清楚是否应当把它们传递给接收进程，除非 TCP 对进程级别定序方案有一定的知晓。这些知识将允许 TCP 决定是否应该把后续的段递送到等待它的进程。在字节流中有空隙的时候找到段的开始处也将是很困难的。
情况 2): 作为另一个选择，我们还可以采用的立场是目的 TCP 在分组到来时应该不需要额外的信息就能够确定到来的分组要去的是哪个或哪些进程，如果这样的话，接着确定它是否应当被递送。
如果 TCP 要确定了到来的分组要去哪个进程，每个分组都必须包含完全的标识目的进程的进程报头(区别于互联网络报头)。出于简单性，我们假定每个分组都包含来自一个单一的进程并去往一个单一的进程的文本。所以每个分组只需要包含一个进程报头。要决定到来的数据是否应当递送到目的进程，TCP 必须能够确定数据是否在正确的顺序中(我们可以做些规定，让目的进程可以指示它的 TCP 忽略顺序，但是这只做为特殊情况来考虑)。采用每个到来的分组都包含进程报头的假定，需要的定序和目的进程识别对与目的 TCP 就是可以立即获得的了。
情况 1) 和 2) 二者都提供解多路复用和把段递送到目的进程，但是只有情况 2) 这么做而不介入潜在的进程间冲突。进一步，情况 1) 介入了额外的机制来处理在主机到主机基础上的流控，因为对进程级别控制还必须作些规定，并且这种机制还很少使用，因为在给定的主机内同时调度两个进程来发送消息到同一个目的主机的可能性很小。为此，我们选择情况 2) 的方法作为互联网络协议的一部分。
地址格式的选择是在网络间的问题，因为 TCP 的本地网络地址在格式和大小上可能有着充分的差异。每个网关和 TCP 都理解统一的 TCP 地址空间对于互联网络分组的递送是本质上的要求。
在我们处理进程寻址和更一般的端口寻址的时候也遇到类似的问题。我们介入了端口的概念来允许进程区别多个消息流。端口只是与进程相关联的这种消息流的标志符(designator)。标识端口的方式在不同的操作系统一般是不同的，所以要获得一致的寻址，还需要标准的端口地址格式。端口地址指定了一个全双工的消息流。
TCP 寻址密切的结合在路由问题中，因为主机和网关必须为外出的互联网络分组选择一个适当的目的主机或网关。让我们为 TCP 地址假定下列地址格式(图 4)。网络标识的选择(8 位)允许最多 256 个不同的网络。对于可预期的将来这个大小好象足够了。类似的，TCP 标识符字段允许最多 65536 个不同的 TCP 被寻址，这对于任何给定的网络都是很充足的。
对通过网关的每个分组，网关遵循目的网络 ID 来决定如何路由这个分组。如果目的网络被连接到了这个网关，则使用 TCP 地址的低 16 位来生成在目的网络中的本地 TCP 地址。如果目的网络没有连接到这个网关上，使用高 8 位地址来选择一个后续的网关。我们不做任何努力指定单独的网络如何给互联网络 TCP 标识符关联上它的本地 TCP 地址。我们也不排除本地网络理解互联网络寻址方案并减轻网关选路的责任。
接收 TCP 面对着对它收到的互联网络分组流做解多路复用，和为每个目的进程重构最初的消息的任务。每个操作系统都有标识进程和端口的自己的内部方式。我们假定 16 位对于充当互联网络端口标识符是充足的。发送进程不需要知道要目的端口是怎样标别的。目的 TCP 将适当的分析这个编号来找到正确的缓冲区，把到来的分组放置到其中。我们允许大端口编号字段来支持进程并发的区分许多不同的消息流。实际上，我们不关心涉及到的 TCP 如何把这 16 位切成薄片。
尽管传输的端口名字字段很大，它仍是端口的内部表示的简洁的外部名字。为端口标识符使用短名字对减少传输花费和在目的 TCP 处减少分组处理时间而言经常是值得的。但是，为每个端口分配短名字要求在源和目的之间对适合的短名字分配达成一致的初始协商，在源和目的两端的转换表的后续维护，和释放这个短名字的最终交易。对于动态分配的端口名字，在任何情况下一般都需要这种协商。
如图 5 中所展示的那样，消息被 TCP 分解到段中，它的格式在图 6 中被详细的展示了。表示出的字段长度只是建议性的。前两个字段(图中的源端口和目的端口)在前面关于寻址的章节中已经讨论了。第三和第四个字段(图中的窗口和确认)将在后面关于重新传输和重复检测章节中讨论。
我们回忆图 3 中互联网络报头包含了序列号和字节计数二者，还有一个标志和一个校验和。随后章节中会解释这些字段。
在接收 TCP 处重构消息明显的要求1每个互联网络分组承载一个序列编号，它对特定目的端口消息流是唯一的。这个序列号必须单调(monotonic)增长(或减少)，因为它们被用来把到来的分组重新排序和重组到一个消息中。如果序列编号空间是无穷的，我们可以简单的对每个新分组赋予下一个编号。明显的，这个空间不能是无穷的，在下一节讨论重新传输和重复检测的时候我们将考虑有穷序列号空间会导致的问题。我们提议下列方案让目的 TCP 进行分组的定序和消息的重构。
1 在加密分组的情况下，在解密之前可能需要做重组的初始阶段。
一对端口在一段时间内将交换一个或多个消息。我们把一个端口生成的消息序列看成被嵌入到一个无穷长的字节流中。消息的每个字节都有一个唯一序列编号，表示它相对于流开始处的字节位置。在源 TCP 从消息中提取一个段并为互联网络传输而格式化它的时候，使用段文本的第一个字节的相对位置作为这个分组的序列编号。在互联网络报头中的字节计数字段总计在这个段中的所有文本(不包括校验和的字节或在互联网或进程报头二者的那些字节)。我们强调与一个给定分组相关联的序列编号只对通信中的这对端口而言是唯一的(参见图 7)。检查到来的分组来确定它要去哪个端口。接着使用在每个到来分组中的序列编号来决定分组文本在重构的消息中的相对位置。我们注意到这允许数据在重构的消息中的精确位置即使在某些片段仍然缺少的时候都是可以确定的。
源 TCP 生成的每个段都包装在一个单一的互联网络分组中，并在文本和与这个段相关联的进程报头上计算校验和。
TCP 把消息分解到段中和网关潜在的把段分解到更小的片断中，造成了对在段结束(ES)已经到来的时候，和消息结束(EM)已经到来的时候指示目的 TCP 的需要。互联网络报头的标志字段被用做这个目的(参见图 8)。
ES 标志由源 TCP 每次在准备好传输一个段的时候设置。如果消息恰好完整的包含在一个段中，则也应当设置 EM 标志。如果消息不能包含在一个段中，则在消息的最后的段中也应当设置 EM 标志。这两个标志分别的被目的 TCP 用来发现对给定段的校验和的存在，和发现完整的消息已经到来了。
在互联网络报头中的 ES 和 EM 标志网关是知晓的，并在分组必须被分解来传播通过下一个本地网络的时候特别重要。我们在图 9 中用例子展示它们的使用。
在图 9 中最初的消息 A 被分解到两个段 A1 和 A2 中，并被 TCP 格式化到两个互联网络分组中。分组 A1 和 A2 都设置了它们的 ES 位，而 A2 还设置了它的 EM 位。在分组 A1 传递通过网关的时候，它被分解成两个片断: 分组 A11 没有设置它的 EM 和 ES 位，而分组 A12 设置了它的 ES 位。类似的，分组 A2 被分解到两个片断，分组 A21 没有设置任何位，而分组 A22 设置了两个位。每个分组的序列编号字段(SEQ)和字节计数字段(CT)都被网关修改来，正确的标识每个分组的文本字节。网关只需要检查互联网络报头来做分片。
目的 TCP 在重组段 A1 的时候，将检测 ES 标志，知道在分组 A12 中包含着校验和并验证它。在接收分组 A22 的时候，假定所有其他分组都已经到达，目的 TCP 检查它已经重组了一个完整的消息，现在就可以把它的收到告诉目的进程。
没有传输能百分之百可靠。我们提议一个超时和肯定确认机制，允许 TCP 从一个主机到另一个主机的分组丢失中恢复过来。TCP 发送分组并等待由反向分组流承载的回应(确认)。如果没有收到对特定分组的确认，则 TCP 会做重新传送。按我们的经验，在下面段落中描述的进程级别重新传输机制，在实际中不会经常被调用的。已经存在的证据2显示可以有效的构造单独的网络而不用这个特征。但是，包含主机重新传输能力使从偶尔的网络问题中恢复过来成为可能，并允许组合广泛的主机协议策略。我们设想它会偶尔的被调用来允许主机的适应性调节去不经常的过度索取有限的缓冲区资源，在其他反面使用的并不多。
2 ARPANET 就是这样的例子。
任何重新传输策略都要求接收者有检测重复到来的某种方法。即使可以获得无穷数目的不同的分组序列编号，接收者仍将遇到为了检测重复要分组需要记住以前的分组多长时间的问题。在实际上只能获得有穷数目的不同的序列编号的事实使事情复杂化了，如果重新使用它们，接收者必须可以区分新传输和重新传输。
这里提议的窗口策略(参见图 10)，类似于法国 CYCLADES 系统(voie virtuelle 传输模式[8])和 ARPANET(非常远距离主机连接 [18])中使用的策略。假设在互联网络报头中序列编号字段允许序列编号的范围是从 0 到 n - 1。我们假定发送者不会传送多于 w 字节而不用接收确认。这个 w 字节就充当窗口(参见图 11)。明显的，w 必须小于 n。给发送者和接收者的规则如下。
发送者: 设 L 是与左窗口边缘相关联的序列编号。
1) 发送者发送文本位于 L 和 L + w - 1 之间的段的字节。
2) 在超时的时候(未指定持续时间)，发送者重传未确认的字节。
3) 在收到由接收者的当前最左窗口边缘组成的确认的时候，发送者的左窗口边缘前进到确认的字节(隐含的前进右窗口边缘)。
接收者:
1) 到来的分组的序列编号与接收者的当前左窗口边缘相符，则通过把期望的下一个序列编号发送到来源地来做确认。这有效的确认在其间的字节。左窗口边缘前进到期望的下一个序列编号。
2) 到来的分组的序列编号在窗口边缘的左边(实际上在窗口的外部)则丢弃，并返回当前左窗口边缘作为确认。
3) 分组的序列编号位于接收者的窗口之内但不与接收者的左窗口边缘相符，则可以随意的保留或丢弃，但立刻确认。这是分组到来失序的情况。
我们对这个策略做了观测。首先，所有关于序列编号和窗口边缘的计算必须模(modulo)以 n (就是说字节 0 跟随在字节 n-1 之后)。其次，w 必须小于 n/23；否则在接收者可以保存或丢弃其序列编号不与接收者的左窗口边缘相符的到来分组的情况下，重新传输就可能被接收者看做新传输。第三，在最简单的实现中，如果空间紧张，接收者不需要为每个消息流缓冲多于一个分组。第四，多个分组可以被同时确认。第五，作为重组机制的自然的结果，接收者能够以正确的次序递送消息到进程。第六，在检测到重复的时候，确认方法自然的起到重新同步发送者和接收者的作用。进一步，如果接收者接受其序列编号位于当前窗口内但不与左窗口边缘相符的分组，由当前左窗口边缘组成的确认将充当刺激，来导致未确认的字节的重新传输。最后，我们提及由重新传输、分组分解、和分组通过不同网关的更替路由导致的交叉问题。
3 实际上 n/2 只是对使用方便的数；它只要求重新传输不能看起来像新传输。
一个 600 字节的分组可能通过一个网关并被分解到两个 300 字节的分组中。在重新传输的时候，同一个分组可能通过不同的网关被分解到三个 200 字节的分组。因为每个分组都有一个序列编号，在接收 TCP 处没有混乱。我们把初始同步发送者和接收者的左窗口边界和窗口大小的问题留待以后考虑。
到达目的 TCP 的每个段都通过返回必须传递给进程的下一个段(它可能仍未到达)的序列编号来最终确认。
前面我们描述了使用序列编号空间和窗口来辅助重复检查。确认在进程报头中承载(参见图 6)，还提供了与之在一起的“建议窗口”，接收者使用它来控制来自发送者的数据流动。这是意图作为进程流控机制的主要构件。接收者自由的依据任何它喜欢的算法改变窗口大小，只要窗口大小不超出序列编号空间的一半。3
这个流控机制非常强力和灵活，并且不遭受在递增缓冲区方案[9],[10]中会遇到的同步麻烦。但是，它严重依赖于有效的重新传输策略。接收者可以减小窗口，甚至在发送者在窗口目前很大时发送的分组仍在路上的时候。这种减少的网络效果将是接收者可以丢弃到来的分组(它们将在窗口之外)，并与当前的窗口边缘一起作为确认，反复申明当前的窗口大小。出于同样原因，发送者在特定场合可以选择发送超出一个窗口应得的数据，接收者有可能扩展它的窗口来接受它(当然，发送者在任何时候都不能发送多于序列号空间一半的数据)。正常的，我们期望发送者遵守窗口限制。接收者对窗口的扩展只是允许更多的数据被接受。对于有少量缓冲区空间的接收主机，丢弃其序列编号不与窗口左边缘相符的分组的策略可能是需要的，但是会招致重新传输的额外延迟和花费的代价。
TCP 有一个构件4处理来去网络的输入/输出(I/O)。 当一个分组到来的时候，它验证地址并把分组放置到队列中。可以架设一个缓冲池来处理到来分组，如果所有可获得的缓冲区都用尽了，随后到来的分组可以被丢弃，因为未确认的分组会被重新传输。
4 这个构件可以服务于处理与其相关的控制程序由互联网络目的地址指定的其他协议。
在输出的时候，需要做小量的缓冲，因为进程缓冲区可以持有要传输的数据。可能双缓冲就足够了。我们不尝试指定如何做缓冲，除了要求它以尽可能小的花费的去服务于网络之外。分组大小的缓冲区，一个或多个环状缓冲区，或任何其他组合都是可能的候选者。
当一个分组到达目的 TCP 的时候，它被放置到 TCP 经常维护的一个队列上。例如，在发生一次队列放置的时候 TCP 可以被中断。TCP 接着尝试把分组文本放置到在适当的进程接收缓冲区中正确的位置上。如果分组终止一个段，则它可以被做校验和并确认。放置可能由于多种原因而失败。
1) 目的进程没有准备好接收自规定的来源，或者目的端口 ID 可能不存在。
2) 没有充足的缓冲区空间给文本。
3) 文本的开始序列编号可能与要递送到进程的下一个序列编号不相符合(就是说分组到来失序)。
在第一种情况下，TCP 应当简单的丢弃这个分组(迄今为止，还没有规定错误确认)。在第二种和第三种情况下，可以检查分组的序列编号来确定分组文本是否位于合法的接收窗口中。如果是，TCP 可以随意的保留这个分组去排队以便随后处理。如果不是，TCP 可以丢弃这个分组。在任一情况下 TCP 都可以随意的用当前最左窗口边缘做确认。
有可能出现进程接收缓冲区不存在于主机的活动内存中，而是存储在二级存储中的情况。如果是这样，TCP 可以提示调度器取回适当的缓冲区并把分组排队以便随后处理。
如果 TCP 不能获得更多的输入缓冲区用于临时的排队到来的分组，如果 TCP 不能很快的使用到来的数据(比如说 TCP 到 TCP 消息)，则丢弃这个分组。设想一个敏感的机能(functioning)系统，除了这个分组要去的那个进程，其他进程都不应当受到这种丢弃的影响。如果延时处理队列增长的过分长，可以安全的丢弃其中的任何分组，因为它们都还没有被确认。在 TCP 级别的拥塞可以灵活的处理归功于健壮的重新传输和重复检测策略。
为了发送一个消息，进程在它自己的地址空间的缓冲区域中设置文本，在发送控制块(TCB)中插入必需的控制信息(在下面的列表中描述)，并把控制交给 TCP。这里不指定 TCB 的精确形式，它可以采用传递的指针形式、伪中断或各种其他形式。要在它的地址空间中接收一个消息，进程设置一个接受缓冲区，在接收控制块(RCB)中插入必需的控制信息，并再次把控制交给 TCP。
在某些简单系统中，缓冲空间实际上可以由 TCP 来提供。出于简单性我们假定每个进程都使用一个环状缓冲区，但不排除其他结构(比如缓冲链)。
在图 11 中展示了一种可能的 TCB 格式。TCB 包含允许 TCP 提取和发送进程数据所必须的信息。某些信息可以隐含的获知，但是我们不涉及到很详细的程度。下面描述 TCB 中的各种字段。
1) 源地址: 这是发送者的完整的网络/主机/TCP/端口地址。
2) 目的地址: 这是接收者的完整的网络/主机/TCP/端口地址。
3) 下一个分组序列编号: 这是 TCP 将从这个端口发送的下一个分组使用的序列编号。
4) 当前缓冲区大小: 这是进程发送缓冲区的当前大小。
5) 下一个写位置: 这是进程可以在其上放置要传输的新数据的缓冲区中下一个位置的地址。
6) 下一个读位置: 这是 TCP 为了建造要输出的下一个段应当在其上开始读取的地址。
7) 结束读位置: 这是 TCP 应当在其上停止传输的地址。最初 6) 和 7) 界定了进程想要发送的消息。
8) 重传次数/最大重传: 这些字段使 TCP 能够跟踪它重新传输数据的次数，并且如果 TCP 不要放弃可以忽略它。
9) 超时/标志: 超时字段指定未确认的数据应当在此后被重新传输的延迟。标志字段用作信号量(semaphore)和其他 TCP/进程同步状态报告等。
10) 当前确认/窗口: 当前确认字段标识仍未被目的 TCP 确认的数据的第一个字节。
读写位置在发送缓冲区上循环的移动，写位置总是在读位置的右边(模以缓冲区大小)。
下一个分组序列编号应当约束为小于或等于当前确认和窗口字段的和。在任何情况下，下一个序列编号不应当超过当前确认和序列编号空间一半的和(来避免混乱接收者的重复检测算法)。在图 12 中展示了一种可能的缓冲区格局。
RCB 基本上相同，除了结束读字段被替代为部分段校验和寄存器之外，它允许接收 TCP 在段以多个分组到来的情况下计算和记住部分校验和。在段的最后的分组到来的时候，TCP 可以验证这个校验和，如果成功则确认这个段。
关于在分组交换网络中的进程到进程通信的多数考虑受到普遍存在的电话系统的影响。ARPANET 的主机到主机协议显式的处理在进程之间的单工连接的打开和关闭[9],[10]。提供了对能够构造基于消息的“连接无关”协议的证据[12]，这导致我们仔细的检查了连接(connection)的概念。
术语连接有着广泛的意义。它可以指称在两个实体之间的物理或逻辑路径，它可以指称在这个路径上的流，在推论上它可以指称与架设一个路径有关的动作，它还可以指称在两个或多个实体之间的关联，可能与在它们之间的任何路径有关也可能无关。在本文中，我们不明确的拒绝术语连接，因为它被如此广泛的使用，并且确实意味着有意义的关系，但是在与路径无关的两个或多个实体之间的关联的意义上排除考虑用它。为了使我们的意图更精确，我们将定义在通信中的或准备好通信的两个或更多端口之间的联系为关联(association)。相互关联的端口叫做伙伴(associate)。
对于在两个进程之间发生的任何通信，一个进程必须能够寻址到另一个进程是很清楚的。两个重要的情况是目的端口可能有一个全局的和不改变的地址，或者是全局性唯一的但动态重新分配的地址。虽然在任何一种情况下发送者都必须知道目的端口地址，约定的目的名字，只有在第二种情况下有在每次要求关联的时候从目的地(或它的代表)知道地址的需求。只有在来源地已经知道如何寻址目的地之后，才可以说关联已经出现了。但这是不充分的。如果还需要递送消息的次序，两个 TCP 都必须维护允许正确的定序所需要的信息。在两端都出现了这种信息的时候，则可以说关联已经出现了。
注意我们没有说与路径有关的任何事情，也没说暗含着任意端知道另一端状况的任何事情。只在两个参与者准备好相互通信的时候关联才出现，可能两个参与者都不能验证关联存在直到数据在它们之间流动。
在 ARPANET 中，接口消息处理机(IMP)不是必须打开和关闭从源到目的的连接。原因是连接在效果上总是打开的，因为所有的源和目的地址都从不重新分配5。当名字和位置是静态和不改变的时候，只需标签一个分组的来源和目的地就可以通过网络传输它。按我们的说法，所有来源和目的地形成了一个关联。
5 除非 IMP 在物理上被移动到其他地点，或 HOST 被连接到不同的 IMP。
但是在进程的情况下，我们发现端口地址被持续的使用和重新使用。某些永远存在的进程被赋予一个固定的地址而不再改变(比如 logger 进程)。但是如果我们假定每个 TCP 都有无穷的端口地址供给，所以没有旧地址将被重新使用，则任何动态建立的端口将被赋予下一个未使用的地址。在这种环境下，关于每个消息的预期归宿或必然来源，源和目的 TCP 永远不会有任何混乱，所有的端口都将是伙伴。
不幸的是，TCP(或者更准确的说操作系统)不打算提供无穷的内部端口地址。在每个端口消亡之后这些内部地址都要重新分配。Walden [12]建议可以通过集中注册来提供一组唯一的一致的外部端口地址。新建立的端口可以提交给集中注册来得到一个地址，集中注册保证它在网络中没有被任何主机使用。每个 TCP 都维护匹配外部名字和内部名字的表格，并为与其他进程的通信使用外部名字。这个想法违反了进程间通信不应当要求集中控制的前提。你必须扩展集中注册服务去包括在所有互连接网络中的所有主机来应用这个想法到我们的情况中，所以我们不打算接受它。
让我们从 TCP 的观点考虑这种情况。为了从给定端口发送或接收数据，TCP 需要设置一个 TCB 和一个 RCB，并为二者初始化窗口大小和左窗口边缘。在接收端，这个任务可能要推延到去往给定端口的第一个分组到来。作为协定，第一个分组应当作标记，接收者将同步到接收的序列编号。
在发送端，第一次发送请求将导致使用某个初始序列编号(比如说零)和一个假定的窗口大小来设置一个 TCB。接收 TCP 如果希望的话可以拒绝这个分组，并通过确认机制向发送 TCP 通知正确的窗口大小，但需要下面条件之一
1) 我们主张第一个分组必须是一个完整的段；
2) 可以为这个第一个分组发送一个确认(即使不是一个段，只要确认指定了下一个序列编号，来源地也能理解没有字节被接受了)。
所以，可以完成窗口大小和左窗口边缘的同步而不用通常叫做连接设置的东西是显然的。
从一个伙伴发送到另一个伙伴的涉及到新建立的 RCB 的第一个分组可以用一位来标记，它请求接收者用到来分组的序列编号同步它的左窗口边缘(参见图 8 中的 SYN 位)。TCP 可以检查在分组中和 RCB 中的源和目的端口地址来决定是接受还是忽略请求。
应当做出让目的进程指定它将要 LISTEN 指定端口或“任意”端口的规定。这个最后的主意允许进程比如 logger 进程去接受来自未指定的来源的数据。但这是纯粹的主机的事情。
最初的分组可能包含可以被目的地存储或丢弃的数据，依赖于那时目的缓冲区的可获得性。在另一个方向上，为收到数据返回的确认还指定接收者的窗口大小。
如果接收 TCP 想要拒绝同步请求，它只需要传送设置了释放(REL)位(参见图 8)的一个确认，指示目的端口地址是未知的或不可访问的。发送主机在发送下一个消息或段之前等待这个确认(在接收端接受或拒绝这个同步请求之后)。这种拒绝与否定性数据确认是非常不同的。我们不用显式的否定确认。如果没有确认返回，发送主机可以重新发送而不会介入混乱，如果左窗口边缘在重新传输时未改变的话。
因为消息在传输和重新传输时可能被分解到很多分组中，它必须忽略 REL 标志，除非是在 EM 标志也设置了的情况下。这可以由 TCP 或网关来完成，它可以在除了设置了 EM 标志的所有分组上复位这个标志(参见图 9)。
在关联结束时，TCP 发送带有 ES、EM 和 REL 标志设置的一个分组。如果仍有未完结的分组在传送中还未到达，分组序列编号方案会提醒接收 TCP，所以过早的断联(dissociation)不能发生。
为了确保两个 TCP 都知道了关联已经结束，我们主张接收 TCP 通过发送它自己的 REL 确认来响应 REL。
假设现在一个进程向一个伙伴发送包括与数据在一起的 REL 的一个单一的消息。假定接收 TCP 已经准备好了一个 RCB 来接受这些数据，TCP 将积累到来的分组直到标记了 ES、EM、REL 的分组到达，在此刻向发送者返回 REL。关联就此终止而适当的 TCB 和 RCB 将被销毁。如果一个消息的第一个分组包含 SYN 请求位而最后的分组包含 ES、EM 和 REL 位，则数据将按“每次一个消息”流动。这个模式非常类似 Walden [12]描述的方案，因为只有在接收进程向它的服务 TCP 发起一次新的 LISTEN(像 Walden 的 RECEIVE)命令之后，每个后续的消息才能被接收者接受。注意只有发送者收到确认之后关联才能正确终止。已经指出了6 如果发送者没有收到这个确认，则接收者可能不正确的接收到重复的传输。这将发生在发送者发送设置了 SYN 和 REL 位的重复分组，而目的地已经销毁了前面传输的所有记录的时候。防止这个问题的一种方式是目的地只在某个已知的和适当选择的超时之后销毁关联的记录。但是，这意味着有相同的源和目的端口标识符的新关联不能建立直到这个超时到期。这个问题甚至在 SYN 和 REL 位分解到不同的互联网络分组中的消息序列中都能发生。我们认识到这个问题必须被解决，但不打算在这里深入其中。
6 做 APRA/IPT 的 S. Crocker。
作为选择，两个进程可以发送一个消息，导致在两端各自的 TCP 分配 RCB/TCB 对，它们与交换的数据会合并接着消失。如果建立和销毁 RCB 和 TCB 的花费很小，则这种协议对多数低带宽使用是足够的。这个想法还可能形成相对安全的传输系统的基础。如果通信中的进程同意以只是相互知道的某种(也就是伪随机)方式改变它们的外部端口地址，则每个消息对于外部世界看起来都如同它是不同关联的消息流的一部分。即使数据被第三方解释，他都没有办法知道这个数据应当实际上被考虑一个消息序列的一部分。
我们已经描述了进程相互间逐渐形成关联，从而为可能的数据交换成为伙伴的方式。这些关联在它们的形成之前不需要涉及到数据传输，并且两个伙伴实际上直到它们尝试通信之前不需要能够确定它们是伙伴。
我们已经讨论了与分组交换网络的互连接有关的一些基本问题。特别是，我们描述了一个简单而非常强力和灵活的协议，它为单独网络中分组大小、传输失败、定序、流控和进程到进程关联建立和破坏的差异作好了准备。我们讨论了引发的某些实现问题并发现提议的协议对于有着广泛差异的主机而言是可实现的。
下一个重要步骤是创作这个协议的详细规定，这样就可以进行最初的实验。需要这些实验来确定提议的协议的某些操作性参数(比如，实际上到来的分组失序的频度和程度；在段确认之间有怎样的延迟；重传超时是多少?)。
作者想要感谢很多同事在国际网络协议的早期讨论中的有帮助的建议，特别是 R. Metcalfe、R. Scantlebury、D. Walden 和 Zimmerman； D. Davies 和 L. Pouzin 在分片和记帐问题上的建设性提议；和 S. Crocker 在关联的建立和破坏上的建议。
[1] L. Roberts and B. Wessler, “Computer network development to achieve resource sharing,” in 1970 Spring Joint Computer Conf., AFIPS Conf. Proc., vol. 36. Montvale, N. J.: AFIPS Press, 1970, pp. 543—549.
[2] L. Pouzin, “Presentation and major design aspects of the CYCLADES computer network,” in Proc. 3rd Data Communications Symp., 1973.
[3] F. R. E. Dell, “Features of a proposed synchronous data network,” in Proc. 2nd Symp. Problems in the Optimization of Data Communications Systems, 1971, pp. 50—57.
[4] R. A. Scantlebury and P. T. Wilkinson, “The design of a switching system to allow remote access to computer services by other computers and terminal devices,” in Proc. 2nd Symp. Problems in the Optimization of Data Communications Systems, 1971, pp. 160-167.
[5] D. L. A. Barber, “The European computer network project,” in Computer Communications: Impacts and Implications, S. Winkler, Ed. Washington , D.C., 1972, pp. 192-200.
[6] R. Despres, “A packet switching network with graceful saturated operation,” in Computer Communications: Impacts and Implications, S. Winkler, Ed. Washington, D.C., 1972, pp. 345-351.
[7] R. E. Kahn and W. R. Crowther, “Flow control in a resource-shaping computer network,” IEEE Trans. Commun., vol. COM-20, pp. 539-546, June 1972.
[8] J. F. Chambon, M. Elie, J. Le Bihan, G. LeLann, and H. Zimmerman, “Functional specification of transmission station in the CYCLADES network. STST protocol” (in French), I.R.I.A. Tech. Rep. SCH502.3, May 1973.
[9] S. Carr, S. Crocker, and V. Cerf, “HOST-HOST Communication Protocol In the ARPA Network,” in Spring Joint Computer Conf., AFIPS Conf. Proc., vol. 36. Montvale, N.J.: AFIPS Press, 1970, pp. 589-597.
[10] A. McKenzie, “HOST/HOST protocol for the ARPA network,” in Current Network Protocols, Network Information Cen., Menlo Park, Calif., NIC 8246, Jan. 1972.
[11] L. Pouzin, “Address format in Mitranet,” NIC 14497, INWG 20, Jan. 1973.
[12] D. Walden, “A system for interprocess communication in a resource sharing computer network,” Commun. Ass. Comput. Mach., vol. 15, pp. 221-230, Apr. 1972.
[13] B. Lampson, “A scheduling philosophy for multiprocessing system,” Commun. Ass. Comput. Mach., vol. 11, pp. 347-360, May 1968.
[14] F. E. Heart, R. E. Kahn, S. Ornstein, W. Crowther, and D. Walden, “The interface message processor for the ARPA computer network,” in Proc. Spring Joint Computer Conf., AFIPS Conf. Proc., vol. 36. Montvale, N.J.: AFIPS Press, 1970, pp. 551-567.
[15] N. G. Anslow and J. Hanscoff, “Implementation of international data exchange networks,” in Computer Communications: Impacts and Implications, S. Winkler, Ed. Washington, D. C., 1972, pp. 181-184.
[16] A. McKenzie, “HOST/HOST protocol design considerations,” INWG Note 16, NIC 13879, Jan. 1973.
[17] R. E. Kahn, “Resource-sharing computer communication networks”, Proc. IEEE, vol. 60, pp. 1397-1407, Nov. 1972.
[18] Bolt, Beranek, and Newman, “Specification for the interconnection of a host and an IMP,” Bolt Beranek and Newman, Inc., Cambridge, Mass., BBN Rep. 1822 (revised), Apr. 1973.
|
Vinton G. Cerf was born in New Haven, Conn., in
1943. He did undergraduate work in mathematics at Stanford University, Stanford,
Calif., and received the Ph.D. degree in computer science from the University of
California at Los Angeles, Los Angeles, Calif., in 1972.
He was with IBM in Los Angeles from 1965 through 1967 and consulted and/or worked part time at UCLA from 1967 through 1972. Currently he is Assistant Professor of Computer Science and Electrical Engineering at Stanford University, and consultant to Cabledata Associates. Most of his current research is supported by the Defense Advanced Research Projects Agency and by the National Science Foundation on the technology and economics of computer networking. He is Chairman of IFIP TC6.1, an international network working group which is studying the problem of packet network interconnection. |
|
Robert E. Kahn (M’65) was born in Brooklyn, N.Y., on December 23 1938. He received the B.E.E. degree from the City College of New York, New York, in 1960, and the M.A. and Ph.D. degrees from Princeton University, Princeton, N.J., in 1962 and 1964, respectively. From 1960 to 1962 he was a Member of the Technical Staff of Bell Telephone Laboratories, Murray Hill, N.J., engaged in traffic and communication studies. From 1964 to 1966 he was a Ford Postdoctoral Fellow and an Assistant Professor of Electrical Engineering at the Massachusetts Institute of Technology, Cambridge, where he worked on communications and information theory. From 1966 to 1972 he was a Senior Scientist at Bolt Beranek and Newman, Inc., Cambridge, Mass., where he worked on computer communications network design and techniques for distributed computation. Since 1972 he has been with the Advanced Research Projects Agency, Department of Defense, Arlington, Va. Dr. Kahn is a member of Tau Beta Pi, Sigma Xi, Eta Kappa Nu, the Institute of Mathematical Statistics, and the Mathematical Association of America. He was selected to serve as a National Lecturer for the Assocation for Computing Machinery in 1972.
|
