网络互联历史 | 分组网络协议奠基与早期架构演化

注：本文为 "网络互联历史" 相关合辑。

英文引文，机翻未校。

中文引文，略作重排。

如有内容异常，请看原文。

A Protocol for Packet Network Intercommunication

分组网络互联协议

VINTON G. CERF AND ROBERT E. KAHN, MEMBER, IEEE

文顿·G·瑟夫罗伯特·E·卡恩（IEEE 会员）

Abstract

摘要

A protocol that supports the sharing of resources that exist in different packet switching networks is presented. The protocol provides for variation in individual network packet sizes, transmission failures, sequencing, flow control, end-to-end error checking, and the creation and destruction of logical process-to-process connections. Some implementation issues are considered, and problems such as internetwork routing, accounting, and timeouts are exposed.

本文提出一套协议，用于实现不同分组交换网络间的资源共享。该协议可适配各网络分组长度差异、传输故障、报文排序、流量控制、端到端差错校验，同时支持进程间逻辑连接的建立与释放。文中探讨了若干实现层面的问题，并列举了网间路由、计费统计、超时机制等相关技术难题。

INTRODUCTION

引言

IN THE LAST few years considerable effort has been expended on the design and implementation of packet switching networks $1$ - $7$ , $14$ , $17$ . A principle reason for developing such networks has been to facilitate the sharing of computer resources. A packet communication network includes a transportation mechanism for delivering data between computers or between computers and terminals. To make the data meaningful, computer and terminals share a common protocol (i.e, a set of agreed upon conventions). Several protocols have already been developed for this purpose $8$ - $12$ , $16$ . However, these protocols have addressed only the problem of communication on the same network. In this paper we present a protocol design and philosophy that supports the sharing of resources that exist in different packet switching networks.

过去数年，业界投入大量精力开展分组交换网络的设计与搭建工作 $1$ - $7$ , $14$ , $17$ 。搭建此类网络的一类出发点是实现计算机资源共享。分组通信网络内置一套传输机制，用于在计算机之间、计算机与终端之间完成数据投递。若要数据具备可解读性，计算机与终端必须遵循统一协议（即双方约定的一套通信规范）。业界已推出多款面向该场景的协议 $8$ - $12$ , $16$ ，但这些协议仅能解决单网络内部通信问题。本文将给出一套协议设计方案与设计思路，实现跨不同分组交换网络的资源共享。

After a brief introduction to internetwork protocol issues, we describe the function of a GATEWAY as an interface between networks and discuss its role in the protocol. We then consider the various details of the protocol, including addressing, formatting, buffering, sequencing, flow control, error control, and so forth. We close with a description of an interprocess communication mechanism and show how it can be supported by the internetwork protocol.

在简要介绍网间协议相关问题后，本文将阐述网关作为网络间接口的功能，以及网关在整套协议中的作用。随后逐一拆解协议各细节，涵盖寻址、报文格式、缓存、排序、流量控制、差错控制等内容。文末介绍进程间通信机制，并说明该机制如何依托这套网间协议运行。

Even though many different and complex problems must be solved in the design of an individual packet switching network, these problems are manifestly compounded when dissimilar networks are interconnected. Issues arise which may have no direct counterpart in an individual network and which strongly influence the way in which internetwork communication can take place.

单一分组交换网络的设计需要解决大量复杂问题，而异构网络互联会进一步放大各类问题。互联场景会催生诸多单网络中不存在的新问题，这类问题会直接约束网间通信的实现方式。

A typical packet switching network is composed of a set of computer resources called HOSTS, a set of one or more packet switches, and a collection of communication media that interconnect the packet switches. Within each HOST, we assume that there exist processes which must communicate with processes in their own or other HOSTS. Any current definition of a process will be adequate for our purposes $13$ . These processes are generally the ultimate source and destination of data in the network. Typically, within an individual network, there exists a protocol for communication between any source and destination process. Only the source and destination processes require knowledge of this convention for communication to take place. Processes in two distinct networks would ordinarily use different protocols for this purpose. The ensemble of packet switches and communication media is called the packet switching subnet. Fig. 1 illustrates these ideas.

典型分组交换网络由三类组件构成：称作主机的计算机资源、一台或多台分组交换机、用于连接分组交换机的通信介质。我们假定每台主机内部运行若干进程，进程需要与本机或其他主机上的进程交换数据。现有任意一种进程定义均可适配本文研究场景 $13$ 。进程是网络数据的最终发送方与接收方。单网络内部会配套一套协议，支撑任意源进程与目的进程通信；通信仅要求收发两端进程知晓该协议规范。分属两个不同网络的进程，通常会采用互不兼容的通信协议。分组交换机与通信介质共同构成分组交换子网，图 1 展示上述架构。

Fig. 1. Typical packet switching network.

图 1 典型分组交换网络

In a typical packet switching subnet, data of a fixed maximum size are accepted from a source HOST, together with a formatted destination address which is used to route the data in a store and forward fashion. The transmit time for this data is usually dependent upon internal network parameters such as communication media data rates, buffering and signalling strategies, routeing, propagation delays, etc. In addition, some mechanism is generally present for error handling and determination of status of the networks components.

典型分组交换子网会接收主机发送的、长度不超过固定上限的数据，同时携带标准化目的地址，子网基于存储转发机制依据地址完成数据路由。数据传输耗时由网络内部参数决定，包含通信介质速率、缓存与信令策略、路由方案、传播时延等。同时子网一般配套对应机制，用于差错处理与网络组件状态检测。

Individual packet switching networks may differ in their implementations as follows.

各分组交换网络在实现方式上存在以下几类差异：

Each network may have distinct ways of addressing the receiver, thus requiring that a uniform addressing scheme be created which can be understood by each individual network.

各网络的接收端寻址格式互不相同，因此需要一套统一寻址规则，保证所有网络均可识别。
Each network may accept data of different maximum size, thus requiring networks to deal in units of the smallest maximum size (which may be impractically small) or requiring procedures which allow data crossing a network boundary to be reformatted into smaller pieces.

各网络支持的最大传输分组长度存在区别，要么所有网络统一采用最小长度作为传输单元（该长度可能过小，不具备工程可行性），要么制定分片规则，让跨网络边界的数据拆分为更小单元传输。
The success or failure of a transmission and its performance in each network is governed by different time delays in accepting, delivering, and transporting the data. This requires careful development of internetwork timing procedures to insure that data can be successfully delivered through the various networks.

各网络的数据接收、转发、传输时延参数不统一，直接决定传输能否成功、传输性能高低。因此需要设计完善的网间时序规则，保障数据可跨多网络完整投递。
Within each network, communication may be disrupted due to unrecoverable mutation of the data or missing data. End-to-end restoration procedures are desirable to allow complete recovery from these conditions.

单网络内可能出现数据不可逆损坏、数据丢失等通信中断场景，因此需要端到端恢复机制，处理此类故障。
Status information, routing, fault detection, and isolation are typically different in each network. thus, to obtain verification of certain conditions, such as an inaccessible or dead destination, various kinds of coordination must be invoked between the communicating networks.

各网络的状态上报、路由策略、故障检测、故障隔离方案存在区别。若要确认目的主机不可达、离线等状态，互联网络之间需要建立多类协同机制。

It would be extremely convenient if all the differences between networks could be economically resolved by suitable interfacing at the network boundaries. For many of the differences, this objective can be achieved. However, both economic and technical considerations lead us to prefer that the interface be as simple and reliable as possible and deal primarily with passing data between networks that use different packet switching strategies.

若能在网络边界通过接口低成本抹平所有网络差异，将大幅简化互联工作；多数差异可通过该方式处理。但结合成本与技术层面考量，接口应当设计得尽可能简洁、稳定，仅负责在采用不同分组交换策略的网络间转发数据。

The question now arises as to whether the interface ought to account for differences in HOST or process level protocols by transforming the source conventions into the corresponding destination conventions. We obviously want to allow conversion between packet switching strategies at the interface, to permit interconnection of existing and planned networks. However, the complexity and dissimilarity of the HOST or process level protocols makes it desirable to avoid having to transform between them at the interface, even if this transformation were always possible. Rather, compatible HOST and process level protocols must be developed to achieve effective internetwork resource sharing. The unacceptable alternative is for every HOST or process to implement every protocol (a potentially unbounded number) that may be needed to communicate with other networks. We therefore assume that a common protocol is to be used between HOST'S or processes in different networks and that the interface between networks should take as small a role as possible in this protocol.

随之产生一个问题：网络接口是否需要转换主机层、进程层协议，将发送端协议规范转为接收端规范。我们希望接口完成分组交换策略的转换，以此兼容现有、规划中的各类网络。但主机、进程层协议复杂度高、差异巨大，即便转换具备理论可行性，也不应交由接口处理。可行方案是统一设计可兼容的主机、进程层协议，实现高效网间资源共享。另一种方案存在明显缺陷：每台主机、每个进程都要部署所有跨网通信所需协议，协议数量没有上限。因此本文设定：跨网络的主机、进程统一使用一套公共协议，网络间接口仅承担少量协议相关工作。

To allow networks under different ownership to interconnect, some accounting will undoubtedly be needed for traffic that passes across the interface. In its simplest terms, this involves an accounting of packets handled by each net for which charges are passed from net to net until the buck finally stops at the user or his representative. Furthermore, the interconnection must preserve intact the internal operation of each individual network. This is easily achieved if two networks interconnect as if each were a HOST to the other network, but without utilising or indeed incorporating any elaborate HOST protocol transformations.

分属不同运营主体的网络互联时，需要对跨接口流量做计费统计。最简计费逻辑为：统计各网络转发的分组数量，费用在网络间逐层流转，最终由终端用户或其代理承担。同时互联架构不能破坏各网络自身内部运行逻辑。实现方式为：两个网络互联时，彼此将对方视作一台普通主机，不执行复杂的主机协议转换操作。

It is thus apparent that the interface between networks must play a central role in the development of any network interconnection strategy. We give a special name to this interface that performs these functions and call it a GATEWAY.

由此可见，网络间接口在各类网络互联方案搭建过程中起到关键作用。本文将具备上述功能的接口命名为网关（GATEWAY）。

THE GATEWAY NOTION

网关概念

In Fig. 2 we illustrate three individual networks labelled A . B , and C which are joined by GATEWAYS M and N . GATEWAY M interfaces network A with network B , and GATEWAY N interfaces network B to network C . We assume that an individual network may have more than one GATEWAY (e.g., network B ) and that there may be more than one GATEWAY path to use in going between a pair of networks. The responsibility for properly routing data resides in the GATEWAY.

图 2 展示三套独立网络 A、B、C，由网关 M、网关 N 完成互联。网关 M 对接网络 A 与网络 B，网关 N 对接网络 B 与网络 C。单网络可部署多台网关（如网络 B）；两套网络之间也可存在多条网关转发路径。网关承担数据路由调度工作。

Fig. 2. Three networks interconnected by two GATEWAYS.

图 2 两台网关互联三套网络

In practice, a GATEWAY between two networks may be composed of two halves, each associated with its own network. It is possible to implement each half of a GATEWAY so it need only embed internetwork packets in local packet format or extract them. We propose that the GATEWAY handle internetwork packets in a standard format, but we are not proposing any particular transmission procedure between GATEWAY halves.

实际应用中，两套网络间的网关可拆分为两个独立模块，分别对接对应网络。每个模块仅需完成网间分组与本地网络分组格式的封装、解封装。本文设定网关统一处理标准化格式的网间分组，不规定网关两个模块之间的传输流程。

Let us now trace the flow of data through the interconnected networks. We assume a packet of data from process X enters network A destined for process Y in network C .The address of Y is initially specified by process X and the address of GATEWAY M is derived from the address of process Y We make no attempt to specify whether the choice of GATEWAY is made by process X , its HOST, or one of the packet switches in network A . The packet traverses network A until it reaches GATEWAY M .At the GATEWAY, the packet is reformatted to meet the requirements of network B , account is taken of this unit of flow between A and B , and the GATEWAY delivers the packet to network B .Again the derivation of the next GATEWAY address is accomplished based on the address of the destination Y . In this case, GATEWAY N is the next one. The packet traverses network B until it finally reaches GATEWAY N where it is formatted to meet the requirements of network C . Account is again taken of this unit of flow between networks B and C Upon entering network C , the packet is routed to the HOST in which process Y resides and there it is delivered to its ultimate destination.

以下为数据在互联网络中的转发流程：进程 X 发送一份分组，目标为网络 C 内的进程 Y。进程 X 预先填写进程 Y 的地址，系统通过该地址解析出网关 M。网关选择逻辑可由进程 X、主机、网络 A 内任意一台分组交换机执行，本文不做限定。分组穿过网络 A，抵达网关 M；网关重新调整分组格式以适配网络 B，统计本次跨 A、B 网络的流量，随后将分组送入网络 B。系统再次通过目的进程 Y 的地址解析出下一级网关 N。分组穿过网络 B 抵达网关 N，网关调整格式适配网络 C，统计跨 B、C 网络流量。分组进入网络 C 后，路由至进程 Y 所在主机，最终交付目标进程。

Since the GATEWAY must understand the address of the source and destination HOSTS, this information must be available in a standard format in every packet which arrives at the GATEWAY. This information is contained in an internetwork header prefixed to the packet by the source HOST. The packet format, including the internetwork header, is illustrated in Fig. 3. The source and destination entries uniformly and uniquely identify the address of every HOST in the composite network. Addressing is a subject of considerable complexity which is discussed in greater detail in the next section. The next two entries in the header provide a sequence number and a byte count that may be used to properly sequence the packets upon delivery to the destination and may also enable the GATEWAYS to detect fault conditions affecting the packet. The flag field is used to convey specific control information and is discussed in the section on retransmission and duplicate detection later. The remainder of the packet consists of text for delivery to the destination and a trailing check sum used for end-to-end software verification. The GATEWAY does not modify the text and merely forwards the check sum along without computing or recomputing it.

网关需要识别源主机、目的主机地址，因此所有抵达网关的分组都必须携带标准化地址信息。该信息由源主机封装在分组头部的网间首部中。图 3 展示包含网间首部的完整分组格式。首部内源地址、目的地址字段可全局、唯一标识整套互联网络内所有主机。寻址机制复杂度较高，下一节展开详细说明。首部后续两个字段分别为序列号、字节计数，用于接收端完成分组重排序，同时网关可依托这两个字段识别分组传输故障。标志位字段承载各类控制指令，将在重传与重复报文检测章节展开说明。分组剩余部分为待交付数据，末尾附带校验和，用于端到端软件校验。网关不会修改数据内容，仅原样转发校验和，不重新计算。

Fig. 3. Internetwork packet format (fields not shown to scale).

图 3 网间分组格式（各字段长度未按比例绘制）

Each network may need to augment the packet format before it can pass through the individual network. We have indicated a local header in the figure which is prefixed to the beginning of the packet. This local header is introduced merely to illustrate the concept of embedding an internetwork packet in the format of the individual network through which the packet must pass. It will obviously vary in its exact form from network to network and may even be unnecessary in some cases. Although not explicitly indicated in the figure, it is also possible that a local trailer may be appended to the end of the packet.

分组进入单网络传输前，网络可能需要额外封装本地格式。图中绘制的本地首部加在分组最前端，仅用于演示"网间分组封装进本地网络格式"这一逻辑。各网络本地首部格式互不相同，部分网络甚至无需封装本地首部。图中未标注，但分组尾部也可追加本地尾部字段。

Unless all transmitted packets are legislatively restricted to be small enough to be accepted by every individual network, the GATEWAY may be forced to split a packet into two or more smaller packets. This action is called fragmentation and must be done in such a way that the destination is able to piece together the fragmented packet. It is clear that the internetwork header format imposes a minimum packet size which all networks must carry (obviously all networks will want to carry packets larger than this minimum). We believe the long range growth and development of internetwork communication would be seriously inhibited by specifying how much larger than the minimum a packet size can be, for the following reasons.

