2021-6-14-DRAPA网

Posted 2021-06-27 轻舟一曲

DRAPA网

• DRAPA网
• • IP层
  • 基础目标
  • 二级目标
  • 面对网络失败的应对
  • 服务类型
  • 广泛的网络技术
  • 其他目标
  • 数据报
• 端到端理解

述：以下为计算机网络老师笔记，暂存以后阅读。

Internet最早来源于美国国防部高级研究计划局DARPA(Defense advanced Research Projects Agency)的前身ARPA建立的ARPAnet，该网于1969年投入使用。从60年代开始，ARPA就开始向美国国内大学的计算机系和一些私人有限公司提供经费，以促进基于分组交换技术的计算机网络的研究。1968年，ARPA为ARPAnet网络项目立项，这个项目基于这样一种主导思想：网络必须能够经受住故障的考验而维持正常工作，一旦发生战争，当网络的某一部分因遭受攻击而失去工作能力时，网络的其它部分应当能够维持正常通信。最初，ARPAnet主要用于军事研究。

---

DRAPA网

IP层

IP层是整个互联网结构最成功的所在：

（1）不是可靠的，而是best-effort，并且是无状态的，非面向连接的。这样给上层协议带来很大的优化空间：像文件传输之类需要可靠连接的可以使用面向连接的TCP；而像视频会议流媒体之类对延时要求高的可以选择UDP……

（2）对底层网络没有过多的要求，只需要在协议层提供对应接口即可。这样可以兼容多种网络

如果IP不是这么做，而是上来就做一个面向连接的、可靠的协议，而且只运行在特定网络上的协议。也许性能真的很好，但是只有一种服务、只在一种网络上使用的东西，能达到今天百家争鸣、百花齐放的繁荣么？

当然，TCP/IP也并非完美的，比如论文中指出的：

（1）TCP流控制使用字节数作为衡量接收窗口大小的衡量。按照包数和按照字节数进行流量控制可以看作一个tradeoff。按照包数控制可能导致相同数目包携带信息容量相差很大；而按照字节数控制可能导致相同容量信息的包数相差很大。也许最初的ARPANET的设计是正确的。

（2）IP难于实现对网络资源的统计与管理。因为协议认为连接状态信息应当保存在终端主机中，而不是在中转节点（网关）中，这样当网络经历短暂中断时可以保证终端通信可以继续（通过丢包重传等机制）。但是，这样一来关于中转节点的资源统计管理就很难实现。为了实现资源统计和管理，有人建议使用新的构造单元代替datagram，这种单元（作者称为flow）可以识别源到目的的分组顺序，而不管这个流是什么服务。这样一来需要在中转节点保存流控制信息，而由前面讨论得到，服务类型信息依然保存在终端主机。这样，流的暂时中断不会影响终端之间的服务通信。

Packet(包)是TCP/IP协议通信传输中的数据单位，一般也称“数据包”。在局域网中，“包”是包含在“帧”里的

datagram（数据报） – 在网络层中的传输单元（例如IP）。一个datagram可能被压缩成一个或几个packets，在数据链路层中传输。

在最初的版本中，没有提出面向无连接的datagram，而随着改进加入到协议中，并成为协议中的特点之一。
本论文回顾网络结构的最初目标，并讨论这些目标和协议重要特点之间的关系。

DARPA网络层次的顶级目标在于为现有互联的网络设计多路传输的有效技术。
网络（network）是互联网（internet）的组件，用来互相连接以提供更大的服务。网络最初被用来连接原始的ARPANET和ARPA无线电网络，以及无线电网络用户可以访问ARPANET更大的服务器。

基础目标

除了连接现有网络，一个替代做法是设计一个统一的系统，包括各种****不同传输媒介****的多媒介网络。这种做法可以保证更高的集成度，进而提供更好的性能。

多路传输使用****分组交换*实现。一个替代方法是使用*电路交换****实现多路传输。但是远程登录等应用可以由分组交换机制自然的提供，并且最初目标中要集成的网络使用的就是分组交换机制。因此互联网结构使用分组交换作为基础构件。

