PRF

FIN
@Lin-vy 翻译的不错！

translated/talk/20210308 How the ARPANET Protocols Worked.md

@@ -10,6 +10,8 @@
 ARPANET 协议是如何工作的
 ======
 
+![](https://img.linux.net.cn/data/attachment/album/202108/03/130239ybmxjmixx3xbx7ix.jpg)
+
 ARPANET 通过证明可以使用标准化协议连接完全不同的制造商的计算机，永远改变了计算。在我的 [关于 ARPANET 的历史意义的文章][1] 中，我提到了其中的一些协议，但没有详细描述它们。所以我想仔细看看它们。也想看看那些早期协议的设计有多少保留到了我们今天使用的协议中。
 
 ARPANET 协议像我们现代的互联网协议，是通过分层形式来组织的。[^1] 较高层协议运行在较低层协议之上。如今的 TCP/IP 套件有 5 层（物理层、链路层、网络层、传输层以及应用层），但是这个 ARPANET 仅有 3 层，也可能是 4 层，这取决于你怎样计算它们。
@@ -52,15 +54,15 @@ Host-Host 控制消息一般通过 3 个字母的助记符来表示。当两个
 
 更高级别的协议都位于 “Level 3”，这层是 ARPANET 的应用层。Telnet 协议，它提供到另一台主机的一个虚拟电传链接，其可能是这些协议中最重要的。但在这层中也有许多其他协议，例如用于传输文件的 FTP 协议和各种用于发送 Email 的协议实验。
 
-在这一层中有一个不同于其他的协议：初始链接协议（ICP）。ICP被认为是一个 “ level-3 ” 层协议，但实际上它是一种 “ level-2.5 ” 层协议，因为其他 “ level-3 ” 层协议都依赖它。ICP的存在是因为 “ level 2 ” 层的 Host-Host 协议提供的链接只是单向的，但大多数的应用需要一个双向（列如：全双工）的链接来做任何有趣的事情。要使得运行在某个主机上的客户端能够链接到另一个主机上长时间运行的服务进程， ICP 定义了两个步骤。第一步是建立一个从服务端到客户端的单向链接，通过使用服务端进程的众所周知的 socket 号来实现。第二步服务端通过建立的这个链接发送一个新的 socket 号给客户端。到那时，那个存在的链接就会被丢弃，然后有另外两个新的链接会被开启，它们是基于传输的 socket 号建立的“读”链接和基于传输的 socket 号加 1 的 “ 写 ” 链接。这个小插曲是大多数事务的一个前提——比如它是建立 Telnet 链接的第一步。
+在这一层中有一个不同于其他的协议：<ruby>初始链接协议<rt>Initial Connection Protocol</rt></ruby>（ICP）。ICP 被认为是一个 “Level-3” 层协议，但实际上它是一种 “Level-2.5” 层协议，因为其他 “Level-3” 层协议都依赖它。之所以需要 ICP，是因为 “Level 2” 层的 Host-Host 协议提供的链接只是单向的，但大多数的应用需要一个双向（例如：全双工）的连接来做任何有趣的事情。要使得运行在某个主机上的客户端能够连接到另一个主机上的长期运行的服务进程，ICP 定义了两个步骤。第一步是建立一个从服务端到客户端的单向连接，通过使用服务端进程的众所周知的套接字号来实现。第二步服务端通过建立的这个连接发送一个新的套接字套接字号给客户端。到那时，那个存在的连接就会被丢弃，然后会打开另外两个新的连接，它们是基于传输的套接字号建立的“读”连接和基于传输的套接字号加 1 的“写”连接。这个小插曲是大多数事务的一个前提——比如它是建立 Telnet 链接的第一步。
 
-以上是我们对 ARPANET 协议层次结构的提升。你们可能一直期待我在某个时候提一下 “ Network Control Protocol ” 。在我坐下来去研究这篇贴子和我的最后一篇贴子之前，我坚定的认为 ARPANET 运行在一个叫做 NCP 的协议之上。那个首字母缩略词有时用来指代整个 ARPANET 协议，这可能就是我为什么有这个想法的原因。举个例子，[RFC801][11] 讨论了将 ARPANET 从 “  NCP ” 过渡到 “ TCP ” 的方式，这使 NCP 听起来像是一个等同TCP的 ARPANET 协议。但是对于 ARPANET 来说，从来都没有一个叫 “ Network Control Protocol ” 的东西（即使[大英百科全书是这样认为的][12]），我怀疑人们错误地将 “ NCP ” 解释为 “ Network Control Protocol ” ，而实际上它代表的是 “ Network Control Pragram ” 。网络控制程序是一个运行在各个主机上的内核级别的程序，主要负责处理网络通信，等同于现如今操作系统中的 TCP/IP 协议栈。用在 RFC 801 的 “ NCP ” 是一种转喻，而不是协议。
+以上是我们逐层攀登了 ARPANET 协议层次结构。你们可能一直期待我在某个时候提一下 “<ruby>网络控制协议<rt>Network Control Protocol</rt></ruby>”（NCP） 。在我坐下来为这篇文章和上一篇文章做研究之前，我肯定认为 ARPANET 运行在一个叫 “NCP” 的协议之上。这个缩写有时用来指代整个 ARPANET 协议，这可能就是我为什么有这个想法的原因。举个例子，[RFC801][11] 讨论了将 ARPANET 从 “NCP” 过渡到 “TCP” 的方式，这使 NCP 听起来像是一个相当于 TCP 的 ARPANET 协议。但是对于 ARPANET 来说，从来都没有一个叫 “网络控制协议” 的东西（即使 [大英百科全书是这样认为的][12]），我怀疑人们错误地将 “NCP” 解释为 “<ruby>网络控制协议<rt>Network Control Protocol</rt></ruby>” ，而实际上它代表的是 “<ruby>网络控制程序<rt>Network Control Program</rt></ruby>” 。网络控制程序是一个运行在各个主机上的内核级别的程序，主要负责处理网络通信，等同于现如今操作系统中的 TCP/IP 协议栈。用在 RFC 801 的 “NCP” 是一种转喻，而不是协议。
 
-### 与TCP/IP的比较
+### 与 TCP/IP 的比较
 
-ARPANET 协议以后都会被 TCP/IP 协议替换（但 Telnet 和 FTP 协议除外，因为它们很容易就能在 TCP 上适配运行）。然而 ARPANET 协议都基于这么一个假设就是网络是由一个单一实体（BBN）来构建和管理的。 TCP/IP 协议套件是为具有可变性和不可靠性的互联的网络而设计的。这就导致了现代协议套件和 ARPANET 协议有明显的不同，比如我们现在怎样区分网络层和传输层。在 ARPANET 中部分由 IMP 实现的类似传输层的功能现在完全由在网络边界的主机负责。
+ARPANET 协议以后都会被 TCP/IP 协议替换（但 Telnet 和 FTP 协议除外，因为它们很容易就能在 TCP 上适配运行）。然而 ARPANET 协议都基于这么一个假设：就是网络是由一个单一实体（BBN）来构建和管理的。而 TCP/IP 协议套件是为网间网设计的，这是一个网络的网络，在那里一切都是不稳定的和不可靠的。这就导致了我们的现代协议套件和 ARPANET 协议有明显的不同，比如我们现在怎样区分网络层和传输层。在 ARPANET 中部分由 IMP 实现的类似传输层的功能现在完全由在网络边界的主机负责。
 
-我发现关于ARPANET协议最有趣的事情是现在在 TCP 中的传输层的功能有多少在 ARPANET 上经历了一个糟糕的青春期。我不是一个网络专家，因此我拿出大学时的网络课本（Kurose and Ross, let’s go），他们对传输层通常负责什么给出了一个非常好的概述。总结一下他们的解释，一个传输层协议必须至少做到以下几点。这里的 “ segment ” 在 ARPANET 上基本等同于 “ message ” 作为术语被使用：
+我发现 ARPANET 协议最有趣的事情是，现在在 TCP 中的许多传输层的功能是如何在 ARPANET 上经历了一个糟糕的青春期。我不是网络专家，因此我拿出大学时的网络课本（让我们跟着 Kurose 和 Ross 学习一下），他们对传输层通常负责什么给出了一个非常好的概述。总结一下他们的解释，一个传输层协议必须至少做到以下几点。这里的 “<ruby>段<rt>segment</rt></ruby>” 基本等同于 ARPANET 上的术语 “<ruby>消息<rt>message</rt></ruby>”：
 
   * 提供进程之间的传送服务，而不仅仅是主机之间的（传输层多路复用和多路分解）
   * 在每个段的基础上提供完整性检查（即确保传输过程中没有数据损坏）
@@ -71,36 +73,20 @@ ARPANET 协议以后都会被 TCP/IP 协议替换（但 Telnet 和 FTP 协议除
   * 不会丢失任何 “段”
   * “段” 的传送速度不会太快以至于被接收端丢弃（流量控制）
 
-似乎在 ARPANET 上关于如何进行多路复用和多路分解以便进程可以通信存在一些混淆—— BBN 在 IMP-Host 层引入了链路号来做到这一点，但结果证明在 Host-Host 层上无论如何套接字号都是必要的。然后链路号只是用于 IMP-Host 级别的流量控制，但 BBN 似乎后来放弃了它，转而支持在唯一的主机对之间进行流量控制，这意味着链路号开始时只是作为这个重载的东西基本上变成了遗迹。 TCP 现在使用端口代替，分别对每一个 TCP 链接进行流量控制。进程间的多路复用和多路分解完全在 TCP 内部进行，不会像 ARPANET 一样泄露到较低层去。
+似乎在 ARPANET 上关于如何进行多路复用和多路分解以便进程可以通信存在一些混淆 —— BBN 在 IMP-Host 层引入了链路号来做到这一点，但结果证明在 Host-Host 层上无论如何套接字号都是必要的。然后链路号只是用于 IMP-Host 级别的流量控制，但 BBN 似乎后来放弃了它，转而支持在唯一的主机对之间进行流量控制，这意味着链路号一开始是一个超载的东西，后来基本上变成了虚设。TCP 现在使用端口号代替，分别对每一个 TCP 连接单独进行流量控制。进程间的多路复用和多路分解完全在 TCP 内部进行，不会像 ARPANET 一样泄露到较低层去。
 
-同样有趣的是，鉴于 Kurose 和 Ross 如何开发 TCP 背后的想法，ARPANET 开始于 Kurose 和 Ross 所调用的一个严谨的 “stop-and-wait” 方法，以便在 IMP-Host 层上进行可靠的数据传输。这个 “stop-and-wait” 方法发送一个 “段” 然后就拒绝再去发送更多 “段” ，直到一个最近发送的 “段” 的确认被接收到为止。这是一种简单的方法，但这意味着只有一个 “段” 在整个网络中运行，从而导致协议非常缓慢——这就是为什么 Kurose 和 Ross 将 “stop-and-wait” 仅仅作为在通往功能齐全的传输层协议的路上的垫脚石的原因。在 ARPANET 上，“stop-and-wait” 是一段时间的工作方式，因为在 IMP–Host 层，必须接收下一条消息的请求以响应每条发出的消息，然后才能发送任何进一步的消息。客观的说 ，BBN 起初认为这对于提供主机之间的流量控制是必要的，因此减速是故意的。正如我已经提到的，为了更好的性能，RFNM 的要求后来放宽松了，而且 IMP 也开始向消息中添加序列号和保持对传输中的消息的 “窗口” 的跟踪，这或多或少与如今 TCP 的实现如出一辙。[5][13]
+同样有趣的是，鉴于 Kurose 和 Ross 如何开发 TCP 背后的想法，ARPANET 一开始就采用了 Kurose 和 Ross 所说的一个严谨的 “<ruby>停止并等待<rt>stop-and-wait</rt></ruby>” 方法，来实现 IMP-Host 层上的可靠的数据传输。这个 “停止并等待” 方法发送一个 “段” 然后就拒绝再去发送更多 “段” ，直到收到一个最近发送的 “段” 的确认为止。这是一种简单的方法，但这意味着只有一个 “段” 在整个网络中运行，从而导致协议非常缓慢 —— 这就是为什么 Kurose 和 Ross 将 “停止并等待” 仅仅作为在通往功能齐全的传输层协议的路上的垫脚石的原因。曾有一段时间 “停止并等待” 是 ARPANET 上的工作方式，因为在 IMP–Host 层，必须接收到<ruby>请求下一条消息<rt>Request for Next Message</rt></ruby>（RFNM）以响应每条发出的消息，然后才能发送任何进一步的消息。客观的说 ，BBN 起初认为这对于提供主机之间的流量控制是必要的，因此减速是故意的。正如我已经提到的，为了更好的性能，RFNM 的要求后来放宽松了，而且 IMP 也开始向消息中添加序列号和保持对传输中的消息的 “窗口” 的跟踪，这或多或少与如今 TCP 的实现如出一辙。[^5]
 
-ARPANET 表明，如果你能让每个人都遵守一些基本规则，异构计算系统之间的通信是可能的。正如我先前所说的，那个是 ARPANET 的最重要的遗产。但是我希望通过这次仔细研究的哪些基本规则所透露的是有多少 ARPANET 协议影响了我们如今所用的协议。在主机和 IMP 之间分担传输层职责的方式上肯定有很多笨拙之处，有时候是冗余的。回想起来，主机之间一开始只能通过给出的任意链路在某刻只发送一条消息，这真的很有趣。 但是 ARPANET 实验是一个独特的机会，可以通过实际构建和操作网络来学习这些经验，当到了是时候升级到我们今天所知的互联网时，似乎这些经验变得很有用。
+因此，ARPANET 表明，如果你能让每个人都遵守一些基本规则，异构计算系统之间的通信是可能的。正如我先前所说的，这是 ARPANET 的最重要的遗产。但是，我希望对这些基线规则的仔细研究揭示了 ARPANET 协议对我们今天使用的协议有多大影响。在主机和 IMP 之间分担传输层职责的方式上肯定有很多笨拙之处，有时候是冗余的。现在回想起来真的很可笑，主机之间一开始只能通过给出的任意链路在某刻只发送一条消息。但是 ARPANET 实验是一个独特的机会，可以通过实际构建和操作网络来学习这些经验，当到了是时候升级到我们今天所知的互联网时，似乎这些经验变得很有用。
 
-_如果你喜欢这篇贴子，更喜欢每四周发布一次的方式！那么在Twitter上关注[@TwoBitHistory][14] 或者订阅[RSS提要][15]，以确保你知道新帖子的发布时间。_
+_如果你喜欢这篇贴子，更喜欢每四周发布一次的方式！那么在 Twitter 上关注 [@TwoBitHistory][14] 或者订阅 [RSS 提要][15]，以确保你知道新帖子的发布时间。_
-
-_以前在 TwoBitHistory 上…_
-
-> Trying to get back on this horse!
->
-> 
-> 我最近的贴子是我的一些关于为什么ARPANET是一个如此重要的突破的看法（当然，是令人惊讶和新颖的），并重点关注ARPANET被首次展示的发布会:<https://t.co/8SRY39c3St>
->
-> — TwoBitHistory (@TwoBitHistory) [2021年2月7日][16]
-
-[^1]: 协议分层是网络工作组发明的。 这个论点是在[ RFC 871][17] 中提出的。分层也是 BBN 如何在主机和 IMP 之间划分职责的自然延伸，因此 BBN 也值得称赞。 
-
-[^2]:	The “level” 是被网络工作组使用的术语。 详见[RFC 100][19]
-
-[^3]: 在 IMP-Host 协议的后续版本中，扩展了头部字段，并且将链路号升级为消息 ID。 但是 Host-Host 协议仅仅继续使用消息 ID 字段的高位 8 位，并将其视为链路号。 请参阅 [ARPANET 协议手册][10]的 “ Host-Host ” 协议部分。
-
-[^4]: John M. McQuillan 和 David C. Walden。 “ARPA 网络设计决策”，第 284页，<https://www.walden-family.com/public/whole-paper.pdf>。 2021 年 3 月 8 日访问。
 
+[^1]: 协议分层是网络工作组发明的。这个论点是在 [RFC 871][17] 中提出的。分层也是 BBN 如何在主机和 IMP 之间划分职责的自然延伸，因此 BBN 也值得称赞。
+[^2]:	“level” 是被网络工作组使用的术语。 详见 [RFC 100][19]
+[^3]: 在 IMP-Host 协议的后续版本中，扩展了头部字段，并且将链路号升级为消息 ID。但是 Host-Host 协议仅仅继续使用消息 ID 字段的高位 8 位，并将其视为链路号。请参阅 [ARPANET 协议手册][10] 的 “Host-Host” 协议部分。
+[^4]: John M. McQuillan 和 David C. Walden。 “ARPA 网络设计决策”，第 284页，<https://www.walden-family.com/public/whole-paper.pdf>。 2021 年 3 月 8 日查看。
 [^5]: 同上。
 
-
-
-
 --------------------------------------------------------------------------------
 
 via: https://twobithistory.org/2021/03/08/arpanet-protocols.html
@@ -108,7 +94,7 @@ via: https://twobithistory.org/2021/03/08/arpanet-protocols.html
 作者：[Two-Bit History][a]
 选题：[lujun9972][b]
 译者：[Lin-vy](https://github.com/Lin-vy)
-校对：[校对者ID](https://github.com/校对者ID)
+校对：[wxy](https://github.com/wxy)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出