若不强制所有分组长度适配所有网络的最大承载上限，网关需要将大分组拆分为多份小分组，该操作称为分片；分片规则需要保证接收端可将分片重组还原完整分组。网间首部格式规定了所有网络都必须支持的最小分组长度（所有网络实际支持的分组长度均大于该下限）。若统一规定分组最大长度，会长期限制网间通信的拓展，原因如下：

If a maximum permitted packet size is specified then it becomes impossible to completely isolate the internal packet size parameters of one network from the internal packet size parameters of all other networks.

统一规定最大分组长度后，各网络内部分组长度参数将无法独立调整，网络间参数完全绑定。
It would be very difficult to increase the maximum permitted packet size in response to new technology (e.g. large memory systems, higher data rate communication facilities, etc.) since this would require the agreement and then implementation by all participating networks.

伴随大内存、高速传输介质等新技术出现，若要上调最大分组长度，需要所有互联网络统一协商、同步部署，调整难度极高。
Associative addressing and packet encryption may require the size of a particular packet to expand during transit for incorporation of new information.

关联寻址、分组加密场景下，传输过程中分组可能需要扩容，新增额外信息字段。

Provision for fragmentation (regardless of where it is performed) permits packet size variations to be handled on an individual network basis without global administration and also permits HOSTS and processes to be insulated from changes in the packet sizes permitted in any networks through which their data must pass.

分片机制（无论分片执行位置）允许各网络独立设定分组长度，无需全局统一管控；同时主机、进程无需感知数据途经网络的分组长度调整。

If fragmentation must be done, it appears best to do it upon entering the next network at the GATEWAY since only this GATEWAY (and not the other networks) must be aware of the internal packet size parameters which made the fragmentation necessary.

分片操作最优执行位置为网关，分组进入下一级网络前完成分片；仅该网关需要知晓触发分片的对端网络分组长度参数，其余网络无需感知。

If a GATEWAY fragments an incoming packet into two or more packets, they must eventually be passed along to the destination HOST as fragments or reassembled for the HOST. It is conceivable that one might desire the GATEWAY to perform the reassembly to simplify the task of the destination HOST (or process) and/or to take advantage of the larger packet size. We take the position that GATEWAY should not perform this function since GATEWAY reassembly can lead to serious buffering problems, potential deadlocks, the necessity for all fragments of a packet to pass through the same GATEWAY, and increased delay in transmission. Furthermore, it is not sufficient for the GATEWAY to provide this function since the final GATEWAY may also have to fragment a packet for transmission. Thus the destination HOST must be prepared to do this task.

网关将一份分组拆分为多片后，分片会完整转发至目的主机，由主机完成重组。有人提出交由网关执行重组，简化目的主机、进程的处理逻辑，同时适配更大分组长度。本文不采用该方案：网关重组会引发缓存资源紧张、死锁风险，且一份分组的所有分片必须经由同一网关转发，传输时延会显著增加。同时网关重组无法覆盖全部场景，最后一级网关仍可能对分组二次分片。因此重组工作交由目的主机完成。

Let us now turn briefly to the somewhat unusual accounting effect which arises when a packet may be fragmented by one or more GATEWAY. We assume, for simplicity, that each network initially charges a fixed rate per packet transmitted, regardless of distance, and if one network can handle a larger packet size than another, it charges a proportionally larger price per packet. We also assume that a subsequent increase in any network's packet size does not result in additional cost per packet to its users. The charge to a user thus remains basically constant through any net which must fragment a packet. The unusual effect occurs when a packet is fragmented into smaller packets which must individually pass through a subsequent network with a larger packet size than the original unfragmented packet. We expect that most networks will naturally select packet sizes close to one another, but in any case, an increase in packet size in one net, even when it causes fragmentation, will not increase the cost of transmission and may actually decrease it. In the event that any other packet charging policies (than the one we suggest) are adopted, differences in cost can be used as an economic lever toward optimisation of individual network performance.

下面简要分析多网关分片带来的特殊计费影响。为简化分析，设定初始计费规则：各网络按分组数量固定计费，与传输距离无关；若网络支持更大分组长度，单分组计费金额同步按比例上调。同时设定任意网络上调分组长度后，终端用户单分组成本不会上涨。基于该规则，数据途经需要分片的网络时，用户总成本基本不变。特殊场景：一份分组被拆分为多片，分片单独穿过支持更大原生分组的下游网络。多数网络会选择相近的分组长度；即便某网络上调分组长度触发分片，用户传输成本不会上升，甚至可能下降。若采用本文以外的计费规则，成本差异可作为调节手段，推动各网络优化自身运行性能。

PROCESS LEVEL COMMUNICATION

进程层通信

We suppose that processes wish to communicate in full duplex with their correspondents using unbounded but finite length messages. A single character might constitute the text of a message from a process to a terminal or vice versa. An entire page of characters might constitute the text of a message from a file to a process. A data stream (e.g. a continuously generated bit string) can be represented as a sequence of finite length messages.

进程与对端采用全双工通信，交互报文长度无固定上限，但单份报文长度有限。进程向终端发送的报文可仅包含单个字符，反之终端向进程传输同理；文件向进程传输的报文可包含整页字符。连续比特流这类数据流，可拆解为多段有限长度报文序列。

Within a HOST we assume that existence of a transmission control program (TCP) which handles the transmission and acceptance of messages on behalf of the processes it serves. The TCP is in turn served by one or more packet switches connected to the HOST in which the TCP resides. Processes that want to communicate present messages to the TCP for transmission, and TCP's deliver incoming messages to the appropriate destination processes. We allow the TCP to break up messages into segments because the destination may restrict the amount of data that may arrive, because the local network may limit the maximum transmission size, or because the TCP may need to share its resources among many processes concurrently. Furthermore, we constrain the length of a segment to an integral number of 8-bit bytes. This uniformity is most helpful in simplifying the software needed with HOST machines of different natural word lengths.

每台主机内部部署传输控制程序（TCP），TCP 代其管理的进程处理报文收发。TCP 依托本机接入的一台或多台分组交换机完成网络传输。需要通信的进程将报文提交 TCP 发送；TCP 收到下行报文后转发至对应目的进程。TCP 可将长报文拆分为分段，拆分触发条件包括：接收端限制接收数据量、本地网络约束最大传输长度、TCP 需要为多进程并发分配资源。同时规定分段长度必须为 8 比特字节的整数倍，该统一标准可简化不同字长主机的配套软件。

Provision at the process level can be made for padding a message that is not an integral number of bytes and for identifying which of the arriving bytes of text contain information of interest to the receiving process.

进程层配套填充机制，处理字节数非整数的报文；同时提供标识字段，区分接收端需要读取的有效数据字节。

Mutliplexing and demultiplexing of segments among processes are fundamental tasks of the TCP. On transmission, a TCP must multiplex together segments from different source processes and produce internetwork packets for delivery to one of its serving packet switches. On reception, a TCP will accept a sequence of packets from its serving packet switch(es). From this sequence of arriving packets (generally from different HOSTS), the TCP must be able to reconstruct and deliver messages to the proper destination processes.

进程间分段的多路复用、多路解复用是 TCP 的基础工作。发送侧：TCP 汇总多源进程的分段，封装为网间分组，下发至本机接入的分组交换机。接收侧：TCP 从分组交换机接收批量分组（通常来自多台主机），将分组还原为完整报文，分发至对应目的进程。

We assume that every segment is augmented with additional information that allows transmitting and receiving TCP's to identify destination and source processes, respectively. At this point, we must face a major issue. How should the source TCP format segments destined for the same destination TCP? We consider two cases.

每一段分段都会附加额外标识信息，让收发两端 TCP 识别对应源、目的进程。此处存在一类需要解决的问题：源 TCP 如何封装发往同一目的 TCP 的分段？本文介绍两种实现方案。

Case 1): If we take the position that segment boundaries are immaterial and that a byte stream can be formed of segments destined for the same TCP, then we may gain improved transmission efficiency and resource sharing by arbitrarily parceling the stream into packets, permitting many segments to share a single internetwork packet header. However, this position results in the need to reconstruct exactly, and in order, the stream of text bytes produced by the source TCP. At the destination, this stream must first be parsed into segments and these in turn must be used to reconstruct messages for delivery to the appropriate processes.

方案 1：忽略分段边界，将发往同一 TCP 的所有分段拼接为字节流；字节流可任意拆分封装分组，多段分段共用一份网间首部，以此提升传输效率、优化资源分配。但该方案要求接收端完整、有序还原源 TCP 输出的字节流；接收端需要先将字节流切分为分段，再将分段重组为完整报文，分发至对应进程。

There are fundamental problems associated with this strategy due to the possible arrival of packets out of order at the destination. The most critical problem appears to be the amount of interference that processes sharing the same TCP-TCP byte stream may cause among themselves. This is especially so at the receiving end. First, the TCP may be put to some trouble to parse the stream back into segments and then distribute them to buffers where messages are reassembled. If it is not readily apparent that all of a segment has arrived (remember, it may come as several packets), the receiving TCP may have to suspend parsing temporarily until more packets have arrived. Second, if a packet is missing, it may not be clear whether succeeding segments, even if they are identifiable, can be passed on to the receiving process, unless the TCP has knowledge of some process level sequencing scheme. Such knowledge would permit the TCP to decide whether a succeeding segment could be delivered to its waiting process. Finding the beginning of a segment when there are gaps in the byte stream may also be hard.

分组乱序抵达接收端会给该方案带来固有缺陷。同一 TCP 字节流内的多进程会互相干扰，接收端该问题尤为突出：

1）TCP 需要消耗算力将字节流切分为分段，存入缓存重组报文；一段分段可能拆分为多份分组抵达，若未收齐分片，TCP 需要暂停解析流程等待剩余分组。

2）若存在分组丢失，即便后续分段可识别，TCP 也无法直接转发给进程；只有配套进程层排序规则，TCP 才能判断后续分段是否可交付。字节流存在空缺时，分段起始位置的识别难度也会上升。

Case 2): Alternatively, we might take the position that the destination TCP should be able to determine, upon its arrival and without additional information, for which process or processes a received packet is intended, and if so, whether it should be delivered then.

方案 2：另一种思路，接收端 TCP 收到分组后，无需额外查询即可直接识别分组归属进程，同时判断该分组是否可立即交付。

If the TCP is to determine for which process an arriving packet is intended, every packet must contain a process header (distinct from the internetwork header) that completely identifies the destination process. For simplicity, we assume that each packet contains text from a single process which is destined for a single process. Thus each packet need contain only one process header. To decide whether the arriving data is deliverable to the destination process, the TCP must be able to determine whether the data is in the proper sequence (we can make provision for the destination process to instruct its TCP to ignore sequencing, but this is considered a special case). With the assumption that each arriving packet contains a process header, the necessary sequencing and destination process identification is immediately available to the destination TCP.

若要 TCP 直接识别分组归属进程，每份分组必须携带进程首部（与网间首部相互独立），完整标识目的进程。简化设定：一份分组仅承载单一源进程发往单一目的进程的数据，因此每份分组仅需一份进程首部。TCP 判断数据是否可交付时，需要校验数据顺序（支持特殊模式，由目的进程告知 TCP 忽略顺序校验）。每份分组自带进程首部后，接收端 TCP 可直接读取排序标识与进程标识。

Both Cases 1) and 2) provide for the demultiplexing and delivery of segments to destination processes, but only Case 2) does so without the introduction of potential interprocess interference. Furthermore, Case 1) introduces extra machinery to handle flow control on a HOST-to-HOST basis, since there must also be some provision for process level control, and this machinery is little used since the probability is small that within a given HOST, two processes will be coincidentally scheduled to send messages to the same destination HOST. For this reason, we select the method of Case 2) as a part of the internetwork transmission protocol.

方案 1、方案 2 均可实现分段解复用与分发，但仅方案 2 不会引发进程间相互干扰。此外方案 1 需要额外搭建主机间流量控制逻辑，同时配套进程层控制机制；同一主机内多进程同时向同一目的主机发送报文的场景出现概率较低，该套控制逻辑利用率偏低。本文将方案 2 纳入网间传输协议规范。

ADDRESS FORMATS

The selection of address formats is a problem between networks because the local network addresses of TCP's may vary substantially in format and size. A uniform internetwork TCP address space, understood by each GATEWAY and TCP, is essential to routing and delivery of internetwork packets.

地址格式

TCP 在各网络内的本地地址格式、长度差异较大，因此地址格式设计是跨网络互联的一类问题。需要一套统一的网间 TCP 地址空间，网关与所有 TCP 均可识别，以此支撑网间分组路由与投递。

Similar troubles are encountered when we deal with process addressing and, more generally, port addressing. We introduce the notion of ports in order to permit a process to distinguish between multiple message streams. The port is simply a designator of one such message stream associated with a process. The means for identifying a port are generally different in different operating systems, and therefore, to obtain uniform addressing, a standard port address format is also required. A port address designates a full duplex message stream.

进程寻址、端口寻址会遇到同类问题。本文引入端口概念，用于区分同一进程的多条独立报文流。端口是进程下属单条报文流的标识。不同操作系统的端口本地标识规则互不相同，因此需要标准化端口地址格式实现统一寻址。一份端口地址对应一条全双工报文流。

TCP ADDRESSING

TCP 寻址

TCP addressing is intimately bound up in routeing issues, since a HOST or GATEWAY must choose a suitable destination HOST or GATEWAY for an outgoing internetwork packet. Let us postulate the following address format for the TCP address (Fig. 4). The choice for network identification (8 bits) allows up to 256 distinct networks. This size seems sufficient for the foreseeable future. Similarly, the TCP identifier field permits up to 65 536 distinct TCP's to be addressed, which seems more than sufficient for any given network.

TCP 寻址与路由逻辑深度绑定，主机、网关需要依据地址为出站网间分组选择下一跳主机或网关。本文设定 TCP 地址格式如图 4：网络标识占用 8 比特，最多可区分 256 套独立网络，该容量可覆盖中长期互联需求。TCP 标识字段长度支持单网络内最多 65536 台 TCP，容量充足。

Fig. 4. TCP address.

图 4 TCP 地址格式

As each packet passes through a GATEWAY, the GATEWAY observes the destination network ID to determine how to route the packet. If the destination network is connected to the GATEWAY, the lower 16 bits of the TCP address are used to produce a local TCP address in the destination network. If the destination network is not connected to the GATEWAY, the upper 8 bits are used to select a subsequent GATEWAY. We make no effort to specify how each individual network shall associate the internetwork TCP identifier with its local TCP address. We also do not rule out the possibility that the local network understands the internetwork addressing scheme and thus alleviates the GATEWAY of the routing responsibility.

分组途经网关时，网关读取目的网络 ID 判定路由走向。若目的网络与本机网关直连，TCP 地址低 16 比特转换为目的网络本地 TCP 地址；若目的网络未直连本机网关，依据高 8 比特选择下一级网关。本文不规定各网络如何将网间 TCP 标识映射至本地 TCP 地址；同时不排除本地网络原生支持网间寻址规则，由本地网络承担路由工作，减轻网关负担。

PORT ADDRESSING

端口寻址

A receiving TCP is faced with the task of demultiplexing the stream of internetwork packets it receives and reconstructing the original messages for each destination process. Each operating system has its own internal means of identifying processes and ports. We assume that 16 bits are sufficient to serve as internetwork port identifiers. A sending process need not know how the destination port identification will be used. The destination TCP will be able to parse this number appropriately to find the proper buffer into which it will place arriving packets. We permit a large port number field to support processes which want to distinguish between many different message streams concurrently. In reality, we do not care how the 16 bits are sliced up by the TCP's involved.

接收端 TCP 需要对入站网间分组做解复用，为各目的进程还原完整报文。不同操作系统内部进程、端口标识规则不同。本文设定网间端口标识占用 16 比特，发送进程无需知晓接收端如何解析端口号；接收端 TCP 可解析该数值，匹配对应缓存存入分组。大长度端口字段可支撑进程同时区分海量独立报文流，两端 TCP 可自由拆分使用 16 比特端口字段，本文不做约束。

