分布式系统 Distributed Systems 第 2 讲 系统模型

Presentation on theme: "分布式系统 Distributed Systems 第 2 讲 系统模型"— Presentation transcript:

1 分布式系统 Distributed Systems 第 2 讲 系统模型
王晓阳、张 奇 复旦大学 计算机科学技术学院

2 授课计划 Lecture 1 - Characterization of Distributed Systems
Lecture 2 - System models Lecture 3 - Interprocess Communication Lecture 4 - Remote Invocation Lecture 5 - Indirect communication Lecture 6 - Map Reduce 1 Lecture 7 - Map Reduce 2 Lecture 8 - Time and Global States Lecture 9 - Coordination and Agreement Lecture 10 - Transactions and Concurrency Control Lecture 11 - Operating System Support Lecture 12 - Virtualization Lecture 13 - Distributed File Systems Lecture 14 - Mobile And Ubiquitous Computing Lecture 15 - Designing Distributed systems: Cases Study

3 目录 2.1 简介 2.2 物理模型 2.3 体系结构模型 2.4 基础模型 2.5 小结 2.4.1 交互模型 2.4.2 故障模型
2.3.1 体系结构元素 2.3.2 体系结构模式 2.3.3 相关中间件解决方案 2.4 基础模型 2.4.1 交互模型 2.4.2 故障模型 2.4.3 安全模型 2.5 小结

4 2.1 简介 不同类型的分布式系统具有一些重要的基本特征，也有 公共的设计问题 分布式系统的困难和威胁 使用模式的多样性 系统环境的多样性
不同类型的分布式系统具有一些重要的基本特征，也有 公共的设计问题 分布式系统的困难和威胁 使用模式的多样性 系统环境的多样性 内部问题 外部威胁

5 2.1 简介 物理模型 体系结构模型 基础模型 描述系统的最显式的方法，系统的硬件组成 描述系统的计算元素执行的计算和通讯任务
采用抽象的观点描述分布式系统的某个方面 交互模型、故障模型和安全模型

6 2.2 物理模型 物理模型是从计算机和所用网络技术的特定细节中抽象 出来的分布式系统底层硬件元素的表示 基线物理模型
物理模型是从计算机和所用网络技术的特定细节中抽象 出来的分布式系统底层硬件元素的表示 基线物理模型 联网计算机上的硬件和软件组件仅通过消息传递进行通信和协调动作的 系统 一组可以扩展的计算机节点，这些节点通过计算机网络相互连接进行所 需的消息传递

7 2.2 物理模型 早期的分布式系统 20世纪70年代晚期到80年代早期 局域网互联的10～100个节点组成 与互联网连接并支持少量的服务
单个系统大部分是同构的，开放性不是主要问题 服务数量有限

8 2.2 物理模型 互联网规模的分布式系统 20世纪90年代开始 Google搜索引擎1996年第一次发布 利用互联网，基础设施变成全球化
异构性问题很突出 操作系统、网络、计算机体系结构、语言、开发者 开放标准和相关中间件技术重要性不断增加

9 2.2 物理模型 当代的分布式系统 上述系统节点通常是台式机，因此相对静态的、分立的、自治的 分布式系统的趋势 泛在互联网技术
移动和无处不在的计算 分布式多媒体系统 分布式计算作为公共设施

10 2.2 物理模型 系统的分布式系统 超大规模分布式系统（Ultra Large Scale, ULS） 复杂系统 洪水预测管理系统
包含一系列的子系统 每个子系统本身也是系统 一起完成一个或多个特定任务 洪水预测管理系统 传感器网络 环境参数 集群计算机模拟系统

11 Figure 2.1 Generations of distributed systems
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn © Pearson Education 2012

12 2.3 体系结构模型 一个系统的体系结构是用独立指定的组件以及这些组件 之间的关系来表示的结构
一个系统的体系结构是用独立指定的组件以及这些组件 之间的关系来表示的结构 整体目标是确保结构能够满足现在和将来可能的需求 主要设计目标 可靠性 可管理性 适应性 性价比

