DARPA网络协议设计的理念.doc_第1页
DARPA网络协议设计的理念.doc_第2页
DARPA网络协议设计的理念.doc_第3页
DARPA网络协议设计的理念.doc_第4页
DARPA网络协议设计的理念.doc_第5页
已阅读5页,还剩1页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

DARPA网络协议设计的理念摘要:Internet协议族TCP/IP在15年前由DARPA提出,并广泛的应用于军事和商业系统。并且已经存在描述协议如何工作的文献和规范,有时难以从文章和规范中推测出为什么要这样设计。例如,Internet协议是基于无连接或者数据包模式的服务。这样设计的初衷已经被严重的误解了。这篇文章试图抓住设计Internet协议族时的一些原因。1、简介在过去的15年中,一直致力于研发用于包传送的一组协议。这些协议包括网络协议IP,传输控制协议TCP,仍是网络连接的标准,并且广泛应用于商业网路环境。研制这些协议的思想也影响了其他一些协议族,尤其是基于无连接的ISO的配置。 同时DODO协议的一些具体信息又是存在的,有时难以知道导致这种设计的动机和理由。 实际上,网络协议的设计的哲学很大程度上源于对现在标准的建议。例如:数据报的观点,或者是无连接服务,起初并没有收到特别的关注,但是成为了协议的标志性特征。另外一个例子是对体系结构分为IP和TCP层。这看起来是设计的基础,但也不是最初建议的一部分。在Internet设计中的一些改变起于在标准设定之前反复的测试和实施。 Internet体系结构仍然在演变之中。有时一个新的延伸会挑战某个设计原则,但是无论如何对体系结构设计历史的理解会对现在涉及延伸提供必要的理解。ISO无连接配置也受Internet体系历史影响了,所以对Internet设计里面的理解有助于使用ISO。 这篇文章列出了最初Internet体系结构的最初设计目标的一种看法,并且讨论了这些协议目标和重要特点之间的关系。2、基本目标DARPA Ineternet体系结构的最高目标是为已经存在的网络使用设计一种有效地技术。一些设计可以弄明白这个目标的意义。Internet的组成部分是网络,这些网络互连以提供一些大型的服务。最初的目标是要把最初的带有ARPA射频包网络的ARPANET结合起来,以便给在ARPA的用户提供接入ARPANET的途径。同时假定有一些其他类型的网络要互连,尽管本地网络并没有出现。另一种对已经存在的网络互连的方法是设计一种系统可以合并大量不同类型的传输媒介,一种多媒体网络。同时这也允许一种更高程度的集成,从而有更好的性能。如果Internet在使用意义上有用,有必要合并那时候已经存在的网络体系结构。进一步,网络代表了控制的边界,并且这也是这个项目的一个目标要抓住合并一系列相互独立管理的实体到一个普通的单元。对多样性选择的技术是包转发。如电路交换可以考虑作为一个代替,但是一些应用已经支持了,如远程登录,自然地使用包交换,并且在本工程重要整合在一起的网络是包交换网络。所以包交换已经被网络体系结构接收作为一个基本的组成单元。基本目标的最后一个方面是对这些网络互连的一些特殊技术的承担。在前面DARPA工程讲述的,自从存储和转发包的技术,ARPANET很好的理解,最高层次的假设是网络会被Internet包转发层互连,叫做网关。从来自Internet基本的结构的假设看出:一种包交换通讯设备,一些相互区别的网络使用包通讯节点连接在一起,叫做网关,网关可以执行存储转发包的转发算法。3、第二层目标在前面讲述的最高层的目标包括“效率”这个词,并没有提供任何一种有关有效地连接的定义。下面总结列出了为Ineternet体系结构建立的更详细的目标。1、 Internet 通讯必须,尽管丢失网络或者网关。2、 Internet 必须支持多种类型的通讯服务。3、 Internet 体系结构必须容纳多种网络。4、 Internet 体系结构必须允许对他的资源分布式管理。5、 Internet 体系结构必须花费合理。6、 Internet 体系结构必须允许用户连接不用太费力。7、 Internet 体系结构中使用的资源必须负责。这些目标是按照重要性进行排序,当需求变换时,这些目标的重要性也会随之变换。例如,最初的网络是为军事服务的,因此网络的通信比资源统计要重要的多。随着网络逐渐转向民用,网络结构的目标也逐渐变化,如资源统计成为非常重要的目标。4、面对失败时的生存性前边列表中最重要的目标是即使在网络和网关失效时,仍能保证通信服务的继续。特别的,这个目标可以解释为:如果两个实体在通过网络进行通信,由于某些原因导致网络暂时被干扰,被重新设置并重新开始服务,则实体通信的通信应当继续,而不是重新建立连接,开始新的会话。对互联网结构的一个假设是除费无力线路失效,主机之间始终可以保持连通。即网络结构可以完全屏蔽任何短暂的网络失效。为了达到这一目的,描述进行中的会话状态信息必须被保存例如包传输个数、包确认个数、或外出流控制等。如果网络低层结构丢失了这些信息,则不能判断数据是否丢失,需要高层应用层应对同步的丢失。在一些网络结构中,状态信息被保存在分组交换的中转节点。为了保存状态信息不会丢失,它们必须被复制。由于复制的分布式特性,健壮的复制算法是难于设计的 ,因此很少有网络结构提供这种状态信息的保护。相反的,网络结构选择将状态信息保存在终端节点。称为命运共享,即只有在终端节点失效(和网络断开连接)时,状态信息才会丢失。 命运共享比复制状态信息的机制有两个重要优势:1、命运共享可以防止任意多的中转节点失败;而复制状态信息只能防止一定数量(少于信息复制数目)的中转节点失效。2、简单,便于工程实现 使用命运共享带来两个后果:1、包中转节点,或称为网关,不能保存进行中连接的任何关键状态信息,相反的,它们是无状态的包中转,有时称为报文网络。2、更加信任终端节点,而不是信任网络结构 更加重要的是网络的连通性。例如,网络对线路连接失效的报告制作了非常弱的假设,因此必须使用互联网级别机制,进行网络错误侦测。 5、服务类型互联网结构的第二个目标是在传输服务级别提供多种类型的服务。传统服务包括双向可靠的数据传输,有时成为虚拟电路,是提供远程登录和文件传输的基础。这是互联网结构提供的第一个服务,使用传输控制协议(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)提供基本报文服务的应用级别接口。 同时提供可靠的和不可靠的传输服务使得互联网结构有了很大的灵活性,可以满足各种对性能,如可靠性、时延、带宽等要求,而这些要求无法在单一的服务模式中得到满足。6、网络的多样性互联网结构获得成功的重要原因在于它能够提供广泛的网络技术,包括民用和商用;并能够适应多种网络,包括远距离网络、局域网、广播卫星网络等。互联网结构能达到如此的弹性,因为它对网络本身能提供的功能只作了最小的要求。基本假设是网络能够传输包或报文。包必须能够达到一定大小,而且以较大的(不是完全)可靠性进行传输。网络有某种寻址机制,而不是简单的点到点的连接。 包括可靠或顺序传输、网络级别的广播或多播、传输包的优先级、失败的内部通知、速率、延时等都不是网络结构显式要求的。否则的话,或者原始网络支持这些功能,或者需要软件模拟这些服务,需要对每个网络/主机实现这些服务。而如果在传输层实现,例如在TCP实现可靠传输,功能之需要实现一次,不需考虑不同的网络。7、其他目标1、分布式网络管理不同的网络可能使用不同的网络管理,在路由方面缺少分布式管理工具,目前(当时?)需要手动设置路由表。这种方式易于出错而且不够强大。今后几年可能发展出下一代的网络资源管理工具。 2、效率问题IP包首部很长(典型值为40字节)。如果包信息很小,浪费显而易见。极端的,远程登录服务(telnet),每个包信息只有一字节,而首部40字节。对于文件传输等大数据包,首部可以忽略不计。 另一个低效的来源是丢包重传。网络层不提供这一功能,而由传输/应用层提供,原因前边提到过,网络接口比较简单,但是传输效率可能较低。根据经验,1%的丢包率是可以接受的,但是10%的丢包率意味着网络的可靠性应当加强。 3、添加用户的消耗在互联网结构中添加新的host可能比其他网络复杂,因为前边的讨论得到的结论是很多网络机制,例如确认和丢包重传,都是在终端主机上实现的。在不同的机器上对协议的移植十分复杂。考虑到前边协议之需要实现一次,但这对协议的实现者要求很高,可能和重新设计协议差不多复杂。 4、可统计性缺少统计工具,例如对包流量的统计。目前处于研究阶段 8、体系结构和实现前面讨论可以看出,互联网结构不应当对网络能够提供的服务做过多的限制。因此对于互联网提供的提供的特殊服务,应当关注特殊主机和网关的软件实现,而不是互联网结构,需要根据不同的服务需求对特定的网络进行设计。 互联网结构设计的困难之一在于如何指引设计者设计出适合服务的网络,如使用什么带宽、吞吐率如何等。可以使用工具帮助验证协议逻辑的正确性,但少有工具可以验证性能问题,而性能问题对于服务类型至关重要。可能协议的逻辑正确性已经证明,而在实现阶段发现设计错误。 结构与性能之间的关系十分具有挑战性。只关注逻辑的正确性而忽略性能问题是十分严重的错误。但是,在网络结构设计中加入形式化的性能约束是十分困难的,因为层次设计的目标之一就是不进行性能约束(保证多种网络的兼容性?),而且没有有效的性能描述工具。此外,很难将性能参数作为标准写入网络结构规范中 9、数据报网络基础结构的一大特色是是使用报文作为底层网络传输的实体。 datagram的重要性:1、无需中转节点保存连接的状态信息,这意味着网络在经历失效后方便地进行重建,而不需要考虑到状态。2、datagram提供了用于创造多种服务的基本构造快。相对的虚拟电路网络只能提供少数的服务类型3、datagram只对网络进行了很少的假设,使得多种网络结构可以包含多种网络实现。选择datagram作为网络传输的基础是互联网结构获得巨大成功的重要原因。 10、传输控制协议早期ARPANET的端对端协议同时使用基于字节和基于包数的流量控制。TCP设计者意识到这点过于复杂,选择了基于流量的窗口控制,原因基于以下考虑:1、允许在字节顺序空间中加入控制信息,使得控制信息和数据都能够被确认(dropped)2、允许TCP包被分割为更小的包以适应不同的网络环境。这一思路被移至IP层3、当发送节点进行重传数据时可以将多个小包集合成一个大包。假设两个主机通信,每个包包含一字节信息,容易形成泛洪、丢包、重传。如果重传的包和原来相同,则很容易造成新的泛洪,将多个重传包集合起来可以避免这一问题。另一方面,如果使用包数进行流量控制,就不会产生类似的泛洪。但是,使用包数的话,可能因为包容量小而导致吞吐量下降。 按照包数和按照字节数进行流量控制可以看作一个tradeoff。按照包数控制可能导致相同数目包携带信息容量相差很大;而按照字节数控制可能导致相同容量信息的包数相差很大。也许最初的ARPANET的设计是正确的。 EOL标志位,已经被PSH标志位取代。最初的思想是将字节流划分为记录,将记录写入包中,EOL表示一个记录的结束。但是这种思想和组合重传的机制不兼容,于是改为较弱的形式,只标记到改点字节流信息已经是一个或多个应用级完整的内容(和PSH类似的语义) 11、总结datagram在互联网结构中的作用十分重要,并且成为整个结构获得成功的关键,但是有些目标,单凭datagram是无法达到的,如资源统计和管理。理由在于datagram通常是由字节流拆分得到的,是整个流的一部分,而不是孤立的单元。但是网关将所有的datagram看作单独的单元进行处理。 为了实现资源统计和管理,有人建议使用新的构造单元代替datagram,这种单元(不妨称为flow)可以识别源到目的的分组顺序,而不管这个流是什么服务。这样一来需要在中转节点保存流控制信息,而由前面讨论得到,服务类型信息依然保存在终端主机。这样,流的暂时中断不会影响终端之间的服

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论