Even though the transmitted port name field is large, it is still a compact external name for the internal representation of the port. The use of short names for port identifiers is often desirable to reduce transmission overhead and possibly reduce packet processing time at the destination TCP. Assigning short names to each port, however, requires an initial negotiation between source and destination to agree on a suitable short name assignment, the subsequent maintenance of conversion tables at both the source and the destination, and a final transaction to release the short name. For dynamic assignment of port names, this negotiation is generally necessary in any case.

尽管传输端口字段长度较长，但相比操作系统内部端口标识，该外部标识仍具备简洁性。采用短端口标识可降低传输开销，缩短接收端 TCP 分组处理耗时。但端口短标识需要收发两端预先协商分配规则，两端持续维护映射表，通信结束后执行释放流程。动态分配端口标识场景下，该协商流程通常不可省略。

SEGMENT AND PACKET FORMATS

分段与分组格式

As shown in Fig. 5, messages are broken by the TCP into segments whose format is shown in more detail in Fig. 6. The field lengths illustrated are merely suggestive. The first two fields (source port and destination port in the figure) have already been discussed in the preceding section on addressing. The uses of the third and fourth fields (window and acknowledgement in the figure) will be discussed later in the section on retransmission and duplicate detection.

如图 5 所示，TCP 将完整报文拆分为分段，分段详细格式见图 6。图中标注字段长度仅作示意。前两个字段（源端口、目的端口）已在寻址章节说明；第三、第四字段（窗口、确认号）将在重传与重复报文检测章节说明。

Fig. 5. Creation of segments and packets from messages.

图 5 报文拆分为分段、封装为分组流程

Fig. 6. Segment format (process header and text).

图 6 分段格式（进程首部+数据载荷）

We recall from Fig. 3 that an internetwork header contains both a sequence number and a byte count, as well as a flag field and a check sum. The uses of these fields are explained in the following section.

回顾图 3，网间首部包含序列号、字节计数、标志位字段、校验和，下一节说明各字段用途。

REASSEMBLY AND SEQUENCING

重组与排序

The reconstruction of a message at the receiving TCP clearly requires that each internetwork packet carry a sequence number which is unique to its particular destination port message stream. The sequence numbers must be monotonic increasing (or decreasing) since they are used to reorder and reassemble arriving packets into a message. If the space of sequence numbers were infinite, we could simply assign the next one to each new packet. Clearly, this space cannot be infinite, and we will consider what problems a finite sequence number space will cause when we discuss retransmission and duplicate detection in the next section. We propose the following scheme for performing the sequencing of packets and hence the reconstruction of messages by the destination TCP.

接收端 TCP 重组报文时，每份网间分组必须携带序列号，序列号仅在对应目的端口报文流内唯一。序列号单调递增（或递减），用于对乱序抵达的分组重排序、重组完整报文。若序列号取值空间无限，仅需为新分组依次分配递增序列号；实际序列号空间有限，有限空间带来的问题将在下一节重传与重复报文检测中说明。本文给出一套分组排序、接收端报文重组实现方案。

A pair of ports will exchange one or more messages over a period of time. We could view the sequence of messages produced by one port as if it were embedded in an infinitely long stream of bytes. Each byte of the message has a unique sequence number which we take to be its byte location relative to the beginning of the stream. When a segment is extracted from the message by the source TCP and formatted for internetwork transmission, the relative location of the first byte of segment text is used as the sequence number for the packet. The byte count field in the internetwork header accounts for all the text in the segment (but does not include the check-sum bytes or the bytes in either internetwork or process header). We emphasise that the sequence number associated with a given packet is unique only to the pair of ports that are communicating (see Fig. 7). Arriving packets are examined to determine for which port they are intended. The sequence numbers on each arriving packet are then used to determine the relative location of the packet text in the messages under reconstruction. We note that this allows the exact position of the data in the reconstructed message to be determined even when pieces are still missing.

一对端口会持续交互多份报文。可将单端口输出的所有报文视作一条无限长字节流，报文内每个字节分配唯一序列号，序列号等于该字节相对字节流起始位置的偏移量。源 TCP 从报文拆分出分段、封装网间分组时，将分段首个数据字节的偏移量设为分组序列号。网间首部字节计数字段统计分段全部数据字节（不含校验和、网间首部、进程首部字节）。重点说明：分组序列号仅在一对通信端口内唯一（见图 7）。接收端识别分组归属端口后，依据序列号判定数据在待重组报文中的偏移位置；即便部分分片尚未抵达，也可精准定位已接收数据的摆放位置。

Fig. 7. Assignment of sequence numbers.

图 7 序列号分配规则

Every segment produced by a source TCP is packaged in a single internetwork packet and a check sum is computed over the text and process header associated with the segment.

源 TCP 生成的每一段分段单独封装为一份网间分组，校验和基于分段数据与进程首部计算。

The splitting of messages into segments by the TCP and the potential splitting of segments into smaller pieces by GATEWAY creates the necessity for indicating to the destination TCP when the end of a segment (ES) has arrived and when the end of a message (EM) has arrived. The flag field of the internetwork header is used for this purpose (see Fig. 8).

TCP 将报文拆分为分段、网关将分段分片，因此需要标识字段告知接收端 TCP：分段末尾（ES）、完整报文末尾（EM）是否抵达，该标识承载于网间首部标志位字段（见图 8）。

Fig. 8. Internetwork header flag field.

图 8 网间首部标志位字段

The ES flag is set by the source TCP each time it prepares a segment for transmission. If it should happen that the message is completely contained in the segment, then the EM flag would also be set. The EM flag is also set on the last segment of a message, if the message could not be contained in one segment. These two flags are used by the destination TCP, respectively, to discover the presence of a check sum for a given segment and to discover that a complete message has arrived.

源 TCP 封装每一段待发送分段时，置位 ES 标志。若单段分段承载完整报文，同步置位 EM；若报文拆分为多段分段，最后一段分段置位 EM。接收端 TCP 通过 ES 识别分段校验和完整、通过 EM 识别完整报文收齐。

The ES and EM flags in the internetwork header are known to the GATEWAY and are of special importance when packets must be split apart from propagation through the next local network. We illustrate their use with an example in Fig. 9.

网关可识别网间首部 ES、EM 标志，分组需要分片转发至下游网络时，这两个标志具备特殊作用，图 9 通过示例演示使用逻辑。

Fig. 9. Message splitting and packet splitting.

图 9 报文拆分与分组分片

The original message A in Fig. 9 is shown split into two segments A 1 A_{1} A1 and A 2 A_{2} A2 and formatted by the TCP into a pair of internetwork packets. Packets A 1 A_{1} A1 and A 2 A_{2} A2 have their ES bits set, and A 2 A_{2} A2 has its EM bit set as well. When packet A 1 A_{1} A1 passes through the GATEWAY, it is split into two pieces: packet A 11 A_{11} A11 for which neither EM nor ES bits are set, and packet A 12 A_{12} A12 whose ES bit is set. Similarly, packet A 2 A_{2} A2 is split such that the first piece, packet A 21 A_{21} A21 ,has neither bit set, but packet A 22 A_{22} A22 has both bits set. The sequence number field (SEQ) and the byte count field (CT) of each packet is modified by the GATEWAY to properly identify the text bytes of each packet. The GATEWAY need only examine the internetwork header to do fragmentation.

图 9 原始报文 A 被 TCP 拆分为分段 A 1 A_{1} A1、 A 2 A_{2} A2，分别封装两份网间分组。分组 A 1 A_{1} A1、 A 2 A_{2} A2 置位 ES，分组 A 2 A_{2} A2 额外置位 EM。分组 A 1 A_{1} A1 途经网关时分片为两份：分片 A 11 A_{11} A11 不置位 ES、EM，分片 A 12 A_{12} A12 置位 ES。同理分组 A 2 A_{2} A2 分片为 A 21 A_{21} A21、 A 22 A_{22} A22， A 21 A_{21} A21 无标志置位， A 22 A_{22} A22 同时置位 ES、EM。网关修改每份分片的序列号（SEQ）、字节计数（CT），精准标识分片承载的数据字节范围；网关仅需读取网间首部即可完成分片操作。

The destination TCP, upon reassembling segment A 1 A_{1} A1 , will detect the ES flag and will verify the check sum it knows is contained in packet A 12 A_{12} A12 Upon receipt of packet A 22 A_{22} A22 , assuming all other packets have arrived, the destination TCP detects that it has reassembled a complete message and can now advise the destination process of its receipt.

接收端 TCP 收齐分段 A 1 A_{1} A1 所有分片后，识别 ES 标志，校验分片 A 12 A_{12} A12 携带的分段校验和。收齐所有分片并收到 A 22 A_{22} A22 后，TCP 判定完整报文重组完成，通知目的进程。

RETRANSMISSION AND DUPLICATE DETECTION

No transmission can be 100 percent reliable. We propose a timeout and positive acknowledgement mechanism which will allow TCP's to recover from packet losses from one HOST to another. A TCP transmits packets and waits for replies (acknowledgements) that are carried in the reverse packet stream. If no acknowledgement for a particular packet is received, the TCP will retransmit. It is our expectation that the HOST level retransmission mechanism, which is described in the following paragraphs, will not be called upon very often in practice. Evidence already exists that individual networks can be effectively constructed without this feature. However, the inclusion of a HOST retransmission capability makes it possible to recover from occasional network problems and allows a wide range of HOST protocol strategies to be incorporated. We envision it will occasionally be invoked to allow HOST accommodation to infrequent overdemands for limited buffer resources, and otherwise not used much.

重传与重复报文检测

传输无法做到完全可靠。本文提出超时+确认应答机制，TCP 可依托该机制处理主机间分组丢失故障。TCP 发送分组后，等待反向数据流携带的确认应答；指定时长未收到应答则重传对应分组。下文描述的主机层重传机制，工程运行中触发频次较低。现有实践证明，单网络不配套该机制也可稳定运行；但主机层重传能力可处理偶发网络故障，兼容多类主机协议实现。该机制主要用于应对缓存资源突发耗尽场景，其余场景极少启用。

Any retransmission policy requires some means by which the receiver can detect duplicate arrivals. Even if an infinite number of distinct packet sequence numbers were available, the receiver would still have the problem of knowing how long to remember previously received packets in order to detect duplicates. Matters are complicated by the fact that only a finite number of distinct sequence numbers are in fact available, and if they are reused, the receiver must be able to distinguish between new transmissions and retransmissions.

所有重传策略都配套重复报文检测逻辑。即便序列号取值空间无限，接收端仍需要存储历史接收分组记录，用于识别重复报文；而实际序列号空间有限，序列号循环复用后，接收端需要区分新传输分组与重传分组，进一步提升实现复杂度。

A window strategy, similar to that used by the French CYCLADES system (voie virtuelle transmission mode $8$ ) and the ARPANET very distant HOST connection $18$ ), is proposed here (see Fig. 10).

本文采用滑动窗口机制，该思路与法国 CYCLADES 系统虚通路传输模式 $8$ 、ARPANET 远距离主机连接方案 $18$ 相近（见图 10）。

Fig. 10. The window concept.

图 10 滑动窗口概念

Suppose that the sequence number field in the internetwork header permits sequence numbers to range from 0 to n − 1 n-1 n−1 . We assume that the sender will not transmit more than w bytes without receiving an acknowledgment. The w bytes serve as the window (see Fig.11).Clearly, w must be less than n . The rules for sender and receiver are as follows.

设网间首部序列号取值范围为 0 ∼ n − 1 0 \sim n-1 0∼n−1。发送端未收到确认应答时，累计发送字节不超过 w，w 为窗口长度（见图 11），且满足 w < n w < n w<n。发送端、接收端执行规则如下：

Fig. 11. Conceptual TCB format.

图 11 传输控制块（TCB）逻辑格式

Sender

Let L be the sequence number associated with the left window edge.

发送端规则

设 L 为窗口左边界序列号。

The sender transmits bytes from segments whose text lies between L and up to L + w − 1 L+w-1 L+w−1
发送端仅发送数据偏移落在 $L , L + w - 1$ $L,\\ L+w-1$ $L, L+w-1$ 区间内的分段字节。
On timeout (duration unspecified), the sender retransmits unacknowledged bytes.
超时后（超时时长不做统一规定），重传所有未收到确认的字节。
On receipt of acknowledgment consisting of the receiver's current left window edge, the sender's left window edge is advanced over the acknowledged bytes (advancing the right window edge implicity).
3）收到携带接收端当前窗口左边界的确认应答后，发送端窗口左边界右移，覆盖已确认字节，窗口右边界同步右移。

Receiver

接收端规则

Arriving packets whose sequence numbers coincide with the receiver's current left window edge are acknowledged by sending to the source the next sequence number expected. This effectively acknowledges bytes in between. The left window edge is advanced to the next sequence number expected.

若入站分组序列号等于接收端窗口左边界，回复确认应答，告知发送端下一个期望接收的序列号，区间内所有字节同步确认；接收端窗口左边界更新为该期望序列号。
Packets arriving with a sequence number to the left of the window edge (or, in fact, outside of the window) are discarded, and the current left window edge is returned as acknowledgement.

序列号小于窗口左边界、或完全超出窗口区间的分组直接丢弃，回复当前窗口左边界作为确认应答。
Packets whose sequence numbers lie within the receiver's window but do not coincide with the receiver's left window edge are optionally kept or discarded, but are now acknowledged. This is the case when packets arrive out of order.

序列号落在窗口区间、但不等于窗口左边界的乱序分组，接收端可选择缓存或丢弃，同时回复确认应答。

We make some observations on this strategy. First, all computations with sequence numbers and window edges must be made modulo n (e.g., byte 0 follows byte n − 1 n-1 n−1 ). Second, w must be less than n / 2 n / 2 n/2 otherwise a retransmission may appear to the receiver to be a new transmission in the case that the receiver can either save or discard arriving packets whose sequence numbers do not coincide with the receiver's left window. Thus, in the simplest implementation, the receiver need not buffer more than one packet per message stream if space is critical. Fourth, multiple packets can be acknowledged simultaneously. Fifth, the receiver is able to deliver messages to processes in their proper order as a natural result of the reassembly mechanism. Sixth, when duplicates are detected, the acknowledgment method used naturally works to resynchronize sender and receiver. Furthermore, if the receiver accepts packets whose sequence numbers lie within the current window but which are not coincident with the left window edge, an acknowledgment consisting of the current left window edge would act as a stimulus to cause retransmission of the unacknowledged bytes. Finally, we mention an overlap problem which results from retransmission, packet splitting, and alternate routing of packets through different GATEWAYS.

该窗口机制配套约束说明：

1）序列号、窗口边界所有计算均对 n 取模（字节 n − 1 n-1 n−1 的下一字节为字节 0）。

2）窗口长度 w 必须小于 n / 2 n/2 n/2；若不满足，接收端缓存/丢弃乱序分组时，重传分组会被误判为新数据。

3）缓存资源紧张时，最简实现方案下，单条报文流仅需缓存一份分组。

4）单条确认应答可一次性确认多份分组。

5）依托重组机制，接收端可按原始顺序向进程交付报文。

6）识别重复报文时，确认应答机制可自动完成收发两端同步。若接收端缓存窗口内乱序分组，回复当前窗口左边界应答会触发发送端重传未确认数据。

7）重传、分组分片、多网关路由会引发数据区间重叠问题，下文简要说明。

A 600-byte packet might pass through one GATEWAY and be broken into two 300-byte packets. On retransmission, the same packet might be broken into three 200-byte packets going through a different HOST. Since each byte has a sequence number, there is no confusion at the receiving TCP. We leave for later the issue of initially synchronizing the sender and receiver left window edges and the window size.

示例：一份 600 字节分组途经网关分片为两份 300 字节分片；重传时该分组切换路由，经另一网关拆分为三份 200 字节分片。每个字节分配独立序列号，接收端 TCP 可精准区分，不会混淆。收发两端窗口左边界、窗口长度的初始同步逻辑，本文暂不展开。

FLOW CONTROL

流量控制

Every segment that arrives at the destination TCP is ultimately acknowledged by returning the sequence number of the next segment which must be passed to the process (it may not yet have arrived).