13 2.3 体系结构模型 2.3.1. 体系结构元素 2.3.2. 体系结构模式 2.3.3. 相关中间件解决方案
支撑现在分布式系统的核心基本元素 体系结构模式 分布式系统解决方案中单独或组合使用的体系结构模式 相关中间件解决方案

14 2.3.1 体系结构元素 四个关键问题 通信的实体是什么？ 它们如何保持通信，使用什么通信范型？ 扮演什么角色，承担什么责任？
如何被映射到物理分布式基础设施上？

15 2.3.1 体系结构元素 通信实体 从系统角度来看，分布式系统中通信的实体通常是进程 注意：
一些原始环境中（如：传感器网络），操作系统可能不支持进程抽象， 因此这些系统中通信的实体是结点 大多数分布式系统中，用线程补充进程。

16 2.3.1 体系结构元素 从编程观点来看，面向问题有更多的抽象： 对象： 组件： Web服务：
在分布式系统中使用面向对象方法；对象通过接口访问，用一个相关的 接口定义语言（IDL）提供定义在一个对象上的方法的规约 组件： 与对象类似，通过接口访问；与对象的区别是，显式的给出其他组件/ 接口的假设 Web服务： 基于行为封装和通过接口访问 利用Web标准表示和发现服务

17 2.3.1 体系结构元素 通信范型—分布式系统中实体如何通信 进程间通信 远程调用 间接通信

18 2.3.1 体系结构元素 进程间通信 是指用于分布式系统进程之间通信的相对底层的支持，包括消息传递原 语、直接访问由互联网协议提供的API和对多播通信的支持。 远程调用 是分布式系统中最常见的通信范型，覆盖一系列分布式系统中通信实体 之间基于双向交换的技术，包括调用远程操作、过程或方法。 请求—应答协议 构建在底层消息传递服务至上，用于支持客户—服务器计算。 通常涉及一对消息的交换，消息从客户到服务器，接着从服务器返回客户。 远程过程调用（Remote Procedure Call，RPC） 远程计算机上进程中的过程调用与本地调用一致

19 2.3.1 体系结构元素 远程调用 上述技术的共同点： 远程方法调用（Remote Method Invocation, RMI）
与远程过程调用类似，但仅应用于分布式对象环境 底层细节对用户隐藏 上述技术的共同点： 通信代表发送者和接收者之间的双向关系 发送者显式地把消息/调用送往相关的接收者 接收者通常了解发送者的标识 大多数情况下，双方必须同时存在

20 2.3.1 体系结构元素 间接通信 通过第三个实体，允许在发送者和接收者之间的深度解耦合 组通信 发布—订阅系统 消息队列
发送者不需要知道正在发送给谁（空间解耦合） 发送者和接收者不需要同时存在（时间解耦合） 组通信 组通信涉及消息传递给若干接收者，是支持一对多通信的多方通信泛型 发布—订阅系统 大量生产者（或发布者）为大量的消费者（订阅者）发布他们感兴趣的信息项 关键特征：中间服务---用于确保由生产者生成的信息被路由到需要这个信息的消费者 消息队列 提供点对点服务 生产者发送消息到指定队列，消费者能从队列中接收消息，或者被通知队列有消息到达

21 2.3.1 体系结构元素 间接通信 元组空间 分布式共享内存（Distributed Shared Memory，DSM）
进程可以把任意的结构化数据项（元组）放到一个持久元组空间，其他进程可以指定感兴 趣的模式，从而可以在元组空间读取或者删除元组。 分布式共享内存（Distributed Shared Memory，DSM） 系统提供一种抽象，用于支持在不同共享物理内存的进程之间共享数据

22 2.3.1 体系结构元素 Figure 2.2 Communicating entities and communication paradigms Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn © Pearson Education 2012

23 Figure 2.3 Clients invoke individual servers
2.3.1 体系结构元素 角色和责任 进程相互交互完成一个有用的活动 进程在系统中扮演给定的角色 客户---服务器 Figure 2.3 Clients invoke individual servers