原始目标的最后一个方面就是连接网络的特殊技术。因为****DARPA的分组交换机制*被ARPANET所接受，因此网络通过一个包交换层进行互联，称为*网关****。

二级目标

前面描述的顶级目标包括有效，而没有给出如何连接以达到有效的定义。接下来列出网络结构要达到的目标的详细列表：
1、即使（部分？ ）网络和网关失效，网络通信必须能够继续
2、互联网必须支持多种通信服务
3、互联网结构必须能够适应多种网络硬件
4、互联网结构必须允许资源的分布式管理
5、互联网结构的花费必须是有效的
6、互联网结构必须能够方便地进行主机连接（host attachment？）
7、互联网结构使用的资源必须是可以统计的
这些目标是按照重要性进行排序，当需求变换时，这些目标的重要性也会随之变换。例如，最初的网络是为军事服务的，因此网络的通信比资源统计要重要的多。随着网络逐渐转向民用，网络结构的目标也逐渐变化，如资源统计成为非常重要的目标。

面对网络失败的应对

前边列表中最重要的目标是即使在网络和网关失效时，仍能保证通信服务的继续。特别的，这个目标可以解释为：如果两个实体在通过网络进行通信，由于某些原因导致网络暂时被干扰，被重新设置并重新开始服务，则实体通信的通信应当继续，而不是重新建立连接，开始新的会话。对互联网结构的一个假设是除费无力线路失效，主机之间始终可以保持连通。即网络结构可以完全屏蔽任何短暂的网络失效。

为了达到这一目的，描述进行中的会话状态信息必须被保存，例如包传输个数、包确认个数、或外出流控制等。如果网络低层结构丢失了这些信息，则不能判断数据是否丢失，需要高层应用层应对同步的丢失。

在一些网络结构中，状态信息被保存在分组交换的中转节点。为了保存状态信息不会丢失，它们必须被复制。由于复制的分布式特性，健壮的复制算法是难于设计的 ，因此很少有网络结构提供这种状态信息的保护。相反的，网络结构选择将状态信息保存在终端节点。称为命运共享（？），即只有在终端节点失效（和网络断开连接？）时，状态信息才会丢失。

命运共享比复制状态信息的机制有两个重要优势：
1、命运共享可以防止任意多的中转节点失效；而复制状态信息只能防止一定数量（少于信息复制数目）的中转节点失效
2、简单，便于工程实现

使用命运共享带来两个后果：
1、包中转节点，或称为网关，不能保存进行中连接的任何关键状态信息，相反的，它们是无状态的包中转，有时称为报文网络。
2、更加信任终端节点，而不是信任网络结构

更加重要的是网络的连通性。例如，网络对线路连接失效的报告制作了非常弱的假设，因此必须使用互联网级别机制，进行网络错误侦测。

服务类型

互联网结构的第二个目标是在传输服务级别提供多种类型的服务。传统服务包括双向可靠的数据传输，有时成为虚拟电路，是提供远程登录和文件传输的基础。这是互联网结构提供的第一个服务，使用传输控制协议（TCP）。在其基础之上的不同变种有不同的性能需求，如远程登录需要低延时、低带宽需求；而文件传输对延时不关心，但对带宽要求很高。TCP被设计为同时支持两种服务。

最初的设计理念是通用并支持各种类型服务，但是由于服务需求的多样性，使得将需求集中于一个协议太过复杂。

第一个超出TCP服务范畴的是XNET，跨网络调试器（？），原因：
1、调试协议不应当基于可靠的连接。因为调试器是为错误准备的，而在错误的环境要求可靠的连接可能导致无法连接。
2、如果TCP足够通用以处理大范围的用户，则可能有点复杂。同上理由，由于调试环境的复杂性不能期待使用可靠的连接。

另一个不适合TCP的服务是实时数字演讲传输（类似流媒体？）。类似服务最关键的不是可靠服务，而是尽量减少包传输的时延。观察发现，网络时延的一个很大的源头是可靠传输机制。丢包重传等机制导致了网络时延。而对于网络会议而言，丢失的包可以不必要求重传，而简单的将该段内容设为静音，不会严重影响效果。

