高级计算机网络考试重点内容八:网络架构

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

8.2互联网设计原则的重新思考
• 条件发生了深刻变化: 条件发生了深刻变化:
3.ISP服务的区分化:ISP在网络核心做的更多是有 竞争力的优势 4.第三方的干预 5.非专业用户的增多
所有的这五个变化都激发了端到端设计原则的转变。
8.2互联网设计原则的重新思考
• 争议 争议(?)(What is at stake): :
8.1 互联网设计原则-端到端观点
• 端到端观点描述 端到端观点描述:
1.一种描述:只有在端系统的应用层的知识和帮助下,一 个功能才能被完整和正确的实现。 2.另一种描述(更加准确):一个系统或者子系统只有在功 能被完整和正确的实现时才会考虑这些功能,只有部 分实现是没有意义的。 3.供选择的描述:如果应用层可以正确的实现一个功能, 只有在可以提高性能的情况下可以将该功能放到低层 实现。 4.总结:如果在底层不能够完整地实现一种功能,把它放 到高层去做;但是都放在应用层实现也有问题,将应 用层比较公共的服务抽出来,放在传输层,在端系统 做这个事情比较合适。
8.2互联网设计原则的重新思考
• 条件发生了深刻变化: 条件发生了深刻变化:
1.非信任环境的操作
– 端节点可能是恶意的 – 如果端节点不可信任,仍希望网络是可以信任的,因此 需在网络核心加入新的机制
2.应用对网络数据传输有更高要求
– 点到点尽力而为服务不再满足需要 – 网络中新的服务模型(intserv,diffserv) – 新的应用层服务架构建立在网络核心上(如CDN,P2P)
8.1 互联网设计原则-future
• 展望未来 展望未来(What about the future?)
– 数据报抽象对于资源管理、问责、服务质量 (QoS)并不是最好的方式。 – 新的抽象方式:流(参见IPv6)。但是没有人知 道流是什么。 – 路由器需要维护每个流的状态。 – 状态管理:恢复丢失的状态非常困难。 – 这里(1988)我们看到了“软状态”的第一次提 出:即由客户端节点来维护状态。
• 总结:最低限度方法 总结:
– 傻网络:网络提供最低限度功能来支持连接(1) 寻址(2)转发(3)路由。 – 智能端系统:传输层及应用层实现更多的专业 功能(1)流量控制(2)拥塞控制(3)错误检验 – 优点: (1)可以接受非均匀技术(连接以太网,调制解调 器,无线网络,卫星网络) (2)支持不同的应用程序(telnet, ftp, Web, X windows) (3)分散网络管理
8.1 互联网设计原则-端到端观点
• 分析
(2)是否有放在应用层实现的理由?
– 流量控制:应用层知道什么时候、如何将数据在拥塞 时放弃。 – 拥塞控制:应用层可以做TCP友好拥塞控制(TCPfriendly cc)。
(3)为什么不放在链路层?
– 放到链路层意味着所有的应用程序都必须使用流量拥 塞控制,但不是所有应用程序都需要; – 链路层中的流量、拥塞信息来自端系统,每一条连接 都需要对其状态信息进行控制,链路层层次太低,无 法区分和控制,因此不合适。
8.1 互联网设计原则-原则
• 互联网设计原则 互联网设计原则(按重要性排序):
0.连接已有的网络,如ARPANET, ARPA packet radio, packet
satellite network;
1.生存能力(健壮性),当网络或路由器发生错误时仍可保 证通信服务; 2.支持多种类型服务; 3.能够连接多种类型的网络; 4.允许分布式管理; 5.允许客户端接入的低代价; 6.使代价有效 7.资源问责制(resourse accountabilily)
第八部分:网络架构
• 提纲 提纲:
– 互联网设计原则 – 互联网设计原则的重新思考 – 分组交换和线路交换实际运行效果的比较
8.1 互联网设计原则
• 关键问题 关键问题:
– 如何把复杂的系统功能分解为协议层? – 哪些功能应该被放在网络的什么地方(边缘or核 心),放在哪一个协议层(protocol layer)? – 一个功能可以被放置在多个协议层上么? 分别在互联网和电话网的背景下 回答这些问题
8.1 互联网设计原则-端到端观点
• 分析 1.网络层提供了一个简单的服务:尽力而为 的分组传输服务。 2.网络边缘的传输层(TCP)提供了端到端的错 误控制(虽然很多应用程序可以提供自己的 错误控制,但该功能被很多应用程序使用, 将其放到传输层可以提高性能)。 3.所有其他功能:应用层功能,网络服务 DNS,都在应用层上实现。
8.1 互联网设计原则-原则
1.生存能力(survivability),
• 当网络(链路或路由器)发生错误时,只要网络没有断开,则需 保证端节点通信,任何错误(除了网络断开)对端节点都是透 明的。 • 只在端节点维持传输状态,此举避免了处理路由器错误时 的状态不一致和状态恢复问题。 • 互联网:无状态网络层结构,即在网络层没有session或 call的概念。
8.2互联网设计原则的重新思考
1.防火墙 • 分组过滤防火墙
– 内网通过路由器防火墙与互联网连接 – 路由器一个分组一个分组的过滤,将分组转发还是丢弃 基于以下标准:(1)源和目的IP地址(2)UDP/TCP源和目 的端口号(3)ICMP消息类型(4)TCP的SYN和ACK位 – 例1:阻塞所有进出数据报中,IP协议里field=17以及源 或目的端口号为23的数据报。 结果:所有进出UDP流及telnet连接都被阻塞。 – 例2:阻塞所有ACK=0的TCP报文段。 结果:阻塞所有外部网络向内部网络发起的TCP连接, 但允许内网向外网的TCP连接。
8.2互联网设计原则的重新思考
1.防火墙 • 将机构的内部网络与外部更大的网络隔离,允许 部分分组通过,其他部分分组隔离。 • 设置防火墙原因:
– 防止服务攻击,如SYN flooding:攻击者建立许多假的 TCP连接,导致没有预留资源给真的连接。 – 防止非法修改或访问内网数据,如攻击者擅自更改CIA 的主页。 – 只允许对内网的授权访问。 – 两种防火墙:应用程序级防火墙,分组过滤防火墙
8.1 互联网设计原则-总结
• 总结:互联网构架 总结:
– 分组交换数据报网络 – IP是粘合剂,网络层 覆盖其上 – IP沙漏结构,所有客 户端和路由器都运行 IP – 无状态网络构架:在 网络内部没有每流状 态
TCP UDP
IP Satellite Ethernet ATM
IP 沙漏
8.1 互联网设计原则-总结
• 可靠文件传输的例子 可靠文件传输的例子:
Host A Appl. OS OK
checksum
Host B Appl. OS
– 方案一:每一步都进行可靠性检验,最后进行 总的错误检验。 – 方案二:不保证每一步的可靠性,只在端系统 中进行总的错误检验和重传。
8.1 互联网设计原则
• 两个方案讨论 两个方案讨论:
4.其他原则(1)
– 允许分布式管理:管理自治。IP互联网络:(1)每个网 络被不同的机构管理(2)不同网络间只在边界处交流信 息(3)这个模型使得路由复杂化
8.1 互联网设计原则-原则
4.其他原则(2)
– 代价有效:无效代价的根源有(1)分组头部的开销(2)分 组重传(3)路由。但是最优性能并不是互联网设计的最 高优先级。 – 客户端接入的低代价:这一点并不强,互联网的智能 化和复杂性在客户端,因此将主机连接到网络上比电 话网络代价要大。而且一个有着不好实现或有恶意的 客户端接入网络对网络有害。
– 允许性价比折衷
8.1 互联网设计原则-端到端观点
• 讨论 讨论:
– 端到端观点强调了正确性和完整性,却没有强 调以下几点,虽然以下都是事实: • 复杂性:复杂性在边缘,形成了简单的网络 构架; • 可发展性:引入新的应用比改进路由器要简 单,即便于引入新的应用; • 技术渗透:简单的网络层结构是的IP的推广 更加容易。
– 把功能放在低层与放在高层相比,可能是多余 的或没有价值的; – 有时,通信系统(低层)提供的不完整版本的功 能可以使性能增强。 (个人理解:将高层中公共的功能部分提取出来 放在低层,有时可以使性能增强) – 以上两点导致了与电话网络中“哑终端,智能 网络”完全相反的设计原理。
8.1 互联网设计原则
8.1 互联网设计原则
• 两个方案讨论 两个方案讨论:
3.有没有在低层实现可靠性检验的原因?
• 有,更容易在中间每一跳检查和恢复错误,错误恢 复和局部重传花费时间更少。
• 权衡(trade-offs) 权衡
– 应用层有更多服务所需要的数据和语义信息, 而低层则有更多关于数据传输的约束信息(如分 组的长度信息等)。 – 这些trade-offs是分层的直接结果。
1.方案一是否合理?
• 不合理,这种方案依赖于所有元件的正确行为,如 果网络中有一个元件失效或发生错误,就不能保证 可靠性传输。
2.只保证低层的可靠性通信是否足够?
• 不够,如果端系统硬盘错误,仍不能保证可靠性, 因此,仍需要进行最终的正确性检验。
– 综上两个问题,得结论:可以在应用层实现完 整的可靠性检验功能,不需要保证低层的可靠 性。既然仍需要进行总的可靠性检验,不如放 弃低层的可靠性工作,还可以带来效率的提高。
8.1 互联网设计原则-原则
2.支持多种类型服务
• 增加UDP服务以更好的支持其他应用程序,如实时应用程 序。否则,就没有将TCP与IP区分开的必要了。 • 数据报抽象:将上层所需要的最基本的服务抽象出来在低 层实现,那些TCP和UDP服务可以在这些基本服务基础上 建立。在IP数据报的格式定义中,也考虑到了不同的服务, 例如TOS字段。
8.1 互联网设计原则
• 电话网 电话网:哑终端,网络智能
brain (smart) brick (dumb) lock (you can’t get in)
Hale Waihona Puke Baidu
8.1 互联网设计原则
• 互联网 互联网:网络简单,终端复杂
8.1 互联网设计原则
• 互联网端到端观点 互联网端到端观点(end-end augment):
8.1 互联网设计原则-端到端观点
• 关键问题 关键问题:
– 端到端原则强调:
• 功能放置问题 • 功能正确性,完整性 • 整个系统的代价
– 原则:
• 如果应用层可以实现一个功能,不要放到低层去做, 应用程序最清楚自己需要什么; • 把功能放到低层只在(1)可以提高性能(2)不会影响其 他应用程序 的情况下可以;
1.信任:区别哪些是可以信任的,哪些是不可信任的。 入口过滤,互联网UNI (user network interface, as in ATM)。 2.改变端节点:抗攻击,主机/路由器实现内容过滤, 分布式应用程序高质量的发送内容。 3.网络核心增加功能:过滤防火墙,应用层防火墙, NAT,主动网络。 下面就网络核心的增加功能进行分析:
8.1 互联网设计原则-端到端观点
• 分析 4.拥塞控制和流量控制为什么在传输层实现, 而不是在应用层和链路层实现?
(1)为什么放在传输层实现而不在应用层?
– 很多应用程序需要拥塞控制,但不需要每个程序都来 做这件事,而且有的程序并不关心有没有拥塞控制, 认为这是网络的事情,因此放在应用层不合适,放在 传输层可提高性能。 – 拥塞控制只负责那些基于TCP的应用程序数据传输, 且只要使用了TCP,就必须使用拥塞控制,这是统一 的代价。
8.1 互联网设计原则-原则
3.能够连接多种类型的物理网络
• 非常成功:原因是最低限度服务仅要求网络按照一个合理 的成功的可能性传递分组 • 并不要求可靠性和按次序传递 • IP over everything: 从IP互联网层面上看,都是IP网络, 将各个物理网络的数据传输功能抽象出来进行互联 – ARPANET, X.25, DARPA satellite network – ATM, SONET, WDM
• 争议的是对于互联网原则的习惯性理解:
– – – – 自由的行为 用户授权 端节点用户为行为负责 在网络中缺乏对用户行为的管理和限制
• 端到端观点产生了这一互联网原则,这一原则可 以保证创新的自由,用户可以自行安装软件,运 行自己选择的应用程序。
8.2互联网设计原则的重新思考
• 对于改变的技术回应: 对于改变的技术回应:
相关文档
最新文档