24 2.3.1 体系结构元素 客户---服务器模式直接、简单，但是伸缩性差，集中化 的提供服务和管理，受到计算机处理资源和网络带宽等 资源条件限制大 对等体系结构 不区分客户和服务器或运行它们的计算机 所有参与进程运行相同的程序并且在相互之间提供相同的接口集合 目的是利用大量参与的计算机的资源来完成某个给定的任务或活动 Eg. BitTorrent

25 Figure 2.4a Peer-to-peer architecture
2.3.1 体系结构元素 Figure 2.4a Peer-to-peer architecture

26 2.3.1 体系结构元素 放置 对象或者服务这样的实体如何映射到底层物理分布基础设施
物理分布基础设施由大量机器组成，机器通过任意复杂的网络互联 决定了分布式系统的特性：性能、可靠性、安全性 如何放置客户和服务器需要仔细设计 考虑实体间的通信模式 机器的可靠性和负载 不同机器间通信质量 通用的指导方针

27 Figure 2.4b A service provided by multiple servers
2.3.1 体系结构元素 将服务映射到多个服务器 一个服务实现为一个单独主机上的几个服务器进程，必要时进行交互以 便为客户进程提供服务 服务器可以将服务所基于的对象分区将这些分区分部到各个服务器上 服务器可以在几个主机上维护复制的对象集 Figure 2.4b A service provided by multiple servers

28 Figure 2.5 Web proxy server
2.3.1 体系结构元素 缓存 用于存储最近使用的数据对象 当服务器接收到一个新对象时，将它存入缓存，必要时进行更新替换 当客户需要一个对象时，缓存服务首先检查缓存 如果有最新的拷贝，则直接提供缓存中的对象 如果没有可用对象，则去取一个最新的拷贝 Figure 2.5 Web proxy server

29 2.3.1 体系结构元素 移动代码 Figure 2.6 Web applets

30 2.3.1 体系结构元素 移动代理 是一个运行的程序（包括代码和数据），它从一台计算机移动到网络上 的另一台计算机，完成指定任务，最后返回结果。 一个移动代理可能多次调用所访问地点的本地资源 比较销售商价格、Xerox PARC蠕虫程序 移动代码与移动代理一样，对所访问的计算机而言是一个潜在的威胁

31 2.3.2 体系结构模式 体系结构模式构建在体系结构元素之上，提供组合的、 重复出现的结构
体系结构模式构建在体系结构元素之上，提供组合的、 重复出现的结构 分布式系统的体系结构模式是核心，同时也是一个很大 的主题，本节介绍几个关键的体系结构模型 分层体系结构 层次化体系结构 瘦客户

32 2.3.2 体系结构模式 分层体系结构 与抽象紧密相关 一个复杂的系统被分成若干层 每层利用下层提供的服务
Figure 2.7 Software and hardware service layers in distributed systems

33 2.3.2 体系结构模式 平台 中间件 一个服务于分布式系统的应用的平台由最底层的硬件和软件层组成
Intel x86/Windows， Intel x86/Mac OS X, ARM/Linux等 中间件 定义为一个软件层，目的是屏蔽异构性 表示成一组计算机上的进程或对象，相互交互实现分布式应用的通信和 资源共享支持 通过对抽象的支持提升应用程序通信活动的层次

34 2.3.2 体系结构模式 层次化体系结构 层次化体系结构与分层体系结构互补的 分层将服务垂直组织成抽象层 层次化用于组织给定层的功能
把某个功能放在合适的服务器或物理节点上 主要与应用和服务的组织最相关，但也可以应用于所有层 考虑如下一个给定应用的功能分解： 表示逻辑 应用逻辑 数据逻辑

35 Figure 2.8 Two-tier and three-tier architectures
2.3.2 体系结构模式 Figure 2.8 Two-tier and three-tier architectures

36 2.3.2 体系结构模式 AJAX（Asynchronous Javascript And XML） 标准Web交互流程
浏览器发送HTTP请求给服务器，请求制定的URL页面、图像或其他资源 服务器发送整个页面作为应答 由服务器上一个文件读取、或者由一个程序生成 浏览器根据其MIME类型相关显示方式呈现

