注：机翻，未校。
How the ARPANET Protocols Worked
ARPANET 协议的工作原理
08 Mar 2021
The ARPANET changed computing forever by proving that computers of wildly different manufacture could be connected using standardized protocols. In my post on the historical significance of the ARPANET, I mentioned a few of those protocols, but didn’t describe them in any detail. So I wanted to take a closer look at them. I also wanted to see how much of the design of those early protocols survives in the protocols we use today.
ARPANET 永久改变了计算机领域，因为它证明了不同制造商的计算机可以使用标准化协议相互连接。在我关于 ARPANET 历史重要性的帖子中，我提到了一些这些协议，但没有详细描述。因此，我想更仔细地看看它们。我还想了解这些早期协议的设计有多少在我们今天使用的协议中得以保留。
The ARPANET protocols were, like our modern internet protocols, organized into layers.1 The protocols in the higher layers ran on top of the protocols in the lower layers. Today the TCP/IP suite has five layers (the Physical, Link, Network, Transport, and Application layers), but the ARPANET had only three layers—or possibly four, depending on how you count them.
ARPANET 的协议与我们现代互联网协议一样，组织成层次结构。较高层的协议运行在较低层的协议之上。今天的 TCP/IP 套件有五个层级（物理层、链路层、网络层、传输层和应用层），而 ARPANET 只有三层 —— 或者可能是四层，这取决于你如何计算它们。
I’m going to explain how each of these layers worked, but first an aside about who built what in the ARPANET, which you need to know to understand why the layers were divided up as they were.
我将解释这些层中的每一个是如何工作的，但首先要说明谁在 ARPANET 中构建了什么，你需要知道这一点才能理解为什么这些层被如此划分是必要的。
Some Quick Historical Context 一些快速的历史背景
The ARPANET was funded by the US federal government, specifically the Advanced Research Projects Agency within the Department of Defense (hence the name “ARPANET”). The US government did not directly build the network; instead, it contracted the work out to a Boston-based consulting firm called Bolt, Beranek, and Newman, more commonly known as BBN.
ARPANET 由美国联邦政府资助，特别是国防部下属的高级研究计划局（因此得名 “ ARPANET ”）。美国政府没有直接建设该网络；取而代之的是，它将这项工作承包给了一家位于波士顿的咨询公司，名为 Bolt，Beranek 和 Newman，通常被称为 BBN。
BBN, in turn, handled many of the responsibilities for implementing the network but not all of them. What BBN did was design and maintain a machine known as the Interface Message Processor, or IMP. The IMP was a customized Honeywell minicomputer, one of which was delivered to each site across the country that was to be connected to the ARPANET. The IMP served as a gateway to the ARPANET for up to four hosts at each host site. It was basically a router. BBN controlled the software running on the IMPs that forwarded packets from IMP to IMP, but the firm had no direct control over the machines that would connect to the IMPs and become the actual hosts on the ARPANET.
反过来，BBN 承担了实施网络的许多责任，但不是全部。BBN 所做的是设计和维护一台称为接口消息处理器（IMP）的机器。IMP 是一台定制的霍尼韦尔小型计算机，其中一台被运送到全国各地要连接到 ARPANET 的每个站点。IMP 充当 ARPANET 的网关，每个主机站点最多可容纳 4 台主机。它基本上是一个路由器。BBN 控制着在 IMP 上运行的软件，该软件将数据包从 IMP 转发到 IMP，但该公司无法直接控制连接到 IMP 并成为 ARPANET 实际主机的机器。
The host machines were controlled by the computer scientists that were the end users of the network. These computer scientists, at host sites across the country, were responsible for writing the software that would allow the hosts to talk to each other. The IMPs gave hosts the ability to send messages to each other, but that was not much use unless the hosts agreed on a format to use for the messages. To solve that problem, a motley crew consisting in large part of graduate students from the various host sites formed themselves into the Network Working Group, which sought to specify protocols for the host computers to use.
主机由计算机科学家控制，这些计算机科学家是网络的最终用户。这些计算机科学家在全国各地的主机站点负责编写软件，使主机能够相互交谈。IMP 使主机能够相互发送消息，但除非主机就消息使用的格式达成一致，否则这没有多大用处。为了解决这个问题，一个由来自各个主机站点的大部分研究生组成的杂乱无章的团队组成了网络工作组，该工作组试图为主机计算机指定要使用的协议。
So if you imagine a single successful network interaction over the ARPANET, (sending an email, say), some bits of engineering that made the interaction successful were the responsibility of one set of people (BBN), while other bits of engineering were the responsibility of another set of people (the Network Working Group and the engineers at each host site). That organizational and logistical happenstance probably played a big role in motivating the layered approach used for protocols on the ARPANET, which in turn influenced the layered approach used for TCP/IP.
因此，如果你想象通过 ARPANET 进行一次成功的网络交互（例如发送电子邮件），那么使交互成功的一些工程部分是一组人（BBN）的责任，而其他工程部分是另一组人（网络工作组和每个主机站点的工程师）的责任。这种组织和后勤上的偶然性可能在推动 ARPANET 协议采用分层方法方面发挥了重要作用，而 ARPANET 协议又影响了用于 TCP/IP 的分层方法。
Okay, Back to the Protocols 好的，回到协议
The ARPANET protocol hierarchy.
ARPANET 协议层次结构。
The protocol layers were organized into a hierarchy. At the very bottom was “level 0.”2 This is the layer that in some sense doesn’t count, because on the ARPANET this layer was controlled entirely by BBN, so there was no need for a standard protocol. Level 0 governed how data passed between the IMPs. Inside of BBN, there were rules governing how IMPs did this; outside of BBN, the IMP sub-network was a black box that just passed on any data that you gave it. So level 0 was a layer without a real protocol, in the sense of a publicly known and agreed-upon set of rules, and its existence could be ignored by software running on the ARPANET hosts. Loosely speaking, it handled everything that falls under the Physical, Link, and Internet layers of the TCP/IP suite today, and even quite a lot of the Transport layer, which is something I’ll come back to at the end of this post.
协议层被组织成一个层次结构。最底部是 “0 级”。2 从某种意义上说，这是不算数的层，因为在 ARPANET 上，这一层完全由 BBN 控制，因此不需要标准协议。级别 0 控制数据在 IMP 之间传递的方式。在 BBN 内部，有管理 IMP 如何做到这一点的规则；在 BBN 之外，IMP 子网络是一个黑匣子，它只是传递您提供给它的任何数据。因此，级别 0 是一个没有真正协议的层，从公开知道和商定的规则集的意义上说，它的存在可以被运行在 ARPANET 主机上的软件忽略。粗略地说，它处理了当今 TCP/IP 套件的物理层、链路层和 Internet 层下的所有内容，甚至还处理了相当多的传输层，这是我将在本文末尾回到的内容。
The “level 1” layer established the interface between the ARPANET hosts and the IMPs they were connected to. It was an API, if you like, for the black box level 0 that BBN had built. It was also referred to at the time as the IMP-Host Protocol. This protocol had to be written and published because, when the ARPANET was first being set up, each host site had to write its own software to interface with the IMP. They wouldn’t have known how to do that unless BBN gave them some guidance.
“1 级” 层在 ARPANET 主机和它们所连接的 IMP 之间建立了接口。如果你愿意的话，这是一个 API，用于 BBN 构建的黑匣子级别 0。它当时也被称为 IMP-Host 协议。该协议必须编写和发布，因为当首次建立 ARPANET 时，每个主机站点都必须编写自己的软件来与 IMP 接口。除非 BBN 给他们一些指导，否则他们不会知道如何做到这一点。
The IMP-Host Protocol was specified by BBN in a lengthy document called BBN Report 1822. The document was revised many times as the ARPANET evolved; what I’m going to describe here is roughly the way the IMP-Host protocol worked as it was initially designed. According to BBN’s rules, hosts could passmessagesto their IMPs no longer than 8095 bits, and each message had aleaderthat included the destination host number and something called alink number.3 The IMP would examine the designation host number and then dutifully forward the message into the network. When messages were received from a remote host, the receiving IMP would replace the destination host number with the source host number before passing it on to the local host. Messages were not actually what passed between the IMPs themselves—the IMPs broke the messages down into smallerpacketsfor transfer over the network—but that detail was hidden from the hosts.
IMP-Host 协议由 BBN 在一份名为 BBN Report 1822 的冗长文档中指定。随着 ARPANET 的发展，该文件被多次修订；我在这里要描述的大致是 IMP-Host 协议最初设计时的工作方式。根据 BBN 的规则，主机可以向其 IMP 传递消息的时间不超过 8095 位，并且每条消息都有一个 leader ，其中包括目标主机号和称为链接号的东西。3 IMP 将检查指定的主机号，然后尽职尽责地将消息转发到网络中。当从远程主机接收到消息时，接收 IMP 会先将目标主机号替换为源主机号，然后再将其传递到本地主机。消息实际上并不是在 IMP 本身之间传递的内容 - IMP 将消息分解为较小的数据包，以便通过网络传输 - 但该细节对主机是隐藏的。
The Host-IMP message leader format, as of 1969. Diagram from BBN Report 1763.
Host-IMP 消息 leader 格式，截至 1969 年。图表来自 BBN 报告 1763。
The link number, which could be any number from 0 to 255, served two purposes. It was used by higher level protocols to establish more than one channel of communication between any two hosts on the network, since it was conceivable that there might be more than one local user talking to the same destination host at any given time. (In other words, the link numbers allowed communication to be multiplexed between hosts.) But it was also used at the level 1 layer to control the amount of traffic that could be sent between hosts, which was necessary to prevent faster computers from overwhelming slower ones. As initially designed, the IMP-Host Protocol limited each host to sending just one message at a time over each link. Once a given host had sent a message along a link to a remote host, it would have to wait to receive a special kind of message called an RFNM (Request for Next Message) from the remote IMP before sending the next message along the same link. Later revisions to this system, made to improve performance, allowed a host to have up to eight messages in transit to another host at a given time.4
链接编号可以是 0 到 255 之间的任何数字，有两个用途。它被更高级别的协议用于在网络上的任意两台主机之间建立多个通信通道，因为可以想象，在任何给定时间，可能有多个本地用户与同一目标主机通信。（换言之，链路号允许在主机之间进行多路复用通信。但它也被用于第 1 层，以控制主机之间可以发送的流量，这对于防止较快的计算机压倒较慢的计算机是必要的。按照最初的设计，IMP 主机协议将每个主机限制为一次只能通过每个链路发送一条消息。一旦给定主机通过链接向远程主机发送了一条消息，它就必须等待从远程 IMP 接收一种称为 RFNM（下一条消息请求）的特殊类型的消息，然后才能沿同一链接发送下一条消息。为了提高性能，后来对此系统进行了修订，允许一个主机在给定时间最多有八条消息传输到另一个主机 4。
The “level 2” layer is where things really start to get interesting, because it was this layer and the one above it that BBN and the Department of Defense left entirely to the academics and the Network Working Group to invent for themselves. The level 2 layer comprised the Host-Host Protocol, which was first sketched in RFC 9 and first officially specified by RFC 54. A more readable explanation of the Host-Host Protocol is given in the ARPANET Protocol Handbook.
“第 2 层” 是事情真正开始变得有趣的地方，因为正是这一层及其上面的一层，BBN 和国防部完全留给了学术界和网络工作组自己发明。第 2 层由主机 - 主机协议组成，该协议首先在 RFC 9 中草拟，并首次由 RFC 54 正式指定。ARPANET 协议手册中对主机 - 主机协议进行了更易读的解释。
The Host-Host Protocol governed how hosts created and managedconnectionswith each other. A connection was a one-way data pipeline between awrite socketon one host and aread socketon another host. The “socket” concept was introduced on top of the limited level-1 link facility (remember that the link number can only be one of 256 values) to give programs a way of addressing a particular process running on a remote host. Read sockets were even-numbered while write sockets were odd-numbered; whether a socket was a read socket or a write socket was referred to as the socket’s gender. There were no “port numbers” like in TCP. Connections could be opened, manipulated, and closed by specially formatted Host-Host control messages sent between hosts using link 0, which was reserved for that purpose. Once control messages were exchanged over link 0 to establish a connection, further data messages could then be sent using another link number picked by the receiver.
主机 - 主机协议控制主机如何创建和管理彼此之间的连接。连接是一台主机上的写入套接字和另一台主机上的读取套接字之间的单向数据管道。“套接字” 概念是在有限的 1 级链接工具之上引入的（请记住，链接编号只能是 256 个值之一），为程序提供了一种寻址远程主机上运行的特定进程的方法。读取套接字是偶数，而写入套接字是奇数；套接字是读取套接字还是写入套接字被称为套接字的性别。没有像 TCP 那样的 “端口号”。可以通过使用链接 0 在主机之间发送的特殊格式的主机 - 主机控制消息来打开、操作和关闭连接，该链接 0 是为此目的保留的。一旦通过链路 0 交换控制消息以建立连接，就可以使用接收方选择的另一个链路号发送进一步的数据消息。
Host-Host control messages were identified by a three-letter mnemonic. A connection was established when two hosts exchanged a STR (sender-to-receiver) message and a matching RTS (receiver-to-sender) message—these control messages were both known as Request for Connection messages. Connections could be closed by the CLS (close) control message. There were further control messages that changed the rate at which data messages were sent from sender to receiver, which were needed to ensure again that faster hosts did not overwhelm slower hosts. The flow control already provided by the level 1 protocol was apparently not sufficient at level 2; I suspect this was because receiving an RFNM from a remote IMP was only a guarantee that the remote IMP had passed the message on to the destination host, not that the host had fully processed the message. There was also an INR (interrupt-by-receiver) control message and an INS (interrupt-by-sender) control message that were primarily for use by higher-level protocols.
主机 - 主机控制消息由三个字母的助记词标识。当两个主机交换 STR（发送方到接收方）消息和匹配的 RTS（接收方到发送方）消息时，即建立了连接，这些控制消息都称为 “连接请求” 消息。可以通过 CLS（关闭）控制消息关闭连接。还有一些进一步的控制消息改变了数据消息从发送方发送到接收方的速率，这是为了再次确保速度较快的主机不会压倒速度较慢的主机所必需的。第 1 级协议已经提供的流量控制在第 2 级显然是不够的；我怀疑这是因为从远程 IMP 接收 RFNM 只能保证远程 IMP 已将消息传递给目标主机，而不是主机已完全处理消息。此外，还有 INR（接收方中断）控制消息和 INS（发送方中断）控制消息，主要供上级协议使用。
The higher-level protocols all lived in “level 3”, which was the Application layer of the ARPANET. The Telnet protocol, which provided a virtual teletype connection to another host, was perhaps the most important of these protocols, but there were many others in this level too, such as FTP for transferring files and various experiments with protocols for sending email.
更高级别的协议都位于 “3 级”，即 ARPANET 的应用层。Telnet 协议提供了与另一台主机的虚拟电传打字连接，可能是这些协议中最重要的协议，但在这个级别中还有许多其他协议，例如用于传输文件的 FTP 和用于发送电子邮件的协议的各种实验。
One protocol in this level was not like the others: the Initial Connection Protocol (ICP). ICP was considered to be a level-3 protocol, but really it was a kind of level-2.5 protocol, since other level-3 protocols depended on it. ICP was needed because the connections provided by the Host-Host Protocol at level 2 were only one-way, but most applications required a two-way (i.e. full-duplex) connection to do anything interesting. ICP specified a two-step process whereby a client running on one host could connect to a long-running server process on another host. The first step involved establishing a one-way connection from the server to the client using the server process’ well-known socket number. The server would then send a new socket number to the client over the established connection. At that point, the existing connection would be discarded and two new connections would be opened, a read connection based on the transmitted socket number and a write connection based on the transmitted socket number plus one. This little dance was a necessary prelude to most things—it was the first step in establishing a Telnet connection, for example.
此级别中的一个协议与其他协议不同：初始连接协议 （ICP）。ICP 被认为是 3 级协议，但实际上它是一种 2.5 级协议，因为其他 3 级协议都依赖于它。之所以需要 ICP，是因为第 2 级的主机 - 主机协议提供的连接只是单向的，但大多数应用程序需要双向（即全双工）连接才能执行任何有趣的操作。ICP 指定了一个两步过程，即在一台主机上运行的客户端可以连接到另一台主机上长时间运行的服务器进程。第一步涉及使用服务器进程的已知套接字号建立从服务器到客户端的单向连接。然后，服务器将通过已建立的连接向客户端发送新的套接字号。此时，将丢弃现有连接，并打开两个新连接，一个基于传输的套接字号的读取连接，另一个基于传输的套接字号加 1 的写入连接。这个小舞蹈是大多数事情的必要前奏 —— 例如，它是建立 Telnet 连接的第一步。
That finishes our ascent of the ARPANET protocol hierarchy. You may have been expecting me to mention a “Network Control Protocol” at some point. Before I sat down to do research for this post and my last one, I definitely thought that the ARPANET ran on a protocol called NCP. The acronym is occasionally used to refer to the ARPANET protocols as a whole, which might be why I had that idea. RFC 801, for example, talks about transitioning the ARPANET from “NCP” to “TCP” in a way that makes it sound like NCP is an ARPANET protocol equivalent to TCP. But there has never been a “Network Control Protocol” for the ARPANET (even if Encyclopedia Britannica thinks so), and I suspect people have mistakenly unpacked “NCP” as “Network Control Protocol” when really it stands for “Network Control Program.” The Network Control Program was the kernel-level program running in each host responsible for handling network communication, equivalent to the TCP/IP stack in an operating system today. “NCP”, as it’s used in RFC 801, is a metonym, not a protocol.
至此，我们完成了对 ARPANET 协议层次结构的提升。您可能一直期待我在某个时候提到 “网络控制协议”。在我坐下来为这篇文章和上一篇文章做研究之前，我肯定认为 ARPANET 运行在一种称为 NCP 的协议上。这个首字母缩略词偶尔用于指代整个 ARPANET 协议，这可能就是我有这个想法的原因。例如，RFC 801 谈到了将 ARPANET 从 “NCP” 过渡到 “TCP”，其方式听起来像是 NCP 是等同于 TCP 的 ARPANET 协议。但是 ARPANET 从未有过 “网络控制协议”（即使《大英百科全书》这么认为），我怀疑人们错误地将 “NCP” 解读为 “网络控制协议”，而实际上它代表 “网络控制程序”。网络控制程序是在负责处理网络通信的每台主机中运行的内核级程序，相当于当今操作系统中的 TCP/IP 堆栈。RFC 801 中使用的 “NCP” 是一个转喻，而不是协议。
A Comparison with TCP/IP 与 TCP/IP 的比较
The ARPANET protocols were all later supplanted by the TCP/IP protocols (with the exception of Telnet and FTP, which were easily adapted to run on top of TCP). Whereas the ARPANET protocols were all based on the assumption that the network was built and administered by a single entity (BBN), the TCP/IP protocol suite was designed for aninter-net, a network of networks where everything would be more fluid and unreliable. That led to some of the more immediately obvious differences between our modern protocol suite and the ARPANET protocols, such as how we now distinguish between a Network layer and a Transport layer. The Transport layer-like functionality that in the ARPANET was partly implemented by the IMPs is now the sole responsibility of the hosts at the network edge.
ARPANET 协议后来都被 TCP/IP 协议所取代（Telnet 和 FTP 除外，它们很容易适应在 TCP 上运行）。ARPANET 协议都是基于网络由单一实体（BBN）构建和管理的假设，而 TCP/IP 协议套件是为网际网设计的，这是一个网络网络，在这个网络中，一切都会更加流畅和不可靠。这导致了我们的现代协议套件和 ARPANET 协议之间一些更直接的明显差异，例如我们现在如何区分网络层和传输层。在 ARPANET 中，类似传输层的功能部分由 IMP 实现，现在由网络边缘的主机单独负责。
What I find most interesting about the ARPANET protocols though is how so much of the transport-layer functionality now in TCP went through a janky adolescence on the ARPANET. I’m not a networking expert, so I pulled out my college networks textbook (Kurose and Ross, let’s go), and they give a pretty great outline of what a transport layer is responsible for in general. To summarize their explanation, a transport layer protocol must minimally do the following things. Heresegmentis basically equivalent tomessageas the term was used on the ARPANET:
不过，我发现 ARPANET 协议最有趣的是，现在 TCP 中的许多传输层功能在 ARPANET 上经历了一个卡顿的青春期。我不是网络专家，所以我拿出了我的大学网络教科书（Kurose 和 Ross，我们走吧），它们很好地概述了传输层的一般职责。总结一下他们的解释，传输层协议必须至少执行以下操作。这里的段基本上等同于消息，因为该术语在 ARPANET 上使用：
- Provide a delivery service betweenprocessesand not just host machines (transport layer multiplexing and demultiplexing)
在进程之间提供交付服务，而不仅仅是主机（传输层多路复用和解复用） - Provide integrity checking on a per-segment basis (i.e. make sure there is no data corruption in transit)
提供基于每个段的完整性检查（即确保传输过程中没有数据损坏）
A transport layer could also, like TCP does, providereliable data transfer, which means:
传输层也可以像 TCP 一样提供可靠的数据传输，这意味着：
- Segments are delivered in order
段按顺序交付 - No segments go missing
不会丢失任何段落 - Segments aren’t delivered so fast that they get dropped by the receiver (flow control)
段的传送速度不会太快，以至于它们会被接收器丢弃（流量控制）
It seems like there was some confusion on the ARPANET about how to do multiplexing and demultiplexing so that processes could communicate—BBN introduced the link number to do that at the IMP-Host level, but it turned out that socket numbers were necessary at the Host-Host level on top of that anyway. Then the link number was just used for flow control at the IMP-Host level, but BBN seems to have later abandoned that in favor of doing flow control between unique pairs of hosts, meaning that the link number started out as this overloaded thing only to basically became vestigial. TCP now uses port numbers instead, doing flow control over each TCP connection separately. The process-process multiplexing and demultiplexing lives entirely inside TCP and does not leak into a lower layer like on the ARPANET.
ARPANET 上似乎对如何进行多路复用和解复用以便进程可以通信存在一些困惑 ——BBN 引入了链路号以在 IMP-Host 级别执行此操作，但事实证明，无论如何，在主机 - 主机级别都需要套接字号。然后，链路号仅用于 IMP-Host 级别的流量控制，但 BBN 后来似乎放弃了这一点，转而在唯一的主机对之间进行流量控制，这意味着链路号最初是作为这种过载的东西，但基本上变得退化了。TCP 现在改用端口号，分别对每个 TCP 连接进行流量控制。过程 - 过程多路复用和解复用完全存在于 TCP 内部，不会像在 ARPANET 上那样泄漏到较低层。
It’s also interesting to see, in light of how Kurose and Ross develop the ideas behind TCP, that the ARPANET started out with what Kurose and Ross would call a strict “stop-and-wait” approach to reliable data transfer at the IMP-Host level. The “stop-and-wait” approach is to transmit a segment and then refuse to transmit any more segments until an acknowledgment for the most recently transmitted segment has been received. It’s a simple approach, but it means that only one segment is ever in flight across the network, making for a very slow protocol—which is why Kurose and Ross present “stop-and-wait” as merely a stepping stone on the way to a fully featured transport layer protocol. On the ARPANET, “stop-and-wait” was how things worked for a while, since, at the IMP-Host level, a Request for Next Message had to be received in response to every outgoing message before any further messages could be sent. To be fair to BBN, they at first thought this would be necessary to provide flow control between hosts, so the slowdown was intentional. As I’ve already mentioned, the RFNM requirement was later relaxed for the sake of better performance, and the IMPs started attaching sequence numbers to messages and keeping track of a “window” of messages in flight in the more or less the same way that TCP implementations do today.5
同样有趣的是，鉴于 Kurose 和 Ross 如何发展 TCP 背后的思想，ARPANET 最初是采用 Kurose 和 Ross 所说的严格的 “停止和等待” 方法，在 IMP 主机级别进行可靠的数据传输。“停止等待” 的做法是传输一个段，然后拒绝传输任何其他段，直到收到对最近传输段的确认。这是一种简单的方法，但这意味着只有一个段在网络上飞行，这使得协议速度非常慢 —— 这就是为什么 Kurose 和 Ross 将 “停止等待” 只是通往功能完备的传输层协议的垫脚石。在 ARPANET 上，“停止等待” 是事情一段时间的运作方式，因为在 IMP 主机级别，在发送任何进一步的消息之前，必须收到对每条传出消息的响应。公平地说，BBN 起初认为这对于在主机之间提供流量控制是必要的，因此减速是故意的。正如我已经提到的，为了获得更好的性能，RFNM 要求后来被放宽了，IMP 开始将序列号附加到消息上，并以一种或多或少与今天的 TCP 实现相同的方式跟踪运行中的消息 “窗口” 5。
So the ARPANET showed that communication between heterogeneous computing systems is possible if you get everyone to agree on some baseline rules. That is, as I’ve previously argued, the ARPANET’s most important legacy. But what I hope this closer look at those baseline rules has revealed is just how much the ARPANET protocols also influenced the protocols we use today. There was certainly a lot of awkwardness in the way that transport-layer responsibilities were shared between the hosts and the IMPs, sometimes redundantly. And it’s really almost funny in retrospect that hosts could at first only send each other a single message at a time over any given link. But the ARPANET experiment was a unique opportunity to learn those lessons by actually building and operating a network, and it seems those lessons were put to good use when it came time to upgrade to the internet as we know it today.
因此，ARPANET 表明，如果你让每个人都同意一些基线规则，那么异构计算系统之间的通信是可能的。正如我之前所指出的，这是 ARPANET 最重要的遗产。但我希望对这些基线规则的仔细研究能够揭示的是，ARPANET 协议也对我们今天使用的协议产生了多大的影响。在主机和 IMP 之间分担传输层责任的方式肯定存在很多尴尬，有时甚至是冗余的。回想起来，主持人起初只能通过任何给定的链接一次向对方发送一条消息，这真的几乎很有趣。但是，ARPANET 实验是一个独特的机会，通过实际构建和运营网络来学习这些经验教训，而且在升级到我们今天所知的互联网时，这些经验教训似乎得到了很好的利用。
The Real Novelty of the ARPANET
ARPANET 的真正新颖之处
07 Feb 202107 2 月 2021
If you run an image search for the word “ARPANET,” you will find lots of maps showing how the government research network expanded steadily across the country throughout the late ’60s and early ’70s. I’m guessing that most people reading or hearing about the ARPANET for the first time encounter one of these maps.
如果你对 “ ARPANET ” 这个词进行图片搜索，你会发现很多地图显示了政府研究网络在 60 年代末和 70 年代初是如何在全国范围内稳步扩张的。我猜大多数第一次阅读或听说 ARPANET 的人都会遇到这些地图中的一张。
Obviously, the maps are interesting—it’s hard to believe that there were once so few networked computers that their locations could all be conveyed with what is really pretty lo-fi cartography. (We’re talking 1960s overhead projector diagrams here. You know the vibe.) But the problem with the maps, drawn as they are with bold lines stretching across the continent, is that they reinforce the idea that the ARPANET’s paramount achievement was connecting computers across the vast distances of the United States for the first time.
显然，这些地图很有趣 —— 很难相信曾经有如此之少的联网计算机，以至于它们的位置都可以通过真正非常低保真的制图来传达。（我们在这里谈论的是 1960 年代的高架投影仪图。你知道那种氛围。但是，这些地图的问题在于，它们用粗线条横跨整个大陆，强化了这样一种观点，即 ARPANET 的最高成就是首次将美国各地计算机连接起来。
Today, the internet is a lifeline that keeps us tethered to each other even as an airborne virus has us all locked up indoors. So it’s easy to imagine that, if the ARPANET was the first draft of the internet, then surely the world that existed before it was entirely disconnected, since that’s where we’d be without the internet today, right? The ARPANET must have been a big deal because it connected people via computers when that hadn’t before been possible.
今天，互联网是一条生命线，即使空气传播的病毒将我们所有人都关在室内，它也能让我们彼此联系在一起。因此，很容易想象，如果 ARPANET 是互联网的初稿，那么肯定是在它完全断开连接之前就存在的世界，因为这就是我们今天没有互联网的地方，对吧？ ARPANET 一定是一件大事，因为它通过计算机将人们连接起来，而这在以前是不可能的。
That view doesn’t get the history quite right. It also undersells what made the ARPANET such a breakthrough.
这种观点并不能完全正确地理解历史。它还低估了使 ARPANET 取得如此突破的原因。
The Debut 首次亮相
The Washington Hilton stands near the top of a small rise about a mile and a half northeast of the National Mall. Its two white-painted modern facades sweep out in broad semicircles like the wings of a bird. The New York Times, reporting on the hotel’s completion in 1965, remarked that the building looks “like a sea gull perched on a hilltop nest.”1
华盛顿希尔顿酒店（Washington Hilton）位于国家广场（National Mall）东北约一英里半的一栋小楼顶附近。它的两个白色现代立面像鸟的翅膀一样以宽阔的半圆形扫过。《纽约时报》在报道该酒店于 1965 年完工时评论说，该建筑看起来 “就像栖息在山顶巢穴上的海鸥”。1
The hotel hides its most famous feature below ground. Underneath the driveway roundabout is an enormous ovoid event space known as the International Ballroom, which was for many years the largest pillar-less ballroom in DC. In 1967, the Doors played a concert there. In 1968, Jimi Hendrix also played a concert there. In 1972, a somewhat more sedate act took over the ballroom to put on the inaugural International Conference on Computing Communication, where a promising research project known as the ARPANET was demonstrated publicly for the first time.
酒店将其最著名的特色隐藏在地下。在车道环形交叉路口下方是一个巨大的卵形活动空间，称为国际宴会厅，多年来它是华盛顿特区最大的无柱宴会厅。1967 年，Doors 在那里举办了一场音乐会。1968 年，吉米・亨德里克斯（Jimi Hendrix）也在那里举办了一场音乐会。1972 年，一个稍微平静得多的举动接管了宴会厅，举办了首届计算通信国际会议，在会上，一个名为 ARPANET 的有前途的研究项目首次公开展示。
The 1972 ICCC, which took place from October 24th to 26th, was attended by about 800 people.2 It brought together all of the leading researchers in the nascent field of computer networking. According to internet pioneer Bob Kahn, “if somebody had dropped a bomb on the Washington Hilton, it would have destroyed almost all of the networking community in the US at that point.”3
1972 年 ICCC 于 10 月 24 日至 26 日举行，约有 800 人参加。根据互联网先驱鲍勃・卡恩（Bob Kahn）的说法，“如果有人向华盛顿希尔顿酒店投下炸弹，那时候几乎会摧毁美国所有的网络社区。3
Not all of the attendees were computer scientists, however. An advertisement for the conference claimed it would be “user-focused” and geared toward “lawyers, medical men, economists, and government men as well as engineers and communicators.”4 Some of the conference’s sessions were highly technical, such as the session titled “Data Network Design Problems I” and its sequel session, “Data Network Design Problems II.” But most of the sessions were, as promised, focused on the potential social and economic impacts of computer networking. One session, eerily prescient today, sought to foster a discussion about how the legal system could act proactively “to safeguard the right of privacy in the computer data bank.”5
然而，并非所有与会者都是计算机科学家。该会议的一则广告声称，它将 “以用户为中心”，面向 “律师、医务人员、经济学家和政府官员，以及工程师和传播者”。4 会议的一些会议具有很强的技术性，例如题为 “数据网络设计问题 I” 的会议及其后续会议 “数据网络设计问题 II”。但是，正如所承诺的那样，大多数会议都集中在计算机网络的潜在社会和经济影响上。今天有一场会议，令人毛骨悚然的先见之明，试图促进一场关于法律系统如何积极行动 “保护计算机数据库隐私权” 的讨论。5
The ARPANET demonstration was intended as a side attraction of sorts for the attendees. Between sessions, which were held either in the International Ballroom or elsewhere on the lower level of the hotel, attendees were free to wander into the Georgetown Ballroom (a smaller ballroom/conference room down the hall from the big one),6 where there were 40 terminals from a variety of manufacturers set up to access the ARPANET.7 These terminals were dumb terminals—they only handled input and output and could do no computation on their own. (In fact, in 1972, it’s likely that all of these terminals were hardcopy terminals, i.e. teletype machines.) The terminals were all hooked up to a computer known as a Terminal Interface Message Processor or TIP, which sat on a raised platform in the middle of the room. The TIP was a kind of archaic router specially designed to connect dumb terminals to the ARPANET. Using the terminals and the TIP, the ICCC attendees could experiment with logging on and accessing some of the computers at the 29 host sites then comprising the ARPANET.8
ARPANET 的演示旨在为与会者提供各种附带的吸引力。在国际宴会厅或酒店下层的其他地方举行的会议之间，与会者可以自由地走进乔治敦宴会厅（一个较小的宴会厅 / 会议室），6 那里有来自不同制造商的 40 个终端，用于访问 ARPANET.7 这些终端是哑终端 - 它们只处理输入和输出，不能对他们的有。（事实上，在 1972 年，所有这些终端可能都是硬拷贝终端，即电传打字机。这些终端都连接到一台称为终端接口消息处理器（TIP）的计算机上，该计算机位于房间中间的一个凸起平台上。TIP 是一种古老的路由器，专门设计用于将哑终端连接到 ARPANET。使用终端和 TIP，ICCC 与会者可以尝试登录和访问 29 个主机站点的一些计算机，然后组成 ARPANET8。
To exhibit the network’s capabilities, researchers at the host sites across the country had collaborated to prepare 19 simple “scenarios” for users to experiment with. These scenarios were compiled into a booklet that was handed to conference attendees as they tentatively approached the maze of wiring and terminals.9 The scenarios were meant to prove that the new technology worked but also that it was useful, because so far the ARPANET was “a highway system without cars,” and its Pentagon funders hoped that a public demonstration would excite more interest in the network.10
为了展示该网络的能力，全国各地主办站点的研究人员合作准备了 19 个简单的 “场景” 供用户试验。这些情景被汇编成一本小册子，当与会者试探性地接近布线和端子的迷宫时，他们被交给了与会者.9 这些情景旨在证明新技术是有效的，但也证明它是有用的，因为到目前为止， ARPANET 是 “一个没有汽车的高速公路系统”，其五角大楼的资助者希望公开演示能够激发人们对网络的更多兴趣 10。
The scenarios thus showed off a diverse selection of the software that could be accessed over the ARPANET: There were programming language interpreters, one for a Lisp-based language at MIT and another for a numerical computing environment called Speakeasy hosted at UCLA; there were games, including a chess program and an implementation of Conway’s Game of Life; and—perhaps most popular among the conference attendees—there were several AI chat programs, including the famous ELIZA chat program developed at MIT by Joseph Weizenbaum.
因此，这些场景展示了可以通过 ARPANET 访问的各种软件选择：有编程语言解释器，一个用于麻省理工学院基于 Lisp 的语言，另一个用于加州大学洛杉矶分校托管的名为 Speakeasy 的数字计算环境；有游戏，包括国际象棋程序和康威生命游戏的实施；而且 —— 也许在与会者中最受欢迎的是 —— 有几个人工智能聊天程序，包括由约瑟夫・魏森鲍姆（Joseph Weizenbaum）在麻省理工学院开发的著名的 ELIZA 聊天程序。
The researchers who had prepared the scenarios were careful to list each command that users were expected to enter at their terminals. This was especially important because the sequence of commands used to connect to any given ARPANET host could vary depending on the host in question. To experiment with the AI chess program hosted on the MIT Artificial Intelligence Laboratory’s PDP-10 minicomputer, for instance, conference attendees were instructed to enter the following:
准备这些场景的研究人员小心翼翼地列出了用户在其终端上预期输入的每个命令。这一点尤其重要，因为用于连接到任何给定 ARPANET 主机的命令序列可能会因相关主机而异。例如，为了试验在麻省理工学院人工智能实验室的 PDP-10 小型计算机上托管的 AI 国际象棋程序，与会者被指示输入以下内容：
[LF], [SP], and [CR] below stand for the line feed, space, and carriage return keys respectively. I’ve explained each command after //, but this syntax was not used for the annotations in the original.
下面的 [LF]、[SP] 和 [CR] 分别代表换行键、空格键和回车键。我已经解释了 // 之后的每个命令，但这种语法并未用于原始中的注释。
@r [LF] // Reset the TIP
@e [SP] r [LF] // "Echo remote" setting, host echoes characters rather than TIP
@L [SP] 134 [LF] // Connect to host number 134
:login [SP] iccXXX [CR] // Login to the MIT AI Lab's system, where "XXX" should be user's initials
:chess [CR] // Start chess program
If conference attendees were successfully able to enter those commands, their reward was the opportunity to play around with some of the most cutting-edge chess software available at the time, where the layout of the board was represented like this:
如果与会者能够成功输入这些命令，他们的回报就是有机会使用当时可用的一些最前沿的国际象棋软件，其中棋盘的布局如下所示：
BR BN BB BQ BK BB BN BR
BP BP BP BP**BP BP BP
--**--**--**--**
**--**-- BP --**--
--**--**WP**--**
**--**--**--**--
WP WP WP WP -- WP WP WP
WR WN WB WQ WK WB WN WR
In contrast, to connect to UCLA’s IBM System/360 and run the Speakeasy numerical computing environment, conference attendees had to enter the following:
相比之下，要连接到加州大学洛杉矶分校的 IBM System/360 并运行 Speakeasy 数值计算环境，与会者必须输入以下内容：
@r [LF] // Reset the TIP
@t [SP] o [SP] L [LF] // "Transmit on line feed" setting
@i [SP] L [LF] // "Insert line feed" setting, i.e. send line feed with each carriage return
@L [SP] 65 [LF] // Connect to host number 65
tso // Connect to IBM Time-Sharing Option system
logon [SP] icX [CR] // Log in with username, where "X" should be a freely chosen digit
iccc [CR] // This is the password (so secure!)
speakez [CR] // Start Speakeasy
Successfully running that gauntlet gave attendees the power to multiply and transpose and do other operations on matrices as quickly as they could input them at their terminal:
成功运行这个挑战使参与者能够快速地对矩阵进行乘法和转置，并在矩阵上执行其他操作，就像他们可以在终端输入它们一样快：
:+! a=m*transpose (m);a [CR]
:+! eigenvals (a) [CR]
Many of the attendees were impressed by the demonstration, but not for the reasons that we, from our present-day vantage point, might assume. The key piece of context hard to keep in mind today is that, in 1972, being able to use a computer remotely, even from a different city, was not new. Teletype devices had been used to talk to distant computers for decades already. Almost a full five years before the ICCC, Bill Gates was in a Seattle high school using a teletype to run his first BASIC programs on a General Electric computer housed elsewhere in the city. Merely logging in to a host computer and running a few commands or playing a text-based game was routine. The software on display here was pretty neat, but the two scenarios I’ve told you about so far could ostensibly have been experienced without going over the ARPANET.
许多与会者对这次演示印象深刻，但并不是因为我们从今天的角度来看可能会假设的原因。今天难以记住的关键背景是，在 1972 年，能够远程使用计算机，即使是来自不同城市，也不是什么新鲜事。几十年来，电传打字设备一直被用来与远处的计算机交谈。在 ICCC 成立前将近五年，比尔・盖茨（Bill Gates）在西雅图的一所高中使用电传打字机在该市其他地方的通用电气计算机上运行他的第一个 BASIC 程序。登录到主机计算机，运行几个命令或玩一个基于文本的游戏是常规操作。这里展示的软件虽然相当不错，但我刚才提到的两个场景实际上可以在不通过 ARPANET 的情况下体验到。
Of course, something new was happening under the hood. The lawyers, policy-makers, and economists at the ICCC might have been enamored with the clever chess program and the chat bots, but the networking experts would have been more interested in two other scenarios that did a better job of demonstrating what the ARPANET project had achieved.
当然，在背后实际上发生了一些新鲜事。在国际计算机通讯会议（ICCC）上，律师、政策制定者和经济学家们可能对巧妙的象棋程序和聊天机器人感到着迷，但网络专家们更感兴趣的是另外两个场景，这两个场景更好地展示了 ARPANET 项目所取得的成就。
The first of these scenarios involved a program called NETWRK running on MIT’s ITS operating system. The NETWRK command was the entrypoint for several subcommands that could report various aspects of the ARPANET’s operating status. The SURVEY subcommand reported which hosts on the network were functioning and available (they all fit on a single list), while the SUMMARY.OF.SURVEY subcommand aggregated the results of past SURVEY runs to report an “up percentage” for each host as well as how long, on average, it took for each host to respond to messages. The output of the SUMMARY.OF.SURVEY subcommand was a table that looked like this:
第一个场景涉及一个名为 NETWRK 的程序，该程序在麻省理工学院的 ITS 操作系统上运行。NETWRK 命令是多个子命令的入口点，这些子命令可以报告 ARPANET 的各种运行状态。SURVEY 子命令报告网络中哪些主机正在运行并可用（它们都可以放在一个单独的列表中），而 SUMMARY.OF.SURVEY 子命令则汇总过去 SURVEY 运行的结果，报告每个主机的“在线百分比”，以及每个主机平均响应消息所需的时间。SUMMARY.OF.SURVEY 子命令的输出是一张看起来像这样的表格：
--HOST-- -#- -%-UP- -RESP-
UCLA-NMC 001 097% 00.80
SRI-ARC 002 068% 01.23
UCSB-75 003 059% 00.63
...
The host number field, as you can see, has room for no more than three digits (ha!). Other NETWRK subcommands allowed users to look at summary of survey results over a longer historical period or to examine the log of survey results for a single host.
主机编号字段，如您所见，最多只能容纳三位数字（哈哈！）。其他 NETWRK 子命令允许用户查看更长历史时期的调查结果摘要或检查单个主机的调查结果日志。
The second of these scenarios featured a piece of software called the SRI-ARC Online System being developed at Stanford. This was a fancy piece of software with lots of functionality (it was the software system that Douglas Engelbart demoed in the “Mother of All Demos”), but one of the many things it could do was make use of what was essentially a file hosting service run on the host at UC Santa Barbara. From a terminal at the Washington Hilton, conference attendees could copy a file created at Stanford onto the host at UCSB simply by running a copy command and answering a few of the computer’s questions:
第二个场景展示了一款名为 SRI-ARC 在线系统的软件，该系统正在斯坦福大学开发。这是一款功能丰富的高级软件（它是道格拉斯·恩格尔巴特在“所有演示之母”中演示的软件系统），但它能做的众多事情之一是利用本质上由加州大学圣塔芭芭拉分校主办的文件托管服务。在华盛顿希尔顿酒店的终端上，与会者可以通过运行 copy 命令并回答计算机的几个问题，将在斯坦福创建的文件复制到 UCSB 的主机上：
UCSB 是加州大学圣塔芭芭拉分校（University of California, Santa Barbara）的缩写。它是一所位于美国加利福尼亚州圣塔芭芭拉的公立研究大学，隶属于加州大学系统。该校在计算机科学和信息技术等领域拥有重要的贡献。
[ESC], [SP], and [CR] below stand for the escape, space, and carriage return keys respectively. The words in parentheses are prompts printed by the computer. The escape key is used to autocomplete the filename on the third line. The file being copied here is called <system>sample.txt;1, where the trailing one indicates the file’s version number and <system> indicates the directory. This was a convention for filenames used by the TENEX operating system.11
下面的 [ESC]、[SP] 和 [CR] 分别代表 escape、space 和 carriage 返回键。括号内的文字是计算机打印的提示。转义键用于自动完成第三行的文件名。此处复制的文件称为 sample.txt;1，其中尾随的表示文件的版本号， 并指示目录。这是 TENEX 操作系统使用的文件名的约定 11。
@copy
(TO/FROM UCSB) to
(FILE) <system>sample [ESC] .TXT;1 [CR]
(CREATE/REPLACE) create
These two scenarios might not look all that different from the first two, but they were remarkable. They were remarkable because they made it clear that, on the ARPANET, humans could talk to computers but computers could also talk to*each other.*The SURVEY results collected at MIT weren’t collected by a human regularly logging in to each machine to check if it was up—they were collected by a program that knew how to talk to the other machines on the network. Likewise, the file transfer from Stanford to UCSB didn’t involve any humans sitting at terminals at either Stanford or UCSB—the user at a terminal in Washington DC was able to get the two computers to talk each other merely by invoking a piece of software. Even more, it didn’t matter which of the 40 terminals in the Ballroom you were sitting at, because you could view the MIT network monitoring statistics or store files at UCSB using any of the terminals with almost the same sequence of commands.
这两种情况可能看起来与前两种情况没有太大区别，但它们非常了不起。他们之所以引人注目，是因为他们清楚地表明，在 ARPANET 上，人类可以与计算机交谈，但计算机也可以相互交谈。麻省理工学院收集的 SURVEY 结果不是由定期登录到每台机器以检查其是否正常运行的人收集的，它们是由知道如何与网络上的其他机器交谈的程序收集的。同样，从斯坦福大学到 UCSB 的文件传输并不涉及任何在斯坦福大学或 UCSB 终端上的人 —— 华盛顿特区终端的用户仅仅通过调用一个软件就能让两台计算机相互交谈。更重要的是，您在宴会厅的 40 个终端中的哪个终端并不重要，因为您可以使用几乎相同的命令序列查看 MIT 网络监控统计数据或在 UCSB 存储文件。
This is what was totally new about the ARPANET. The ICCC demonstration didn’t just involve a human communicating with a distant computer. It wasn’t just a demonstration of remote I/O. It was a demonstration of software remotely communicating with other software, something nobody had seen before.
这就是 ARPANET 完全新颖之处。ICCC 演示不仅仅涉及人与远程计算机之间的通信。这不仅仅是对远程输入/输出（I/O）的演示。这也是之前没人见过的软件与其他软件远程通信的演示。
To really appreciate why it was this aspect of the ARPANET project that was important and not the wires-across-the-country, physical connection thing that the host maps suggest (the wires were leased phone lines anyhow and were already there!), consider that, before the ARPANET project began in 1966, the ARPA offices in the Pentagon had a terminal room. Inside it were three terminals. Each connected to a different computer; one computer was at MIT, one was at UC Berkeley, and another was in Santa Monica.12 It was convenient for the ARPA staff that they could use these three computers even from Washington DC. But what was inconvenient for them was that they had to buy and maintain terminals from three different manufacturers, remember three different login procedures, and familiarize themselves with three different computing environments in order to use the computers. The terminals might have been right next to each other, but they were merely extensions of the host computing systems on the other end of the wire and operated as differently as the computers did. Communicating with a distant computer was possible before the ARPANET; the problem was that the heterogeneity of computing systems limited how sophisticated the communication could be.
要真正理解为什么 ARPANET 项目的这一方面很重要，而不是主机地图所暗示的全国电线，物理连接的事情（无论如何，电线是租用的电话线，并且已经在那里！），请考虑一下，在 1966 年 ARPANET 项目开始之前，五角大楼的 ARPA 办公室有一个终端室。里面有三个终端。每个都连接到不同的计算机；一台计算机在麻省理工学院，一台在加州大学伯克利分校，另一台在圣莫尼卡。12 ARPA 的工作人员甚至可以在华盛顿特区使用这三台计算机，这非常方便。但对他们来说不方便的是，他们必须购买和维护三个不同制造商的终端，记住三种不同的登录程序，并熟悉三种不同的计算环境才能使用这些计算机。这些终端可能彼此相邻，但它们只是电线另一端的主机计算系统的延伸，其操作方式与计算机一样不同。在 ARPANET 之前，可以与远处的计算机进行通信；问题在于，计算系统的异构性限制了通信的复杂程度。
Come Together, Right Now 现在就走到一起
So what I’m trying to drive home here is that there is an important distinction between statement A, “the ARPANET connected people in different locations via computers for the first time,” and statement B, “the ARPANET connected computer systems to each other for the first time.” That might seem like splitting hairs, but statement A elides some illuminating history in a way that statement B does not.
我想强调的是，陈述 A “ARPANET 首次通过计算机将不同地点的人连接起来”与陈述 B “ARPANET 首次将计算机系统彼此连接起来”之间有一个重要的区别。乍看之下，这似乎是在纠缠细节，但陈述 A 在某种程度上忽略了一些启发性的历史，而陈述 B 则没有。
To begin with, the historian Joy Lisi Rankin has shown that people were socializing in cyberspace well before the ARPANET came along. In A People’s History of Computing in the United States, she describes several different digital communities that existed across the country on time-sharing networks prior to or apart from the ARPANET. These time-sharing networks were not, technically speaking, computer networks, since they consisted of a single mainframe computer running computations in a basement somewhere for many dumb terminals, like some portly chthonic creature with tentacles sprawling across the country. But they nevertheless enabled most of the social behavior now connoted by the word “network” in a post-Facebook world. For example, on the Kiewit Network, which was an extension of the Dartmouth Time-Sharing System to colleges and high schools across the Northeast, high school students collaboratively maintained a “gossip file” that allowed them to keep track of the exciting goings-on at other schools, “creating social connections from Connecticut to Maine.”13 Meanwhile, women at Mount Holyoke College corresponded with men at Dartmouth over the network, perhaps to arrange dates or keep in touch with boyfriends.14 This was all happening in the 1960s. Rankin argues that by ignoring these early time-sharing networks we impoverish our understanding of how American digital culture developed over the last 50 years, leaving room for a “Silicon Valley mythology” that credits everything to the individual genius of a select few founding fathers.
首先，历史学家 Joy Lisi Rankin 表明，在 ARPANET 出现之前，人们已经在网络空间中进行社交活动。在她的著作《A People’s History of Computing in United States》中，她描述了许多在 ARPANET 之前或之外存在的数字社区，这些社区分布在全国范围内的时间共享网络上。从技术上来说，这些时间共享网络并不是计算机网络，因为它们由一台位于某个地下室的主机计算机运行计算，为许多简单终端提供服务，就像某种肥胖的地下生物，其触手遍布全国。但尽管如此，它们仍然使得大多数在 Facebook 后时代与“网络”一词相关联的社会行为成为可能。例如，在 Kiewit 网络上，这是达特茅斯时间共享系统扩展到东北地区各大高校和高中的一个项目，高中生们共同维护了一个“八卦文件”，让他们能够跟踪其他学校的有趣动态， “从康涅狄格州到缅因州建立了社会联系。”与此同时，霍利奥克学院的女性通过这个网络与达特茅斯的男性沟通，也许是为了安排约会或保持与男友的联系。这一切发生在 1960 年代。Rankin 认为，忽视这些早期的时间共享网络将使我们对过去 50 年美国数字文化的发展理解变得贫乏，从而为一种“硅谷神话”留下了空间，这种神话将一切都归功于少数创始人的个人天才。
As for the ARPANET itself, if we recognize that the key challenge was connecting the computer systems and not just the physical computers, then that might change what we choose to emphasize when we tell the story of the innovations that made the ARPANET possible. The ARPANET was the first ever packet-switched network, and lots of impressive engineering went into making that happen. I think it’s a mistake, though, to say that the ARPANET was a breakthrough because it was the first packet-switched network and then leave it at that. The ARPANET was meant to make it easier for computer scientists across the country to collaborate; that project was as much about figuring out how different operating systems and programs written in different languages would interface with each other than it was about figuring out how to efficiently ferry data back and forth between Massachusetts and California. So the ARPANET was the first packet-switched network, but it was also an amazing standards success story—something I find especially interesting given how many times I’ve written about failed standards on this blog.
至于 ARPANET 本身，如果我们认识到关键的挑战是连接计算机系统，而不仅仅是物理计算机，那么这可能会改变我们在讲述使 ARPANET 成为可能的创新故事时选择强调的内容。ARPANET 是有史以来第一个分组交换网络，为了实现这一目标，我们付出了许多令人印象深刻的工程设计。然而，我认为说 ARPANET 是一个突破，仅仅因为它是第一个分组交换网络，这样的看法是错误的。ARPANET 旨在让全国各地的计算机科学家更容易合作；该项目不仅涉及如何有效地在马萨诸塞州和加利福尼亚州之间传输数据，还涉及弄清楚用不同语言编写的不同操作系统和程序如何相互交互。因此，ARPANET 是第一个分组交换网络，但它也是一个了不起的标准成功故事。
Inventing the protocols for the ARPANET was an afterthought even at the time, so naturally the job fell to a group made up largely of graduate students. This group, later known as the Network Working Group, met for the first time at UC Santa Barbara in August of 1968.15 There were 12 people present at that first meeting, most of whom were representatives from the four universities that were to be the first host sites on the ARPANET when the equipment was ready.16 Steve Crocker, then a graduate student at UCLA, attended; he told me over a Zoom call that it was all young guys at that first meeting, and that Elmer Shapiro, who chaired the meeting, was probably the oldest one there at around 38. ARPA had not put anyone in charge of figuring out how the computers would communicate once they were connected, but it was obvious that some coordination was necessary. As the group continued to meet, Crocker kept expecting some “legitimate adult” with more experience and authority to fly out from the East Coast to take over, but that never happened. The Network Working Group had ARPA’s tacit approval—all those meetings involved lots of long road trips, and ARPA money covered the travel expenses—so they were it.17
即使在当时，发明 ARPANET 的协议也是事后才想到的，因此这项工作自然而然地落在了一个主要由研究生组成的团队身上。该小组，后来被称为网络工作组，于 1968 年 8 月在加州大学圣巴巴拉分校首次会面.15 有 12 人出席了第一次会议，其中大多数是将成为 ARPANET 首批主机站的四所大学的代表，当设备准备就绪时，这些大学将成为 ARPANET 的第一批主办站点.[16] 史蒂夫・克罗克， 当时是 UCLA 的研究生，也参加了这次会议。他在 Zoom 电话中告诉我，第一次会议都是年轻人，主持会议的埃尔默・夏皮罗（Elmer Shapiro）可能是那里年龄最大的人，大约 38 岁。ARPA 没有让任何人负责弄清楚计算机一旦连接后将如何通信，但很明显，一些协调是必要的。随着小组继续会面，克罗克一直期待一些具有更多经验和权威的 “合法成年人” 从东海岸飞过来接管，但这从未发生过。网络工作组得到了 ARPA 的默许 —— 所有这些会议都涉及大量的长途旅行，而 ARPA 的资金覆盖了旅行费用——所以他们就是负责这项工作的团队 17。
The Network Working Group faced a huge challenge. Nobody had ever sat down to connect computer systems together in a general-purpose way; that flew against all of the assumptions that prevailed in computing in the late 1960s:
网络工作组面临着巨大的挑战。从来没有人坐下来以一种通用的方式将计算机系统连接在一起；这与 1960 年代后期计算领域盛行的所有假设背道而驰：
The typical mainframe of the period behaved as if it were the only computer in the universe. There was no obvious or easy way to engage two diverse machines in even the minimal communication needed to move bits back and forth. You could connect machines, but once connected, what would they say to each other? In those days a computer interacted with devices that were attached to it, like a monarch communicating with his subjects. Everything connected to the main computer performed a specific task, and each peripheral device was presumed to be ready at all times for a fetch-my-slippers type command…. Computers were strictly designed for this kind of interaction; they send instructions to subordinate card readers, terminals, and tape units, and they initiate all dialogues. But if another device in effect tapped the computer on the shoulder with a signal and said, “Hi, I’m a computer too,” the receiving machine would be stumped.18
那个时期的典型主机表现得好像它是宇宙中唯一的计算机。没有明显或简单的方法可以让两台不同的机器参与进来，即使是来回移动比特所需的最小通信。你可以连接机器，但一旦连接，它们会对彼此说什么？在那些日子里，计算机与连接到它的设备进行交互，就像君主与他的臣民交流一样。连接到主计算机的所有设备都执行了特定的任务，并且假定每个外围设备都已准备好执行 fetch-my-slippers 类型的命令。计算机是严格为这种交互而设计的；它们向从属读卡器、终端和磁带单元发送指令，并启动所有对话。但是，如果另一台设备实际上用信号轻拍计算机的肩膀并说：“嗨，我也是一台计算机”，那么接收机就会被困惑不已 18。
As a result, the Network Working Group’s progress was initially slow.19 The group did not settle on an “official” specification for any protocol until June, 1970, nearly two years after the group’s first meeting.20
因此，网络工作组的进展最初非常缓慢。19 该小组直到 1970 年 6 月才确定任何协议的“官方”规范，这距离小组首次会议已经过去了将近两年。20
But by the time the ARPANET was to be shown off at the 1972 ICCC, all the key protocols were in place. A scenario like the chess scenario exercised many of them. When a user ran the command @e r, short for @echo remote, that instructed the TIP to make use of a facility in the new TELNET virtual teletype protocol to inform the remote host that it should echo the user’s input. When a user then ran the command @L 134, short for @login 134, that caused the TIP to invoke the Initial Connection Protocol with host 134, which in turn would cause the remote host to allocate all the necessary resources for the connection and drop the user into a TELNET session. (The file transfer scenario I described may well have made use of the File Transfer Protocol, though that protocol was only ready shortly before the conference.21) All of these protocols were known as “level three” protocols, and below them were the host-to-host protocol at level two (which defined the basic format for the messages the hosts should expect from each other), and the host-to-IMP protocol at level one (which defined how hosts communicated with the routing equipment they were linked to). Incredibly, the protocols all worked.
但是，当 ARPANET 在 1972 年的 ICCC 上展示时，所有关键协议都已到位。像国际象棋这样的场景锻炼了他们中的许多人。当用户运行命令 @e r（@echo remote 的缩写）时，该命令指示 TIP 使用新的 TELNET 虚拟电传打字协议中的设施来通知远程主机它应回显用户的输入。当用户随后运行命令 @L 134（@login 134 的缩写）时，这会导致 TIP 调用与主机 134 的初始连接协议，这反过来会导致远程主机为连接分配所有必要的资源，并将用户置于 TELNET 会话中。（我所描述的文件传输方案很可能使用了文件传输协议，尽管该协议在会议召开前不久才准备就绪 21。所有这些协议都被称为 “第三级” 协议，在它们之后是第二级的主机到主机协议（定义了主机之间应相互期望的消息的基本格式）和第一级的主机到 IMP 协议（定义了主机如何与它们所链接的路由设备进行通信）。令人难以置信的是，这些协议都奏效了。
In my view, the Network Working Group was able to get everything together in time and just generally excel at its task because it adopted an open and informal approach to standardization, as exemplified by the famous Request for Comments (RFC) series of documents. These documents, originally circulated among the members of the Network Working Group by snail mail, were a way of keeping in touch between meetings and soliciting feedback to ideas. The “Request for Comments” framing was suggested by Steve Crocker, who authored the first RFC and supervised the RFC mailing list in the early years, in an attempt to emphasize the open-ended and collaborative nature of what the group was trying to do. That framing, and the availability of the documents themselves, made the protocol design process into a melting pot of contributions and riffs on other people’s contributions where the best ideas could emerge without anyone losing face. The RFC process was a smashing success and is still used to specify internet standards today, half a century later.
在我看来，网络工作组能够及时将所有内容整合在一起，并且总体上在其任务中表现出色，因为它采用了一种开放和非正式的标准化方法，著名的征求意见 （RFC） 系列文件就是例证。这些文件最初是通过蜗牛邮件在网络工作组成员之间分发的，是在会议之间保持联系和征求对想法的反馈的一种方式。“征求意见” 的框架是由史蒂夫・克罗克（Steve Crocker）提出的，他撰写了第一个 RFC，并在早期监督了 RFC 邮件列表，试图强调该小组试图做的事情的开放式和协作性。这种框架，以及文件本身的可用性，使协议设计过程变成了一个贡献和重复他人贡献的大熔炉，最好的想法可以在不让任何人丢脸的情况下出现。RFC 过程取得了巨大的成功，半个世纪后的今天，它仍然被用来指定互联网标准。
It’s this legacy of the Network Working Group that I think we should highlight when we talk about ARPANET’s impact. Though today one of the most magical things about the internet is that it can connect us with people on the other side of the planet, it’s only slightly facetious to say that that technology has been with us since the 19th century. Physical distance was conquered well before the ARPANET by the telegraph. The kind of distance conquered by the ARPANET was instead the logical distance between the operating systems, character codes, programming languages, and organizational policies employed at each host site. Implementing the first packet-switched network was of course a major feat of engineering that should also be mentioned, but the problem of agreeing on standards to connect computers that had never been designed to play nice with each other was the harder of the two big problems involved in building the ARPANET—and its solution was the most miraculous part of the ARPANET story.
我认为，当我们谈论 ARPANET 的影响时，应该强调网络工作组的遗产。虽然今天互联网最神奇的事情之一是它能让我们与地球另一端的人连接，但稍微有点滑稽地说，这项技术自 19 世纪以来就已经存在。物理距离在 ARPANET 之前就被电报征服了。ARPANET 征服的则是各主机站所采用的操作系统、字符编码、编程语言和组织政策之间的逻辑距离。实现第一个分组交换网络当然是一项重大的工程壮举，也应当提及，但达成标准以连接那些从未设计过以友好方式进行交互的计算机，是构建 ARPANET 所涉及的两个重大问题中更为困难的，而其解决方案则是 ARPANET 故事中最神奇的部分。
In 1981, ARPA issued a “Completion Report” reviewing the first decade of the ARPANET’s history. In a section with the belabored title, “Technical Aspects of the Effort Which Were Successful and Aspects of the Effort Which Did Not Materialize as Originally Envisaged,” the authors wrote:
1981 年，ARPA 发布了一份 “完成报告”，回顾了 ARPANET 历史上的第一个十年。在标题为 “Technical Aspects of the Effort Which Were Successful and Aspects of the Effort Which Did Not Materialize as Originally Envisaged” 的一节中，作者写道：
Possibly the most difficult task undertaken in the development of the ARPANET was the attempt—which proved successful—to make a number of independent host computer systems of varying manufacture, and varying operating systems within a single manufactured type, communicate with each other despite their diverse characteristics.22
在开发 ARPANET 的过程中，最艰巨的任务可能是尝试（事实证明是成功的），即使许多不同制造的独立主机系统，以及单一制造类型中的不同操作系统，尽管它们具有不同的特性，但可以相互通信 22。
There you have it from no less a source than the federal government of the United States.
这就是来自不亚于美国联邦政府官方的信息。
istory (@TwoBitHistory) June 28, 2020
- “Hilton Hotel Opens in Capital Today.”The New York Times, 20 March 1965, https://www.nytimes.com/1965/03/20/archives/hilton-hotel-opens-in-capital-today.html?searchResultPosition=1. Accessed 7 Feb. 2021.
- James Pelkey.*Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968-1988,*Chapter 4, Section 12, 2007, [http://www.historyofcomputercommunications.info/Book/4/4.12-ICCC%20Demonstration71-72.html](http://www.historyofcomputercommunications.info/Book/4/4.12-ICCC Demonstration71-72.html). Accessed 7 Feb. 2021.
- Katie Hafner and Matthew Lyon.Where Wizards Stay Up Late: The Origins of the Internet. New York, Simon & Schuster, 1996, p. 178.
- “International Conference on Computer Communication.”Computer, vol. 5, no. 4, 1972, p. c2, https://www.computer.org/csdl/magazine/co/1972/04/01641562/13rRUxNmPIA. Accessed 7 Feb. 2021.
- “Program for the International Conference on Computer Communication.”The Papers of Clay T. Whitehead, Box 42, https://d3so5znv45ku4h.cloudfront.net/Box+042/013_Speech-International+Conference+on+Computer+Communications,+Washington,+DC,+October+24,+1972.pdf. Accessed 7 Feb. 2021.
- It’s actually not clear to me which room was used for the ARPANET demonstration. Lots of sources talk about a “ballroom,” but the Washington Hilton seems to consider the room with the name “Georgetown” more of a meeting room. So perhaps the demonstration was in the International Ballroom instead. But RFC 372 alludes to a booking of the “Georgetown Ballroom” for the demonstration. A floorplan of the Washington Hilton can be found here.
- Hafner, p. 179.
- ibid., p. 178.
- Bob Metcalfe. “Scenarios for Using the ARPANET.” Collections-Computer History Museum, https://www.computerhistory.org/collections/catalog/102784024. Accessed 7 Feb. 2021.
- Hafner, p. 176.
- Robert H. Thomas. “Planning for ACCAT Remote Site Operations.” BBN Report No. 3677, October 1977, https://apps.dtic.mil/sti/pdfs/ADA046366.pdf. Accessed 7 Feb. 2021.
- Hafner, p. 12.
- Joy Lisi Rankin.A People’s History of Computing in the United States. Cambridge, MA, Harvard University Press, 2018, p. 84.
- Rankin, p. 93.
- Steve Crocker. Personal interview. 17 Dec. 2020.
- Crocker sent me the minutes for this meeting. The document lists everyone who attended.
- Steve Crocker. Personal interview.
- Hafner, p. 146.
- “Completion Report / A History of the ARPANET: The First Decade.” BBN Report No. 4799, April 1981, https://walden-family.com/bbn/arpanet-completion-report.pdf, p. II-13.
- I’m referring here to RFC 54, “Official Protocol Proffering.”
- Hafner, p. 175.
- “Completion Report / A History of the ARPANET: The First Decade,” p. II-29.
via：
-
How the ARPANET Protocols Worked
-
The Real Novelty of the ARPANET
4 Ways To Check Uptime of Apache Web Server (httpd) on Linux
Linux 操作系统下检查 Apache Web Server (httpd) 正常运行时间的 4 种方法
November 28, 2019 - by Magesh Maruthamuthu
We all know about the purpose of**uptime command**in Linux.
我们都知道 Linux 中 uptime 命令的目的。
It is used to check the uptime of the Linux system, how long the system has been running without restarting.
它用于检查 Linux 系统的正常运行时间，系统在不重新启动的情况下运行了多长时间。
If you want to check other service uptime like Apache, MySQL, sftp, etc. on Linux, how do you do that?
如果您想在 Linux 上检查其他服务的正常运行时间，如 Apache、MySQL、sftp 等，您该怎么做？
Each service has their own command to check the service uptime.
每个服务都有自己的命令来检查服务正常运行时间。
Also, we can check the service uptime using the**ps command**because there are many options to collect this information.
此外，我们可以使用 ps 命令检查服务正常运行时间，因为有很多选项可以收集此信息。
It shows when the parent process started (which I say when it restarts or starts) and how long the service runs with the [DD:HH:MM:SS] format.
它显示父进程的启动时间（我说的是它重新启动或启动的时间）以及服务以 [DD:HH:MM:SS] 格式运行的时间。
In this tutorial, we are going to show you how to check**Apache web server**uptime using different method.
在本教程中，我们将向您展示如何使用不同的方法检查 Apache Web 服务器的正常运行时间。
This is a small tutorial and very useful if you want to get Apache web server uptime for some reason.
这是一个小教程，如果您出于某种原因想要获得 Apache Web 服务器的正常运行时间，则非常有用。
This can be done using the following 4 methods.
这可以使用以下 4 种方法完成。
- Apache mod_status module
- ps command ps
- systemctl command systemctl
- proc filesystem (procfs)
Method-1: How to Check Apache (httpd) Web Server Uptime Using mod_status Module on Linux
方法 1：如何在 Linux 上使用 mod_status 模块检查 Apache （httpd） Web 服务器的正常运行时间
The Apache mode_status module allows a server administrator to check Apache Web server uptime, concurrent connections, and server performance with a given interval through the CLI and GUI.
Apache mode_status 模块允许服务器管理员通过 CLI 和 GUI 在给定的时间间隔内检查 Apache Web 服务器的正常运行时间、并发连接和服务器性能。
However, it is disabled by default and must be enabled to use the feature.
但是，默认情况下，它是禁用的，必须启用才能使用该功能。
The Apache “mod_status” module displays the following useful information about the Apache Web server.
Apache “mod_status” 模块显示以下有关 Apache Web 服务器的有用信息。
- Apache Web server built & version information
Apache Web 服务器构建和版本信息 - Web server last restart & uptime information
Web 服务器上次重启和正常运行时间信息 - Total number of incoming requests
传入请求总数 - Idle workers 空闲 worker
- Server load & Web server CPU usage
服务器负载和 Web 服务器 CPU 使用率 - Total traffic (Bandwidth usage)
总流量（带宽使用量） - Average number of requests per second
每秒平均请求数 - Average number of bytes per request
每个请求的平均字节数 - Number of bytes served per second
每秒提供的字节数 - How many requests currently being processed
当前正在处理的请求数 - Details about running process
有关正在运行的进程的详细信息
How to Install and Enable Apache’s mod_status Module on Linux
如何在 Linux 上安装和启用 Apache 的 mod_status 模块
By default, the Apache “mod_status” module is installed on Apache. But reports are disabled and you have to uncomment it to access it. To do so, you need to uncomment the codes below in your Apache configuration file based on your distribution.
默认情况下，Apache “mod_status” 模块安装在 Apache 上。但是报表被禁用，您必须取消注释才能访问它。为此，您需要根据您的分配在 Apache 配置文件中取消注释以下代码。
See the following article if you want to**verify the Apache web server performance using the mod_status module**.
如果要使用 mod_status 模块验证 Apache Web 服务器性能，请参阅以下文章。
For**RHEL/CentOS/Fedora**systems, open the /etc/httpd/conf/httpd.conf file and uncomment the below codes.
对于 RHEL/CentOS/Fedora 系统，请打开 /etc/httpd/conf/httpd.conf 文件并取消注释以下代码。
[For Apache 2.2]
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from all
</Location>
[For Apache 2.4]
<Location "/server-status">
SetHandler server-status
Require host localhost
</Location>
For**Debian/Ubuntu**systems, open /etc/apache2/mods-enabled/status.conf file and uncomment the below codes.
对于 Debian/Ubuntu 系统，请打开 /etc/apache2/mods-enabled/status.conf 文件并取消注释以下代码。
<Location "/server-status">
SetHandler server-status
Require local
#Require ip 192.0.2.024
</Location>
Save and close the file and restart the Apache web server service.
保存并关闭文件，然后重新启动 Apache Web 服务器服务。
Use the below commands to**restart the Apache (httpd) server in Linux**.
使用以下命令在 Linux 中重新启动 Apache （httpd） 服务器。
For SysVinit Systems – openSUSE & Debian based systems.
对于 SysVinit 系统 – 基于 openSUSE & Debian 的系统。
# service apache2 restart
or
# /etc/init.d/apache2 restart
For SysVinit Systems – RHEL (RedHat) based systems.
对于 SysVinit 系统 – 基于 RHEL (RedHat) 的系统。
# service httpd restart
or
# /etc/init.d/httpd restart
For systemd Systems – openSUSE & Debian based systems.
对于 systemd 系统 – 基于 openSUSE & Debian 的系统。
# systemctl restart apache2.service
or
# systemctl restart apache2
For systemd Systems – RHEL (RedHat) based systems.
对于 systemd 系统 – 基于 RHEL (RedHat) 的系统。
# systemctl restart httpd
or
# systemctl restart httpd.service
Run the following command to get the Apache uptime.
运行以下命令以获取 Apache 正常运行时间。
$ apachectl status
Apache Server Status for localhost (via 127.0.0.1)
Server Version: Apache/2.4.29 (Ubuntu)
Server MPM: prefork
Server Built: 2019-09-16T12:58:48
--------------------------------------------------------------------------
Current Time: Wednesday, 27-Nov-2019 13:06:03 IST
Restart Time: Wednesday, 27-Nov-2019 12:24:26 IST
Parent Server Config. Generation: 2
Parent Server MPM Generation: 1
Server uptime: 41 minutes 36 seconds
Server load: 0.00 0.02 0.14
Total accesses: 8 - Total Traffic: 88 kB
CPU Usage: u0 s0 cu0 cs0
.00321 requests/sec - 36 B/second - 11.0 kB/request
1 requests currently being processed, 4 idle workers
__W__...........................................................
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process
Alternatively, you can run this command using a**Linux text-based browser**.
或者，您也可以使用基于 Linux 文本的浏览器运行此命令。
$ elinks http://localhost/server-status
Apache uptime with page refresh every N seconds.
Apache 正常运行时间，每 N 秒刷新一次页面。
$ elinks http://localhost/server-status?refresh=5
Method-2: How to Check Apache (httpd) Web Server Uptime Using the ps Command on
Linux 方法 2：如何在 Linux 上使用 ps 命令检查 Apache （httpd） Web 服务器的正常运行时间
The ps command displays information about a selection of the active processes. It displays the process ID (pid=PID), the terminal associated with the process (tname=TTY), the cumulated CPU time in [DD-] hh:mm:ss format (time=TIME), and the executable name (ucmd=CMD). Output is unsorted by default.
ps 命令显示有关所选活动进程的信息。它显示进程 ID （pid=PID）、与进程关联的终端 （tname=TTY）、[DD-] hh：mm：ss 格式的累积 CPU 时间 （time=TIME） 和可执行文件名称 （ucmd=CMD）。默认情况下，输出未排序。
To do so, you need to**find the PID of the Apache process**, and it can be easily identified using the pidof command.
为此，您需要找到 Apache 进程的 PID，并且可以使用 pidof 命令轻松识别它。
For RPM based systems:
对于基于 RPM 的系统：
# pgrep httpd | head -1
10915
For DEB based systems:
对于基于 DEB 的系统：
# pgrep apache2 | head -1
1111
Once you get the Apache PID, use the following command to get it.
获取 Apache PID 后，使用以下命令获取它。
# ps -p 10915 -o etime
ELAPSED
05:59:59
The above output shows the elapsed time since the process was started. As per the above output, it’s up and running 5 hours, 59 mins, and 59 sec.
上述输出显示自进程启动以来经过的时间。根据上述输出，它已启动并运行 5 hours, 59 mins, and 59 sec。
Method-3: How to Check Apache (httpd) Web Server Uptime Using the systemctl Command on Linux
方法 3：如何在 Linux 上使用 systemctl 命令检查 Apache （httpd） Web 服务器的正常运行时间
The**systemctl command**is used to control the systemd service manager. This is a replacement for the old SysVinit system management, and most of the modern Linux operating systems have been moved to the systemd.
systemctl 命令用于控制 systemd 服务管理器。这是旧 SysVinit 系统管理的替代品，大多数现代 Linux 操作系统已迁移到 systemd。
# systemctl status httpd
● httpd.service - Web server Apache
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2019-11-27 03:43:37 UTC; 5h 50min ago
Process: 10907 ExecStop=/usr/local/apache/bin/apachectl graceful-stop (code=exited, status=0/SUCCESS)
Process: 11025 ExecReload=/usr/local/apache/bin/apachectl graceful (code=exited, status=0/SUCCESS)
Process: 10912 ExecStart=/usr/local/apache/bin/apachectl start (code=exited, status=0/SUCCESS)
Main PID: 10915 (httpd)
CGroup: /system.slice/httpd.service
├─10915 /usr/local/apache/bin/httpd -k start
├─11082 /usr/local/apache/bin/httpd -k start
├─11083 /usr/local/apache/bin/httpd -k start
├─11084 /usr/local/apache/bin/httpd -k start
└─11681 /usr/local/apache/bin/httpd -k start
Nov 27 03:43:37 ns1.nsforcdn.com systemd [1]: Started Web server Apache.
Nov 27 03:43:38 ns1.nsforcdn.com systemd [1]: Reloading Web server Apache.
Nov 27 03:43:38 ns1.nsforcdn.com apachectl [11025]: AH00112: Warning: DocumentRoot [/home/nowdigitaleasy/public_html/billing] does not exist
Nov 27 03:43:38 ns1.nsforcdn.com apachectl [11025]: AH00112: Warning: DocumentRoot [/home/nowdigitaleasy/public_html/billing] does not exist
Nov 27 03:43:38 ns1.nsforcdn.com apachectl [11025]: AH00112: Warning: DocumentRoot [/home/nutechnologyinc/public_html/poc.nutechnologyinc.com] does not exist
Nov 27 03:43:38 ns1.nsforcdn.com apachectl [11025]: AH00112: Warning: DocumentRoot [/home/witskills/public_html] does not exist
Nov 27 03:43:38 ns1.nsforcdn.com apachectl [11025]: AH00112: Warning: DocumentRoot [/home/witskills/public_html] does not exist
Nov 27 03:43:38 ns1.nsforcdn.com systemd [1]: Reloaded Web server Apache.
Hint: Some lines were ellipsized, use -l to show in full.
Method-4: How to Check Apache (httpd) Web Server Uptime Using the proc filesystem (procfs) on Linux
方法 4：如何在 Linux 上使用 proc 文件系统 （procfs）检查 Apache （httpd） Web 服务器的正常运行时间
The proc filesystem (procfs) is a special filesystem in Unix-like operating systems that presents information about processes and other system information.
proc 文件系统 （procfs） 是类 Unix 操作系统中的一种特殊文件系统，用于显示有关进程的信息和其他系统信息。
It’s sometimes referred to as a process information pseudo-file system. It doesn’t contain ‘real’ files but run time system information (e.g. system memory, devices mounted, hardware configuration, etc).
它有时称为进程信息伪文件系统。它不包含 “真实” 文件，而是运行时系统信息（例如系统内存、挂载的设备、硬件配置等）。
Once you have Apache PID, use the following proc file system to identify it. As per the below output the httpd process has been running since**Aug 05 at 17:20**.
拥有 Apache PID 后，请使用以下 proc 文件系统来识别它。根据以下输出，httpd 进程自 8 月 5 日 17：20 以来一直在运行。
# ls -ld /proc/10915
dr-xr-xr-x. 9 root root 0 Aug 5 17:20 /proc/10915/
via：
-
4 Ways To Check Uptime of Apache Web Server (httpd) on Linux | 2DayGeek
https://www.2daygeek.com/check-find-apache-httpd-web-server-uptime-linux/
扫一扫
572
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
