高级计算机网络考试重点内容八：网络架构(1)

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