37 2.3.2 体系结构模式 标准交互方式的约束 JavaScript是跨平台、跨浏览器语言，能下载到浏览器中 并执行
一旦浏览器发送了一个新的Web页面请求，用户不能与页面交互，直到 html内容被浏览器收到并呈现，这个时间间隔不确定 为了用来自服务器的额外数据修改当前页面的一小部分，也需要请求和 显示整个新的页面 客户显示的页面内容不能被更新 JavaScript是跨平台、跨浏览器语言，能下载到浏览器中 并执行

38 Figure 2.9 AJAX example: soccer score updates
2.3.2 体系结构模式 需要Web应用允许用户访问和更新大量共享数据集 数据集通常很大，还可能是动态的 用户一次更新数据量较少 AJAX提供了一套通信机制 运行在浏览器的前端组件能发送请求，并从运行在服务器上的后端组件 接收结果 Figure 2.9 AJAX example: soccer score updates

39 2.3.2 体系结构模式 瘦客户 分布式计算的趋势是将复杂性从最终用户设备移向互联网服务
它使得能以很少的对客户设备的假设或需求，获得对复杂网络化服务的 访问，这些服务可以通过云解决方案提供 指的是一个软件层，在执行一个应用程序或访问远程计算机上的服务时， 由该软件层提供一个基于窗口的本地用户界面 Figure 2.10 Thin clients and compute servers

40 2.3.2 体系结构模式 瘦客户端的优势 瘦客户端的缺点 虚拟网络计算（Virtual Network Computing, VNC）
极大的简化了本地设备 瘦客户端的缺点 交互频繁的图形活动中，受到网络和操作系统的影响大 虚拟网络计算（Virtual Network Computing, VNC） 为远程访问提供图形用户界面 RealVNC 软件解决方案 Adventiq硬件解决方案

41 Figure 2.11 The web service architectural pattern
2.3.2 体系结构模式 其他经常出现的模式 代理（Proxy） 提供远程过程调用或远程方法调用的位置透明 Web服务中的业务代理（Brokerage） 复杂分布式基础设施中支持互操作性的体系结构 反射（Reflection） Introspection （系统动态发现的特性） Intercession（动态修改结构或行为的能力） Figure 2.11 The web service architectural pattern

42 2.3.3 相关的中间件解决方案 中间件的任务是为分布式系统的开发提供一个高层的编 程抽象，通过分层对底层基础设施中的异构性提供抽象， 从而提升互操作性和可移植性 中间件的类别 中间件的限制

43 Figure 2.12 Categories of middleware
2.3.3 相关的中间件解决方案 中间件的类别 远程过程调用包和组通信，之后出现了大量不同风格的中间件 Figure 2.12 Categories of middleware

44 2.3.3 相关的中间件解决方案 中间件的限制 依靠中间件支持的开发，能大大简化分布式系统变成 但系统可依赖性的一些方面要求应用层面的支持
发送，构建在TCP之上 Saltzer, Redd, Clarke的观点是：通信相关功能可以只依靠通信系统终点的 应用的知识和帮助，即可完整、可靠的实现。

45 2.4 基础模型 系统模型各有不同，但具有一些基本特征 所有模型都由若干进程组成 进程之间通过在计算机网络上发送消息而相互通信
共享的设计需求 进程及网络的性能和可靠性 系统中资源安全 基础模型的目的是： 显式的表示有关我们正在建模的系统的假设 给定这些假设，就什么是可能的、什么是不可能的给出结论

46 2.4 基础模型 基本模型中提取的分布式系统能解决下列问题： 交互 故障 安全
计算在进程中发生，进程通过传递消息交互，并引发进程之间的通信和协调 交互模型必须反映通信所带来的延迟 故障 分布式系统中任一计算机出现故障或连接他们的网络出现故障，分布式系统的正确操作就 会受到威胁 模型要对这些故障进行定义、分类、分析和容忍 安全 分布式系统的模块特性和开放性，使其暴露在外部代理和内部代理的攻击下 分析系统的威胁以及设计抵御这些威胁的系统