接收端 TCP 收到任意分段后，最终都会回复确认应答，告知发送端下一段待交付进程的数据起始序列号（该分段可能尚未抵达）。

Earlier we described the use of a sequence number space and window to aid in duplicate detection. Acknowledgments are carried in the process header (see Fig. 6) and along with them there is provision for a "suggested window" which the receiver can use to control the flow of data from the sender. This is intended to be the main component of the process flow control mechanism. The receiver is free to vary the window size according to any algorithm it desires so long as the window size never exceeds half the sequence number space.

前文介绍序列号空间与滑动窗口用于重复报文检测；确认应答承载于进程首部（见图 6），首部配套 "建议窗口" 字段，接收端通过该字段管控发送端数据发送速率，构成进程流量控制机制的主要组成部分。接收端可自定义算法动态调整窗口长度，约束条件为窗口长度不超过序列号空间的一半。

This flow control mechanism is exceedingly powerful and flexible and does not suffer from synchronization troubles that may be encountered by incremental buffer allocation schemes $9$ , $10$ . However, it relies heavily on an effective retransmission strategy. The receiver can reduce the window even while packets are en route from the sender whose window is presently larger. The net effect of this reduction will be that the receiver may discard incoming packets (they may be outside the window) and reiterate the current window size along with a current window edge as acknowledgment. By the same token, the sender can, upon occasion, choose to send more than a window's worth of data on the possibility that the receiver will expand the window to accept it (of course, the sender must not send more than half the sequence number space at any time). Normally, we would expect the sender to abide by the window limitation. Expansion of the window by the receiver merely allows more data to be accepted. For the receiving HOST with a small amount of buffer space, a strategy of discarding all packets whose sequence numbers do not coincide with the current left edge of the window is probably necessary, but it will incur the expense of extra delay and overhead for retransmission.

该流量控制机制适配场景广、调整灵活，不会出现增量缓存分配方案 $9$ $10$ 存在的同步异常问题，但机制运行依赖稳定的重传逻辑。发送端已有大量分组在途时，接收端可下调窗口长度；调整后入站分组序列号可能超出窗口区间，接收端直接丢弃，应答中同步告知更新后的窗口长度与窗口左边界。发送端可预判接收端会扩容窗口，临时发送略超窗口上限的数据（上限仍不超过序列号空间一半）；常规场景下发送端遵循窗口约束。接收端上调窗口长度后，可接收更多数据。缓存资源稀缺的接收主机，可选择丢弃所有非窗口左边界的分组；该方案会增加重传带来的时延与算力开销。

TCP INPUT/OUTPUT HANDLING

TCP 输入输出处理

The TCP has a component which handles input/ output (I/O) to and from the network. When a packet has arrived, it validates the addresses and places the packet on a queue. A pool of buffers can be set up to handle arrivals, and if all available buffers are used up, succeeding arrivals can be discarded since unacknowledged packets will be retransmitted.

TCP 内置网络收发处理模块。分组抵达后，模块校验地址合法性，将分组送入接收队列。系统可配置一组共享缓存用于存储入站分组；缓存耗尽时，后续入站分组直接丢弃，未确认分组会由发送端重传，不会造成数据永久丢失。

On output, a smaller amount of buffering is needed, since process buffers can hold the data to be transmitted. Perhaps double buffering will be adequate. We make no attempt to specify how the buffering should be done, except to require that it be able to service the network with as little overhead as possible. Packet sized buffers, one or more ring buffers, or any other combination are possible candidates.

发送侧缓存需求更低，待发送数据存储于进程缓存，双缓存架构通常可满足需求。本文不规定缓存实现架构，仅要求缓存处理网络数据的算力开销尽可能低；可采用分组长度缓存、环形缓存或多类缓存组合方案。

When a packet arrives at the destination TCP, it is placed on a queue which the TCP services frequently. For example, the TCP could be interrupted when a queue placement occurs. The TCP then attempts to place the packet text into the proper place in the appropriate process receive buffer. If the packet terminates a segment, then it can be checksummed and acknowledged. Placement may fail for several reasons.

分组抵达目的 TCP 后进入处理队列，TCP 持续轮询队列；可配置分组入队时触发中断，提升处理响应速度。TCP 将分组数据写入对应进程接收缓存的指定偏移位置；若该分组是分段最后一片，执行校验和校验并回复确认应答。数据写入缓存失败存在几类诱因：

The destination process may not be prepared to receive from the stated source, or the destination port ID may not exist.
目的进程未监听该源端，或目的端口标识不存在。
There may be insufficient buffer space for the text.
缓存剩余空间不足以存储分组数据。
The beginning sequence number of the text may not coincide with the next sequence number to be delivered to the process (e.g., the packet has arrived out of order).
分组数据起始序列号不等于进程待接收下一字节序列号，即分组乱序抵达。

In the first case, the TCP should simply discard the packet (thus far, no provision has been made for error acknowledgments). In the second and third cases, the packet sequence number can be inspected to determine whether the packet text lies within the legitimate window for reception. If it does, the TCP may optionally keep the packet queued for later processing. If not, the TCP can discard the packet. In either case the TCP can optionally acknowledge with the current left window edge.

场景 1：TCP 直接丢弃分组，本文暂不配套错误应答机制。

场景 2、场景 3：读取分组序列号，判断数据是否落在接收窗口区间。落在区间内可缓存分组延后处理；超出区间直接丢弃。两类场景均可选择回复当前窗口左边界作为确认应答。

It may happen that the process receive buffer is not present in the active memory of the HOST, but is stored on secondary storage. If this is the case, the TCP can prompt the scheduler to bring in the appropriate buffer and the packet can be queued for later processing.

进程接收缓存可能存放于二级存储，未载入主机内存。TCP 可调度系统加载对应缓存，分组存入队列等待后续处理。

If there are no more input buffers available to the TCP for temporary queuing of incoming packets, and if the TCP cannot quickly use the arriving data (e.g., a TCP to TCP message), then the packet is discarded. Assuming a sensibly functioning system, no other processes than the one for which the packet was intended should be affected by this discarding. If the delayed processing queue grows excessively long, any packets in it can be safely discarded since none of them have yet been acknowledged. Congestion at the TCP level is flexibly handled owing to the robust retransmission and duplicate detection strategy.

TCP 无空闲缓存临时存储入站分组，且无法即时处理数据时，直接丢弃分组。系统正常运行前提下，丢弃操作仅影响分组对应目的进程，其余进程不受干扰。延时处理队列长度超限后，队列内所有分组均可安全丢弃，所有分组均未收到确认应答。依托完善的重传、重复报文检测机制，TCP 层拥塞可灵活处理。

TCP/PROCESS COMMUNICATION

TCP 与进程交互

In order to send a message, a process sets up its text in a buffer region in its own address space, inserts the requisite control information in a transmit control block (TCB) and passes control to the TCP. The exact form of a TCB is not specified here, but it might take the form of a passed pointer, a pseudointerrupt, or various other forms. To receive a message in its address space, a process sets up a receive buffer, inserts the requisite control information in a receive control block (RCB) and again passes control to the TCP.

进程发送报文时，将数据存入自身地址空间缓存，在传输控制块（TCB）写入配套控制信息，将处理权限移交 TCP。本文不规定 TCB 具体实现格式，可采用指针传递、软中断等各类实现方式。进程接收报文时，预先分配接收缓存，在接收控制块（RCB）写入控制信息，移交处理权限至 TCP。

In some simple systems, the buffer space may in fact be provided by the TCP. For simplicity we assume that a ring buffer is used by each process, but other structures (e.g., buffer chaining) are not ruled out.

简易系统可由 TCP 统一分配缓存。本文默认每个进程配套环形缓存，同时兼容链式缓存等其他架构。

A possible format for the TCB is shown in Fig. 11. The TCB contains information necessary to allow the TCP to extract and send the process data. Some of the information might be implicitly known, but we are not concerned with that level of detail. The various fields in the TCB are described as follows.

图 11 给出 TCB 逻辑格式。TCB 存储 TCP 读取、发送进程数据所需全部信息；部分信息可由系统隐式获取，本文不细化底层实现。TCB 各字段说明如下：

Source Address: This is the full net/HOST/ TCP/port address of the transmitter.

源地址：发送端完整地址，包含网络、主机、TCP、端口标识。
Destination Address: This is the full net/HOST/ TCP/port of the receiver.

目的地址：接收端完整地址，包含网络、主机、TCP、端口标识。
Next Packet Sequence Number: This is the sequence number to be used for the next packet the TCP will transmit from this port.

下一分组序列号：该端口待发送下一份分组使用的序列号。
Current Buffer Size: This is the present size of the process transmit buffer.

当前缓存长度：进程发送缓存当前占用容量。
Next Write Position: This is the address of the next position in the buffer at which the process can place new data for transmission.

下一次写入偏移：缓存内进程写入新待发数据的位置。
Next Read Position: This is the address at which the TCP should begin reading to build the next segment for output.

下一次读取偏移：TCP 读取数据封装下一段分段的起始位置。
End Read Position: This is the address at which the TCP should halt transmission. Initially 6) and 7) bound the message which the process wishes to transmit.

读取终止偏移：TCP 停止读取数据的位置；初始状态下字段 6、字段 7 划定待发送报文的数据区间。
Number of Retransmissions/Maximum Retransmissions: These fields enable the TCP to keep track of the number of times it has retransmitted the data and could be omitted if the TCP is not to give up.

重传计数/最大重传次数：TCP 记录数据重传次数；若不限制重传上限，该字段可省略。
Timeout/Flags: The timeout field specifies the delay after which unacknowledged data should be retransmitted. The flag field is used for semaphores and other TCP/process synchronization status reporting, etc.

超时时间/标志位：超时字段设定未确认数据的重传等待时长；标志位用于信号量、TCP 与进程同步状态上报。
Current Acknowledgment/Window: The current acknowledgment field identifies the first byte of data still unacknowledged by the destination TCP.

当前确认号/窗口长度：当前确认号标识接收端尚未确认的首个数据字节偏移。

The read and write positions move circularly around the transmit buffer, with the write position always to the left (module the buffer size) of the read position.

读写偏移在发送缓存内循环移动，对缓存长度取模后，写入偏移始终位于读取偏移左侧。

