《分布式系统原理与范型 (第二版)》复习资料
《分布式系统原理与范型：第2版》原书课件第2章
Figure 2-4. The simplified organization of an Internet search engine into three different layers.
•Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Structured Peer-to-Peer Architectures (2)
Figure 2-8. (a) The mapping of data items onto nodes in CAN.
•Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Multitiered Architectures (1)
The simplest organization is to have only two types of machines:
• A client machine containing only the programs implementing (part of) the userinterface level
Figure 2-9. (a) The steps taken by the active thread.
分布式系统 原理与范型
分布式系统原理与范型分布式系统是由多台计算机通过网络连接，共同协作完成任务的系统。
它具有高性能、高可靠性、可扩展性等优点，被广泛应用于大规模的数据处理、并行计算、云计算等领域。
在分布式系统中，各个计算机之间彼此独立，通过消息传递进行通信和协调，没有共享内存。
分布式系统的原理主要包括：并发性、透明性、故障容错、可扩展性和一致性。
首先是并发性原理，分布式系统中的多个计算机并行地执行任务，能够提高系统的处理能力。
并发性可以通过多线程、多进程等方式来实现，并且需要解决同步、互斥、死锁等并发控制问题。
其次是透明性原理，分布式系统希望对用户来说，就像是一个单一的计算机系统，隐藏了分布式部署的复杂性。
透明性包括：访问透明性（用户无感知地访问分布式系统）、位置透明性（用户无需关心数据的物理位置）、迁移透明性（用户无需关心资源在系统中的迁移）、复制透明性（用户无需关心数据的副本）、并发透明性（用户无需关心并发访问的问题）等。
第三是故障容错原理，分布式系统中的计算机节点可能会发生故障，为了保证系统的可靠性，需要进行故障检测、故障恢复和容错处理。
例如，使用冗余备份、错误检测和纠错码等技术来检测和修复故障，确保系统可以继续正常运行。
第四是可扩展性原理，分布式系统需要能够方便地扩展计算资源，以应对数据量和任务量的增长。
可扩展性可以通过水平扩展和垂直扩展来实现。
水平扩展是增加计算机节点的数量，垂直扩展是增加单个计算机节点的处理能力。
最后是一致性原理，分布式系统中的数据可能被存储在不同的节点上，而多个节点之间需要保持一致的数据视图。
一致性可以通过强一致性和弱一致性来实现。
强一致性要求所有的节点都能观察到同样的数据视图，而弱一致性则容忍一定的数据不一致性。
分布式系统有多种范型，包括客户端-服务器模型、对等模型、发布-订阅模型等。
客户端-服务器模型是最常见的分布式系统范型，其中一台计算机作为服务器提供服务，而其他计算机作为客户端请求服务。
《分布式系统原理与范型(第2版) 》课后习题答案
第一章1.分布式系统的另一个定义，它是各自独立的计算机的集合，这些计算机看起来像是一个单的系统，就是说，它对用户是完全隐藏的，即使他有多个计算机也是如此。
请给出一个实例。
答：并行计算。
一个程序在一个分布式的系统中运行，但看起来是在单个系统中运行的。
2.中间件在分布式系统中扮演什么角色？答：中间件主要是为了增强分布式系统的透明性（这正是网络操作系统所缺乏的），换言之，中间件的目标是分布式系统的单系统视图，即使种类各异的计算机和网络都呈现为单个系统。
3.很多网络系统组织成后端办公系统和前端办公系统。
这种组织方式是如何满足分布式系统要求的？答：一个比较容易犯错的地方就是假设运行在一个组织下的分布式系统，应该运行在系统的整个组织框架下。
实际上，分布式系统被安装在一个分离的组织中。
从这层意义上讲，我们的分布式系统可以支持独立的后端处理和前端处理。
当然，这两部分可能是耦合的，并不需要要求这个耦合的部分完全透明。
4.解释（分布）透明性的含义，并且给出各种类型透明性的例子。
答：分布透明性是一种现象，即一个系统的分布情况对于用户和应用来说是隐藏的。
包括：访问透明：分布式系统中的多个计算机系统运行可能是不同的操作系统，这些操作系统的文件命名方式不同，命名方式的差异以及由此引发的文件操作方式的差异应该对用户和应用程序隐藏起来。
位置透明：从/index.htm这个url看不出parentice hall 的主web服务器所在的位置，同时也看不出index.html的位置情况。
移植透明：分布式系统中的资源移动不会影响该资源的访问方式。
重定位透明：资源可以在接受访问的同时进行重新定位，而不引起用户和应用系统的注意。
移动通信用户从一个点到另一个点，可以一直使用移动设备，而无中断连接。
复制透明：对同一个资源存在多个副本这样一个事实的隐藏。
所有的副本同名。
并发透明：访问位于同一个共享数据库中的一批表。
故障透明：用户不会注意到某个资源无法正常工作，以及系统随后的恢复过程。
分布式数据库系统复习材料
分布式数据库系统复习材料在学习和复习分布式数据库系统时，需要掌握以下几个关键知识点：1.分布式数据库架构：分布式数据库系统可以采用集中式架构、两层架构、三层架构等不同的架构模式。
其中集中式架构通过一个中央服务器管理所有的数据，两层架构将数据分为客户端和服务器两部分进行管理，三层架构引入中间层服务器来协调不同的功能和数据层。
2.分布式数据库一致性：分布式数据库系统需要保证数据的一致性。
数据的一致性可以通过ACID原则来保证，即原子性、一致性、隔离性和持久性。
此外，还可以使用分布式事务来保证数据的一致性，分布式事务可以通过两阶段提交（2PC）或者三阶段提交（3PC）来实现。
3.分布式数据库的查询：分布式数据库系统可以进行分布式查询，即将查询请求分发给不同的节点进行处理。
常用的查询分发策略包括哈希分发、范围分发和复制分发。
哈希分发根据查询内容的哈希值将查询请求分发到对应的节点上，范围分发根据数据的范围将查询请求分发到对应节点上，复制分发将查询请求分发到多个节点上进行处理。
4.分布式数据库的数据复制：分布式数据库系统可以通过数据复制来提高数据的可靠性和性能。
数据复制可以采用同步复制或者异步复制方式。
同步复制要求数据在所有节点上都写入成功后才算成功，而异步复制则可以先将数据写入一个节点，然后再异步地将数据复制到其他节点上。
5.分布式数据库的容错与恢复：分布式数据库系统需要具备容错和恢复机制，以应对节点故障或者网络故障等异常情况。
常用的容错机制包括故障检测、容错存储和故障恢复。
故障检测可以通过心跳机制或者节点监视来实现，容错存储可以通过数据备份或者数据冗余来实现，故障恢复可以通过副本恢复或者数据迁移来实现。
6.分布式数据库的性能优化：分布式数据库系统可以通过多种方式来优化性能。
常用的性能优化方法包括数据分片、负载均衡和缓存机制。
数据分片可以将数据分散到不同的节点上，以减轻节点的负载；负载均衡可以将查询请求均匀地分发到各个节点上，以提高查询的响应速度；缓存机制可以将频繁查询的数据缓存在节点上，以减少磁盘访问，提高查询性能。
分布式系统原理与范型pdf
分布式系统原理与范型pdf分布式系统是指一个由多个自治计算机共同组成的系统，这些计算机互相协作，为用户提供统一的服务。
在分布式系统中，通信、协作和管理都是非常重要的，因此在分布式系统中使用了一些特殊的技术和思想来处理这些问题。
分布式系统的原理可以分为以下几个方面：1. 分布式系统的目标分布式系统的目标是通过将计算机资源划分为更小且互相独立的单元来提高计算机系统的可靠性和性能。
这些单元之间通过消息传递进行通信协作，从而实现共同完成任务的目标。
2. 数据管理在分布式系统中，数据通常被分散在不同的节点上。
要保证数据的一致性和可靠性，需要采用特定的算法和机制来实现数据管理。
3. 通信协议分布式系统中需要通过网络进行节点之间的通信。
因此，需要选择合适的通信协议，以保证通信的可靠性和效率。
4. 容错性由于分布式系统中的节点可能会发生故障或失效，因此需要采用一定的容错机制，以保证系统的可靠性和稳定性。
5. 安全性分布式系统中的数据和资源往往非常重要，因此需要采用一些安全机制来保护系统的安全性。
分布式系统的范型可以分为以下几个方面：1. 数据共享分布式系统中的节点通常需要共享数据。
为了保证数据的一致性，需要采用特殊的数据共享算法来实现。
2. 任务分配分布式系统中的各个节点通常需要协同完成任务。
为了实现任务分配，需要采用特殊的任务分配算法。
3. 负载均衡分布式系统中的各个节点的负载可能不均衡，为了充分利用系统的资源，需要采用负载均衡算法。
4. 分布式计算分布式系统中的各个节点可以通过分布式计算来实现高性能计算。
5. 分布式文件系统分布式文件系统可以将文件分散储存在不同的节点中，从而实现高效的文件共享和管理。
总之，分布式系统是当前非常重要的研究领域，有着广泛的应用前景。
了解分布式系统的原理和范型是非常必要的，有助于我们更好地理解和应用分布式系统。
分布式系统：原理与范式第二版答案
PRENTICE HALL
UPPER SADDLE RIVER, NJ 07458
SOLUTIONS TO CHAPTER 1 PROBLEMS 1. Q: An alternative definition for a distributed system is that of a collection of independent computers providing the view of being a single system, that is, it is completely hidden from users that there even multiple computers. Give an example where this view would come in very handy. A: What immediately comes to mind is parallel computing. If one could design programs that run without any serious modifications on distributed systems that appear to be the same as nondistributed systems, life would be so much easier. Achieving a single-system view is by now considered virtually impossible when performance is in play. 2. Q: What is the role of middleware in a distributed system? A: To enhance the distribution transparency that is missing in network operating systems. In other words, middleware aims at improving the single-system view that a distributed system should have. 3. Q: Many networked systems are organized in terms of a back office and a front office. How does organizations match with the coherent view we demand for a distributed system? A: A mistake easily made is to assume that a distributed system as operating in an organization, should be spread across the entire organization. In practice, we see distributed systems being installed along the way that an organization is split up. In this sense, we could have a distributed system supporting backoffice procedures and processes, as well as a separate front-office system. Of course, the two may be coupled, but there is no reason for letting this coupling be fully transparent. 4. Q: Explain what is meant by (distribution) transparency, and give examples of different types of transparency. A: Distribution transparency is the phenomenon by which distribution aspects in a system are hidden from users and applications. Examples include access transparency, location transparency, migration transparency, relocation transparency, replication transparency, concurrency transparency, failure transparency, and persistence transparency. 5. Q: Why is it sometimes so hard to hide the occurrence and recovery from failures in a distributed system? A: It is generally impossible to detect whether a server is actually down, or that it is simply slow in responding. Consequently, a system may have to report that a service is not available, although, in fact, the server is just slow.
分布式系统原理与范型 课堂重点
1. INTRODUCTION+ 1.1. DEFINITION OF A DISTRIBUTED SYSTEM + 1.2. GOALS+ 1.2.1. Making Resources Accessible++ 1.2.2. Distribution Transparency++Types of Transparency++Degree of Transparencyo 1.2.3. Opennesso Separating Policy from Mechanism++ 1.2.4. Scalability++Scalability Problems++Scaling Techniques++ 1.2.5. Pitfalls+ 1.3. TYPES OF DISTRIBUTED SYSTEMS+ 1.3.1. Distributed Computing Systems+Cluster Computing Systems+Grid Computing Systems+ 1.3.2. Distributed Information Systems+Transaction Processing Systems+Enterprise Application Integration+ 1.3.3. Distributed Pervasive Systems+Home Systems+Electronic Health Care Systems+Sensor Networkso 1.4. SUMMARY2. ARCHITECTURES++ 2.1. ARCHITECTURAL STYLES2.2. SYSTEM ARCHITECTURES++ 2.2.1. Centralized Architectures++Application Layering++Multitiered Architectures+ 2.2.2. Decentralized Architectures++Structured Peer-to-Peer Architectures+Unstructured Peer-to-Peer Architectureso Topology Management of Overlay Networks o Superpeers+ 2.2.3. Hybrid Architectures+Edge-Server Systems+Collaborative Distributed Systems+ 2.3. ARCHTECTURES VERSUS MIDDLEWARE + 2.3.1. Interceptors+ 2.3.2. General Approaches to Adaptive Software + 2.3.3. Discussion +l+ 2.4. SELF-MANAGEMENT IN DISTRIBUTED SYSTEMS++ 2.4.1. The Feedback Control Modelo 2.4.2. Example: Systems Monitoring with Astrolabe+ 2.4.3. Example: Differentiating Replication Strategies in Globuleo 2.4.4. Example: Automatic Component Repair Management in Jade o 2.5. SUMMARY+ 3. PROCESSES+ 3.1. THREADS+ 3.1.1. Introduction to Threads+Thread Usage in Nondistributed Systems+Thread Implementation+ 3.1.2. Threads in Distributed Systems+Multithreaded Clients+Multithreaded Servers+ 3.2. VIRTUALIZATION+ 3.2.1. The Role of Virtualization in Distributed Systems++ 3.2.2. Architectures of Virtual Machineso 3.3. CLIENTSo 3.3.1. Networked User Interfaceso Example: The X Window Systemo Thin-Client Network Computingo Compound Documents+ 3.3.2. Client-Side Software for Distribution Transparency+ 3.4. SERVERS3413.4.. General Design IssuesGenera Design Issues+ 3.4.2. Server Clusters+General Organizationo Distributed Servers+ 3.4.3. Managing Server Clusters+Common Approaches++Example: PlanetLabo 3.5. CODE MIGRATIONo 3.5.1. Approaches to Code Migrationo Reasons for Migrating Codeo Models for Code Migrationo 3.5.2. Migration and Local Resourceso 3.5.3. Migration in Heterogeneous Systemso 3.6. SUMMARY+ 4. COMMUNICATIONems o 4.1.FUNDAMENTALS o 4.1.1.Layered Protocols oLower-Level Protocols oTransport Protocols oHigher-Level Protocols oMiddleware Protocols ++ 4.1.2.Types of Communication ++ 4.2.REMOTE PROCEDURE CALL ++ 4.2.1.Basic RPC Operation ++Conventional Procedure Call ++Client and Server Stubs ++ 4.2.2.Parameter Passing ++Passing Value Parameters ++Passing Reference Parameters ++Parameter Specification and Stub Generation + 4.2.3.Asynchronous RPC + 4.2.4.Example: DCE RPC +Introduction to DCE +Goals of DCE RPC +Writing a Client and a Server +Binding a Client to a Server +Performing an RPC o 4.3.MESSAGE-ORIENTED COMMUNICATION o 4.3.1.Message-Oriented Transient Communication oBerkeley Sockets oThe Message-Passing Interface (MPI) o 4.3.2.Message-Oriented Persistent Communication oMessage-Queuing Model oGeneral Architecture of a Message-Queuing System +Message Brokers +A Note on Message Queuing Systems Note on Message-Queuing Syst o 4.3.3.Example: IBM's WebSphere Message-Queuing System oOverview oChannels oMessage Transfer oManaging Overlay Networks + 4.4.STREAM-ORIENTED COMMUNICATION + 4.4.1.Support for Continuous Media +Data Stream + 4.4.2.Streams and Quality of Service +Enforcing QoS ++ 4.4.3.Stream Synchronization ++Synchronization Mechanisms ++ 4.5.MULTICAST COMMUNICATION ++ 4.5.1.Application-Level Multicasting ++Overlay Construction ++ 4.5.2.Gossip-Based Data Dissemination ++ Information Dissemination Models ++ Removing Data ++ Applications o 4.6. SUMMARY + 5. NAMING ++ 5.1. NAMES, IDENTIFIERS, AND ADDRESSES + 5.2. FLAT NAMING + 5.2.1. Simple Solutions + Broadcasting and Multicasting + Forwarding Pointers + 5.2.2. Home-Based Approaches ++ 5.2.3. Distributed Hash Tables ++ General Mechanism + Exploiting Network Proximity o 5.2.4. Hierarchical Approaches + 5.3. STRUCTURED NAMING + 5.3.1. Name Spaces o 5.3.2. Name Resolution o Closure Mechanism o Linking and Mounting o 5.3.3. The Implementation of a Name Space o Name Space Distribution o Implementation of Name Resolution ++ 5.3.4. Example: The Domain Name System ++ The DNS Name Space ++ DNS Implementation + Decentralized DNS Implementations 5.4. ATTRIBUTE-BASED NAMING + 5.4.1. Directory Services o 5.4.2. Hierarchical Implementations: LDAP + 5.4.3. Decentralized Implementations + Mapping to Distributed Hash Tables + Semantic Overlay Networks o 5.5. SUMMARY 6. SYNCHRONIZATION + 6.1. CLOCK SYNCHRONIZATION + 6.1.1. Physical Clocks ++ 6.1.2. Global Positioning System ++ 6.1.3. Clock Synchronization Algorithms ++ Network Time Protocol ++ The Berkeley Algorithm ++ Clock Synchronization in Wireless Networksque ++ 6.2.LOGICAL CLOCKS ++ 6.2.1.Lamport's Logical Clocks ++Example: Totally Ordered Multicasting + 6.2.2.Vector Clocks ++Enforcing Causal Communication +A Note on Ordered Message Delivery o 6.3.MUTUAL EXCLUSION o 6.3.1.Overview o 6.3.2.A Centralized Algorithm o 6.3.3.A Decentralized Algorithm o 6.3.4.A Distributed Algorithm o 6.3.5.A Token Ring Algorithm o 6.3.6.A Comparison of the Four Algorithms + 6.4.GLOBAL POSITIONING OF NODES o 6.5.ELECTION ALGORITHMS o 6.5.1.Traditional Election Algorithms oThe Bully Algorithm oA Ring Algorithm o 6.5.2.Elections in Wireless Environments + 6.5.3.Elections in Large-Scale Systems o 6.6.SUMMARY ++7.CONSISTENCY AND REPLICATION ++7.1.INTRODUCTION ++7.1.1.Reasons for Replication ++7127.1..Replication as Scaling Technique Replication as Scaling Techni ++7.2.DATA-CENTRIC CONSISTENCY MODELS ++7.2.1.Continuous Consistency ++The Notion of a Conit ++7.2.2.Consistent Ordering of Operations ++Sequential Consistency ++Causal Consistency ++Grouping Operations ++Consistency versus Coherence ++7.3.CLIENT-CENTRIC CONSISTENCY MODELS ++7.3.1.Eventual Consistency ++7.3.2.Monotonic Reads ++7.3.3.Monotonic Writes ++7.3.4.Read Your Writes ++7.3.5.Writes Follow Reads ++7.4.REPLICA MANAGEMENT ++7.4.1. Replica-Server Placement il ++7.4.2. Content Replication and Placement ++ Permanent Replicas ++ Server-Initiated Replicas ++ Client-Initiated Replicas ++7.4.3. Content Distribution ++ State versus Operations ++ Pull versus Push Protocols ++ Unicasting versus Multicasting ++7.5. CONSISTENCY PROTOCOLS +7.5.1. Continuous Consistency ++ Bounding Numerical Deviation + Bounding Staleness Deviations o Bounding Ordering Deviations ++7.5.2. Primary-Based Protocols ++ Remote-Write Protocols ++ Local-Write Protocols ++7.5.3. Replicated-Write Protocols ++ Active Replication ++ Quorum-Based Protocols +7.5.4. Cache-Coherence Protocols o 7.5.5. Implementing Client-Centric Consistency o A Naive Implementation o Improving Efficiency o 7.6. SUMMARY +8. FAULT TOLERANCE +8.1. INTRODUCTION TO FAULT TOLERANCE +8.1.1. Basic Concepts +8128.1.. Failure Models Fa ure Models +8.1.3. Failure Masking by Redundancy +8.2. PROCESS RESILIENCE +8.2.1. Design Issues + Flat Groups versus Hierarchical Groups + Group Membership +8.2.2. Failure Masking and Replication o 8.2.3. Agreement in Faulty Systems +8.2.4. Failure Detection +8.3. RELIABLE CLIENT-SERVER COMMUNICATION +8.3.1. Point-to-Point Communication ++8.3.2. RPC Semantics in the Presence of Failures ++ Client Cannot Locate the Server ++ Lost Request Messages ++ Server Crashes ++ Lost Reply Messages ++ Client Crashes+8.4. RELIABLE GROUP COMMUNICATION+8.4.1. Basic Reliable-Multicasting Schemes+8.4.2. Scalability in Reliable Multicasting+Nonhierarchical Feedback Control+Hierarchical Feedback Control++8.4.3. Atomic Multicast++Virtual Synchronyo Message Orderingskip Implementing Virtual Synchrony++8.5. DISTRIBUTED COMMIT++8.5.1. Two-Phase Commit++8.5.2. Three-Phase Commit+8.6. RECOVERY+8.6.1. Introductiono Stable Storage+8.6.2. Checkpointing+Independent Checkpointing+Coordinated Checkpointing+8.6.3. Message Logging+Characterizing Message-Logging Schemes+8.6.4. Recovery-Oriented Computingo8.7. SUMMARYskip9. SECURITYskip9.1. INTRODUCTION TO SECURITYskip9.1.1. Security Threats, Policies, and Mechanisms skip Example: The Globus Security Architecture skip9129.1.. Design IssuesDesign Issuesskip Focus of Controlskip Layering of Security Mechanismsskip Distribution of Security Mechanismsskip Simplicityskip9.1.3. Cryptographyskip Symmetric Cryptosystems: DESskip Public-Key Cryptosystems: RSAskip Hash Functions: MD5skip9.2. SECURE CHANNELSskip9.2.1. Authenticationskip Authentication Based on a Shared Secret Key skip Authentication Using a Key Distribution Center skip Authentication Using Public-Key Cryptography skip9.2.2. Message Integrity and Confidentialityskip Digital Signaturesskip Session Keysskip9.2.3. Secure Group Communicationskip Confidential Group Communication skip Secure Replicated Serversskip9.2.4. Example: Kerberosskip9.3. ACCESS CONTROLskip9.3.1. General Issues in Access Controlskip Access Control Matrixskip Protection Domainsskip9.3.2. Firewallsskip9.3.3. Secure Mobile Codeskip Protecting an Agentskip Protecting the Targetskip9.3.4. Denial of Serviceskip9.4. SECURITY MANAGEMENTskip9.4.1. Key Managementskip Key Establishmentskip Key Distributionskip Lifetime of Certificatesskip9.4.2. Secure Group Managementskip9.4.3. Authorization Managementskip Capabilities and Attribute Certificatesskip Delegationskip9.5. SUMMARY+10. DISTRIBUTED OBJECT-BASED DISTRIBUTED SYSTEMS o10.1. ARCHITECTUREo10.1.1. Distributed Objectso Compile-time versus Runtime Objectso Persistent and Transient Objectso101210.1.. Example:Enterprise Java BeansExample: Enterprise Java Beansskip10.1.3. Example: Globe Distributed Shared Objectsskip Object Model++10.2. PROCESSES++10.2.1. Object Servers++Alternatives for Invoking Objects++Object Adapter++10.2.2. Example: The Ice Runtime Systemo10.3. COMMUNICATIONo10.3.1. Binding a Client to an Objecto Implementation of Object Referenceso10.3.2. Static versus Dynamic Remote Method Invocationso10.3.3. Parameter Passing+10.3.4. Example: Java RMI+The Java Distributed-Object Model+Java Remote Object Invocationskip10.3.5. Object-based Messagingskip10.4. NAMINGskip10.4.1. CORBA Object Referencesskip10.4.2. Globe Object Referencesskip10.5. SYNCHRONIZATION+10.6. CONSISTENCY AND REPLICATION +10.6.1. Entry Consistencyskip Replication Frameworks+10.6.2. Replicated Invocationsskip10.7. FAULT TOLERANCEskip10.7.1. Example: Fault-Tolerant CORBAskip An Example Architectureskip10.7.2. Example: Fault-Tolerant Javaskip10.8. SECURITYskip10.8.1. Example: Globeskip Overviewskip Secure Method Invocationskip10.8.2. Security for Remote Objectsskip10.9. SUMMARYskip11. DISTRIBUTED FILE SYSTEMSskip11.1. ARCHITECTUREskip11.1.1. Client-Server Architecturesskip File System Modelskip11.1.2. Cluster-Based Distributed File Systems skip11.1.3. Symmetric Architecturesskip11.2. PROCESSESskip11.3. COMMUNICATIONskip RPCs in NFSskip The RPC2 Subsystemskip File-oriented Communication in Plan 9 skip11.4. NAMINGskip11.4.1. Naming in NFSskip File Handlesskip Automountingskip11.4.2. Constructing a Global Name space skip11.5. SYNCHRONIZATIONskip Semantics of File Sharingskip File Lockingskip Sharing Files in Codaskip11.6. CONSISTENCY AND REPLICATIONltiti d ecskip11.6.1. Client-side Cachingskip Caching in NFSskip Client-side caching in Codaskip Client-side Caching for Portable Devices skip11.6.2. Server-side Replicationskip Server Replication in Codaskip11.6.3. Replication in Peer-to-Peer File Systems skip Unstructured Peer-to-Peer Systemsskip Structured Peer-to-Peer Systemsskip11.6.4. File Replication in Grid Systemsskip11.7. FAULT TOLERANCEskip11.7.1. Handling Byzantine Failuresskip11.7.2. High Availability in Peer-to-Peer Systemsskip11.8. SECURITYskip11.8.1. Security in NFSskip Secure RPCsskip Access Controlskip11.8.2. Decentralized Authenticationskip11.8.3. Secure Peer-to-Peer File-Sharing Systems skip Secure Lookups in DHT-based Systems skip Secure Collaborative Storageo11.9. SUMMARY+12. DISTRIBUTED WEB-BASED SYSTEMS+12.1. ARCHITECTURE+12.1.1. Traditional Web-based Systems+Web Documents++Multitiered ArchitecturesMu ere Archit tureso12.1.2. Web Serviceso Web Services Fundamentalso Web Services Composition and Coordinationo12.2. PROCESSESskip12.2.1. Clients+12.2.2. The Apache Web Server+12.2.3. Web Server Clustersskip12.3. COMMUNICATIONskip12.3.1. Hypertext Transfer Protocolskip HTTP Connectionsskip HTTP Methodsskip HTTP Messagesskip12.3.2. Simple Object Access Protocolskip12.4. NAMINGskip12.5. SYNCHRONIZATION++12.6. CONSISTENCY AND REPLICATION++12.6.1. Web Proxy Caching++12.6.2. Replication for Web Hosting Systems++Metric Estimation++Adaptation Triggering++Adjustment Measures++12.6.3. Replication of Web Applicationsskip12.7. FAULT TOLERANCEskip12.8. SECURITYo12.9. SUMMARY+13. DISTRIBUTED COORDINATION-BASED SYSTEMS +13.1. INTRODUCTION TO COORDINATION MODELS+13.2. ARCHITECTURES+13.2.1. Overall Approach+13.2.2. Traditional Architectures+Example: Jini and JavaSpaces+Example: TIB/Rendezvousskip13.2.3. Peer-to-Peer Architecturesskip Example: A Gossip-based Publish/Subscribe System skip Discussionskip13.2.4. Mobility and Coordinationskip Example: Limeskip13.3. PROCESSES++13.4. COMMUNICATION++Content-based Routingskip Supporting Composite Subscriptionsskip13.5. NAMINGskip Describing Composite Eventsskip Matching Events and Subscriptionsskip13.6. SYNCHRONIZATION++13.7. CONSISTENCY AND REPLICATION++13.7.1. Static Approaches++General Considerations++13.7.2. Dynamic Replication+GSpace Overview+Adaptive Replicationskip13.8. FAULT TOLERANCEskip13.8.1. Reliable Publish-Subscribe Communication skip Example: Fault Tolerance in TIB/Rendezvous skip13.8.2. Fault Tolerance in Shared Dataspacesskip13.9. SECURITYskip13.9.1. Confidentialityskip Decoupling Publishers from Subscribersskip13.9.2. Secure Shared Dataspaceso13.10. SUMMARY。
分布式系统原理与范型
分布式系统原理与范型
分布式系统是由多个独立计算机组成的系统，它们通过网络进行通信和协作，以实现共同的任务。
分布式系统的设计和实现涉及到多种原理和范型，这些范型描述了不同方面的分布式系统行为和特征。
1. 分布式计算原理：分布式系统的核心，它描述了如何将任务分配到不同计算节点上进行并行计算。
其中最常用的原理是MapReduce，它将任务划分为多个子任务，每个节点负责处理其中的一部分，最后将结果汇总。
其他常见的分布式计算原理包括Flocking，Migrating，Scatter/Gather 等。
2. 通信原理：描述了分布式系统中不同节点之间的通信方式和协议。
常用的通信原理包括RPC（远程过程调用），消息队列，RESTful API 等。
3. 一致性原理：描述了分布式系统中不同节点之间如何保持数据一致性的方法。
常见的一致性原理包括Paxos算法，Raft算法，分布式锁等。
4. 可靠性原理：描述了分布式系统如何保障可靠性和容错性。
其中最常见的原理是副本备份，即将关键数据在多个节点上备份，以防止单点故障和数据丢失。
还有其他的可靠性原理，如容错冗余，自适应容错等。
5. 安全原理：描述了分布式系统如何保障数据的安全性和隐私性。
常见的安全原理包括身份认证，数据加密，防火墙等。
以上是分布式系统中常见的原理和范型，它们都是构建高可用、可靠、安全的分布式系统的基础。
不同原理和范型之间相互关联，它们之间的交互和协作影响着系统的整体性能和稳定性。
《分布式系统原理与范型--(第二版)》复习资料
分布式复习资料第1章分布式系统是若干独立计算机的结合，这些计算机对于用户来说就像是单个相关系统。
硬件方面：机器本身是独立的。
软件方面：对用户来说就像与单个系统打交道。
重要特性：1、各种计算机之间的差别以及计算机之间的通信方式的差别对用户是隐藏的。
2、用户和应用程序无论在何时何地都能够以一种一致和统一的方式与分布式系统进行交互。
中间件：为了使种类各异的计算机和网络都呈现为单个的系统，分布式系统常常通过一个“软件层”组织起来。
该“软件层”在逻辑上位于由用户和应用程序组成的高层与由操作系统组成的低层之间。
如图，这样的分布式系统有时又称为中间件。
注意层次分布与组件分布式系统的最主要目标是使用户能够方便地访问远程资源，并且以一种受控的方式与其他用户共享这些资源。
透明性：如果一个分布式系统能够在用户和应用程序面前呈现为单个计算机系统，这样的分布式系统就是透明的。
透明的类型：1、访问透明性：指对不同数据表示形式以及资源访问方式的隐藏。
2、位置透明性：指用户无法判别资源在系统中的物理位置。
3、并发透明性：在资源共享时，用户不会感觉到他人也在使用自己正使用的资源。
4、故障透明性：用户不会注意到某个资源(也许他从未听说过这个资源)无法正常工作，以及系统随后从故障中恢复的过程。
开放性：一个开放式的分布式系统，是根据一系列准则来提供服务，这些准则描述了所提供服务的语法和含义。
互操作性：刻画了来自不同厂商的系统或组件的两种实现能够在何种程度上共存并且协同工作，这种共存和协同工作只能依赖于通过双方在公共标准中规定的各自所提供的服务来完成。
可移植性：刻画了这样的性能，如果为分布式系统A开发了某个应用程序，并且另一个分布式系统B与A具有相同的接口，该应用程序在不做任何修改的情况下在B上执行的可行程度。
可扩展性：当一个系统需要进行扩展时，必须解决多方面的问题。
首先考虑规模上的扩展。
在需要支持更多的用户或资源时，我们常常收到集中的服务、数据以及算法所造成的限制，如图所示。
分布式系统原理与泛型
分布式系统原理与泛型一、引言随着互联网的发展和应用的深入，分布式系统成为了当今计算机领域一项重要的技术。
分布式系统是由多个独立的处理器或计算机节点组成，这些节点通过网络进行通信和协作，共同完成特定的任务。
而泛型是一种编程范式，它通过参数化类型的方式来实现代码的复用和泛化。
本文将对分布式系统原理和泛型进行详细介绍，并探讨它们之间的关系。
二、分布式系统原理1. 定义分布式系统是由多个自治的计算机节点组成，这些节点通过网络进行通信和协作，共同完成特定的任务。
分布式系统的设计目标是提高系统的可靠性、可扩展性和性能。
2. 特点（1）分布性：分布式系统的核心特点是由多个节点组成，节点之间可以独立运行，并通过网络进行通信。
（2）并发性：分布式系统的节点可以并行地执行任务，提高系统的处理能力。
（3）故障容忍性：分布式系统可以通过冗余设计和容错机制来提高系统的可靠性，即使一个节点发生故障，系统仍然可以正常工作。
（4）透明性：分布式系统可以隐藏底层的细节，使用户感觉系统是一个整体，而不用关心具体的实现细节。
3. 架构模型（1）客户端-服务器模型：客户端向服务器发出请求，服务器处理请求并返回结果。
常见的应用有Web服务器和数据库服务器。
（2）对等模型：所有节点都是对等的，可以相互通信和协作。
常见的应用有文件共享和P2P网络。
（3）集群模型：多个节点组成一个集群，在集群中共享资源，提高系统的可靠性和性能。
常见的应用有负载均衡和高可用性系统。
三、泛型1. 定义泛型是一种编程范式，它通过参数化类型的方式来实现代码的复用和泛化。
通过使用泛型，我们可以编写出更加通用和灵活的代码，提高代码的可读性和可维护性。
2. 泛型的优势（1）代码复用：通过使用泛型，我们可以编写出适用于多种类型的通用代码，避免重复编写相似的代码。
（2）类型安全：使用泛型可以在编译期间检查类型的正确性，避免在运行时出现类型错误。
（3）可读性和可维护性：泛型代码可以更加清晰和易于理解，减少了类型转换和强制转换的代码。
2023年分布式系统复习笔记
分布式系统复习笔记朱贵强(南京大学计算机科学与技术系,江苏省南京市210093)1 绪论1.1 分布式系统旳定义A distributed system is a collection of independent computers that appears to its user as a single, coherent system.（独立旳计算机旳集合，对这个系统旳顾客来说，系统就像一台计算机同样）。
1.1.1 定义包括了硬件和软件两个方面旳内容。
硬件指旳是机器自身是独立旳；软件是说对于顾客来讲就像在和单个系统打交道。
1.1.2 分布式系统旳目旳是单一性（single），不过区别于网络系统旳单一性，从功能上来说，网络系统都可以完毕，不过两者之间旳差异在于透明性。
而构造分布式系统也不仅仅是用网线连接若干台独立旳计算机。
1.2 分布式系统旳原因（why distributed）1.2.1 相对于集中系统，分布式系统旳长处1.2.2 相对于独立旳PC，分布式系统旳长处1.2.3 分布式系统旳缺陷1.3 分布式系统旳挑战（challenges，D2 P18-19）1.3.1 Heterogeneity异构性：独立旳计算机（系统）之间旳异构性，重要表目前系统、硬件、网络体系构造之间旳差异。
1.3.2 Openness开放性：通过一致旳接口实现通信和互访。
一种开放旳分布式系统根据一系列准则来提供服务，这些准则描述了所提供服务旳语法和语义。
一般接口旳语法比较轻易由IDL定义，不过语义比较难实现。
1.3.3 Security安全性：包括机密性、完整性，通过加密、访问控制、强行访问、隐蔽通道等方式实现。
1.3.4 Scalability可扩展性：通过规模、地区、管理扩展来度量，体现为服务器和网络能力有限所导致旳性能问题。
扩展技术有隐藏通信等待时间（异步通信，地区扩展合用），分布技术（把组件分割成多种部分并分散到系统中去），复制技（复制组件并把备份分布到系统各处，缓存是复制旳一种特殊形式，不过都会带来一致性旳问题）。
《分布式系统原理与范型：第2版》原书课件第1章
Scalability Problems
Figure 1-3. Examples of scalability limitations.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Transaction Processing Systems (2)
Characteristic properties of transactions: • Atomic: To the outside world, the transaction happens indivisibly. • Consistent: The transaction does not violate system invariants. • Isolated: Concurrent transactions do not interfere with each other. • Durable: Once a transaction commits, the changes are permanent.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5
Cluster Computing Systems
Definition of a Distributed System (1)
分布式系统原理与范型
分布式系统原理与范型1.并行计算：分布式系统中的计算任务可以在多个节点上并行执行，提高了计算速度和效率。
2.通信机制：分布式系统中的节点通过网络进行通信，可以使用消息传递或远程过程调用等通信机制。
3.数据一致性：分布式系统中对数据的读写操作需要保持一致性，避免数据的冲突和重复。
4.容错机制：分布式系统中的节点可能存在故障或意外断开连接的情况，需要通过容错机制来保证系统的可靠性。
5.负载均衡：分布式系统中的节点可能具有不同的计算和存储能力，需要通过负载均衡机制来平衡任务的分配。
6.安全性和隐私保护：分布式系统中的节点之间的通信需要进行安全性和隐私保护，防止数据的泄露和攻击。
1. 客户端-服务器模型：客户端向服务器发送请求并获取响应，服务器负责处理请求并返回结果。
这种模型适用于各种应用场景，如Web服务器和数据库管理系统。
2.对等网络模型：各个节点之间没有明确的客户端和服务器角色，彼此之间平等地进行通信和协调。
这种模型适用于文件共享、对等计算和点对点通信等应用场景。
3.消息传递模型：节点之间通过消息传递进行通信，消息被发送到消息队列中，由接收者主动从队列中获取并处理。
这种模型适用于异步通信和松耦合的应用场景。
4.流计算模型：数据通过流传递，节点对数据进行实时处理，结果可以通过流再次传递给其他节点。
这种模型适用于实时数据分析和流媒体处理等应用场景。
5.RPC模型：远程过程调用（RPC）模型是一种使得分布式系统中的节点能够像调用本地过程一样调用远程过程的方法。
这种模型适用于分布式计算和服务调用等应用场景。
总之，分布式系统的原理和范型为我们理解和设计分布式系统提供了重要的思路和方法。
在实际应用中，需要根据具体的场景和需求选择合适的原理和范型，并结合相关的技术和工具进行实现和优化。
分布式系统复习总结
分布式系统复习总结分布式系统复习总结1.分布式系统定义A distributed system is a collection of autonomous computing elements that appears to its users as a single coherent system.（独⽴的计算机的集合，对这个系统的⽤户来说，系统就像⼀台计算机⼀样）。
2.分布式系统的⽬标Making resource availableDistribution transparency(分布的透明性)Openness(开放性)Scalability(可扩展性)包含三个⽅⾯：Size: Number of users and/or processes(solution:强⼤的服务器)Geographical: Maximum distance between nodesAdministrative: Number of administrative domains3.为什么需要分布式4.分布式系统透明性含义分布式系统的透明性（Transparency in a Distributed System）定义：对⽤户和应⽤程序员屏蔽分布式系统组件的分散性，系统被认为是⼀个整体，⽽不是独⽴的组件集合。
透明性对⽤户和应⽤程序员隐藏了与⼿头任务⽆直接关系的资源，并匿名使⽤，使得分布的某些特性对应⽤程序员具有不可见性，这样应⽤程序员只要关⼼特定应⽤的设计问题。
(1)⽹络透明性：⽤户察觉不出是以⽹络的⽅式⼯作，所有的⼯作对象是在单台机器上完成。
(2)操作系统透明性：使⽤不同操作系统的机器和⽤户可以⾃由的协同⼯作，不同操作系统带来的不同被掩盖。
(3)语⾔透明性：使⽤不同语⾔编写的程序或者模块能够⾃由交互⼯作，相互调⽤。
(4)数据复制与分⽚透明性：分⽚的数据像未分⽚的数据⼀样⼯作，修改数据时复制在多处的数据⾃动更新。
分布式系统 入门书 -回复
分布式系统入门书-回复分布式系统入门书指的是那些旨在向读者介绍分布式系统基本原理和应用的书籍。
分布式系统是一种由多个独立计算机组成的网络系统，这些计算机通过通信网络进行协作，共同完成一组任务。
在这篇文章中，我们将一步一步地回答有关分布式系统入门书的问题，以帮助读者更好地了解和学习分布式系统。
第一步：为什么要学习分布式系统？分布式系统已经成为当今计算领域的热门话题。
与传统的集中式系统相比，分布式系统具有更高的可靠性、可扩展性和性能。
在面对大规模数据处理、云计算、物联网等领域的挑战时，分布式系统的知识和技能变得尤为重要。
学习分布式系统可以让人们更好地理解和应对这些挑战，为未来的职业发展提供更广阔的机会。
第二步：如何选择合适的入门书？在选择合适的分布式系统入门书时，我们可以考虑以下几个因素：1. 内容覆盖范围：好的入门书应该全面介绍分布式系统的基本原理、架构和技术，以及分布式系统中常见的问题和挑战。
2. 语言和风格：入门书的语言和风格应该简洁易懂，尽量避免过于专业的术语和复杂的数学推导。
3. 实践案例和示例：入门书中应该包含实际的案例和示例，以帮助读者更好地理解和应用所学知识。
4. 作者资质和口碑：选择那些有经验和口碑良好的作者撰写的书籍，可以提高学习效果和可信度。
第三步：常见的分布式系统入门书推荐以下是一些常见的分布式系统入门书的推荐，供读者参考：1.《分布式系统原理与范型》（Distributed Systems: Principles and Paradigms）：该书由安德鲁·塔能鲍姆（Andrew S. Tanenbaum）、玛亚尔·范·斯泰恩（Maarten van Steen）合著，深入介绍了分布式系统的基本原理和常见问题。
书中还包含了一些示例和实践案例，适合作为分布式系统入门的首选。
2.《大规模分布式系统设计》（Designing Distributed Systems）：该书由布伯格（Brendan Burns）撰写，重点介绍了如何设计和实现大规模分布式系统。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
分布式复习资料第1章分布式系统是若干独立计算机的结合，这些计算机对于用户来说就像是单个相关系统。
硬件方面：机器本身是独立的。
软件方面：对用户来说就像与单个系统打交道。
重要特性：1、各种计算机之间的差别以及计算机之间的通信方式的差别对用户是隐藏的。
2、用户和应用程序无论在何时何地都能够以一种一致和统一的方式与分布式系统进行交互。
中间件：为了使种类各异的计算机和网络都呈现为单个的系统，分布式系统常常通过一个“软件层”组织起来。
该“软件层”在逻辑上位于由用户和应用程序组成的高层与由操作系统组成的低层之间。
如图，这样的分布式系统有时又称为中间件。
注意层次分布与组件分布式系统的最主要目标是使用户能够方便地访问远程资源，并且以一种受控的方式与其他用户共享这些资源。
透明性：如果一个分布式系统能够在用户和应用程序面前呈现为单个计算机系统，这样的分布式系统就是透明的。
透明的类型：1、访问透明性：指对不同数据表示形式以及资源访问方式的隐藏。
2、位置透明性：指用户无法判别资源在系统中的物理位置。
3、并发透明性：在资源共享时，用户不会感觉到他人也在使用自己正使用的资源。
4、故障透明性：用户不会注意到某个资源(也许他从未听说过这个资源)无法正常工作，以及系统随后从故障中恢复的过程。
开放性：一个开放式的分布式系统，是根据一系列准则来提供服务，这些准则描述了所提供服务的语法和含义。
互操作性：刻画了来自不同厂商的系统或组件的两种实现能够在何种程度上共存并且协同工作，这种共存和协同工作只能依赖于通过双方在公共标准中规定的各自所提供的服务来完成。
可移植性：刻画了这样的性能，如果为分布式系统A开发了某个应用程序，并且另一个分布式系统B与A具有相同的接口，该应用程序在不做任何修改的情况下在B上执行的可行程度。
可扩展性：当一个系统需要进行扩展时，必须解决多方面的问题。
首先考虑规模上的扩展。
在需要支持更多的用户或资源时，我们常常收到集中的服务、数据以及算法所造成的限制，如图所示。
例如，许多服务是以集中的方式实现的，它们由分布式系统中一台特定的计算机上运行的单个服务来提供。
这种方案存在的问题是显而易见的：用户增多时该服务将成为系统的瓶颈。
即使它拥有无限的处理能力和存储能力，在系统达到一定规模后与该服务器的通信也将发生困难。
从而使得系统规模无法继续增长。
扩展技术：1、隐藏通信等待时间对于地域扩展是比较适用的。
基本想法：尽量避免等待远程服务对请求的响应。
例如，当对远程计算机的某个服务发出请求时，在发出请求端，除了等待服务器响应之外，还可以利用这段时间做其他工作。
本质上，以这种方式构建的应用程序使用的异步通信。
当响应到来时，应用程序产生中断，并且调用专门的处理程序对前面发出的请求进行处理。
2、分布技术分布技术把某个组件分割成多个部分，然后再将它们分散到系统中区。
3、缓存缓存是复制的一种特殊形式。
与复制相同，缓存一般是在访问资源的客户附近制作该资源的副本。
然而，与复制不同的是，是否进行缓存是由要访问资源的客户决定的，而不是由资源拥有者决定的。
缓存和复制都存在严重的缺点，这些缺点可能会对可扩展性造成不良影响。
进行缓存或者复制以后，由于资源存在多个副本，修改其中的一个会导致它与其他副本不相同，从而导致一致性方面的问题。
集群计算：底层硬件是由类似的工作站或PC集组成，通过高速的局域网紧密连接起来。
而且，每个节点运行的都是相同的操作系统。
网格计算：组成分布式系统的这种子分组通常构建成一个计算机系统联盟，其中的每个系统归属于不同的管理域，而且在硬件、软件和部署网格技术上也差别很大。
光纤层：在特定站点提供对局部资源的接口。
这些接口都进行了定制，以允许在某个虚拟组织中实现资源共享。
连接层：由通信协议组成，用于支持网格事务处理，延伸多个资源的使用。
例如，用于在资源之间传输数据或从远程地点访问资源的协议。
另外，连接层还有安全协议，用于进行用户和资源的认证。
线层可用的接口。
汇集层：负责处理对多个资源的访问，通常由资源分派、把任务分配和调度到多资源以及数据复制等服务组成。
连接层和资源层由相对较小、较标准的协议集组成，而汇集层由很多用于不同目的的不同协议组成。
应用层：由应用程序组成。
第2章体系结构样式：1、分层体系结构2、基于对象的体系结构3、以数据为中心的体系机构4、基于事件的体系结构客户—服务器模型分为三层：1)用户接口层2)处理层3)数据层多层体系结构点对点体系结构：在结构化的点对点体系机构中，覆盖网络是一个确定性的过程来构成的。
这个使用最多的进程是超级对等体：能维护一个索引或者充当一个代理程序的结点。
控制管理多个常规对等体。
边界服务器系统这种系统部署在因特网中，服务器放置在网络的“边界”。
这种边界是由企业网络和实际的因特网之间的分界线形成的。
协作分布式系统混合结构主要部署在协作式分布式系统中。
在很多重要的系统中，主要问题是先启动起来，因为经常会部署一个传递的客户-服务器结构。
一旦某个结点要加入系统，就可以使用完全非集中式的组织结构，用于协作。
自治计算：以高级反馈控制系统的形式来组织分布式系统，允许自动自适应变换。
也叫做自主系统。
自适应的多样性：自我管理、自我恢复、自我配置、自我优化等。
反馈控制模型反馈控制系统的核心由需要管理的组件形成。
这些组件能通过可控输入参数驱动，受干扰或噪声输入的影响。
系统本身需要被监视，因此需要对系统各个方面进行测量。
但是实际测量很难做到，就需要一个逻辑尺度预测组件。
控制循环的核心部分是反馈分析组件，分析上述测量值，并把它们与参考值进行比较。
包含了决定自适应的各种算法。
第三章线程为什么要使用线程？虽然进程构成了分布式系统中的基本组成单元，但是实践表明，操作系统提供的用于构建分布式系统的进程在粒度上还是太大了。
而就粒度而言，将每个进程细分为若干控制线程的形式则更加合适，可以使构建分布式应用程序变得更加方便，获得更好的性能。
进程间通信机制IPCIPC需要内核干预。
从用户模式切换到内核模式S1，在内核中进行上下文切换S2，再从内核模式切换到用户模式S3。
完成进程之间的切换。
多线程客户隐藏通信时间延迟的常规方法是启动通信后立即进行其他工作。
例子：Web浏览器。
Web浏览器一般在开始获取HTML页面后随即就显示它。
为了尽量隐藏通信时间延迟，某些浏览器在接收数据的过程中就开始显示这些数据。
首先将文本显示出来，并提供页面滚动之类的功能，同时获取组成页面的其他文件，比如图像等。
用户不必等待浏览器取得整个页面的所有组件就能够查看页面。
从效果来看，web浏览器好像在同时进行多任务一样。
只要取得了主HTML文件，就可以激活多个独立的线程，它们分别负责取得页面的各个部分。
每个线程都与服务器建立一个独立连接以获取数据。
多线程服务器虚拟化计算机界面1)由机器指令组成，可由任何程序激起的硬件软件界面。
2)由机器指令组成，只有特权程序(如OS)才可激活的。
3)由操作系统提供的系统调用组成的界面。
4)由库调用组成的界面，通常形成了所谓的应用程序编程结构(API)。
很多情况下前述的系统调用由API隐藏。
虚拟化的实质是模仿这些界面的行为。
虚拟化可采用两种方式。
第一种：可以构建一个运行时系统，实质上提供一套抽象指令集来执行程序。
指令可以被翻译执行，也可以仿真执行，就像在Unix平台上运行Windows应用程序。
第二种：提供一种系统。
把它做成一层完全屏蔽硬件但是提供一个同样指令集(或其他硬件)的界面。
这个界面可以同时提供给不同的程序。
可以有多个不同的操作系统独立并发地运行在同一平台。
客户端软件与分布透明性客户端通过将调用请求转发给每一个服务器的副本来达到复制透明性。
服务器组织结构：1)迭代服务器：自己处理请求，并且在必要的情况下将响应返回给发出请求的客户。
3)状态无关服务器：不保存其客户的状态信息，而且也不将自身的状态变化告知任何客户。
如Web服务器，仅仅对输入的HTTP请求做出响应，在处理请求的时候，彻底忽略用户的存在。
软状态：有一种特别的状态无关设计是服务器维护软状态的信息。
服务器仅维护一小段时间的客户状态。
时间到期后就删除相关客户信息，到无状态行为。
4)状态相关服务器：一直保存客户端的信息直到显式地删除。
如文件服务器，它让客户保留文本的本地副本，甚至进行更新操作。
端口：客户总是向服务器所在机器上的端点发送请求，这种端点就是端口。
a)有许多服务不需要预先分配好端点。
比如，一个时间服务器可能会使用由本地操作系统动态分配给它的端点。
在这种情况下，客户首先必须查询到该端点号。
一种解办法在运行服务器的每一台机器上都运行一个特殊的守护程序，该守护程序负责跟踪位于同一台机器上的服务器实现的每一项服务所使用的当前端点。
守护程序还监听一个已知的端口。
客户通过这个端口与该守护程序进行联系，请求得到指定服务器的端点号，随后再与该服务器进行联系。
b)与其对这么多被动进程进行跟踪，不如由一个超级服务器来负责监听所有与这些服务关联的端点。
当收到请求时候，派生出一个进程以对该请求进行进一步处理，这个派生出的进程在处理完毕后自动退出运行。
中断服务器工作：处理通信中断的更好方法是在开发客户程序和服务器程序的时候考虑到对带外数据发送的支持。
带外数据是服务器在处理客户发送的其他所有数据之前必须处理的数据。
一种办法是让客户将带外数据发送到一个另外的控制端点，服务器则监听该端点，同时也监听常规数据传输的端点。
另一种方法是通过发送原始请求所使用的连接来发送带外数据。
TCP转发原理：当交换机接收到一个TCP连接请求时，找到处理这个请求的最佳服务器，把请求包转发给这个服务器。
服务器反过来发送一个响应给客户，同时把交换机的IP地址也放入数据段。
第四章通信OSI模型是用来支持开放式系统间通信的。
开放式系统通过一系列标准规则来与其他开放式系统通信的系统。
每一层都规定了与上一层的接口。
接口中包括一组操作，定义向用户提供的服务。
面向连接的协议：消息发送方和接收方必须首先显式地确立连接，可能还需要就采用的协议进行协商，然后才能进行数据交换。
在通信完毕后，必须终止连接。
如电话系统。
无连接的协议：交换数据之前不需要有建立连接的过程，消息发送方只需要在准备好的时候传送第一个消息即可。
如将信件投入邮箱。
如果机器1上的进程A想传消息给机器2上的进程B。
那么消息先到机器1上的应用层，依次向下传递，每传递一层，就在消息前增加一个报头。
第n层添加的报头中的信息是供第n层协议使用的。
某些层还要增加报尾。
物理层只负责传输位，而数据链路层是负责检查传输是否出错。
数据链路层在每一帧的开头和结尾分别放置特殊的位来对头尾进行标记，并用某种方法将帧中的所有字节相加，计算出校验和。
再将校验和放入帧中。
当接收到消息后，接收方重新计算校验和，跟原有进行比较。