47 2.4.1 交互模型 分布式系统由多个以复杂方式进行交互的进程组成，例如： 算法---采取一系列步骤以执行期望的计算
多个服务器进程进行相互协作提供服务 对等进程能相互协作获得一个共同的目标 算法---采取一系列步骤以执行期望的计算 算法中的每一步都有严格的顺序 算法决定程序的行为和程序变量的状态 分布式算法---定义了组成系统的每个进程所采取的步骤 包括进程之间的消息传递，以便协调每个进程所采取的步骤 每个进程的执行速率和进程之间消息传递的时限通常不能预测，因此描述分 布式算法的所有状态也十分困难，要处理所涉及的一个或多个进程的故障或 消息传递的故障

48 2.4.1 交互模型 进程交互完成了分布式系统中所有的活动 每个进程有自己的状态，该状态由进程能访问和更新的 数据集组成
每个进程有自己的状态，该状态由进程能访问和更新的 数据集组成 属于每个进程的状态是私有的 影响进程交互的两个重要因素： 通信性能经常是一个限制特性 不可能维护一个全局时间概念

49 2.4.1 交互模型 通信信道的性能 通信信道在分布式系统中可用许多方法实现 计算机网络上的通信有下列性能特征： 延迟（Latency）
计算机网络上的流或简单消息传递 计算机网络上的通信有下列性能特征： 延迟（Latency） 从一个进程开始发送消息到另一个进程开始接收消息之间的间隔时间称为延迟 带宽（Bandwidth） 给定时间内网络能传递的信息总量 抖动（Jitter） 传递一系列消息所花费的时间的变化值

50 2.4.1 交互模型 计算机时钟和时序事件 分布式系统中每台计算机有自己的内部时钟 不同计算机的时钟会提供不同的值 计算机时钟和绝对时间之间有偏移，每台计算机的偏移率互不相同 时钟漂移率 指的是计算机时钟偏离绝对参考时钟的比率 即使分布式系统中所有计算机时钟在初始情况下都设置 成相同时间，它们的时钟最后也会相差巨大，除非进行 校正

51 2.4.1 交互模型 时钟的校正方法 GPS，以大约1μs的精度接收时间读数 具有精确时间源的计算机可以发送时序消息给网络中其他计算机
详细会在14章中进行介绍

52 2.4.1 交互模型 交互模型的两个变体 Pepperland协定 同步分布式系统 异步分布式系统——对下列因素没有限制的系统
进程执行每一步的时间有一个上限和下限 通过通道传递的每个消息在一个已知的时间范围内接收到 每个进程有一个本地时钟，与实际时间的偏移率在一个已知的范围内 异步分布式系统——对下列因素没有限制的系统 进程执行速度 消息传递延迟 时钟漂移率 对异步分布式系统有效的任何解决方案对于同步系统同样有效 Pepperland协定 红师和蓝师在邻近两座山的山顶

53 Figure 2.13 Real-time ordering of events
2.4.1 交互模型 事件排序 许多情况下我们需要知道一个进程中的一个事件（发送或接受一个消息） 是发生在另一个进程的另一个事件之前、之后或同时。 例如： X,Y,Z,A之间的邮件交换 X发送主题Meeting的消息 Y读取并回复它 Z读取X消息和Y的回复并 发送另外一个回复 Figure 2.13 Real-time ordering of events

54 2.4.1 交互模型 如果X,Y,Z计算机上的时间可以同步，每个消息发送时可 以携带本地时间戳，那么消息可以按照正常的顺序排列
如果一个分布式系统中时间不能精确同步，Lamport提 出了逻辑时间的模型，为在分布式系统中运行于不同计 算机上的进程的事件提供顺序 使用逻辑时间不需要借助时钟就可以推断出消息的顺序