The next packet sequence number should be constrained to be less than or equal to the sum of the current acknowledgment and the window fields. In any event, the next sequence number should not exceed the sum of the current acknowledgment and half of the maximum possible sequence number (to avoid confusing the receiver's duplicate detection algorithm). A possible buffer layout is shown in Fig. 12.

下一分组序列号取值上限为当前确认号与窗口长度之和；同时不能超过当前确认号与最大序列号空间一半之和，避免接收端重复检测逻辑误判。图 12 展示缓存布局方案。

The RCB is substantially the same, except that the end read field is replaced by a partial segment check-sum register which permits the receiving TCP to compute and remember partial check sums in the event that a segment arrives in several packets. When the final packet of the segment arrives, the TCP can verify the check sum and if successful, acknowledge the segment.

RCB 字段与 TCB 基本一致，仅读取终止偏移替换为分段部分校验和寄存器。分段拆分为多份分片抵达时，接收端 TCP 分段计算、存储校验和；分段最后一份分片抵达后，完成完整校验和校验，校验通过后回复分段确认应答。

CONNECTIONS AND ASSOCIATIONS

连接与关联

Much of the thinking about process-to-process communication in paket switched networks has been influenced by the ubiquitous telephone system. The HOST-HOST protocol for the ARPANET deals explicitly with the opening and closing of simplex connections between processes $9$ , $10$ . Evidence has been presented that message-based "connectionfree" protocols can be constructed $12$ , and this leads us to carefully examine the notion of a connection.

分组交换网络进程间通信的早期设计思路大量借鉴电话通信系统。ARPANET 主机间协议专门定义进程单向连接的建立、释放流程 $9$ $10$ 。已有研究证明可构建基于报文的无连接协议 $12$ ，因此本文重新界定 "连接" 的定义。

The term connection has a wide variety of meanings. It can refer to a physical or logical path between two entities, it can refer to the flow over the path, it can inferentially refer to an action associated with the setting up of a path, or it can refer to an association between two or more entities, with or without regard to any path between them. In this paper, we do not explicitly reject the term connection, since it is in widespread use, and does connote a meaningful relation, but consider it exclusively in the sense of an association between two or more entities without regard to a path. To be more precise about our intent, we shall define the relationship between two or more ports that are in communication, or are prepared to communicate to be an association. Ports that are associated with each other are called associates.

"连接"存在多重释义：可指代两端实体间物理/逻辑通路、通路上的数据流、通路建立操作；也可指代实体间关联，与通路无关。本文不否定"连接"这一通用术语，仅重新界定其内涵：本文语境下，连接等价于实体间关联，不关注底层传输通路。精准定义：两条及以上可通信、待通信端口之间的绑定关系称为关联；建立关联的端口互称为对端端口。

It is clear that for any communication to take place between two processes, one must be able to address the other. The two important cases here are that the destination port may have a global and unchanging address or that it may be globally unique but dynamically reassigned. While in either case the sender may have to learn the destination address, given the destination name, only in the second instance is there a requirement for learning the address from the destination (or its representative) each time an association is desired.

两进程通信的前提是双方可互相寻址。端口地址分为两类：全局固定不变地址、全局唯一但动态复用地址。两类场景下发送端都需要通过目标名称查询地址；仅第二类动态地址场景，每次建立关联都需要向接收端或其代理查询地址。

Only after the source has learned how to address the destination can an association be said to have occurred. But this is not yet sufficient. If ordering of delivered messages is also desired, both TCP's must maintain sufficient information to allow proper sequencing. When this information is also present at both ends, then an association is said to have occurred.

发送端获取接收端地址后，仅完成关联建立的前置条件，不代表关联已完成。若要求报文按序交付，两端 TCP 均需存储排序所需信息；两端均具备该类信息时，才算正式建立关联。

Note that we have not said anything about a path, nor anything which implies that either end be aware of the condition of the other. Only when both partners are prepared to communicate with each other has an association occurred, and it is possible that neither partner may be able to verify that an association exists until some data flows between them.

本文定义的关联不绑定底层传输通路，也不要求两端互相感知对方在线状态。仅当两端均做好通信准备时关联成立；两端若无数据交互，无法确认关联是否存在。

CONNECTION-FREE PROTOCOLS WITH ASSOCIATIONS

In the ARPANET, the interface message processors (IMP's) do not have to open and close connections from source to destination. The reason for this is that connections are, in effect, always open, since the address of every source and destination is never reassigned. When the name and the place are static and unchanging, it is only necessary to label a packet with source and destination to transmit it through the network. In our parlance, every source and destination forms an association.

带关联机制的无连接协议

ARPANET 的接口报文处理器（IMP）无需为收发两端建立、释放连接。底层逻辑为：所有连接永久生效，收发端地址不会重复分配。地址与节点位置固定不变时，仅需在分组标记源、目的地址即可完成跨网传输。按照本文术语，任意一对收发端天然形成关联。

In the case of processes, however, we find that port addresses are continually being used and reused. Some ever present processes could be assigned fixed addresses which do not change (e.g., the logger process). If we supposed that every TCP had an infinite supply of port addresses so that no old address would ever be reused, then any dynamically created port would be assigned the next unused address. In such an environment, there could never be any confusion by source and destination TCP as to the intended recipient or implied source of each message, and all ports would be associates.

但进程场景下，端口地址会持续分配、回收复用。常驻进程可分配固定端口地址（例如日志进程）。假设每台 TCP 拥有无限端口地址资源，旧地址永不复用，新建端口依次分配未使用地址；该场景下收发 TCP 不会混淆报文归属，所有端口两两自动形成关联。

Unfortunately, TCP's (or more properly, operating systems) tend not to have an infinite supply of internal port addresses. These internal addresses are reassigned to new ports after the demise of each port. Walden $12$ suggests that a set of unique uniform external port addresses could be supplied by a central registry. A newly created port could apply to the central registry for an address which the central registry would guarantee to be unused by any HOST system in the network. Each TCP could maintain tables matching external names with internal ones, and use the external names for communication with other processes. This idea violates the premise that interprocess communication should not require centralized control. One would have to extend the central registry service to include all HOST'S in all the interconnected networks to apply this idea to our situation, and we therefore do not attempt to adopt it.

现实中 TCP（准确来说是操作系统）不具备无限内部端口地址，端口销毁后地址会回收分配给新端口。Walden $12$ 提出方案：搭建中央注册中心，统一分配全局唯一外部端口地址；新建端口向注册中心申请地址，注册中心保证该地址未被全网任意主机占用。每台 TCP 维护外部端口与内部端口映射表，跨进程通信使用外部端口标识。该方案引入集中管控，违背跨网进程通信无中心管控的设计前提；若适配本文多网络互联场景，注册中心需要覆盖所有互联网络内全部主机，因此本文不采用该方案。

Let us consider the situation from the standpoint of the TCP. In order to send or receive data for a given port, the TCP needs to set up a TCB and RCB and initialize the window size and left window edge for both. On the receive side, this task might even be delayed until the first packet destined for a given port arrives. By convention, the first packet should be marked so that the receiver will synchronize his left window edge with the sequence number of the arriving packet (see SYN bit in Fig. 8).

从 TCP 视角分析端口通信流程：TCP 为端口收发数据前，需要创建传输控制块 TCB、接收控制块 RCB，并初始化两端窗口长度与窗口左边界。接收端可延迟创建控制块，直至该端口收到第一份分组。规范约定：首份分组携带同步标记，接收端依据该分组序列号同步自身窗口左边界（见图 8 SYN 标志位）。

On the send side, the first request to transmit could cause a TCB to be set up with some initial sequence number (say, zero) and an assumed window size. The receiving TCP can reject the packet if it wishes and notify the sending TCP of the correct window size via the acknowledgment mechanism, but only if either

发送端首次发起传输请求时，创建 TCB，配置初始序列号（例如 0）与默认窗口长度。接收端 TCP 可拒绝该分组，通过确认应答机制告知发送端适配窗口长度，该逻辑生效需满足以下任一条件：

we insist that the first packet be a complete segment;

首份分组承载完整分段；
an acknowledgment can be sent for the first packet (even if not a segment, as long as the acknowledgment specifies the next sequence number such that the source also understands that no bytes have been accepted).

可针对首份分组回复应答（无需承载完整分段，应答中写明期望接收的首个序列号，代表未接收任何数据）。

It is apparent, therefore, that the synchronizing of window size and left window edge can be accomplished without what would ordinarily be called a connection setup.

由此可见，窗口长度、窗口左边界的同步流程，无需传统意义上的连接建立流程即可完成。

The first packet referencing a newly created RCB sent from one associate to another can be marked with a bit which requests that the receiver synchronize his left window edge with the sequence number of the arriving packet (see SYN bit in Fig. 8). The TCP can examine the source and destination port addresses in the packet and in the RCB to decide whether to accept or ignore the request.

对端端口发送至新建 RCB 的首份分组可置位同步标志，请求接收端基于分组序列号同步窗口左边界（见图 8 SYN 标志）。TCP 比对分组与 RCB 内的源、目的端口地址，判定是否接受本次同步请求。

Fig. 12. Transmit buffer layout.

图 12 发送缓存布局

Provision should be made for a destination process to specify that it is willing to LISTEN to a specific port or "any" port. This last idea permits processes such as the logger process to accept data arriving from unspecified sources. This is purely a HOST matter, however.

目的进程可配置监听指定端口或全部端口。全部端口监听模式可供日志进程使用，接收任意源端发来的数据；该配置逻辑仅作用于本机主机，不影响跨网协议规则。

The initial packet may contain data which can be stored or discarded by the destination, depending on the availability of destination buffer space at the time. In the other direction, acknowledgment is returned for receipt of data which also specifies the receiver's window size.

携带同步标记的首份分组可附带数据；接收端依据当前缓存剩余容量选择存储或丢弃数据，同时回复确认应答，告知发送端自身窗口长度。

If the receiving TCP should want to reject the synchronization request, it merely transmits an acknowledgment carrying a release (REL) bit (see Fig. 8) indicating that the destination port address is unknown or inaccessible. The sending HOST waits for the acknowledgment (after accepting or rejecting the synchronization request) before sending the next message or segment. This rejection is quite different from a negative data acknowledgment. We do not have explicit negative acknowledgments. If no acknowledgment is returned, the sending HOST may retransmit without introducing confusion if, for example, the left window edge is not changed on the retransmission.

接收端 TCP 拒绝同步请求时，回复置位释放标志（REL，见图 8）的应答，标识目的端口不存在或无法访问。发送主机收到同步请求的应答（无论接受或拒绝）后，才会发送下一段报文或分段。该拒绝应答与数据否定应答存在明显区分，本文不设计专用否定应答报文。若未收到任何应答，发送主机执行重传；重传时窗口左边界不发生变更，不会引发收发两端状态混淆。

Because messages may be broken up into many packets for transmission or during transmission, it will be necessary to ignore the REL flag except in the case that the EM flag is also set. This could be accomplished either by the TCP or by the GATEWAY which could reset the flag on all but the packet containing the set EM flag (see Fig. 9).

报文会被拆分为多份分组传输，因此仅当分组同时置位 EM 标志时，REL 释放标志才具备效力，其余分片的 REL 标志直接忽略。该处理逻辑可由 TCP 或网关执行：网关清除所有非 EM 分片的 REL 标志（见图 9）。

At the end of an association, the TCP sends a packet with ES, EM, and REL flags set. The packet sequence number scheme will alert the receiving TCP if there are still outstanding packets in transit which have not yet arrived, so a premature dissociation cannot occur.

关联终止时，TCP 发送同时置位 ES、EM、REL 标志的分组。序列号机制可让接收端识别是否存在在途未抵达分组，避免关联提前释放。

To assure that both TCP's are aware that the association has ended, we insist that the receiving TCP respond to the REL by sending a REL acknowledgment of its own.

为保证两端 TCP 同步知晓关联终止，接收端收到 REL 分组后，必须回复携带 REL 标志的确认应答。

Suppose now that a process sends a single message to an associate including a REL along with the data. Assuming an RCB has been prepared for the receiving TCP to accept the data, the TCP will accumulate the incoming packets until the one marked ES, EM, REL arrives, at which point a REL acknowledgment is returned to the sender. The association is thereby terminated and the appropriate TCB and RCB are destroyed. If the first packet of a message contains a SYN request bit and the last packet contains ES, EM and REL bits, then data will flow "one message at a time." This mode is very similar to the scheme described by Walden $12$ , since each succeeding message can only be accepted at the receiver after a new LISTEN (like Walden's RECEIVE) command is issued by the receiving process to its serving TCP. Note that only if the acknowledgment is received by the sender can the association be terminated properly. It has been pointed out that the receiver may erroneously accept duplicate transmissions if the sender does not receive the acknowledgment. This may happen if the sender transmits a duplicate message with the SYN and REL bits set and the destination has already destroyed any record of the previous transmission. One way of preventing this problem is to destroy the record of the association at the destination only after some known and suitably chosen timeout. However, this implies that a new association with the same source and destination port identifiers could not be established until this timeout had expired. This problem can occur even with sequences of messages whose SYN and REL bits are separated into different internetwork packets. We recognize that this problem must be solved, but do not go into further detail here.

场景示例：进程向对端发送单份报文，报文末尾分片同时携带 REL 标志。接收端 TCP 已创建 RCB 接收数据时，持续缓存所有入站分组，直至收到同时置位 ES、EM、REL 的分片，随即回复 REL 应答，关联正式终止，对应 TCB、RCB 资源销毁。若报文首分组置位 SYN，末尾分片同时置位 ES、EM、REL，则通信模式为单次单报文交互。该模式与 Walden $12$ 提出的方案高度近似：接收进程需要向 TCP 重新发起监听指令（对应 Walden 方案的接收指令），才能接收下一份报文。仅当发送端收到 REL 应答，关联才能完整终止。若发送端未收到应答，接收端可能误判重复传输：发送端重传同时携带 SYN、REL 的报文时，接收端已销毁上一次关联记录，会新建关联处理重复报文。一类规避方案：接收端延迟销毁关联记录，等待一段预设超时时长；但该方案约束为：超时未结束前，相同源、目的端口无法新建关联。即便 SYN 与 REL 标志拆分至不同分组传输，该异常问题仍会出现。本文确认该问题需要配套解决方案，此处不展开详细实现逻辑。

Alternatively, both processes can send one message, causing the respective TCP's to allocate RCB/TCB pairs at both ends which rendezvous with the exchanged data and then disappear. If the overhead of creating and destroying RCB's and TCB's is small, such a protocol might be adequate for most low-bandwidth uses. This idea might also form the basis for a relatively secure transmission system. If the communicating processes agree to change their external port addresses in some way known only to each other (i.e., pseudorandom), then each message will appear to the outside world as if it is part of a different association message stream. Even if the data is intercepted by a third party, he will have no way of knowing that the data should in fact be considered part of a sequence of messages.

另一类交互模式：两端进程各发送一份报文，两端 TCP 分别创建一组 TCB/RCB，完成数据交互后直接释放资源。若创建、销毁控制块的算力开销较低，该模式可适配多数低带宽业务场景。该思路也可作为安全传输系统的底层设计依据：通信双方进程约定一套仅彼此知晓的外部端口变更规则（伪随机变更），对外观测时每份报文归属不同关联流；第三方截获数据后，无法识别多份报文属于同一条通信序列。

We have described the way in which processes develop associations with each other, thereby becoming associates for possible exchange of data. These associations need not involve the transmission of data prior to their formation and indeed two associates need not be able to determine that they are associates until they attempt to communicate.

上文完整描述进程建立关联的流程，关联建立后两端可交互数据。关联建立无需预先传输数据；两端端口若无数据交互行为，无法判定彼此已建立关联。

CONCLUSIONS

结论

We have discussed some fundamental issues related to the interconnection of packet switching networks. In particular, we have described a simple but very powerful and flexible protocol which provides for variation in individual network packet sizes, transmission failures, sequencing, flow control, and the creation and destruction of process-to-process associations. We have considered some of the implementation issues that arise and found that the proposed protocol is implementable by HOST'S of widely varying capacity.

本文围绕分组交换网络互联的各类基础问题展开研究，设计一套简洁、适配场景广、调整灵活的协议。该协议可适配各网络分组长度差异、处理传输故障、实现报文排序、流量控制，同时支撑进程间关联的建立与释放。文中分析实现相关问题，验证该协议可在不同算力规格的主机上部署运行。

The next important step is to produce a detailed specification of the protocol so that some initial experiments with it can be performed. These experiments are needed to determine some of the operational parameters (e.g., how often and how far out of order do packets actually arrive; what sort of delay is there between segment acknowledgments; what should retransmission timeouts be?) of the proposed protocol.

后续推进工作为编写完整协议规范文档，开展原型实验。实验用于标定协议运行参数，包括分组乱序出现频次与乱序偏移量、分段确认应答往返时延、重传超时阈值等。

ACKNOWLEDGMENT

The authors wish to thank a number of colleagues for helpful comments during early discussions of international network protocols, especially R. Metcalfe, R. Scantlebury, D. Walden, and H. Zimmerman; D. Davies and L. Pouzin who constructively commented on the fragmentation and accounting issues; and S. Crocker who commented on the creation and destruction of associations.

致谢

作者感谢多位同事在早期跨网协议研讨阶段提供的修改意见，包括 R. Metcalfe、R. Scantlebury、D. Walden、H. Zimmerman；D. Davies、L. Pouzin 针对分片、流量计费机制提出建设性观点；S. Crocker 针对关联建立与释放逻辑给出修改建议。

REFERENCES

参考文献

$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.

$1$ L. Roberts, B. Wessler. 面向资源共享的计算机网络开发 $C$ //1970 年春季联合计算机大会论文集，AFIPS 论文集第 36 卷. 新泽西州蒙特维尔：AFIPS 出版社，1970：543-549.

$2$ L. Pouzin, "Presentation and major design aspects of the CYCLADES computer network," in Proc. 3rd Data Communications Symp., 1973.

$2$ L. Pouzin. CYCLADES 计算机网络介绍与主要设计内容 $C$ //第三届数据通信研讨会论文集，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.

$3$ F. R. E. Dell. 一套同步数据网络方案特性 $C$ //第二届数据通信系统优化问题研讨会论文集，1971：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.

$4$ R. A. Scantlebury, P. T. Wilkinson. 支持计算机与终端远程访问算力服务的交换系统设计 $C$ //第二届数据通信系统优化问题研讨会论文集，1971：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.

$5$ D. L. A. Barber. 欧洲计算机网络项目 $M$ //S. Winkler. 计算机通信：影响与发展. 华盛顿特区，1972：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.

$6$ R. Despres. 拥塞平滑运行的分组交换网络 $M$ //S. Winkler. 计算机通信：影响与发展. 华盛顿特区，1972：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.

$7$ R. E. Kahn, W. R. Crowther. 资源共享计算机网络的流量控制 $J$ . IEEE 通信汇刊，1972, COM-20：539-546.

$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.

$8$ J. F. Chambon, M. Elie, J. Le Bihan, G. LeLann, H. Zimmerman. CYCLADES 网络传输站功能规范：STST 协议（法文） $R$ . 法国国家信息与自动化研究所技术报告 SCH502.3，1973 年 5 月.

$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.

$9$ S. Carr, S. Crocker, V. Cerf. ARPA 网络主机间通信协议 $C$ //1970 年春季联合计算机大会论文集，AFIPS 论文集第 36 卷. 新泽西州蒙特维尔：AFIPS 出版社，1970：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.

$10$ A. McKenzie. ARPA 网络主机间协议 $R$ //现有网络协议文档集，加州门洛帕克网络信息中心，文档编号 NIC 8246，1972 年 1 月.

$11$ L. Pouzin, "Address format in Mitranet," NIC 14497, INWG 20, Jan. 1973.

$11$ L. Pouzin. Mitranet 地址格式 $R$ . 国际网络工作组文档 INWG 20，文档编号 NIC 14497，1973 年 1 月.

$12$ D. Walden, "A system communication in a resource sharing computer network," Commun. Ass. Comput. Mach., vol. 15, pp. 221-230, Apr. 1972.

$12$ D. Walden. 资源共享计算机网络的系统通信机制 $J$ . ACM 通信汇刊，1972, 15：221-230.

$13$ B. Lampson, "A scheduling philosophy for multiprocessing system," Commun. Ass. Comput. Mach., vol. 11, pp. 347-360, May 1968.

$13$ B. Lampson. 多进程系统调度设计思路 $J$ . ACM 通信汇刊，1968, 11：347-360.

$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.

$14$ F. E. Heart, R. E. Kahn, S. Ornstein, W. Crowther, D. Walden. ARPA 计算机网络接口报文处理器 $C$ //1970 年春季联合计算机大会论文集，AFIPS 论文集第 36 卷. 新泽西州蒙特维尔：AFIPS 出版社，1970：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.

$15$ N. G. Anslow, J. Hanscoff. 国际数据交换网络实现 $M$ //S. Winkler. 计算机通信：影响与发展. 华盛顿特区，1972：181-184.

$16$ A. McKenzie, "HOST/HOST protocol design considerations," INWG Note 16, NIC 13879, Jan. 1973.

$16$ A. McKenzie. 主机间协议设计考量 $R$ . 国际网络工作组笔记 INWG 16，文档编号 NIC 13879，1973 年 1 月.

$17$ R. E. Kahn, "Resource-sharing computer communication networks", Proc. IEEE, vol. 60, pp. 1397-1407, Nov. 1972.

$17$ R. E. Kahn. 资源共享计算机通信网络 $J$ . IEEE 会刊，1972, 60：1397-1407.

$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.

$18$ BBN 公司. 主机与 IMP 互联规范 $R$ . 马萨诸塞州剑桥市 BBN 公司报告 1822（修订版），1973 年 4 月.

作者简介

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.

文顿·G·瑟夫，1943 年生于康涅狄格州纽黑文。本科就读于加利福尼亚州斯坦福大学数学专业，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.

1965--1967 年任职于洛杉矶 IBM；1967--1972 年在加州大学洛杉矶分校兼职、担任咨询顾问。时任斯坦福大学计算机科学与电子工程助理教授，同时为 Cabledata 联合公司提供咨询服务。当前研究方向为计算机网络技术与产业经济，相关研究由美国国防部高级研究计划局、美国国家科学基金会资助。担任国际信息处理联合会 TC6.1 工作组主席，该工作组专注分组网络互联问题研究。

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.

罗伯特·E·卡恩（IEEE 会员，1965 年入会），1938 年 12 月 23 日生于纽约布鲁克林。1960 年取得纽约城市学院电子工程学士学位；1962、1964 年分别于普林斯顿大学取得文学硕士、博士学位。

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, Mass., where he worked on communications and information theory.

1960--1962 年任职于新泽西州默里山贝尔实验室技术部，从事通信流量相关研究；1964--1966 年为福特博士后研究员，同时担任麻省理工学院电子工程助理教授，研究通信与信息论。

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.

1966--1972 年任职于马萨诸塞州剑桥市 BBN 公司高级科学家，研究计算机通信网络设计、分布式计算技术；1972 年后任职于弗吉尼亚州阿灵顿市美国国防部高级研究计划局。

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.

卡恩博士是美国工程荣誉协会、西格玛西科学研究协会、埃塔卡帕努电子工程协会、数理统计学会、美国数学协会会员。1972 年受邀担任美国计算机协会全国巡回讲座讲师。

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.

本文经 IEEE 通信学会数据通信副编审审核，准予免口头答辩刊发。稿件接收时间：1973 年 11 月 5 日。本文研究工作部分由美国国防部高级研究计划局资助，合同编号 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.

V·G·瑟夫任职于加利福尼亚州斯坦福大学计算机科学与电子工程系；R·E·卡恩任职于弗吉尼亚州阿灵顿市美国国防部高级研究计划局信息处理技术办公室。

附注

1. 所属层级

属于进程层封装，位于网间首部（IH / Internetwork Header）之后、业务载荷 TEXT 之前，是端到端进程通信专属头部，不属于网间统一字段，网关不会解析、修改 PH 内部内容。

3. 内部字段（对应 Fig.6 分段格式）

PH 包含4个固定16比特字段：

Source Port 源端口
Destination Port 目的端口
Window 窗口长度（流量控制）
ACK 确认序列号

4. 功能说明

多路复用/解复用
同一台主机内可同时运行多条进程通信流，依靠端口区分不同业务，接收端 TCP 通过 PH 内端口号，将分段分发至对应进程缓存。
端到端流量控制
携带窗口字段，接收端通过此字段告知发送端单次可发送的数据字节上限，控制发送速率。
确认应答承载
ACK 字段存放接收端期望接收的下一字节序列号，用于重传、乱序重排、重复报文检测。

5. PH（进程首部）与 IH（网间首部）、LH（本地首部）区分

标识	名称	处理主体	跨网规范
LH	Local Header 本地首部	子网/网关	单网络私有，可省略
IH	Internetwork Header 网间首部	网关、主机	全网统一标准字段
PH	Process Header 进程首部	仅收发两端主机TCP	端到端统一，网关不解析

6. 结合 Fig.9 场景说明

图中每一份分组都携带 PH：

源 TCP 拆分报文生成分段时，为每段分段封装 PH；
网关执行分片操作时，仅拆分 TEXT 载荷，不会修改、剥离 PH，PH 随分片完整透传至目的主机；
只有目的主机 TCP 会解析 PH，完成端口分流、流量控制校验。

A Brief History of the Internet

互联网简史

Tania Regina Tronco

塔妮娅·蕾吉娜·特龙科

CPqD Foundation, Rodovia Campinas Mogi-Mirim, km 118,5, Campinas -- São Paulo, CEP 13096-902, Brazil

巴西圣保罗州坎皮纳斯市，莫吉米林公路 118.5 公里处，CPqD 基金会，邮编 13096-902

tania@cpqd.com.br

Abstract

This chapter introduces a brief history review of Internet with focus on its original conception. It's important to remember such initial ideas because they were the basis of Internet architecture, they are still at the core of today's Internet and they can be helpful to rethink new design requirements. Hence, we start by the initial packet-based network protocols and their evolution to TCP/IP.

摘要

本章阐述互联网发展简史，内容侧重互联网最初设计构想。研究早期设计思路具备重要参考价值，该类构想构成互联网架构底层框架，至今仍支撑现有互联网运行，也可为全新网络设计需求提供参考。本文从早期分组网络协议入手，介绍其逐步演进至 TCP/IP 协议体系的完整过程。

1 Introduction

The Internet architecture concept was conceived at the end of the 60´s by ARPA (Advanced Research Projects Agency) during the Cold War, when the United States and Soviet Union were preparing for an eventual military confrontation. At that time, the U.S. military created an underground network of cables and equipments intended to survive a nuclear attack. This network was named ARPANET and its design consisted of a number of requirements such as:

1 引言

互联网架构雏形诞生于 20 世纪 60 年代末，由美国高级研究计划局（ARPA）在冷战背景下提出，彼时美苏双方存在军事对峙预期。美国军方搭建一套地下线缆设备网络，目标是在核打击场景下维持通信连通，该网络命名为 ARPANET（阿帕网），设计约束包含以下几条：

Data should be moved through leased lines to avoid problems with interruptions of the telephone system;
数据通过专线传输，规避公用电话系统中断带来的通信故障；
The information to be transmitted should be broken into segments of fixed length (packets) instead of being a continuous stream and
待传输数据拆分为固定长度单元（分组），摒弃连续数据流传输模式；
The network should be totally decentralized, without a single node in the control of the network, yielding reliability and robustness.
网络采用完全分布式架构，不存在单一管控节点，以此提升通信稳定度与抗损毁能力。

ARPANET was opened to universities after the end of arms race and a key requirement was added to the network project:

军备竞赛缓和后，阿帕网向高校开放接入，设计方案新增一条约束：

Communication between computers, called hosts, should be done through devices called Interface Message Processor (IMP), as shown in Fig. 1.

计算机（称为主机）之间的通信，需要经由接口报文处理器（IMP）完成，见图 1。

Fig. 1 A Typical Section of ARPANET (adapted from $1$ )

图 1 阿帕网典型拓扑片段（改编自文献 $1$ ）

The IMP function was to receive messages from a host and break them in packets. These packets should pass from IMP to IMP through the network until the destination IMP, which should pass them to the destination host.

IMP 负责接收主机报文，并将报文拆分为分组；分组在网络中逐台 IMP 转发，抵达目的 IMP 后，由 IMP 交付对应目的主机。

The network consisted of the interconnection of these IMPs through the leased lines supplied by telephonic companies. The first IMP was built by the company

整套网络由多台 IMP 通过电信运营商提供的专线互联构成。首台 IMP 由 BBN 公司（Bolt Beraneck and Newman，位于剑桥）在 1976 年研发完成。BBN 发布的 1822 号报告 $2$ 记载了主机与 IMP 互联规范。依据这份报告，主机发送普通报文时，需要填写三类参数构成目的地址：IMP 编号、主机编号、传输处理类型。三类参数可唯一标识一对收发主机之间的通信链路。传输处理类型用于标记链路属性，例如传输优先级、普通无优先级传输。报文交付目的主机时，需要维持源主机发送顺序；主机为每份普通报文分配 12 位标识，与目的地址组合生成报文编号，网络故障时可依托编号执行重传。

The first IMP was installed at University of California (UCLA), in Los Angeles, followed by SRI (Stanford Research Institute), University of California in Santa Barbara and University of Utah, 4 points in total. In 1969, the first ARPANET transmission was completed between UCLA and 斯坦福研究院（SRI）门洛帕克分部；同年首份 RFC 文档对外发布，RFC3 定义阿帕网 RFC 文档系列规范，该系列后续沿用至互联网体系。

2 Decade of the 70´s

2 20 世纪 70 年代

After installing some IMPs in a network, the objective of DARPA was to standardize the ARPANET network interface to allow more DARPA sites to join the network. To achieve this, the first standard networking protocol was developed in December 1970, namely Network Control Protocol (NCP) $4$ .

部署多台 IMP 后，美国国防高级研究计划局（DARPA）计划统一阿帕网网络接口标准，吸纳更多合作机构接入。1970 年 12 月，首款标准化网络协议网络控制协议（NCP）完成研发 $4$ 。

2.1 Network Control Protocol Operation

2.1 网络控制协议运行机制

The NCP operation consisted of store-and-forward messages from a sending host to a receiving host. After a host sent a message, it was prohibited from sending another message until receives a RFMN (Request-for-Next-Message). This sequence of requests made a connection. A connection linked two processes between a sending and a receiving host.

NCP 基于存储转发机制完成主机间报文传输。主机发送单份报文后，必须收到下一条报文请求（RFMN），才能继续发送后续报文；整套请求应答序列构成一条连接，连接绑定收发主机上一对通信进程。

The primary function of the NCP was to establish connections and release connections. In order to send control commands to establish and release connections between the hosts, one particular link, designated as the control link, was established between each pair of host.

NCP 的主要作用是完成连接建立与连接释放流程。每一对主机之间单独搭建一条控制链路，用于传输建链、断链控制指令。

Each host had its internal naming scheme, often incompatible with other hosts. Then, an intermediate name space, named socket, was created in NCP to prevent using this internal name scheme. Each host was responsible for mapping its inner process identifiers into sockets as shown in Fig. 2.

各主机内部进程命名规则互不兼容，因此 NCP 引入套接字（socket）作为统一中间命名空间。主机负责将本机内部进程标识映射为套接字标识，见图 2。

Fig. 2 A Typical Socket (adapted from $4$ )

图 2 典型套接字结构（改编自文献 $4$ ）

A socket specifies one connection endpoint and is determined by three numbers:

套接字代表一条连接端点，由三段数值组合唯一标识：

A user number (24 bits) composed by:
用户编号（24 比特），细分两段：
- 8-bit for home host number,
  8 比特本机主机编号；
- 16 bits to identify him at that host.
  16 比特本机用户标识；
A host number (8 bits)
主机编号（8 比特）；
An AEN (Another Eight-bit Number) composed by:
附加 8 位编号（AEN），细分两段：
- 1 bit that indicate a receive host (=0) or a send host (=1) :
  1 比特标识收发属性，0 代表接收主机，1 代表发送主机；
- 7 bits -- that provide a population of 128 sockets for each used number at each host.
  7 比特，单台主机内每一组用户编号可分配 128 个独立套接字。

When a user tried to log into a host, her user number was used to tag all the processes created in that host, producing a sort of virtual network.

用户登录主机后，本机新建所有进程都会绑定该用户编号，形成独立虚拟通信域。

By the end of 1971, there were fifteen sites attached into ARPANET using NCP $10$ as follows:

1971 年末，共有 15 家机构通过 NCP 接入阿帕网 $10$ ：

Bolt Baranek and Newman (BBN)
BBN 公司
Carnegie Mellon University
卡内基梅隆大学
Case Western Reserve University
凯斯西储大学
Harvard University
哈佛大学
Lincoln Laboratories
林肯实验室
Massachusetts Institute of Technology (MIT)
麻省理工学院（MIT）
NASA at AMES
美国国家航空航天局埃姆斯研究中心
RAND Corporation
兰德公司
Stanford Research Institute (SRI)
斯坦福研究院（SRI）
Stanford University
斯坦福大学
System Development Corporation
系统开发公司
University of California at Los Angeles (UCLA)
加州大学洛杉矶分校（UCLA）
University of California of Santa Barbara
加州大学圣巴巴拉分校
University of Illinois at Urbana
伊利诺伊大学厄巴纳分校
University of UTAH
犹他大学

At this time, BBN also developed an electronic mail program for ARPANET that quickly became the most popular application on the ARPANET $11$ . The e-mail program specified the destination address as username@hostname, where username was the same used to login in the host.

同期 BBN 为阿帕网开发邮件程序，该应用迅速成为阿帕网使用最广泛业务 $11$ ；邮件地址格式为用户名@主机名，用户名与主机登录账号保持一致。

At the end of the seventies, there were about 200 hosts connected to ARPANET $11$ . The NCP was becoming inefficient to connect different packet switching networks because individual networks could differ in their implementations like the heterogeneous addressing schemes, the different maximum size for the data, the different time delays for accepting, delivering, and transporting data and so on. In May 1974, Robert Kahn and Vinton Cerf published a paper entitled "A Protocol for Packet Network Intercommunication" on IEEE Transaction on Communication $3$ , proposing a new protocol to support the sharing resources between different packet switching networks. This protocol was named TCP.

70 年代末，阿帕网接入主机数量达到 200 台左右 $11$ 。NCP 无法适配异构分组交换网络互联场景，各网络寻址规则、最大传输长度、数据收发转发时延等参数均存在差异。1974 年 5 月，罗伯特·卡恩与文顿·瑟夫在《IEEE 通信汇刊》发布论文《分组网络互联协议》 $3$ ，提出一套适配异构网络资源共享的全新协议，命名为传输控制协议（TCP）。

According to $3$ , for both economic and technical considerations, it was convenient that all the differences between networks could be resolved by simple and reliable interface. This interconnection should also preserve intact the internal operation of each individual network. This interface was named Gateway. Fig. 3 illustrates two network interconnected by one gateways.

依据文献 $3$ 的设计思路，综合成本与技术层面考量，异构网络差异可依靠简洁稳定的接口完成适配；互联架构不能改动各网络内部运行逻辑，该接口定义为网关（Gateway）。图 3 展示两套网络通过一台网关互联的拓扑。

Fig. 3 Internetworking by Gateway (adapted from $3$ )

图 3 网关实现跨网互联（改编自文献 $3$ ）

The gateway was divided into two parts; each one associated with its own network and its function was understand the source and destination host addresses and insert this information in a standard format in every packet. For this operation, an internetwork header was added to the local header of the packet by the source host, as illustrated in Fig. 4.

网关拆分为两个独立模块，分别对接两套互联网络；网关需要识别源、目的主机地址，将地址封装为标准化字段写入每一份分组。源主机在分组本地首部外层追加网间首部完成该封装操作，见图 4。

Fig. 4 Internetwork Header (adapted from $3$ )

图 4 网间首部结构（改编自文献 $3$ ）

The internetwork header contained the standardized source and destination addresses. The next two fields in the header provided a sequence number and a byte count used to properly sequence the packets upon delivery to the destination and also enabling the gateways to detect fault conditions. The flag field was used to convey specific control information. The remainder of the packet contained the payload (text) and a trailing check sum used for end-to-end software verification. The gateway does not modify the information, only forwarded the header check sum along the path.

网间首部承载标准化源、目的地址；紧随其后的序列号、字节计数字段用于接收端分组重排序，同时网关可依托两个字段识别传输异常；标志位字段承载各类控制指令。分组剩余部分为业务载荷，末尾附带校验和用于端到端软件校验。网关不会修改分组内部数据，仅原样转发首部校验和。

2.2 TCP

2.2 传输控制协议（TCP）

The TCP protocol specified by Cerf and Kahn $3$ had the function of promoting the transmission and acceptance of messages of processes that wanted to communicate. To implement this function, TCP first broke the process messages into segments according to a maximum transmission size. This action was called fragmentation and was done in such a way that the destination process was able to reassemble the fragmented segments. On the transmission side, the TCP multiplexed together segments from different processes and produced packets for delivery to the packet switches. On the reception side, the TCP accepted the packets sequence from the packet switches, demultiplexed and reassembled the segments to the destination processes.

瑟夫与卡恩在文献 $3$ 中定义的 TCP，负责收发通信进程的报文。执行流程为：TCP 依据最大传输长度拆分进程报文为分段，该操作称为分片，分片规则保障接收进程可重组完整报文；发送侧 TCP 多路复用多进程分段，封装为分组下发至分组交换机；接收侧 TCP 从交换机接收分组流，解复用、重组分段后交付对应目的进程。

This system introduced the notion of ports and TCP address. A port was used to designate a message stream associated with a process. A TCP address was used to routing and delivery packets from diverse processes to the suitable destination host. The original TCP address format is shown in Fig. 5.

该协议体系新增端口与 TCP 地址概念：端口标识单条进程报文流；TCP 地址用于路由转发，将多进程分组投递至对应目的主机。原始 TCP 地址格式见图 5。

Fig. 5 TCP Address Format (adapted from $3$ )

图 5 TCP 地址格式（改编自文献 $3$ ）

The use of 8 bits for network identification (ID) allowed up to 256 distinct networks. At that time, this address field seemed enough for the future. The TCP identifier field permitted up to 65 536 distinct TCP be addressed. As each packet passed through the gateway, it observed the destination network ID to determine the packet route. If the destination network was connected to the gateway, the lower 16 bits of the TCP address were used to produce a local TCP address in the destination network. On the other hand, if the destination network was not connected to the gateway, the upper 8 bits was used to select the next gateway.

网络标识占用 8 比特，最多区分 256 套独立网络，在当时可覆盖中长期互联需求；TCP 标识字段支持单网络内寻址 65536 台 TCP 实例。分组途经网关时，网关读取目的网络 ID 判定路由走向：若目的网络与网关直连，TCP 地址低 16 比特转换为目的网络本地 TCP 地址；若未直连，则依据高 8 比特选择下一级网关。

In order to send a TCP message, a process settled the information to be transmitted in its own address space, inserted network/host/port addresses of the transmitter and receiver in a transmit control block (TCB), and transmitted it. At the receiving side, the TCP examined the source and destination port addresses and decided whether accepted or reject the request. If the request was rejected, it merely transmitted a release indicating that the destination port address was unknown or inaccessible. On the other hand, if the request was accepted, the sending and receiving ports were associated and the connection was established. After it, TCP started the transmission of the packets and waited for the acknowledgements carried in the reverse direction of the communication. If no acknowledgement for a particular packet was received, the TCP retransmitted the packet.

进程发送 TCP 报文时，将待传输数据存入本机地址空间，在传输控制块（TCB）写入收发两端网络、主机、端口完整地址后发起传输。接收侧 TCP 校验源、目的端口地址，判定是否接纳通信请求；拒绝请求时发送释放标识，告知对端目的端口不存在或无法访问；接纳请求后，收发端口建立关联，通信链路正式生成。链路建立完成后，TCP 持续发送分组，等待反向通道传回确认应答；指定时长未收到单份分组应答时，TCP 执行重传。

Aftertime, a window strategy to flow control of sent and received packets also was proposed by Cerf and Kahn $3$ , as shown in Fig. 6.

瑟夫与卡恩同步提出滑动窗口机制管控收发分组流量，见图 6。

Fig. 6 Window Strategy (adapted from $3$ )

图 6 滑动窗口机制（改编自文献 $3$ ）

Supposing that the sequence number field in the internetwork header permits packet sequence numbers to range from 0 to n − 1 n-1 n−1 , the sender could not transmit more than w bytes without receiving an acknowledgment. The w bytes were named a window (see Fig. 6). On timeout, the sender retransmits the unacknowledged bytes. Once acknowledgment was received, the sender's left window edge advanced over the acknowledged.

设网间首部序列号取值区间为 0 ∼ n − 1 0 \sim n-1 0∼n−1；发送端未收到确认应答时，累计发送字节总量不能超过 w，w 定义为窗口长度，见图 6。超时触发后，发送端重传全部未确认字节；收到确认应答后，发送端窗口左边界向右移动，覆盖已确认数据区间。

After the development of fundamental characteristics of TCP, the next challenge of DARPA was running TCP on multiple hardware platforms and making experiments to determine optimal parameters for the protocol. In 1977, the ARPA research program included important players in this development such as: BBN, DCEC, ISI, MIT, SRI, UCLA and some prototypes of TCP/IP were implemented.

完成 TCP 基础能力设计后，DARPA 下一阶段目标为实现 TCP 跨多硬件平台部署，通过实验标定协议最优运行参数。1977 年，BBN、DCEC、ISI、麻省理工学院、斯坦福研究院、加州大学洛杉矶分校等机构参与研发，完成多版 TCP/IP 原型实现。

2.3 Ethernet

2.3 以太网

At the same time, the development of the first concepts of new computer networking technology for local area networks (LANs) named Ethernet. This technology has been widely used under TCP/IP and has grown importance to encompass new technologies.

同期面向局域网（LAN）的全新网络技术概念以太网完成初步设计，该技术长期配套 TCP/IP 体系使用，后续持续迭代衍生多类衍生技术。

The Ethernet idea began on May 22, 1973, when Bob Metcalfe (then at the Xerox Palo Alto Research Center, PARC, in California) wrote a memo describing the Ethernet network system he had invented for interconnecting advanced computer workstations, making it possible to send data to one another and to high-speed laser printers (see Fig. 7). The seminal article: "Ethernet: Distributed Packet Switching for Local Computer Networks" was published by Robert M. Metcalfe and David R. Boggs in $6$ .

以太网构想诞生于 1973 年 5 月 22 日，彼时鲍勃·梅特卡夫任职于加州施乐帕洛阿尔托研究中心（PARC），他撰写备忘录记录自研以太网系统，该系统用于互联高端工作站，支持设备互传数据、对接高速激光打印机，见图 7。罗伯特·梅特卡夫与戴维·博格斯后续发布奠基论文《以太网：面向本地计算机网络的分布式分组交换》 $6$ 。

Fig. 7 Robert Metcalfe picture and his famous Ethernet first drawing (adapted from $4$ )

图 7 梅特卡夫绘制的首版以太网拓扑图（改编自文献 $4$ ）

Robert Metcalfe got the idea for the Ethernet protocol when he read a 1970 computer conference paper by Norman Abramson of the University of Hawaii about the packet radio system called ALOHANET linking the Hawaiian Islands. At the end of 1972, the ALOHANET was connected to ARPANET by satellite given a pass to the development of the Internet.

梅特卡夫的以太网设计灵感，来源于夏威夷大学诺曼·艾布拉姆森 1970 年会议论文，论文介绍覆盖夏威夷群岛的无线分组网络 ALOHA 网。1972 年末，ALOHA 网通过卫星链路接入阿帕网，为互联网后续发展提供技术参考。

Each node in ALOHANET sent out its messages in streams of separate packets of information. If it did not get an acknowledgment back for some packets because two radios were broadcasting at the same time, then the missing packets were considered "lost in the ether". The word ether was used to denote the propagation medium that could be used by any type of machine, in analogy to the material believed by physicists to 填充真空、传递电磁波的以太介质。

ALOHA 网各节点将报文拆分为独立分组发送；两台无线设备同时发送数据会产生冲突，对应分组收不到应答，判定为"丢失在以太介质中"。术语"以太"指代可供任意设备共享的传输介质，借鉴物理学中假想的真空传播介质概念。

When a packet was lost in the ether, the node would re-broadcast them after waiting a random interval of time. Because of this randomness, problems with collisions were quickly resolved except under very high traffic loads. On average, the network rarely had to retry more than once or twice to get all the packets to the destination, which was more efficient than trying to implement a complex coordination system to prevent collisions in the first place. The original 10 Mbps Ethernet standard was first published in the next decade by the DEC-Intel-Xerox (DIX) vendor consortium.

分组冲突丢失后，节点等待随机时长再重发；随机等待机制可快速消解冲突，仅超高负载场景冲突频发。多数场景下分组重传 1 至 2 次即可送达，相比搭建复杂预协调防冲突机制，该方案开销更低。初代 10 兆比特每秒以太网标准，由数字设备、英特尔、施乐三家厂商组成的 DIX 联盟在 80 年代正式发布。

3 Decade of the 80´s

3 20 世纪 80 年代

After testing three increasingly better versions: TCPv1, TCPv2, a split into TCPv3 and IPv3, finally in 1981, TCP (Transmission Control protocol) v4 and IP (Internet Protocol) v4, posted in RFC 791 $7$ and RFC 793 $9$ , respectively, became stable. This version is still in use on the Internet today.

研发团队先后迭代 TCPv1、TCPv2，再拆分出 TCPv3 与 IPv3 两套独立协议；1981 年，TCPv4、IPv4 完成稳定定稿，分别写入 RFC791 $7$ 、RFC793 $9$ ，该版本至今仍在互联网大范围部署。

In 1982, an Internet Gateway, to route internet packets based on TCPv4/IPv4, developed by BBN, was standardized in RFC 823 $5$ . TCPv4/IPv4 became a standard for DARPA and, in January, 1983, the ARPANET protocol switched from NCP to TCP/IP. This date is considered the date of the birth of the Internet $11$ . In 1985, Dan Lynch and the IAB (Internet Architecture Board) realized a workshop for the computer industry to become TCP/IP a commercial standard and promote the development of networking products.

1982 年，BBN 研发适配 TCPv4/IPv4 的互联网网关，相关规范写入 RFC823 $5$ 。TCP/IP 正式成为 DARPA 官方标准；1983 年 1 月，阿帕网全网由 NCP 切换至 TCP/IP 协议，该时间点被认定为互联网诞生节点 $11$ 。1985 年，丹·林奇联合互联网架构委员会（IAB）举办行业研讨会，推动 TCP/IP 成为商用标准，带动网络硬件软件产品研发。

3.1 Internet Protocol

3.1 互联网协议（IP）

The IPv4 implements two basic functions: fragmentation and addressing. Fragmentation is used to break the packets in small pieces to transmit through "small packet" networks.

IPv4 包含两类基础能力：分片、寻址。分片用于拆分大分组，适配仅支持短分组传输的网络。

The addressing is used to forward Internet packets toward their destinations. The Internet protocol treats each Internet packet as an independent entity. There are no connections or logical circuit establishment. So, the Internet protocol does not provide a reliable communication facility, only hop-by-hop forwarding of packets. There is no error control for the information, only a header checksum and errors detected in the header are reported via Internet Control Message Protocol (ICMP) $8$ .

寻址机制用于将互联网分组转发至目的地址。IP 协议将每份分组视作独立数据单元，不建立连接、不分配逻辑通路，因此无法提供可靠传输保障，仅完成逐跳转发。IP 不对载荷数据做差错校验，仅校验首部；首部校验异常通过互联网控制报文协议（ICMP）上报 $8$ 。

The Internet transmission occurs when an application program via transport protocols sends a request on its local router (gateway) to send data as a packet thought the Internet (see Fig. 8). The Internet router prepares the packet header and attaches it to the data. The router determines a local network address and sends the packet to the local network interface. The local network interface creates a local network header, attaches it to the packet and sends it to the local network. The packet is forward hop-by-hop through the network until the local network where the destination host is located. At each hop, the router examines the header and determines the next hop based on the destination address. At the destination router, the packet is sent to the destination host, via transport protocol socket to the application.

应用程序通过传输协议向本地路由器（网关）发起互联网数据传输请求时，正式启动 IP 传输流程，见图 8。路由器生成 IP 首部封装数据，解析本地二层地址后下发至网卡；网卡追加本地链路首部，送入局域网。分组在全网逐跳转发，直至抵达目的主机所在局域网；每一跳路由器读取首部目的地址，计算下一跳转发节点。抵达目的侧路由器后，分组交付目的主机，经由传输协议套接字上传至对应应用程序。

Fig. 8 Internet Forwarding Packets (adapted from $3$ )

图 8 互联网分组转发流程（改编自文献 $3$ ）

3.2 Ethernet Protocol

3.2 以太网协议

The first Ethernet standard was entitled "The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications" and was published in 1980 by the DIX vendor consortium. It contained the specifications of both the operation of Ethernet and the single media system based on thick coaxial cable.

首版以太网标准由 DIX 厂商联盟 1980 年发布，全称《以太网局域网：数据链路层与物理层规范》，文档记载以太网运行规则，以及基于粗同轴电缆的单介质组网方案。

Ethernet is by definition a broadcast protocol where any signal can be received by all hosts. The packets from the network layer are transmitted over an Ethernet by encapsulating them in a frame format as shown in Fig. 9.

以太网属于广播型协议，链路上所有主机均可接收广播信号；网络层分组封装为以太网帧完成传输，帧结构见图 9。

Fig. 9 Ethernet Frame

图 9 以太网帧结构

字段依次：前导码、源 MAC 地址、目的 MAC 地址、类型字段、数据载荷、CRC 校验码

The fields of this frame are described as follow:

帧各字段说明：

Preamble: is a sequence of 8 bytes, each set to "10101010" and used to synchronize receiver before actual data is sent;
前导码：8 字节固定序列，单字节二进制为 10101010，用于接收端时钟同步，同步完成后再解析有效数据；
Addresses
地址段

48-bit unicast address assigned to each adapter, named MAC (Medium Access Control) Address
单播地址：网卡分配 48 比特唯一介质访问控制（MAC）地址；
Broadcast address: all bits set to 1
广播地址：48 比特全部置 1；
Multicast: first bit is set to 1
组播地址：地址首比特置 1；

Type field: is used to determine which higher level protocol the frame should be delivered to
类型字段：标识帧承载的上层协议；
Body: contains up to 1500 bytes of data
载荷段：最大承载 1500 字节上层数据；
CRC：
循环冗余校验码，校验整帧传输完整性。

When the Ethernet standard was published, a new effort led by the Institute of Electrical and Electronics Engineers (IEEE) to develop open network standards was also getting underway. The IEEE standard was created under the direction of the IEEE Local and Metropolitan Networks (LAN/MAN) Standards Committee, which identifies all the standards it develops with the number 802. There have been a number of networking standards published in the 802 branch of the IEEE, including the 802.3 Ethernet and 802.5 Token Ring standards. The IEEE 802.3 committee took up the network system described in the original DIX standard and used it as the basis for an IEEE standard. The IEEE 802.3 standard was first published in 1985 with the title IEEE 802.3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Ethernet uses CSMA/CD to listen the line before sending data:

DIX 以太网标准发布同期，电气与电子工程师协会（IEEE）启动开放网络标准制定工作，由局域网/城域网标准委员会牵头，该委员会产出全部标准编号前缀为 802，包含 802.3 以太网、802.5 令牌环等规范。IEEE 802.3 委员会以初代 DIX 以太网为基础制定行业标准，1985 年正式发布 IEEE 802.3《带冲突检测的载波侦听多路访问（CSMA/CD）》。以太网依托 CSMA/CD 机制，发送数据前侦听链路状态，规则如下：

If the line is idle (no carrier sensed), it sends packet immediately;
链路空闲（无载波信号），立即发送帧；
If line is busy (carrier sensed), it wait until idle and transmit packet immediately;
链路占用（检测到载波），等待链路空闲后立即发送；
If collision is detected, it stops sending and try again later.
传输过程检测到冲突，立刻终止发送，等待随机时长重传。

After the publication of the original IEEE 802.3 standard for thick Ethernet, the next development in Ethernet media was the thin coaxial Ethernet variety, inspired by technology first marketed by 3Com Corporation. When the IEEE 802.3 committee standardized the thin Ethernet technology, they gave it the shorthand identifier of 10BASE2. Following thin coaxial 以太网，业界陆续推出双绞线、光纤等 10 兆传输介质方案；后续迭代百兆快速以太网，配套多类双绞线、光纤介质；再发展千兆、万兆以太网，十万兆以太网进入研发阶段。所有迭代方案均作为 IEEE 802.3 标准补充规范对外发布。

3.3 Evolution of Internet

3.3 互联网演进历程

In 1985, the National Science Foundation (NSF) launched a network to connect academic researchers to supercomputer centers to provide very high-speed computing resources for the research community. This network was named NSFNET and one of its project design premises was to use ARPANET's TCP/IP protocol. In 1986, the NSFNET was connected to ARPANET and these backbones forming what today is known as Internet. At the end of this decade, NSFNET became de facto the backbone of the Internet and the ARPANET was ended (Stewart 2000).

1985 年，美国国家科学基金会（NSF）搭建 NSFNET 骨干网，用于连接科研机构与超算中心，为科研人员提供高速算力资源；项目明确采用阿帕网 TCP/IP 协议。1986 年，NSFNET 与阿帕网互通，两套骨干网共同构成早期互联网。80 年代末，NSFNET 承担互联网骨干传输任务，阿帕网正式下线（斯图尔特，2000）。

Also in this period, the World Wide Web (WWW) system was created by Tim Berners-Lee $1$ to run in the Internet and provide graphical user interfaces and hypertext links between different addresses.

同期蒂姆·伯纳斯-李发明万维网（WWW）系统 $1$ ，运行于互联网之上，提供图形交互界面与跨地址超文本跳转能力。

In 1991, the Internet became commercially exploited and new backbones were built to offer services of communications. This fact made Internet completely decentralized, without a central coordination, difficult architectural changes. In 1995, the NSFNET was officially dissolved, although the authority retained a core research network called the Very High Speed Backbone Network Service (vBNS), which formed the basis for the Internet2 project $10$ .

1991 年，互联网全面开放商用运营，多家机构新建商用骨干网提供通信服务；商用化后互联网彻底分布式，无统一管控主体，全网架构调整难度提升。1995 年 NSFNET 正式关停，但保留科研专用高速骨干网 vBNS，该网络为第二代互联网（Internet2）项目底层支撑 $10$ 。

Since 1995, the Internet continues growing; more and more people use it to be connected, find information, create business, and share information. The Internet is now an essential part of our lives.

1995 年至今互联网持续扩张，接入用户规模持续增长，大众依托互联网社交、检索信息、开展商业活动、共享数据，互联网现已成为日常生活基础配套。

References

参考文献

Berners-Lee: Information Management: A Proposal, CERN (1989), http://www.w3.org/History/1989/proposal.html (accessed March 2010)
伯纳斯-李. 信息管理提案 $R$ .欧洲核子研究中心，1989（2010 年 3 月访问）
Bolt, Beranek, Newman: Report No. 1822: Specification for the Interconnection of a host and an IMP (1976)
BBN 公司. 1822 号报告：主机与 IMP 互联规范 $R$ .1976
Cerf, V., Kahn, R.: A Protocol for Packet Network Intercommunication. IEEE Transactions on Communication 22(5) (1974)
瑟夫，卡恩. 分组网络互联协议 $J$ .IEEE 通信汇刊，1974，22(5)
Cocker, S., Carr, S., Cerf, V.: RFC 33 New Host-Host Protocol (1970)
科克尔，卡尔，瑟夫. RFC33 全新主机间协议 $R$ .1970
Hinden, R., Shelzer, A.: RFC 823 DARPA Internet gateway (1982)
欣登，谢尔泽. RFC823 DARPA 互联网网关规范 $R$ .1982
Metcalfe, R., Boggs, D.: Ethernet: Distributed Packet Switching for Local Computer Networks. Communications of the ACM 19(5), 395--404 (1976), http://www.acm.org/classics/apr96/ (accessed March 2010)
梅特卡夫，博格斯. 以太网：面向本地计算机网络的分布式分组交换 $J$ .ACM 通信汇刊，1976，19(5):395-404（2010 年 3 月访问）
Postel, J.: RFC 791 Internet Protocol (1981)
波斯特尔. RFC791 互联网协议规范 $R$ .1981
Postel, J.: RFC 792 Internet Control Message Protocol (1981)
波斯特尔. RFC792 互联网控制报文协议 $R$ .1981
Postel, J.: RFC 793 Transmission Control Protocol (1981)
波斯特尔. RFC793 传输控制协议规范 $R$ .1981
Stewart, B.: Living Internet (2000), http://www.livinginternet.com/i/i.htm
斯图尔特. 鲜活互联网 $EB/OL$ .2000
Wladrop, M.: Darpa and the Internet Revolution. DARPA 78-85 (2008), http://www.darpa.mil/Docs/ Internet_Development_200807180909255.pdf (accessed March 2010)
弗拉德罗普. DARPA 与互联网变革 $R$ .美国国防部高级研究计划局，2008（2010 年 3 月访问）

网络互联历史与演变

一、引言

网络互联（Internetworking）技术的发展经历了从单一分组交换网络到多异构网络互通的演变。其历史文献可分为四类：（1）通史专著，提供完整技术演进脉络；（2）奠基原始论文，记录互联思想的发端；（3）RFC 标准文档，构成互联网的技术编年史料；（4）架构哲学论文，阐释互联设计的底层逻辑。以下按此分类逐一评述。

二、通史类专著

2.1 Comer, D. E. Internetworking with TCP/IP, Vol. 1: Principles, Protocols, and Architectures

出版信息：Prentice Hall，第 6 版，2013。
ISBN-13: 978-0-13-608530-0；ISBN-10: 0-13-608530-X
ACM Digital Library | Pearson 出版社
网络互联领域通史性教材，以"多网络互通"为主线，从 ARPANET、以 CYCLADES、ALOHANET 等异构网络的兼容冲突为切入点，系统剖析 TCP/IP 跨网兼容机制的设计与演变。每章附协议诞生历史、技术矛盾及迭代背景，涵盖早期互联实验、网关设计、路由演变的详实考据。
覆盖时段：分组交换诞生 o o o 多异构网络孤岛 o o o 网关 / 路由器雏形 o o o TCP/IP 分层互联模型 o o o IPv4 / 路由体系 o o o 现代互联网互联架构。

2.2 Hafner, K., Lyon, M. Where Wizards Stay Up Late: The Origins of the Internet

出版信息：Simon & Schuster，1996。
ISBN-10: 0-684-87216-1；ISBN-13: 978-0-684-87216-2
Simon & Schuster 出版社
互联网起源纪实通史，基于 ARPA 原始档案与先驱口述史料，记录 ARPANET 立项、分组交换实现、跨网互联需求诞生全过程。还原 1960--1970 年代 RAND、NPL、CYCLADES 等分组网络并行发展的历史背景。

2.3 Tanenbaum, A. S., Wetherall, D. J. Computer Networks（第 5 版）

出版信息（英文原版）：Pearson / Prentice Hall，2010。
- ISBN-13: 978-0-13-212695-3；ISBN-10: 0-13-212695-8
出版信息（中文译本）：《计算机网络（第 5 版）》，严伟、潘爱民译，清华大学出版社，2012 年 3 月。
- ISBN: 978-7-302-27462-9
- 丛书：世界著名计算机教材精选
Pearson 出版社 | 清华大学出版社
高校标准教材，设独立章节阐释网络互联分层思想演变，涵盖 NCP、OSI 七层模型与 TCP/IP 四层模型的博弈、路由器 / 网关技术迭代、广域互联、域间路由（BGP）发展史，并横向对比同期技术方案的优劣与淘汰原因。

2.4 Cerf, V., Kahn, R., Postel, J., et al. A Brief History of the Internet

出版信息：Internet Society，1997。
Internet Society 官方版本 | Springer 收录版本
由互联网先驱集体编撰的官方简史，联邦网络委员会（FNC）背书。按时间线定义"internet"互联概念诞生、TCP/IP 标准化、全球网络互通扩张，兼顾技术、产业、政策层面演变，原始史料未经二次加工。

2.5 Standage, T. The Victorian Internet: The Remarkable Story of the Telegraph and the Nineteenth Century's On-line Pioneers

出版信息：Berkley Books / Walker & Company，1998。
ISBN-10: 0-8027-1342-4；ISBN-13: 978-0-8027-1604-0
Walker Books | Penguin Random House
从电报切入的长周期通信技术史，将 19 世纪电报网络与 20 世纪互联网进行结构类比，为理解分布式通信系统的历史连续性提供参照框架。

三、奠基论文

3.1 Baran, P. On Distributed Communications Networks

发表信息：RAND Corporation Memorandum RM-3420-PR，1964；DOI：https://doi.org/10.7249/RM3420
分布式分组交换理论奠基文献，提出无中心化、自适应分组路由通信模型，为网间网关架构与互联网分布式底层体系提供核心理论支撑。

3.2 Cerf, V. G., Kahn, R. E. A Protocol for Packet Network Intercommunication

发表信息：IEEE Transactions on Communications，Vol. COM-22，No. 5，May 1974，pp. 637--648。
DOI: 10.1109/TCOM.1974.1092259
IEEE Xplore
首次提出"internetwork"概念，定义跨异构分组网络互通标准框架，设计统一报文头、跨网路由、分片重组机制，构成 TCP/IP 原始设计蓝图。
说明：1974 年规范将功能合并于单一协议（Transmission Control Program）；1978 年 Cerf、Postel、Cohen 将其正式拆分为 TCP 与 IP 两层，形成沿用至今的架构。

3.3 Roberts, L. G. Towards a Cooperative Network of Time-Shared Computers

发表信息：Proceedings of the Fall Joint Computer Conference (AFIPS '66)，Spartan Books，1966，pp. 425--431。
DOI: 10.1145/1464291.1464336
ACM Digital Library
ARPANET 立项原始方案，最早提出"多计算机网络协同互通"构想，记录首个跨主机互联实验设计。

3.4 Cerf, V. G. Protocols for Interconnected Packet Networks

发表信息：1980。
IEEE Xplore 相关收录
1974 年论文的演进版本，详细阐述 TCP 拆分为 TCP + IP 两层架构的技术原因，记录早期网关、跨网寻址、分片机制迭代细节。

3.5 Saltzer, J. H., Reed, D. P., Clark, D. D. End-To-End Arguments in System Design

发表信息：ACM Transactions on Computer Systems (TOCS)，Vol. 2，No. 4，November 1984，pp. 277--288。
DOI: 10.1145/357401.357402
ACM Digital Library
互联底层设计哲学文献，奠定 TCP/IP 跨网分层设计准则，阐释无连接 IP 层实现异构网络互通的设计 rationale。

四、RFC 标准文档

4.1 RFC 1 --- Host Software

作者：Crocker, S.
日期：1969-04-07。
RFC Editor | RFC 2CN 中文翻译
第一份 RFC，ARPANET 主机软件规范，互联网互联文档体系开端。注：NCP（Network Control Protocol）为后续发展的主机协议，RFC 1 本身并非 NCP 规范。

4.2 RFC 791 --- Internet Protocol (IPv4)

日期：1981-09。
RFC Editor | RFC 2CN 中文翻译
IP 互联层正式标准，定义跨网寻址、分片、网关转发规则，全球异构网络互通基石。

4.3 RFC 793 --- Transmission Control Protocol

日期：1981-09。
RFC Editor | RFC 9293（现行 TCP 规范）
TCP 传输互联标准，端到端跨网可靠传输规范，TCP/IP 分层互联体系定型。

4.4 RFC 1958 --- Architectural Principles of the Internet

日期：1996-06。
RFC Editor
互联网互联架构总纲，总结三十年网际互联设计准则，阐述从 ARPANET 到全球互联网的架构演变历程。

4.5 RFC 2235 --- Hobbes' Internet Timeline

作者：Zakon, R. H.（MITRE）。
日期：1997-11。
类别：FYI 32，Informational。
RFC Editor | RFC 2CN 中文翻译
互联网互联时间线，量化记录网络互通规模、互联技术实现、协议标准化节点，附完整数据统计。

4.6 RFC 1058 / RFC 1771 --- RIP / BGP

RFC 1058（1988）：Routing Information Protocol，域内距离向量路由标准。
- RFC Editor
RFC 1771（1995）：Border Gateway Protocol 4 (BGP-4)，域间路由互联标准。
- RFC Editor（注：RFC 1771 已被 RFC 4271 更新）
记录局域网、广域网、全球 AS 域逐层互通机制，还原互联网路由体系演进。注：RIP 用于自治系统内部，BGP 用于自治系统之间，两者分属不同层次。

4.7 IEN 151 --- Final Report of the Stanford University TCP Project

作者：Cerf, V. G.
日期：1980-04-01。
RFC Editor IEN 索引
早期 TCP/IP 内部工程报告，记录 1973--1980 年网关、跨网互联原型实验的调试迭代记录。

五、互联架构演进里程碑论文

5.1 Clark, D. D. The Design Philosophy of the DARPA Internet Protocols

发表信息：Proc. ACM SIGCOMM 1988，Computer Communication Review，Vol. 18，No. 4，August 1988，pp. 106--114。
DOI: 10.1145/52325.52336
ACM Digital Library
拆解 DARPA 时代网络互联设计取舍------面向连接的放弃、数据报网关的选择、异构底层网络的兼容，复盘 1970 年代多网互通技术路线博弈。

5.2 Clark, D. D., Tennenhouse, D. L. Architectural Considerations for a New Generation of Protocols

发表信息：ACM SIGCOMM Computer Communication Review，Vol. 20，No. 4，1990，pp. 200--208。
DOI: 10.1145/99517.99553
ACM Digital Library
1990 年代互联网规模化互联反思，分析早期 TCP/IP 跨网互通的缺陷，引出路由扩展、NAT、CIDR 等下一代互联改造方案。

发表信息：Proceedings of the IEEE，Vol. 60，No. 11，November 1972，pp. 1397--1407。
DOI: 10.1109/PROC.1972.8911
IEEE Xplore
ARPANET 首次公开大规模跨主机互联实验报告，记录早期多节点互通、跨线路数据交换实测数据。

六、阅荐

通史入门：Hafner & Lyon o o o Comer，建立完整时间线；
思想起源：Baran (1964) o o o Cerf & Kahn (1974)；
架构逻辑：Saltzer, Reed & Clark (1984) + Clark (1988, 1990)；
原始档案：RFC 1, 791, 793, 1958, 2235 + IEN 151；
体系补充：Tanenbaum & Wetherall，横向对比 OSI 与 TCP/IP 模型竞争与演变。

Reference

A Protocol for Packet Network Intercommunication - VINTON G. CERF AND ROBERT E. KAHN,MEMBER, IEEE

https://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf
A Brief History of the Internet | Springer Nature Link

https://rd.springer.com/chapter/10.1007/978-3-642-13247-6_1
......

网络互联历史 | 分组网络协议奠基与早期架构演化

A Protocol for Packet Network Intercommunication

分组网络互联协议

Abstract

摘要

INTRODUCTION

引言

THE GATEWAY NOTION

网关概念

PROCESS LEVEL COMMUNICATION

进程层通信

ADDRESS FORMATS

地址格式

TCP ADDRESSING

TCP 寻址

PORT ADDRESSING

端口寻址

SEGMENT AND PACKET FORMATS

分段与分组格式

REASSEMBLY AND SEQUENCING

重组与排序

RETRANSMISSION AND DUPLICATE DETECTION

重传与重复报文检测

Sender

发送端规则

Receiver

接收端规则

FLOW CONTROL

流量控制

TCP INPUT/OUTPUT HANDLING

TCP 输入输出处理

TCP/PROCESS COMMUNICATION

TCP 与进程交互

CONNECTIONS AND ASSOCIATIONS

连接与关联

CONNECTION-FREE PROTOCOLS WITH ASSOCIATIONS

带关联机制的无连接协议

CONCLUSIONS

结论

ACKNOWLEDGMENT

致谢

REFERENCES

参考文献

作者简介

附注

PH （Process Header，进程首部）

1. 所属层级

3. 内部字段（对应 Fig.6 分段格式）

4. 功能说明

5. PH（进程首部）与 IH（网间首部）、LH（本地首部）区分

6. 结合 Fig.9 场景说明

A Brief History of the Internet

互联网简史

Abstract

摘要

1 Introduction

1 引言

2 Decade of the 70´s

2 20 世纪 70 年代

2.1 Network Control Protocol Operation

2.1 网络控制协议运行机制

2.2 TCP

2.2 传输控制协议（TCP）

2.3 Ethernet

2.3 以太网

3 Decade of the 80´s

3 20 世纪 80 年代

3.1 Internet Protocol

3.1 互联网协议（IP）

3.2 Ethernet Protocol

3.2 以太网协议

3.3 Evolution of Internet

3.3 互联网演进历程

References

参考文献

网络互联历史与演变

一、引言

二、通史类专著

2.1 Comer, D. E. Internetworking with TCP/IP, Vol. 1: Principles, Protocols, and Architectures

2.2 Hafner, K., Lyon, M. Where Wizards Stay Up Late: The Origins of the Internet