在互联网结构发展早期就决定了多于一种传输协议是必须的，并且必须被设计为适合。可靠性、时延、带宽等约束的服务。这个目标导致了TCP/IP的产生。TCP提供可靠的数据流传输；而IP提供了基于报文的协议，并可以其为基础建立多种服务。报文（datagram）作为IP协议的基本构造单元（basic building block）。由于IP是不可靠的，称为best-effort，可以在高层协议（TCP或应用层手动实现）通过确认、重传等机制实现可靠性；或者用可靠性交换低时延（tradeoff）。UDP（user datagram protocol）提供基本报文服务的应用级别接口。

同时提供可靠的和不可靠的传输服务使得互联网结构有了很大的灵活性，可以满足各种对性能，如可靠性、时延、带宽等要求，而这些要求无法在单一的服务模式中得到满足。

广泛的网络技术

互联网结构获得成功的重要原因在于它能够提供广泛的网络技术，包括民用和商用；并能够适应多种网络，包括远距离网络、局域网、广播卫星网络等。互联网结构能达到如此的弹性，因为它对网络本身能提供的功能只作了最小的要求。基本假设是网络能够传输包或报文。包必须能够达到一定大小，而且以较大的（不是完全）可靠性进行传输。网络有某种寻址机制，而不是简单的点到点的连接。

包括可靠或顺序传输、网络级别的广播或多博、传输包的优先级、失败的内部通知、速率、延时等都不是网络结构显式要求的。否则的话，或者原始网络支持这些功能，或者需要软件模拟这些服务，需要对每个网络/主机实现这些服务。而如果在传输层实现，例如在TCP实现可靠传输，功能之需要实现一次，不需考虑不同的网络。

其他目标

1、分布式网络管理
不同的网络可能使用不同的网络管理，在路由方面缺少分布式管理工具，目前（当时？）需要手动设置路由表。这种方式易于出错而且不够强大。今后几年可能发展出下一代的网络资源管理工具。

2、效率问题
IP包首部很长（典型值为40字节）。如果包信息很小，浪费显而易见。极端的，远程登录服务（telnet），每个包信息只有一字节，而首部40字节。对于文件传输等大数据包，首部可以忽略不计。

另一个低效的来源是丢包重传。网络层不提供这一功能，而由传输/应用层提供，原因前边提到过，网络接口比较简单，但是传输效率可能较低。根据经验，1%的丢包率是可以接受的，但是10%的丢包率意味着网络的可靠性应当加强。

3、添加加用户的消耗
在互联网结构中添加新的host可能比其他网络复杂，因为前边的讨论得到的结论是很多网络机制，例如确认和丢包重传，都是在终端主机上实现的。在不同的机器上对协议的移植十分复杂。考虑到前边协议之需要实现一次，但这对协议的实现者要求很高，可能和重新设计协议差不多复杂。

4、可统计性
缺少统计工具，例如对包流量的统计。目前处于研究阶段

Architecture and Implementation
前面讨论可以看出，互联网结构不应当对网络能够提供的服务做过多的限制。因此对于互联网提供的提供的特殊服务，应当关注特殊主机和网关的软件实现，而不是互联网结构，需要根据不同的服务需求对特定的网络进行设计。

互联网结构设计的困难之一在于如何指引设计者设计出适合服务的网络，如使用什么带宽、吞吐率如何等。可以使用工具帮助验证协议逻辑的正确性，但少有工具可以验证性能问题，而性能问题对于服务类型至关重要。可能协议的逻辑正确性已经证明，而在实现阶段发现设计错误。

结构与性能之间的关系十分具有挑战性。只关注逻辑的正确性而忽略性能问题是十分严重的错误。但是，在网络结构设计中加入形式化的性能约束是十分困难的，因为层次设计的目标之一就是不进行性能约束（保证多种网络的兼容性？），而且没有有效的性能描述工具。此外，很难将性能参数作为标准写入网络结构规范中 。