55 2.4.2 故障模型 分布式系统中，进程和通信通道都可能出故障 故障模型定义了故障可能发生的方式，以便理解故障所 产生的影响 遗漏故障
故障模型定义了故障可能发生的方式，以便理解故障所 产生的影响 遗漏故障 随机故障 时序故障

56 2.4.2 故障模型 遗漏故障 是指进程或者通信通道不能完成它应该做的动作 进程遗漏故障中最常见的是进程崩溃
崩溃检测方法依赖超时的使用 异步系统中超时只能表明进程没有响应 崩溃 执行速度慢 消息没有送达 故障—停止，如果能够确切检测到进程崩溃 同步系统中，确定消息送达后，超时可用于检测故障—停止行为 例如：P和Q两个进程，Q应答P的消息，如果进程P按照本地时间度量最大超时范围内还 没有收到Q的消息，那么P可以得出结论：Q进程出现了故障

57 Figure 2.14 Processes and channels
2.4.2 故障模型 通信遗漏故障 通信原语send和receive 进程p将消息m插入到它外发消息缓冲区来执行send 通信通道将m传输到q的接受消息缓冲区 进程q通过将m从接受消息缓冲区取走并完成传递来执行receive Figure 2.14 Processes and channels

58 2.4.2 故障模型 如果通信信道不能将消息从p传递到q，那么就产生了遗 漏故障 发送遗漏故障 接收遗漏故障 通道遗漏故障
接收端或中间网关缺乏缓冲区 网络传输错误 发送遗漏故障 接收遗漏故障 通道遗漏故障

59 2.4.2 故障模型 故障检测 面对通信故障时达成协定的不可能性 Pepperland，同步系统，异步系统
Ringo证明， Pepperland环境中，在通信不能保证的情况下，两师不能一 致的决定做什么

60 2.4.2 故障模型 随机故障（拜占庭故障） 用于描述可能出现的最坏的故障，此时可能发生任何类型的错误 进程的随机故障 通信信道随机故障
例如：一个进程可能在数据项中设置了错误的值，响应一个调用返回一个错误的值 进程的随机故障 是指进程随机地省略要做的处理步骤或执行一些不需要的处理步骤 不能通过查看进程是否应答调用来检测 通信信道随机故障 例如：消息内容被破坏或传递不存在的消息，也可能多次传递实际消息 通信软件可以识别这类故障并拒绝出错的消息

61 2.4.2 故障模型 Class of failure Affects Description Fail-stop Process
Process halts and remains halted. Other processes may detect this state. Crash Process Process halts and remains halted. Other processes may not be able to detect this state. Omission Channel A message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer. Send-omission Process A process completes a send, but the message is not put in its outgoing message buffer. Receive-omission Process A message is put in a process’s incoming message buffer, but that process does not receive it. Arbitrary Process or Process/channel exhibits arbitrary behaviour: it may (Byzantine) channel send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step. Figure 2.15 Omission and arbitrary failures

62 Figure 2.11 Timing failures
2.4.2 故障模型 时序故障 时序故障适用于同步分布式系统 对进程执行时间、消息传递时间和时钟漂移率均有要求 Figure 2.11 Timing failures

63 2.4.2 故障模型 时序故障 异步分布式系统中，一个负载过重的服务器响应时间可能很长，但我们 不能说它有时序故障
异步分布式系统中，一个负载过重的服务器响应时间可能很长，但我们 不能说它有时序故障 实时操作系统是以提供时序保证为目的而设计的 设计复杂 需要冗余硬件保障 大多数通用操作系统不能满足实时约束 时序与音频和视频通道的多媒体计算关系尤为密切

64 2.4.2 故障模型 故障屏蔽 分布式系统中的每个组件通常是基于其他一组组件构造的 利用存在故障的组件构造可靠的服务是可能的
例如：有数据副本的多个服务器中一个服务器崩溃时能继续提供服务 一个服务通过隐藏故障或者转换为一个更能接受的故障类型来屏蔽故障 例如：通过校验可以屏蔽错误消息，将随机故障转化为遗漏故障

