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

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