数据报

网络基础结构的一大特色是是使用报文作为底层网络传输的实体。

datagram的重要性：
1、无需中转节点保存连接的状态信息，这意味着网络在经历失效后方便地进行重建，而不需要考虑到状态。
2、datagram提供了用于创造多种服务的基本构造快。相对的虚拟电路网络只能提供少数的服务类型
3、datagram只对网络进行了很少的假设，使得多种网络结构可以包含多种网络实现。
选择datagram作为网络传输的基础是互联网结构获得巨大成功的重要原因。

TCP
早期ARPANET的端对端协议同时使用基于字节和基于包数的流量控制。TCP设计者意识到这点过于复杂，选择了基于流量的窗口控制，原因基于以下考虑：
1、允许在字节顺序空间中加入控制信息，使得控制信息和数据都能够被确认（dropped）
2、允许TCP包被分割为更小的包以适应不同的网络环境。这一思路被移至IP层
3、当发送节点进行重传数据时可以将多个小包集合成一个大包。
假设两个主机通信，每个包包含一字节信息，容易形成泛洪、丢包、重传。如果重传的包和原来相同，则很容易造成新的泛洪，将多个重传包集合起来可以避免这一问题。
另一方面，如果使用包数进行流量控制，就不会产生类似的泛洪。但是，使用包数的话，可能因为包容量小而导致吞吐量下降。

按照包数和按照字节数进行流量控制可以看作一个tradeoff。按照包数控制可能导致相同数目包携带信息容量相差很大；而按照字节数控制可能导致相同容量信息的包数相差很大。也许最初的ARPANET的设计是正确的。

EOL标志位，已经被PSH标志位取代。最初的思想是将字节流划分为记录，将记录写入包中，EOL表示一个记录的结束。但是这种思想和组合重传的机制不兼容，于是改为较弱的形式，只标记到改点字节流信息已经是一个或多个应用级完整的内容（和PSH类似的语义）

datagram在互联网结构中的作用十分重要，并且成为真个结构获得成功的关键，但是有些目标，单凭datagram是无法达到的，如资源统计和管理。理由在于datagram通常是由字节流拆分得到的，是整个流的一部分，而不是孤立的单元。但是网关将所有的datagram看作单独的单元进行处理。

为了实现资源统计和管理，有人建议使用新的构造单元代替datagram，这种单元（不妨称为flow）可以识别源到目的的分组顺序，而不管这个流是什么服务。这样一来需要在中转节点保存流控制信息，而由前面讨论得到，服务类型信息依然保存在终端主机。这样，流的暂时中断不会影响终端之间的服务通信。

端到端理解

讯系统设计的主要目标是要让传输中各种错误发生的概率降低到一个可以接受的水平。对于一个通讯可靠系统，它的出错率应该是很低的，而且只需通过简单的多次传输就可以实现系统的目标。当然也可以采用“端到端确认重传”来实现，这时就要考虑这些功能在系统中什么地方实现，即层次上的考虑。设置功能时要考虑两个因素的权衡：代价和性能。通常底层的功能可以提高系统的性能（如底层的校验机制），但全局的代价较大（overall cost）。在文中作者通过几个例子（传输保证、安全传输、时序控制以及实务管理）来说明将一些功能放到高层（End）是有利于系统的实现和性能提高的。同时也强调一点：任何应用对功能的需求都是有特指的，因此不可能存在一种底层的功能满足所有的上层应用需求。任何底层功能的设定都是高全局代价的。因此，某些功能的不完全实现往往是提高系统功能的好办法。作者认为网络传输是不可靠的，即由于错误的复制或缓冲，硬件处理器或记忆短暂的错误等各种原因会出现数据包的丢失和损坏，因此在网络的最核心的部分应该只做数据的传输而不能去做一些其他的应用，而数据是否正确传输则应该放到应用层去检查和判断——由此产生了我们今天网络应用层上的确定重传机制。这样一来实际上是降低了网络的核心复杂度，同时也提高了网络的灵活性和可维护性，因为网络只需要做一件事情即传输数据，而其他的功能可以放到应用层上去实现，这样网络一旦出现故障我们首先想到的就不会是网络的核心部件了。