65 2.4.2 故障模型 一对一通信的可靠性 可靠通信可从下列角度定义： 有效性：外发消息缓冲区中的任何消息最终能传递到接受消息缓冲区
完整性：接收到的消息与发送消息一致，没有消息被传递两次

66 2.4.3 安全模型 体系结构模型：进程，进程间交互 通过保证进程和用于进程交互的通道的安全以及保护所 封装的对象免遭未经授权访问可实现分布式系统安全

67 Figure 2.17 Objects and principals
2.4.3 安全模型 保护对象 Figure 2.17 Objects and principals

68 2.4.3 安全模型 保护对象 对象可由不同的客户按照不同的方式调用 访问权限指定了允许谁执行一个对象的操作
需要将每个调用和每个结果均与对应的授权方相关联 一个授权方成为一个主体（principal） 一个主体可以是一个用户或进程 服务器验证每个调用的主体身份，检查是否有足够的访问权限在所调用 的某个对象上完成所请求的操作，如果没有就拒绝它们的请求。客户可 以检查服务器的主体身份以确保结果来自所请求的服务器

69 2.4.3 安全模型 保护进程和它们的交互 分布式系统经常在可能受到来地敌对用户的外部攻击的 任务中使用和部署。
进程通过消息进行交互 消息易收到攻击 所使用的网络和通信服务是开放的 服务器和对等进程暴露它们的接口 分布式系统经常在可能受到来地敌对用户的外部攻击的 任务中使用和部署。 为了识别和抵御这些威胁，需要分析安全威胁的模型。

70 2.4.3 安全模型 敌人 假定敌人能给任何进程发送任何消息，并能读取或复制一对进程之间的 任何消息。
假定敌人能给任何进程发送任何消息，并能读取或复制一对进程之间的 任何消息。 攻击可能来自合法连接到网络的计算机或以非授权的方式连接到网络的 计算机 Figure 2.18 The enemy

71 2.4.3 安全模型 敌人 潜在敌人的威胁包括对进程的威胁和对通信信道的威胁 对进程的威胁 对通信信道的威胁
处理到达的请求的进程可以出接收来自其他进程的消息，但是未必能能确定发送方的身份 缺乏消息源的可靠的知识对服务器和客户的正确工作而言是一个威胁 服务器 客户 对通信信道的威胁 对人在网络和网关上能复制、改变或插入消息 试图保存消息的拷贝并在以后重放这个消息 利用安全信道可以解除这些威胁

72 2.4.3 安全模型 解除安全威胁 密码学和共享秘密 密码学 认证 假设一对进程共享一个秘密
如果一对进程交换的消息包括证明发送方共享秘密的信息，那么接收方就能确认发送方是 一对进程中的另一个进程 密码学 保证消息安全的科学 加密是将消息编码以隐藏其内容的过程 认证 证明由发送方提供的身份 基础是共享秘密和加密 在消息中包含加密部分，该部分中包含足够的消息内容以保证它的真实性

73 Figure 2.19 Secure channels
2.4.3 安全模型 解除安全威胁 安全通道 是连接一对进程的通信通道 加密和认证用于构建安全通道，安全通道作为已有的通信服务层之上的服务层 具有以下特征 每个进程确切的知道其他正在执行的进程所代表的主体身份 安全通道确保在其上传送的数据的私密性和完整性 每个消息包括一个物理的或逻辑的时间戳以防消息被重放或重排序 Figure 2.19 Secure channels

74 2.4.3 安全模型 其他可能的来自敌人的威胁 安全模型的使用 拒绝服务 移动代码 安全技术和访问控制的使用会产生实质性的处理和管理开销
通过超量地、无意义地调用服务或在网络上进行消息传送，干扰授权用户的活动，导致物 理资源的过载 移动代码 如果进程接收和执行来自其他地方的程序代码，那么这些移动代码就会来带新的安全问题。 特洛伊木马，生成完全无害的事情但事实上包括了访问或修改资源的代码 安全模型的使用 安全技术和访问控制的使用会产生实质性的处理和管理开销 需要对系统网络环境、物理环境和人际环境等进行评估分析

75 Question?