今天我们的网络已经是非常庞大了，可是在当时网络还刚刚起步，我在想作者当时为什么会提出这样一种论点呢？带着这样一个问题反复地拜读了好多次，细细揣摩作者写作的动机，隐隐明白了作者当初想要解决的一些问题。

其一，降低网络核心复杂度，简化复杂功能。文件从主机A传到主机B，也就是说AB主机要通信，需要经过三个环节：首先是主机A从磁盘上读取文件并将数据分组成一个个数据包packet,，然后数据包通过连接主机A和主机B的网络传输到主机B，最后是主机B收到数据包并将数据包写入磁盘。在这个看似简单其实很复杂的过程中可能会由于某些原因而影响正常通信。比如：磁盘上文件读写错误、缓冲溢出、内存出错、网络拥挤等等这些因素都有可能导致数据包的出错或者丢失，由此可见用于通信的网络是不可靠的。那么怎么样在不可靠的网络上实现和确保两个主机之间文件的可靠传输，即实现数据的完整而准确的传输成为通信双方信息共享的关键。由于实现通信只要经过上述三个环节，那么我们就想是否在其中某个环节上增加一个检错纠错机制来用于对信息进行把关呢？在通信时一旦发现数据包有问题就进行相应的处理使得到达主B的数据包都是没有问题的或者说都是正确的数据包。连接主机A和B的网络在通信过程中起着桥梁的作用，同时它在整个网络体系结构中也处于一个较低的层次，那么是不是可以把数据包的纠错任务也交给网络呢？事实证明这是行不通的。因为这不但会增加网络的复杂性而且会降低网络的可维护，从而必须要付出昂贵的开销，这是不可取的。这时候“端系统”似乎理所当然地成为了要完成这个任务的佼佼者。实验证明“端系统”完全可以胜任这个工作，因为只有“端系统”可以知道哪个地方出现了错误，哪个地方需要重传。我们将确认传输正确的任务交给“端系统”去完成，在“端系统”没有接收到完整的所需要的资源的同时，可以有多种机制来保证满足传输的正确。如将确认重传机制放在端系统的应用层上可以保证信息的可靠到达，这样就最大的保证了传输的可靠性和完整性。但是为了在一个原本不可靠的网络上实现可靠传输，就必须要有一个独立于网络层的可靠传输协议和一个端系统的应用层的错误检测功能。这样一来，网络的使命就很单纯了，网络只需要负责传输数据，而其他方面都由网络以外的系统去实现了，从而大大地降低了网络的复杂性，提高了网络的通用性和灵活性，当增加新应用时也不必改变核心网络，便于网络的升级，提高了网络的可靠性。

其二，尽可能好的数据传输服务。对于数据的传输来说，网络层的最主要目的是增大数据传输的速率，网络层不需要考虑数据的完整性，数据的完整性和正确性交给端系统去检测就行了，因此在数据传输中，对于网络层只能要求其提供尽可能好的数据传输服务，而不可能寄希望于网络层提供数据完整性的服务。这种设计原则可以使得传输的速率最大化，同时也为多种服务的实现提供了数据传输方面的保证。现在广泛使用的TCP协议也只能够用确定重传的机制来保证数据的一致性和完整性，因此这对于端系统的检测数据完整性和保证数据的正确性提出了更高的要求。

其三，“End-To-End”地址透明性和全球唯一地址。“端到端”设计原则需要给Internet上的主机分配全球唯一的地址以用于标识不同的主机，这样在传输的过程中不需要中间的节点或者转发节点对于包的内容进行修改。在数据包中包括了来源和目的地的完整的信息，中间的路由等转发节点也不需要去知道该数据包的信息。在这个意义上，数据在端系统之间的传输好像是有唯一的通路直接相连。这样，端系统上的应用程序也不需要知道实际传输的具体的线路，为实际应用也带来了方便。